Bugzilla – Bug 139578
dhclient fails (with NetworkManager and LDAP authentication)
Last modified: 2006-01-19 16:15:07 UTC
When installing, leave the network setup to default (NetworkManager) and choose LDAP user authentication. Afterwards, you're left with only a link local IP address. Even root login does not work (probably a separate bug). See attached /etc/nsswitch.conf and /var/log/messages: dhclient (and other daemons) tries to contact the LDAP server (!?) via nss_ldap. It naturally does not succeed and waits with exponential backoff. As can be seen at Dec 16 13:01:56, if NM is disabled it eventually gives up and proceeds to obtain an address, but if NM is running, NM gives up after 25 seconds (Dec 16 12:14:01). One way would be to increase the timeout in NM but I think a better way is to fix either dhclient or our nsswitch.conf so that dhclient does not try to contact LDAP if the network is not up yet. I wonder whether a similar thing happens with NIS...
Created attachment 61075 [details] messages
Created attachment 61076 [details] nsswitch.conf
Robert, you work on NetworkManager, don't you? Could this depend on the configuration of dhclient? And, what does dhclient look up which causes an ldap lookup?
NM, yes. My dhclient mastery is minimal, though. I don't know why it is contacting an LDAP server. dhclient, even under NM, uses the default dhclient config file.
Looking at /var/log/messages, and noticing that all kinds of processes trigger the ldap lookup, I don't think this is a problem of network manager at all, unless it is the reason why the boot process proceeds although it should wait for network first (?). Ralf, what do you think about this bug?
Might be a misconfiguration or a bug in the reconnection behaviour of nss_ldap. Could you attach the /etc/ldap.conf from that machine?
Not now, unfortunately (gorgon.suse.cz is offline). If you want to try yourself, the machine was a standard install with LDAP authentication selected in yast during the installation.
I was able to reproduce it. This is a configuration problem I think. Since some versions nss_ldap support the bind_policy option which, if not present in /etc/ldap.conf defaults to "hard" (which means, if a connection attempt to the LDAP server fails nss_ldap retries to connect until it was successful). Earlier nss_ldap version behaved different AFAIK :( Jiri could you change yast2-ldap-client to always add bind_policy soft to /etc/ldap.conf? We should also consider to add this to our default /etc/ldap.conf.
*** Bug 135589 has been marked as a duplicate of this bug. ***
> We should also consider to add this to our default /etc/ldap.conf. Isn't this the only correct solution? If I will do it from yast2-ldap-client, it will write "soft" value even if user want to leave his own "hard" one.
Actually, yes I think it should be included in the default /etc/ldap.conf.
I added it, but be aware that this will not work in case of an update.
AFAIK update must be solved in the script of rpm package; I don't know of which one, but I would say pwdutils.
I will not add a parser for ldap.conf to pwdutils.
Ralf, we need a different solution then.
I am currently discussing some options with Luke Howard. In the worst case I'll add the option in the %post of nss_ldap.
nss_ldap will now add "bind_policy soft" during package update if nothing differnt is present in ldap.conf.