Hi!
I'm using CentOS 5.1 (x86_64) machines which authenticate using LDAP. At the start of booting I get messages like this:
udevd[1158]: nss_ldap: failed to bind to LDAP server ldaps://ldap.server.example.com/: Can't contact LDAP server udevd[1158]: nss_ldap: reconnecting to LDAP server... udevd[1158]: nss_ldap: could not connect to any LDAP server as (null) - Can't contact LDAP server udevd[1158]: nss_ldap: failed to bind to LDAP server ldaps://ldap.server.example.com/: Can't contact LDAP server udevd[1158]: nss_ldap: reconnecting to LDAP server (sleeping 1 seconds)...
This escaletes to 2, 4, 8, 16, 32, 64 seconds. After that (==timeouting for 2 minutes) booting continues without problem, so this is not really a showstopper, but inconvenient.
Googling around revealed some fixes for Debian/Ubuntu. The bottom line i that udevd needs some user/group that is not in the local files but on the LDAP-server. The fix usually was adding this user (nvram, scanner ...) or group locally. The problem is, that on these systems after the last attempt something like
udevd[1158]: lookup_group: error resolving group 'rdma': Illegal seek
is printed out, makeing it easy to find the right group/user. Is there a way to get CentOS to a similar behaviour, making it easier to find the culprit?
Bernhard
Bernhard Gschaider wrote:
Hi!
I'm using CentOS 5.1 (x86_64) machines which authenticate using LDAP. At the start of booting I get messages like this:
udevd[1158]: nss_ldap: failed to bind to LDAP server ldaps://ldap.server.example.com/: Can't contact LDAP server udevd[1158]: nss_ldap: reconnecting to LDAP server... udevd[1158]: nss_ldap: could not connect to any LDAP server as (null) - Can't contact LDAP server udevd[1158]: nss_ldap: failed to bind to LDAP server ldaps://ldap.server.example.com/: Can't contact LDAP server udevd[1158]: nss_ldap: reconnecting to LDAP server (sleeping 1 seconds)...
This escaletes to 2, 4, 8, 16, 32, 64 seconds. After that (==timeouting for 2 minutes) booting continues without problem, so this is not really a showstopper, but inconvenient.
Googling around revealed some fixes for Debian/Ubuntu. The bottom line i that udevd needs some user/group that is not in the local files but on the LDAP-server. The fix usually was adding this user (nvram, scanner ...) or group locally. The problem is, that on these systems after the last attempt something like
udevd[1158]: lookup_group: error resolving group 'rdma': Illegal seek
is printed out, makeing it easy to find the right group/user. Is there a way to get CentOS to a similar behaviour, making it easier to find the culprit?
There is a BUG with nss_ldap:
https://bugzilla.redhat.com/show_bug.cgi?id=448014
We have this bug listed in our release notes:
http://wiki.centos.org/Manuals/ReleaseNotes/CentOS5.2#head-447967c60eb305ef2...
You can try the nss_ldap from our testing repo for this bug:
http://dev.centos.org/centos/5/
This may help with the problem.
Thanks, Johnny Hughes
On Tue, Jun 24, 2008 at 3:44 PM, Johnny Hughes johnny@centos.org wrote:
There is a BUG with nss_ldap:
https://bugzilla.redhat.com/show_bug.cgi?id=448014
We have this bug listed in our release notes:
http://wiki.centos.org/Manuals/ReleaseNotes/CentOS5.2#head-447967c60eb305ef2...
You can try the nss_ldap from our testing repo for this bug:
http://dev.centos.org/centos/5/
This may help with the problem.
FWIW, my experience with a variant of this problem and nss_ldap from the testing repo was that boot would hang indefinitely at udevd unless I limited the nss_reconnect_* values. I ended up changing to bind_policy soft as a workaround.
M
Thanks for the answers
On Tue, 24 Jun 2008 15:51:37 -0400 "MS" == Meenoo Shivdasani meenoo@gmail.com wrote:
MS> On Tue, Jun 24, 2008 at 3:44 PM, Johnny Hughes MS> johnny@centos.org wrote: >> There is a BUG with nss_ldap: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=448014 >> >> We have this bug listed in our release notes: >> >> http://wiki.centos.org/Manuals/ReleaseNotes/CentOS5.2#head-447967c60eb305ef2...
I read that, but I didn't connect it to my bug, because I didn't think that anything to do with bash is relevant at that time during the boot process. But obviously I was wrong (and by the way: that problem also occurs with 5.1, so I don't think that it is a bash 3.2 problem)
>> You can try the nss_ldap from our testing repo for this bug: >> >> http://dev.centos.org/centos/5/ >> >> This may help with the problem.
MS> FWIW, my experience with a variant of this problem and MS> nss_ldap from the testing repo was that boot would hang MS> indefinitely at udevd unless I limited the nss_reconnect_* MS> values. I ended up changing to bind_policy soft as a MS> workaround.
So the bottom line is - it is possible to shave 2 min off the boot process - a good chance to make the machine unbootable (and then play around until it works) Well, I'm a lazy coward ;) but thanks
Bernhard
-
Bernhard Gschaider -
Johnny Hughes -
Meenoo Shivdasani