Bug 169725 - udev requires network access for ldap
udev requires network access for ldap
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: udev (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
:
: 176605 176836 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-02 04:02 EDT by Ola Thoresen
Modified: 2007-11-30 17:11 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-01-16 05:31:37 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 Ola Thoresen 2005-10-02 04:02:13 EDT
Description of problem:
It seems like udev might need network access if nsswitch is set up with
authentication from ldap:

passwd:     files ldap
shadow:     files ldap
group:      files ldap

This leads to the following errors:

Sep 19 15:48:36 ws21 udevstart[2042]: nss_ldap: reconnecting to LDAP
server (sleeping 4 seconds)...
Sep 19 15:48:40 ws21 udevstart[2042]: nss_ldap: reconnecting to LDAP
server (sleeping 8 seconds)...

Version-Release number of selected component (if applicable):
udev-069-5
glibc-2.3.90-12

How reproducible:
Always

Steps to Reproduce:
1. configure ldap authentication
2. reboot
  
Actual results:
start_udev hangs, and exits with an error.
udev is not available, making all sorts of bad things happen...

Expected results:
udev should start fine even before the network is up

Additional info:
Harald Hoyer replied with the following on the fedora-devel list:
"grrr... this seems to be glibc and getpwnam(3)"

I am posting this as a bug in udev, even if that might just be a symptom, but I
am adding jakub@redhat.com to Cc: as glibc-maintainer.
Comment 1 Harald Hoyer 2005-10-05 03:23:14 EDT
This is getgrnam(3) and getpwnam(3).
Jakub, how can I prevent this to happen, if there is no network access?
Comment 2 Jakub Jelinek 2005-10-05 03:47:18 EDT
glibc honors whatever you state in nsswitch.conf.
This bug report doesn't go into detail what exact users/groups have been looked
up and whether they exist in /etc/passwd resp. /etc/group or just in ldap.
With the order files ldap in nsswitch.conf ldap ought to be used only if
the user/group hasn't been found in the local files (just tested that
to make sure and it works that way).
The way to prevent ldap from being accessed is to edit nsswitch.conf.

But, if the user resp. group udev is trying to look up only exist in ldap,
you are screwed up anyway.  Even if you edited nsswitch.conf to exclude all
networking nss modules (say e.g. mount --bind'ed it for the process or
something), if the user/group is not present locally, udev will never be able
to find it out.
Comment 3 Harald Hoyer 2005-10-05 04:10:24 EDT
Ola Thoresen, did you add any custom udev rules?
Comment 4 Ola Thoresen 2005-10-05 04:39:03 EDT
No, I have not added any custom rules.

But could this be the reason?

rules.d/50-udev.rules:
KERNEL=="usb/dabusb*",            GROUP="usb", MODE="0660"
KERNEL=="usb/mdc800*",            GROUP="usb", MODE="0660"
KERNEL=="usb/rio500",             GROUP="usb", MODE="0660"

I don't have any "usb" group in /etc/group, so it might be that group it is
trying to resolve?
All other groups mentioned in rules.d/* are in /etc/group

Now, I can't find any of these devices in /dev, and the modules are not loaded,
but it is the only thing that I can think of that might cause it to connect to
the ldap-server.
But I am in no way an udev expert, so it might be something completely different.
I'll try to remove these rules (or add the group "usb", whatever you think is
the correct solution) and see if that makes a difference.
Comment 5 Ola Thoresen 2005-10-10 04:20:13 EDT
It is the missing group "usb" that causes the problem.
Commenting out those three lines wil allow udev to start at boot again.

When was this group added, and by what package?
Comment 6 Harald Hoyer 2005-10-10 05:48:00 EDT
yes, group USB is wrong, sry... removed..
Comment 7 Jarod Wilson 2006-01-03 03:31:27 EST
This one's back. Looks like its probably being triggered by this line in
50-udev.rules...

SUBSYSTEM=="dvb", PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb}; printf
dvb/adapter%%i/%%s $${K%%%%.*} $${K#*.}'", NAME="%c", GROUP="video"

...since there's no video group. And that's a positive confirmation, just
rebooted after adding a video group, no more udev complaints about nss_ldap.
Comment 8 Harald Hoyer 2006-01-11 04:45:14 EST
*** Bug 176836 has been marked as a duplicate of this bug. ***
Comment 9 Harald Hoyer 2006-01-11 04:45:24 EST
*** Bug 176605 has been marked as a duplicate of this bug. ***
Comment 10 Harald Hoyer 2006-01-11 07:31:24 EST
should be fixed again with udev-078-4
Comment 11 W. Michael Petullo 2006-01-13 09:31:45 EST
Seems fixed in udev-078-4.
Comment 12 Pawel Salek 2006-02-14 05:37:37 EST
This problem is present again in udev-084. I have no custom groups added.
Comment 13 Harald Hoyer 2006-02-14 05:48:42 EST
This may be bug #181432 .

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