Hi,
most of you probably know the issues with using syncrepl with SASL/gssapi when built against MIT Kerberos. Is cause of the problem is also well know. MIT's gssapi implementation will not encode packages for established connection anymore once the ticket is expired. Once this happened any connected syncrepl consumer will just hang forever.
I know there have been a lot of discussion in the past on wether Heimdal's of MIT's approach is correct. And I don't want to start yet another one. (It seems even that MIT will switch to the Heimdal behavior with future releases: http://krbdev.mit.edu/rt/Ticket/Display.html?id=6739 )
But to fixing the problem with current releases seems to be pretty easy. At least if I didn't overlook something. If we'd just close the syncrepl connection once the provider fails to send a message to the consumer, we consumer's retry mechanmis can try to reestablish the connection (this will succeed once the tickets have be refreshed by some external tool).
The basic functionality is there already it seems. send_ldap_ber() calls connection_closing() when ber_flush fails (which happens when sasl_encode() fails because the ticket expired). The only thing that's missing seems to be to actually close the connection in the syncprov overlay after syncprov_sendresp() failed. For that to happened we'd need to export connection_close() to have it available in syncprov.c.
Did I overlook something? Would anybody object if I'd commit the required changes?
--On Tuesday, June 22, 2010 4:27 PM +0200 Ralf Haferkamp rhafer@suse.de wrote:
Did I overlook something? Would anybody object if I'd commit the required changes?
Shouldn't they just use the TCP/IP timeout code introduced in 2.4.22?
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
--On Tuesday, June 22, 2010 8:38 PM -0700 Quanah Gibson-Mount quanah@zimbra.com wrote:
--On Tuesday, June 22, 2010 4:27 PM +0200 Ralf Haferkamp rhafer@suse.de wrote:
Did I overlook something? Would anybody object if I'd commit the required changes?
Shouldn't they just use the TCP/IP timeout code introduced in 2.4.22?
Never mind, that's for keep alive... :P
If MIT's changing, it seems somewhat silly to me to change the code now. In any case, it's never been difficult to simply build OpenLDAP against Heimdal libs, regardless if MIT is used or not.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Am Mittwoch 23 Juni 2010, 05:39:06 schrieb Quanah Gibson-Mount:
--On Tuesday, June 22, 2010 8:38 PM -0700 Quanah Gibson-Mount
quanah@zimbra.com wrote:
--On Tuesday, June 22, 2010 4:27 PM +0200 Ralf Haferkamp rhafer@suse.de
wrote:
Did I overlook something? Would anybody object if I'd commit the required changes?
Shouldn't they just use the TCP/IP timeout code introduced in 2.4.22?
Never mind, that's for keep alive... :P
If MIT's changing, it seems somewhat silly to me to change the code now.
The change hasn't been released yet. I guess it'll still take some time until it is. To me the change in slapd seems to make sense anyway as it seems be the correct way to react when packages couldn't be send to the consumer (There might be other situations where that happens, apart from the SASL/(MIT-)GSSAPI case. This one is just the easiest to reproduce). as the connection is already prepared for being closed, just the last step is missing.
In any case, it's never been difficult to simply build OpenLDAP against Heimdal libs, regardless if MIT is used or not.
Yes, I know. Let's just say that for non-technical reasons we currently need to use MIT Kerberos.
Ralf Haferkamp wrote:
Hi,
most of you probably know the issues with using syncrepl with SASL/gssapi when built against MIT Kerberos. Is cause of the problem is also well know. MIT's gssapi implementation will not encode packages for established connection anymore once the ticket is expired. Once this happened any connected syncrepl consumer will just hang forever.
I know there have been a lot of discussion in the past on wether Heimdal's of MIT's approach is correct. And I don't want to start yet another one. (It seems even that MIT will switch to the Heimdal behavior with future releases: http://krbdev.mit.edu/rt/Ticket/Display.html?id=6739 )
But to fixing the problem with current releases seems to be pretty easy. At least if I didn't overlook something. If we'd just close the syncrepl connection once the provider fails to send a message to the consumer, we consumer's retry mechanmis can try to reestablish the connection (this will succeed once the tickets have be refreshed by some external tool).
The basic functionality is there already it seems. send_ldap_ber() calls connection_closing() when ber_flush fails (which happens when sasl_encode() fails because the ticket expired). The only thing that's missing seems to be to actually close the connection in the syncprov overlay after syncprov_sendresp() failed. For that to happened we'd need to export connection_close() to have it available in syncprov.c.
Did I overlook something? Would anybody object if I'd commit the required changes?
I recall wanting to export connection_close() for syncprov before, but stopping. I don't remember at the moment why, probably it was going to take too much time to figure out the locking order. Go ahead and try if you like.
-
Howard Chu -
Quanah Gibson-Mount -
Ralf Haferkamp