Bug 169725
| Summary: | udev requires network access for ldap | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Ola Thoresen <redhat> |
| Component: | udev | Assignee: | Harald Hoyer <harald> |
| Status: | CLOSED RAWHIDE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | jakub, jarodwilson, pawsa, vonbrand |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-01-16 10:31:37 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Ola Thoresen
2005-10-02 08:02:13 UTC
This is getgrnam(3) and getpwnam(3). Jakub, how can I prevent this to happen, if there is no network access? 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. Ola Thoresen, did you add any custom udev rules? 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. 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? yes, group USB is wrong, sry... removed.. 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.
*** Bug 176836 has been marked as a duplicate of this bug. *** *** Bug 176605 has been marked as a duplicate of this bug. *** should be fixed again with udev-078-4 Seems fixed in udev-078-4. This problem is present again in udev-084. I have no custom groups added. This may be bug #181432 . |