Comment 2 for bug 67404

A better solution would be for libnss-ldap to be disabled completely
until such a point as network access is available.

Or you know, it should disable itself. No network, no LDAP, no timeout.

On Sun, 2006-10-29 at 11:44 +0000, Shawn Church wrote:
> Here is a complete description of this problem (I noticed this entry as
> I was filing a bug report for the same problem, so am just going to
> paste it here instead):
>
> The default installation of libnss-ldap is called by the udev and other
> subsystems to resolve group names (i.e. udev rules with "GROUP=") before
> the network is configured so libnss-ldap hangs on boot.
>
> This problem is discussed in the following debian posts:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=375215,
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=375077, and
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=391167.
>
> According to the above threads, the 'solution' devised to fix this
> problem is to place a file that will override the default libnss-ldap
> connection policy from hard to soft at the beginning of the rcS.... boot
> sequence. The edgy installation does include this via the rcS.d
> /S03libnss-ldap script -- the only problem is when this script attempts
> to create the lib/init/rw/libnss-ldap.bind_policy_soft file it fails
> because the file system is read only at that point in the boot sequence.
>
> Another problem I noted with the edgy distribution is that the
> lib/init/rw/ directory is not created by the install script and must be
> created manually.
>
> This whole issue could be avoided if all of the nsswitch data came from
> local files so libnss-ldap never gets called. I was able to avoid the
> udev problem by adding a missing 'nvram' group that is referenced in
> the udev rules but not created when edgy was installed (I did install
> and upgrade Edgy so a fresh install may work).
>
> Even with the additional group added the rcS.d/S49console-setup script
> still hangs unless I manually change the connection policy in libnss-
> ldap.conf to 'soft'. I was not able to trace the reason for this
> problem. I will try again ;ater and update this thread if I have any
> luck.
>
> For now I am keeping the 'soft' policy, this should not be a problem
> since I am only using this on a small test network.
>