[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: errant SASL/GSSAPI setup?
>>>>> "quanah" == Quanah Gibson-Mount <quanah@stanford.edu> writes:
quanah> --On Wednesday, August 30, 2006 10:19 AM -0400 "Allan E. Johannesen"
quanah> <aej@WPI.EDU> wrote:
>> I've been using rootdn passwords over TLS with slurpd and since switching to
>> syncrepl. Seeing a posting by Quanah Gibson-Mount <quanah@stanford.edu>
>> some weeks ago about k5start and KRB5CCNAME, I was inspired to try to make
>> the switch.
>>
>> I grabbed kstart-3.5 and installed it and installed a sasl-regexp in the
>> LDAP master:
>> So far, everything looks good. An update went through and the ldap ticket
>> was established. However, after the ticket expires, a subsequent update
>> does not take place and a new ldap ticket isn't obtained.
quanah> I'd take a look at why you haven't set up kstart to continually refresh
quanah> the ticket, so that it never expires... That's part of the point of
quanah> using it.
Thanks for looking into the problem.
The ticket DOES refresh. In your example below, you have a 10 hour life and a
30 minute refresh. I'd used 10 hours and an 8 hour refresh, but I found that
the updates stopped happening at the intial ticket expiration, even though
there was a current ticket in place. Is there a reason to refresh a long-life
ticket so often?
In my example, though, I had a 5 minute life with a 4 minute refresh. I wanted
to create an example which would show the problem in a shorter time.
This was my start:
# k5start -f /var/openldap-manager -k /tmp/ldap-manager.slapd.tkt -K 4 -l 5m -U -b
As opposed to your daemontools thing, which I recognize is another way to run
this, the command above continues running in the background (-b) for the
duration of the test. I know it is running, since the ticket is renewing.
This was my klist output, which I should have included in my email:
# klist
Ticket cache: FILE:/tmp/ldap-manager.slapd.tkt
Default principal: ldap-manager/seethe.wpi.edu@WPI.EDU
Valid starting Expires Service principal
08/30/06 09:21:07 08/30/06 09:26:07 krbtgt/WPI.EDU@WPI.EDU
08/30/06 09:21:38 08/30/06 09:26:07 ldap/utility5.wpi.edu@WPI.EDU
# date
Wed Aug 30 09:22:56 EDT 2006
The above was the initial ticket, with the ldap service principal from the
master due to the successful syncrepl update.
... waiting a while ...
# klist
Ticket cache: FILE:/tmp/ldap-manager.slapd.tkt
Default principal: ldap-manager/seethe.wpi.edu@WPI.EDU
Valid starting Expires Service principal
08/30/06 09:29:07 08/30/06 09:34:07 krbtgt/WPI.EDU@WPI.EDU
I did the klist to be sure the updated ticket was in place. The ldap/ ticket
wasn't updated, though, since that is negotiated with the master and the old
one had expired. A new one doesn't seem to appear over time as that renewal
happened.
I made a principal named ldap-manager for each slave and it is that pricipal's
ticket that I was updating with k5start. Maybe I'm just befuddled as to which
principal's ticket to update.
quanah> See daemontools. Here is the ticket I use with daemontools to
quanah> continually keep the K5 ticket active.
quanah> #!/bin/sh # /service/k5start/run -- Run kstart to maintain our ticket
quanah> for LDAP binds. # $Id: run,v 1.2 2006/08/03 20:02:07 quanah Exp $
quanah> HOSTNAME=`hostname`
quanah> exec /usr/bin/k5start -u ldap -i $HOSTNAME -r stanford.edu \ -f
quanah> /etc/krb5.keytab -k /var/run/ldap_syncreplica.tkt -l 10h -K 30
quanah> --Quanah
quanah> -- Quanah Gibson-Mount Principal Software Developer ITS/Shared
quanah> Application Services Stanford University GnuPG Public Key:
quanah> http://www.stanford.edu/~quanah/pgp.html