I just happened across this page after spending the last 2 days trying to figure this out. This is exactly the issue that I have, and I'd like to add a couple of additional things I've noticed:
1) Setting "bind_policy soft" DOES NOT WORK. It appears to work, as things like "getent passwd" return immediately (instead of blocking) after dumping /etc/passwd, but if you try to ssh in as an ldap user, sshd will bail out with:
nss_ldap: could not search LDAP server - Server is unavailable fatal: login_get_lastlog: Cannot find account for uid 1000
2) Putting the user in /etc/passwd DOES NOT WORK. nss_ldap will go through the passwd file first, and will indeed find the user, but it will still attempt to do the ldap lookup. Once that fails, it will return the info it found in /etc/passwd. There needs to be a way to short-circuit this (see #4 below).
3) Your comments about init scripts are spot on, and affect /etc/init.d/slapd as well. If your ldap server is using ldap auth, restarting slapd will take the entire timeout period (about 3 minutes).
This seems like the "right" way to fix this problem, but it does not appear to do anything.
IMHO, v249 should be masked. I've got servers running v239 that have run fine for months and handle this in a more sane way (if ldap isn't available, the lookup fails immediately instead of blocking). I just noticed this problem when setting up a new ldap infrastructure. Should I just revert to v239, or is this problem fixed in newer versions?
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mask versions over 239?
Date: 2006-12-14 07:03 pm (UTC)1) Setting "bind_policy soft" DOES NOT WORK. It appears to work, as things like "getent passwd" return immediately (instead of blocking) after dumping /etc/passwd, but if you try to ssh in as an ldap user, sshd will bail out with:
nss_ldap: could not search LDAP server - Server is unavailable
fatal: login_get_lastlog: Cannot find account for uid 1000
2) Putting the user in /etc/passwd DOES NOT WORK. nss_ldap will go through the passwd file first, and will indeed find the user, but it will still attempt to do the ldap lookup. Once that fails, it will return the info it found in /etc/passwd. There needs to be a way to short-circuit this (see #4 below).
3) Your comments about init scripts are spot on, and affect /etc/init.d/slapd as well. If your ldap server is using ldap auth, restarting slapd will take the entire timeout period (about 3 minutes).
4) I tried messing with nsswitch.conf:
passwd: files [SUCCESS=return] ldap
shadow: files [SUCCESS=return] ldap
group: files [SUCCESS=return] ldap
This seems like the "right" way to fix this problem, but it does not appear to do anything.
IMHO, v249 should be masked. I've got servers running v239 that have run fine for months and handle this in a more sane way (if ldap isn't available, the lookup fails immediately instead of blocking). I just noticed this problem when setting up a new ldap infrastructure. Should I just revert to v239, or is this problem fixed in newer versions?