Bug 234541 - udev hangs when configured with ldap
udev hangs when configured with ldap
Status: CLOSED CANTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: udev (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-29 17:53 EDT by Steve Cleveland
Modified: 2008-01-31 05:57 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-31 05:57:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Steve Cleveland 2007-03-29 17:53:42 EDT
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.
Comment 1 Harald Hoyer 2007-03-30 06:16:02 EDT
udev does not query directly.. glibc is doing this.
Comment 2 Steve Cleveland 2007-03-30 12:47:07 EDT
Can I just change the Component of this bug report to glibc, or do I need to
create a new ticket?
Comment 3 Kay Sievers 2007-04-02 05:41:03 EDT
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.
Comment 4 Harald Hoyer 2007-04-02 05:58:16 EDT
right.
Do you use any custom rules with specific users/groups?
Comment 5 Steve Cleveland 2007-04-02 11:10:20 EDT
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.
Comment 6 Kay Sievers 2007-04-02 12:31:09 EDT
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.
Comment 7 Weston Rogers 2007-05-16 14:07:20 EDT
> 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}.
Comment 8 Weston Rogers 2007-05-16 16:33:21 EDT
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.
Comment 9 Don Hoover 2007-05-31 14:57:32 EDT
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.
Comment 10 Don Hoover 2007-05-31 15:10:28 EDT
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

Comment 11 Don Hoover 2007-05-31 17:52:43 EDT
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.
Comment 12 Weston Rogers 2007-06-20 16:02:12 EDT
> 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.
Comment 13 Harald Hoyer 2007-06-21 06:18:02 EDT
> 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?
Comment 14 Richard Bullington-McGuire 2007-07-05 19:00:07 EDT
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:" 
Comment 15 Daniel Riek 2007-09-13 15:57:45 EDT
What is the version of nss_ldap on your system?
Comment 16 Daniel Riek 2007-09-13 17:03:40 EDT
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.

Comment 19 RHEL Product and Program Management 2007-10-19 16:29:56 EDT
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.
Comment 21 Phil Knirsch 2007-11-21 07:39:14 EST
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.
Comment 22 Daniel Qarras 2007-12-27 11:00:20 EST
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.
Comment 23 Phil Knirsch 2008-01-31 05:57:48 EST
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

Note You need to log in before you can comment on or make changes to this bug.