[Pkg-openldap-devel] r699 - openldap/trunk-2.3/debian

[Stephen Frost]

* Steve Langasek (vorlon at debian.org) wrote:
> On Tue, Jul 25, 2006 at 08:33:51PM +0000, Matthijs Mohlmann wrote:
> > +  * Create a new user before slapd is stopped. It is possible that libnss-ldap
> > +    is using slapd on localhost which causes a hang in the upgrade procedure.
> > +    (Closes: #379728)
> 
> I don't think this is a correct solution at all.  Why is getent group
> hanging on this user's system?  slapd being disabled shouldn't cause this;
> it sounds to me like this is a buggy NSS configuration, probably caused by
> the new stupid upstream defaults in libnss-ldap which the Debian maintainer
> has confirmed over my objections.
> 
> NSS hanging indefinitely due to a downed server is BROKEN BROKEN BROKEN, and
> one-off workarounds for the symptoms are a disservice to our users.

Users might also not particularly care for NSS lookups failing
immediately when slapd is restarted.  Of course, this is certainly
configurable by the user: set bind_policy soft if you want NSS lookups
to fail immediately on server failure.  Additionally, it shouldn't
actually hang indefinitely.  It should look like this:

tries 0:
	Attempt connection to all URIs
tries 1:
	Attempt connection to all URIs
tries 2:
	sleep(4)
	Attempt connection to all URIs
tries 3:
	sleep(8)
	Attempt connection to all URIs
tries 4:
	sleep(16)
	Attempt connection to all URIs
tries 5:
	sleep(32)
	Attempt connection to all URIs
tries 6:
	sleep(64)
	Attempt connection to all URIs
fail

There should also be log messages happening along the lines of:
"nss_ldap: reconnecting to LDAP server (sleeping %d seconds)..."

Or about 2 minutes per NSS call.  Unfortunately, there could be quite a
few NSS calls, though I'm somewhat skeptical about the 10 minute claim.
I'm willing to drop the length of time till failure some but I'd like
input from people on how long a slapd restart takes on decent sized
directories.  I don't think it's a good idea to have 'soft' be the
default bind policy.

	Thanks,

		Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-openldap-devel/attachments/20060726/d6e62cf3/attachment.pgp