On Mon, 2010-09-27 at 17:24 +0200, Matthias Wamser wrote: > Without ssl i have the following behaviour: > > If the first LDAP Server fails, nslcd reconnects to the second server > after a minimum time of 10 seconds. Even if all possible timelimits in > nslcd.conf are set to 1 second.
I cannot fully reproduce this in my test environment. In my setup I have slapd listening on both ports 389 and 390. Both URIs are in /etc/nslcd.conf. Also, to simplify testing, I have threads 1 configured. I start slapd and then nslcd. I do getent passwd someuser and everything works (now nslcd has a connection option to slapd). I kill the connection with: iptables -A OUTPUT -d 127.0.0.1 -p tcp --dport 389 -j DROP If I now retry the getent it takes exactly timelimit + bind_timelimit seconds. This is because first the connection takes timelimit seconds to time out at which point it is disconnected. If the failure occurs on an existing connection no fail-over is done and first a reconnect to the current server is done. This takes another bind_timelimit seconds. Arguably, nslcd could fail over to the second LDAP server on first error but this is a bit more tricky to get right (so may not be fixable for squeeze). Currently, the fail-over is only implemented when the initial connection fails. > If the first ldap server is available again, nslcd still uses the second > server and doest not seem to reconnect to the first server, even if > waiting some minutes (what does the idle_timelimt, nothing?). Again, nslcd only switches LDAP server on bind error so it will stay with the second server until either that one fails or nslcd is restarted. There is probably room for improvement here though. > If i enable ssl the reconnect mechanism does not work at all. > nslcd never tries to connect to the second ldap server. nslcd hangs while disconnecting from the first server. It hangs inside OpenLDAP code. For non-TLS bind the unbind() only writes some data and doesn't care about any answers, for an unbind() of a TLS connection some response is expected from the server. I'll see of something can be done about this but I suspect it may be a problem within OpenLDAP. > I tested with version 0.7.10 from unstable. Anyway, thanks for the thorough testing. -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong --
signature.asc
Description: This is a digitally signed message part
