Re: BUG #4932: Upgrade 8.2.13 -> 8.4.0 - Kerberos option missing

The following bug has been logged online:

Bug reference: 4932
Logged by: Peter Much
Email address: pmc(at)citylink(dot)dinoex(dot)sub(dot)org
PostgreSQL version: 8.4.0
Operating system: FreeBSD 7.2
Description: Upgrade 8.2.13 -> 8.4.0 - Kerberos option missing
Details:

In chapter 19.3.5 of the manual an option "krb_server_hostname" is
mentioned.
This option was present in 8.2 but is no longer present in 8.4.0
So at least we have a documentation bug here.

I was using this option.
According to my notices, the problem is that (since about 7.4) psql (or the
client lib) uses the network-interface-name to build the K5 principal name,
while postgres (the server) uses the local hostname. So this works fine as
long as hostname == interface-name; and otherwise one should set the
hostname to the interface-name in postgresql.conf with the beforementioned
option.

I found another solution in absence of that option: I can rename the
principal in the keytab file with K5 tools and so change this name to the
hostname.

Without trying to dig deeper, I am thinking what would happen if the server
listens on more than one interface. Wouldnt we need more than one principal
then? And how would we configure these on the server side if only one name
is used?

But the essential point seems to me the following: section 19.3.5 of the
manual reads "hostname is the fully qualified host name of the server
machine."

But _there_is_no_such_thing_ as a "fully qualified hostname"!
There are only _fully_qualified_interface-names_, and any host can have
*many* of these. The hostname itself is nothing else than an arbitrary label
for the machine, and it should never be used by networking software.

rgds,
PMc

On Wed, Jul 22, 2009 at 11:42, Peter Much<pmc(at)citylink(dot)dinoex(dot)sub(dot)org> wrote:
>
> The following bug has been logged online:
>
> Bug reference:      4932
> Logged by:          Peter Much
> Email address:      pmc(at)citylink(dot)dinoex(dot)sub(dot)org
> PostgreSQL version: 8.4.0
> Operating system:   FreeBSD 7.2
> Description:        Upgrade 8.2.13 -> 8.4.0 - Kerberos option missing
> Details:
>
> In chapter 19.3.5 of the manual an option "krb_server_hostname" is
> mentioned.
> This option was present in 8.2 but is no longer present in 8.4.0

It is present, only it has now been moved to pg_hba.conf. It is no
longer in postgresql.conf. My guess is that you tried it configured
the same way as in previous versions, where there was a global
parameter in postgresql.conf?

> So at least we have a documentation bug here.

That page lists settings for pg_hba.conf, so I believe it is correct.
However, suggestions for improvements are always welcome :-)

> But the essential point seems to me the following: section 19.3.5 of the
> manual reads "hostname is the fully qualified host name of the server
> machine."
>
> But _there_is_no_such_thing_ as a "fully qualified hostname"!
> There are only _fully_qualified_interface-names_, and any host can have
> *many* of these. The hostname itself is nothing else than an arbitrary label
> for the machine, and it should never be used by networking software.

In a very large part of the cases, the fully qualified hostname will
be the same as the fully qualified interface name for the only
interface that's configured.

Anyway, the whole reason for moving the krb_server_hostname parameter
into pg_hba.conf is to make it *more* flexible to configure situations
like this.

--
Magnus Hagander
Self: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

Dear Magnus!

On Wed, Jul 22, 2009 at 11:52:32AM +0200, Magnus Hagander wrote:
! On Wed, Jul 22, 2009 at 11:42, Peter Much<pmc(at)citylink(dot)dinoex(dot)sub(dot)org> wrote:

! > In chapter 19.3.5 of the manual an option "krb_server_hostname" is
! > mentioned.
! > This option was present in 8.2 but is no longer present in 8.4.0
!
! It is present, only it has now been moved to pg_hba.conf. It is no
! longer in postgresql.conf. My guess is that you tried it configured
! the same way as in previous versions, where there was a global
! parameter in postgresql.conf?

Nearly. I merged my old and new config, noticed the option was gone,
tried it nevertheless and got an error, tried again without it and
obviousely logins did not work.

I confess that I did not carefully study new HBA features - but even
if I had, I am not quite sure if I would have gotten that point at
once.

Now understanding it, I bow in respect - this is indeed a fine
improvement!

! > But _there_is_no_such_thing_ as a "fully qualified hostname"!

! In a very large part of the cases, the fully qualified hostname will
! be the same as the fully qualified interface name for the only
! interface that's configured.

Alright, frankly and just out of band of the topic, let me say
one thing: I am installing systems for the big commercial vendors
for more than a decade now, and this matter was an ongoing annoyance
all of the time.
While at first glance it may be considered just a matter of
convenience, the real trouble starts as soon as one does
high-availability solutions; these will definitely break on such
an assumption, and we end up with patching the hostname on takeover:
so having no functional mailer, unintellegible logfiles, not knowing
for sure on which hardware we admins are logged in, and similar
ugliness more.
Here I am talking about the commercial middleware vendors, who
are really stubborn in this matter - in the OpenSource the situation
is already a thousand times better!

! Anyway, the whole reason for moving the krb_server_hostname parameter
! into pg_hba.conf is to make it *more* flexible to configure situations
! like this.

Indeed, I agree with You, and I am very happy. :)

rgds,
PMc

On Wed, Jul 22, 2009 at 17:29, Peter Much<pmc(at)citylink(dot)dinoex(dot)sub(dot)org> wrote:
> On Wed, Jul 22, 2009 at 11:52:32AM +0200, Magnus Hagander wrote:
> ! On Wed, Jul 22, 2009 at 11:42, Peter Much<pmc(at)citylink(dot)dinoex(dot)sub(dot)org> wrote:
>
> Now understanding it, I bow in respect - this is indeed a fine
> improvement!

Thanks :-)

> ! > But _there_is_no_such_thing_ as a "fully qualified hostname"!
>
> ! In a very large part of the cases, the fully qualified hostname will
> ! be the same as the fully qualified interface name for the only
> ! interface that's configured.
>
> Alright, frankly and just out of band of the topic, let me say
> one thing: I am installing systems for the big commercial vendors
> for more than a decade now, and this matter was an ongoing annoyance
> all of the time.
> While at first glance it may be considered just a matter of
> convenience, the real trouble starts as soon as one does
> high-availability solutions; these will definitely break on such
> an assumption, and we end up with patching the hostname on takeover:
> so having no functional mailer, unintellegible logfiles, not knowing
> for sure on which hardware we admins are logged in, and similar
> ugliness more.
> Here I am talking about the commercial middleware vendors, who
> are really stubborn in this matter - in the OpenSource the situation
> is already a thousand times better!

If you have any suggestions for improvements on either the
documentation on the feature itself from someone who's deploying them
"for real customers", that's always interesting.

--
Magnus Hagander
Self: http://www.hagander.net/
Work: http://www.redpill-linpro.com/