How can I tell if postgres has kerberos installed? [closed] - postgresql

Question

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I am trying to configure postgres (8.4.13) to work with Kerberos. I cannot seem to get it work. The one "gotcha" I keep reading about is that postgres must be built with kerberos support. Well, the postgres I have is an rpm downloaded from the internet. How I can tell if this postgres was built with Kerberos support or not? Is there a way to list "installed components? Thanks!!!

Answer 1

pg_config might be helpful, e.g.:
pg_config --configure

Answer 2

Some binaries have command like options which will allow you to see how they were compiled. I'm not sure if postgres will do that. You can use --version (but this is generally very minimalistic) and --describe-config which will dump values like:
Security and Authentication STRING FILE:/usr/local/etc/postgresql/krb5.keytab
Sets the location of the Kerberos server key file
if kerberos capabilites are configured for the postgresql installation.
As well many packaging systems have methods for capturing compile time options that were passed to the build process (FreeBSD's pkg info -f for example does this). It's been a while since I have used rpm and newer versions may have methods for this sort of query directly on the binary. On rpm based systems I have administered I would keep the src.rpm and .spec files on hand in a local repository for each installed application. This was in order to comply with out in house "policies" :-) and to track the configure and OPTFLAGS settings, source code used in the build, etc.
Here is a response to a similar question:
https://serverfault.com/questions/36037/how-can-i-find-what-options-an-rpm-was-compiled-with
A generic UNIX method for seeing which libraries a binary is linked against is to use "ldd" like this:
$~/ ldd /usr/local/bin/postgres
/usr/local/bin/postgres:
libgssapi.so.3 => /usr/local/lib/libgssapi.so.3 (0x800a38000)
libxml2.so.5 => /usr/local/lib/libxml2.so.5 (0x800b74000)
libpam.so.5 => /usr/lib/libpam.so.5 (0x800dc4000)
libssl.so.6 => /usr/lib/libssl.so.6 (0x800ecc000)
libcrypto.so.6 => /lib/libcrypto.so.6 (0x80101f000)
libm.so.5 => /lib/libm.so.5 (0x8012bf000)
libc.so.7 => /lib/libc.so.7 (0x8013df000)
libintl.so.9 => /usr/local/lib/libintl.so.9 (0x801621000)
libheimntlm.so.1 => /usr/local/lib/libheimntlm.so.1 (0x80172a000)
libkrb5.so.26 => /usr/local/lib/libkrb5.so.26 (0x801830000)
libheimbase.so.1 => /usr/local/lib/libheimbase.so.1 (0x8019ad000)
libhx509.so.5 => /usr/local/lib/libhx509.so.5 (0x801ab1000)
libwind.so.0 => /usr/local/lib/libwind.so.0 (0x801bf9000)
libsqlite3.so.8 => /usr/local/lib/libsqlite3.so.8 (0x801d21000)
libasn1.so.8 => /usr/local/lib/libasn1.so.8 (0x801ec3000)
libcom_err.so.2 => /usr/local/lib/libcom_err.so.2 (0x802058000)
libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x80215b000)
libroken.so.19 => /usr/local/lib/libroken.so.19 (0x802358000)
libcrypt.so.5 => /lib/libcrypt.so.5 (0x802469000)
libthr.so.3 => /lib/libthr.so.3 (0x802589000)
libz.so.5 => /lib/libz.so.5 (0x8026a2000)
As you can see on my system the postgresql binary is linked against libkrb5.so.26, libgssapi.so.3, libheimntlm.so.1 etc. (these are Heimdal Kerberos libraries).
[EDIT: I still think Milen's response is most likely the best, most thorough and recommended approach BUT one caveat I ran into just today: on most of my systems (most of these are FreeBSD) pg_config appears to be installed with the postgresql-client pkg and so can potentially have different options set than what is selected when the postgresql-server is built. I tend to build lots of functionality into the clients so they can connect to a range of servers which are often running on different machines. The package with the client command line shell and libraries (postgresql-devel in most RPM-based or Linux systems) is what give capabilities to database modules and libraries for python, perl, etc. that connect to your DB server. The client libraries often reside on a separate host when you have a web application that is grabbing and storing data (CRUD) in a database back end. That said, most likely binary client/server/devel packages are built with the same options set ;-)
Anyway, just another data point ... cheers.]
Hope that helps.
Cheers,