* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Hm. That might happen to work for Kerberos, but it won't work for
> GSSAPI or SSPI --- in both those code paths we just push the host name
> literally into a constructed principal string. Not sure if we really
> want Kerberos to work differently from the more modern alternatives.
I'm not looking at the code right now, but I just don't see how this can
be the case, at least for GSSAPI. I routinely use both krb5 and GSSAPI
auth types (depending on which server I'm using) with values passed to
-h that certainly aren't the FQDN of the host, and it works just fine.
I can't imagine we're doing some magic here ourselves and then passing
the right FQDN to the Kerberos/GSSAPI libraries.
Typical usage, all of them work:
vardamir/8.2:
psql -h 172.18.148.10 -d gis
psql -h vardamir -d gis
psql -h vardamir.tsf.noblis.org -d gis
beren/8.3:
psql -h beren -d gis
psql -h 172.18.148.12
beren/8.4:
psql --cluster 8.4/main -h beren -d gis
psql --cluster 8.4/main -h 172.18.148.12
psql --cluster 8.4/main -h beren.nicc.noblis.org -d gis
beren:/home/sfrost> hostname --fqdn
beren.tsf.noblis.org
I always get a postgres/beren.tsf.noblis.org@TSF.NOBLIS.ORG ticket, for
that server, since that's what the rDNS is, and that's what's in the KDC
(it hasn't got entries for any of the others).
In any case, let's please make sure not to break that. :)
Thanks!
Stephen