Yes, the bug is actually older than that---Don't know if it's only RH based systems (as so many things seem to work everywhere but RH and their offshoots) or ldap. You should be able to fix it by changing /etc/ldap.conf. There is a default commented line in there
#bind_policy hard
Uncomment it, change it to soft. (On the client.) Note this is /etc/ldap.conf--in Fedora, if that's the client, I believe it's now /etc/pam_ldap.conf or possibly /etc/nss_ldap.conf.
I can't find the earlier bug at first glance, but it's FAR older than 2010, and they never bothered to fix it.
Has anyone else ever solved this to still be able to keep the group
ldap
entry in nsswitch.conf without having a server hang on boot if
there's
no network?
See above. Darn, I wish I could find that older bug, so that I could
go
to the newer one you mention and point out that they've been unable to fix it for far longer than a year. :) (I might do it anyway)
Grouchily yours, (Not at you, at RH for being unable to get such a basic thing to work--actually, at one point, Fedora changed
bind_policy
to soft so that it would work, but now they're back to the broken
way.)
-- Scott Robbins
Hi Scott,
In case you're wondering, this is about the oldest entry (2006): https://bugzilla.redhat.com/show_bug.cgi?id=186527
The bind_policy didn't seem to have the wanted effect with me, it kept trying to connect to LDAP server even after 10+ failed attempts, taking 1m50s on each and every attempt.
I read quite a few topics on that solving the issue, but it didn't seem to be that case in my environment. Are there other workarounds/tips if the bind_policy doesn't work? The rc.local hack seems ... ugly ... and embarrassing if a client would ever find it out. :-)
Regards, Mattias