On Fri, Jan 17, 2014 at 11:00 PM, Murthy Nunna <mnunna@fnal.gov> wrote:
Hello PG Admins,
I am new to postgres and also to the list. I am glad I found this domain list for help.
I am setting up streaming replication using Virtaul IP.
Server1 is primary which has its own server IP address
Server2 is standby which has its own server IP address
We created a virtual IP (say pgvip) which is different from server IPs. This IP will move between server1 and server2 to help provide application transparency. Application uses “pgvip”, so when the standby is converted to serve as primary, we move the virtual IP from server1 to server2 and simply bring up the application with no changes. That is the idea.
Everything works fine EXCEPT Kerberos client authentication. We put both server key (postgres/server1@fnal.gov) and VIP key (postgres/pgvip@fnal.gov) in the keytab but it still doesn’t work. When I specify physical hostname in the connect string of the client, Kerberos is able to authenticate. But when “pgvip” is used it fails.
Following is what I have in my postgresql.conf:
krb_server_keyfile = '/home/postgres/krb5/keytab'
krb_srvname = 'postgres’
I also tried krb_server_hostname in pg_hba file as below. It didn’t work either. May be this is supposed to work but it may be wrong syntactically.
host all mnunna 0.0.0.0/0 krb5 krb_server_hostname='minos-ecl-pgvip'
Please help. Is what we are trying supported in postgres? If so, please help me point in the right direction.
First of all, note that krb5 has been deprecated for several releases now, and you should probably be using "gss". That will use Kerberos "under the hood", but do so using a standard protocol.
Second - Kerberos is notoriously sensitive to DNS setups. Make sure you have both forward and reverse lookups working correctly for the VIP address. I've also generally seen better results if you use the FQDN of the hosts - both when accessing them and of course in they keys.
I would remove the server key from the keytab - it's supposed to pick it automatically, but I've seen issues sometimes with some kerberos libraries where it hasn't worked.
(The last two points are generic Kerberos points and not directly about PostgreSQL of course)