> 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