Problems in error situations

[Riku Anttila <rixa@cs.tut.fi>]

I am interested in using an OpenLDAP database to replace NIS on a
currently small but expanding cluster of Linux computers.

Currently my test environment, using nss_ldap and pam_ldap, is working
fine as long as there is no error, such as the main server getting
disconnected. I have not been able to get the system working nicely in
such an event, which prevents wider adaptation. Often in the case of an
error, test clients need a reboot to recover completely.

nscd and certain pam-aware programs appear to be keeping a connection
open to the main server at all times. Is this normal and necessary?
When something goes wrong with the connection, such as the server
getting disconnected from the network, the programs do not recover
along with the master server, nor do they start using a back-up server.
A locked X session, for instance, stays locked for good, as far as I
can help it. Most of my pam config files look something like this:

auth [success=done default=ignore] pam_unix.so
auth required pam_ldap.so
account [success=done default=ignore] pam_unix.so
account required pam_ldap.so
session required pam_permit.so

There is also a problem with new ldap queries in case the master server
is down. I have slurp replicate the database to another server, and the
test clients are configured in the manner of:

uri ldap://main.server.here/ ldap://backup.server.here/

Now if the master server is totally down and gives no reply, the
clients end up waiting a long time before the backup server is asked.
Can I adjust the timeout value somehow, or is there another way of
doing this that works better?

We are using Debian Woody systems, with some local modifications. The
ldap-related packages have been rebuilt from unstable and modified as
necessary to get support for SSL. The versions in use are, effectively:

openldap2   Debian 2.0.23-10, but configured with "--with-tls"
libnss-ldap Debian 199-1,     recompiled with Woody libraries.
libpam-ldap Debian 151-1,     recompiled with Woody libraries.

Now of course it is possible that Debian has broken something, so if
the behaviour I am describing does not sound normal, I would like to
know about that, too.

Riku Anttila