Thread: Kerberos patch in the queue

Hi!

I'd like to vote in favor of this patch:
http://candle.pha.pa.us/mhonarc/patches2/msg00025.html.

I know Tom said he didn't really like it, but I'd ask you to reconsider
that.

My use would be mainly for my integrate-with-active-directory project.
AD requires uppercase principal names, which maens POSTGRES instead of
postgres. If I could change this at runtime, that would certainly make
my life a *lot* easier.  I'm sure it helps in several other cases as
well.

(I haven't looked at the actual patch, just at the end result of it)

//Magnus

"Magnus Hagander" <mha@sollentuna.net> writes:
> I'd like to vote in favor of this patch:
> http://candle.pha.pa.us/mhonarc/patches2/msg00025.html.

> I know Tom said he didn't really like it, but I'd ask you to reconsider
> that. 

The patch is unacceptable as is because (a) it adds a libpq
configuration parameter that acts differently from all the other ones
(not supported in connect strings for instance) and (b) it adds no
documentation for that variable, nor for the server-side variable it
adds.  Doing the libpq parameter in a more thorough fashion is just a
matter of programming-by-example (grep for CONNECT_TIMEOUT for an
example) but I for one don't know enough about Kerberos to document
the thing.
        regards, tom lane

>> I'd like to vote in favor of this patch:
>> http://candle.pha.pa.us/mhonarc/patches2/msg00025.html.
>
>> I know Tom said he didn't really like it, but I'd ask you to
>reconsider
>> that.
>
>The patch is unacceptable as is because (a) it adds a libpq
>configuration parameter that acts differently from all the other ones
>(not supported in connect strings for instance) and (b) it adds no
>documentation for that variable, nor for the server-side variable it
>adds.  Doing the libpq parameter in a more thorough fashion is just a
>matter of programming-by-example (grep for CONNECT_TIMEOUT for an
>example) but I for one don't know enough about Kerberos to document
>the thing.

Daniel asked about (a) - I'm not sure if he received an answer, I
couldn't find one at least.
(http://candle.pha.pa.us/mhonarc/patches2/msg00024.html has the question
and some more comments from him). And he offered to write up docs.

Daniel, still up for doing this? If not, I can try to update the patch
to address Toms concerns.

Tom, assuming we fix this, are you fine with the concept? The discussion
back then mentioned the "another way to fail the connection". I think
the gain far overweighs the pain, but it'd be nice to have that
confirmed before more work is committed.

//Magnus

"Magnus Hagander" <mha@sollentuna.net> writes:
> Tom, assuming we fix this, are you fine with the concept?

Mostly.  Should the --with-krb-srvnam configure parameter go away?
Or is it now seen as establishing an installation default?  (Either
way implies some documentation work.)
        regards, tom lane

>> Tom, assuming we fix this, are you fine with the concept?
>
>Mostly.  Should the --with-krb-srvnam configure parameter go away?
>Or is it now seen as establishing an installation default?  (Either
>way implies some documentation work.)

The original way kept it in there to establish an installation default.
I think that is a good idea (yes, it certainly has to be documented) to
keep it as such, and just allow it to be overridden (the same way you
can use --with-pgport to change the default port, but you can still
override it in postgresql.conf).

//Magnus