Re: errant SASL/GSSAPI setup?

["Allan E. Johannesen" <aej@WPI.EDU>]

>>>>> "quanah" == Quanah Gibson-Mount <quanah@stanford.edu> writes:

quanah> The reason things still work between (d) & (e) is because the
quanah> connection is *persistent*.  The ldap/* bit for the master is only
quanah> necessary for establishing the initial connection.  That is why
quanah> replication continues to work on my ldap slaves even though they don't
quanah> have an ldap/* principal in their ticket cache any more:

Ok.  I did a run with -d-1 on master and slave.  This is the relavent stuff
from the LDAP master:

SASL [conn=1] Failure: GSSAPI Error: The context has expired (No error)
sb_sasl_write: failed to encode packet: generic failure
ldap_write: want=11176 error=Input/output error
ber_flush failed errno=5 reason="Input/output error"
connection_closing: readying conn=1 sd=13 for close

I see this after an update after the refresh of the ticket on the slave.

sd=13 may be the replica, since there is this connection in the master log:

conn=1 fd=13 ACCEPT from IP=130.215.36.26:58607 (IP=0.0.0.0:389)

where the IP is the slave.  I guess that's assuming fd=13 and sd=13 are
related.

I guess the error/close explains why no further updates propagate.

Assuming the thing closed, though, I would have expected something to show in
the slave's -d-1 log, which doesn't happen.  You'd think if it knew the master
disconnected that it would try to connect again and things would work...


Is the requirement that the client use the server key?  I guess that way the
server doesn't see expiry.  It may also mean that refreshing the key remotely
is irrelavent...

As you suggest the connection is *persistent*.