Description of problem: Version-Release number of selected component (if applicable): udev-095-14.5.el5 How reproducible: very Steps to Reproduce: 1. Use authconfig to configure ldap 2. Modify /etc/nsswitch.conf to list ldap first in passwd or groups 3. reboot machine Actual results: udev hangs indefinitely complaining about not being able to find the ldap server. Expected results: When udev starts, the network is not available, so under no circumstances should udev try to query the server. Additional info: Most likely, udev is just using another tool to lookup a user account (and that may need to be what's fixed). Setting bind_policy=soft in /etc/ldap.conf keeps udev from hanging, but that's not how I want to have things setup.
udev does not query directly.. glibc is doing this.
Can I just change the Component of this bug report to glibc, or do I need to create a new ticket?
Please just fix your /etc/nsswitch.conf to lookup /etc/group first. And make sure, _all_ required system users exist in the /etc/group file. This isn't a bug in udev nor glibc. System users which are not stored on the local system, but used in udev-rules, are a "configuration bug", which can't be worked around.
right. Do you use any custom rules with specific users/groups?
We're not using any custom rules. I was just setting up /etc/nsswitch.conf the same as we had it in rhel4. I will change the group setting. I still think it's something that shouldn't happen, but I can live with things this way.
If you specify to lookup /etc/group before querying ldap, and you still see any delay/failure in bootup, please let us know, because then there are rules, that use a name that needs to be added to the system-files.
> If you specify to lookup /etc/group before querying ldap, and you still see any > delay/failure in bootup, please let us know This still doesn't fix the issue. This is using stock /etc/{passwd,shadow,group}.
Also if it helps : 1. Enabling nscd and rebooting after changing /etc/{ldap,nsswitch}.conf gets you past INIT/udev yet hangs at messagebus during boot. 2. _just_ changing /etc/nsswitch.conf to use ldap (in either order) on any line wither it be passwd, shadow or group results in the system hang in someway, either during INIT, udev or messagebus. 3. As above, this is on a stock RHEL5 install with no modifications to /etc/{passwd,shadow,group}. 4. Indeed bind_policy=soft fixes the boot issues on all fronts. But, you have to set an extremely small bind_timelimit.
ALSO experiencing this same hang with RHEL5. I was testing installing RHEL5 using the same config we used for RHEL4 and now have the exact same issues. Something is obviously broken in RHEL5 with regard to udev/mapper and LDAP.
BTW, found this in a discussion from the ARCH mailing list.......... AND by the way this seems to have been an issue since fedora core 5 and still no one has fixed it for sure. RedHat guys, LDAP is pretty important for your enterprise customers and its one area you guys might want to test a little more closely than the rest of the fedora community since prob only a tiny percentage of them use LDAP. This needs to be made a high priority bugzilla issue for RHEL5. I did find that there is a BUGZILLA for fedora that addresses this issue too and contains a possible fix/workaround: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186527
Ok.. I have figured out my problem. I deleted the uucp group as per pretty standard policy of deleting unused groups out of the /etc/group files like recommended by CIS, or Bastille etc. Apparently the udev configs in RHEL5 depend on the uucp user group and try to do a lookup of that group when it starts. And when it cant find it then nss tries to go and see if maybe it can find it in LDAP instead...and of course the network isnt up and boom errors. MY FIX FOR RHEL5 system with LDAP turned on getting "udevd[xxxx]: Failed to bind to LDAP Server": 1) Don't delete the uucp group from the default /etc/group file, even though many people like Bastille, CIS recommend it 2) or groupadd uucp to fix the problem.
> MY FIX FOR RHEL5 system with LDAP turned on getting "udevd[xxxx]: Failed to bind > to LDAP Server": > > 1) Don't delete the uucp group from the default /etc/group file, even though > many people like Bastille, CIS recommend it > > 2) or groupadd uucp to fix the problem. This isn't a real fix for everyone, considering a STOCK RHEL5 system with the uucp group untouched and existing still exhibits this problem.
> This isn't a real fix for everyone, considering a STOCK RHEL5 system with the > uucp group untouched and existing still exhibits this problem. Then another group is undefined? Can you figure out which one? Or is this a /etc/nsswitch.conf ordering problem?
Don Hoover mentioned the Fedora 5 bug and workaround: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186527 When both vcsa and dbus were added to the /etc/ldap.conf nss_initgroups_ignoreusers line from bug # 186527, the RHEL 5 installation would boot: nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,vcsa,dbus Without the vcsa user, it would hang on "Starting udev:"
What is the version of nss_ldap on your system?
I am aware of the messagebus problem and it is going to be fixed in 5.1 through bug 243753. Bascially adds "dbus" to the nss_initgroups_ignoreusers. Now I am not able to reproduce the udev hang... Please set the nss_initgroups_ignoreusers line in /etc/ldap.conf to root,ldap,named,avahi,haldaemon,messagebus,dbus and see if the problem still exists. If it does, please also addd vcsa as recommended in comment 14. And a reminder: Bugzilla is a development tool, not a support tool. So if you are having issues in production systems, please contact your Red Hat Support representative and do not rely on jsut filing the bug in BZ.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
This request was evaluated by Red Hat Engineering for inclusion in a Red Hat Enterprise Linux maintenance release. Red Hat does not currently plan to provide this change in a Red Hat Enterprise Linux update release for currently deployed products. With the goal of minimizing risk of change for deployed systems, and in response to customer and partner requirements, Red Hat takes a conservative approach when evaluating enhancements for inclusion in maintenance updates for currently deployed products. The primary objectives of update releases are to enable new hardware platform support and to resolve critical defects. However, Red Hat will further review this request for potential inclusion in future major releases of Red Hat Enterprise Linux. Specifically in this case the bug isn't related to udev but to non-existing groups that are still required for proper operation. If the current fixes in Red Hat Enterprise Linux 5.1 are not complete please feel free to file bugs against either nss_ldap to ignore those groups or against the related components to add those groups properly.
FWIW, nss_ldap has been forked and the new incarnation, nss-ldapd, promises to fix many of the issues found with nss_ldap. Please see http://ch.tudelft.nl/~arthur/nss-ldapd/ http://ch.tudelft.nl/~arthur/nss-ldapd/design.html Of course, for RHEL5 this is irrelevant but you might want to investigate this with Fedora/RHEL6.
Thanks for the update. I'll be closing this bug then but we'll keep an eye on the nss-ldap development. Read ya, Phil