Description of problem: Putting the following in /etc/nsswitch.conf results in a non-bootable system: passwd: files ldap shadow: files ldap group: files ldap Version-Release number of selected component (if applicable): nss_ldap-265-10.fc17.x86_64 How reproducible: always Steps to Reproduce: 1.enable nss_ldap in /etc/nsswitch.conf, as above 2.reboot Actual results: What happens is the following: - systemd starts up - systemd spawns udevd - systemd triggers udev device add events - udevd reads its config files, tries to resolve group names given (such as video or plugdev) - nss_ldap tries to contact the ldap server, but fails, because so early in the boot process the network is not configured - nss_ldap delays udevd startup for a long time (more than 2 minutes) - systemd waits for device add events; after 1:30 minutes, it times out waiting for the device add event for the disks given in /etc/fstab, dropping into the emergency shell Expected results: clean and expeditious boot Additional info: I solved my problem by switching to sssd, maybe it's time to drop nss_ldap? Maybe nss_ldap should distinguish transient errors from hard errors, like no network present, and use a shorter timeout for no network present?
SSSD was designed with this case in mind. The problem with dropping nss_ldap is that nss_ldap supports more maps than SSSD. SSSD can do passwd (& shadow to some extent), group, netgroup, services. It works with sudo and autofs but it does not support other maps that theoretically can be put into LDAP. The biggest question is: are there any other maps like ethers, bootparams, protocols etc that must be supported by SSSD i.e. really used in deployments before a switch can happen. Any guidance on this matter would be much appreciated.
In my case the server is an IPA server. I used nss_ldap because at the time I installed the client, ipa-client-install wasn't able to configure sssd such that it was able to connect securely to the dirserv. So I just used nss_ldap in insecure mode because it was easier than to debug why sssd wouldn't want to connect. Right now I don't think there are many users of nss_ldap left, because I can't see how it doesn't result in a nonbooting machine with F17.
(In reply to comment #0) > - udevd reads its config files, tries to resolve group names given (such as > video or plugdev) > - nss_ldap tries to contact the ldap server, but fails, because so early in > the boot process the network is not configured This shouldn't be the case for users who are in plan UNIX files which should be the case for the likes of video or plugdev. Were the users who were looked up UNIX users stored in files? > - nss_ldap delays udevd startup for a long time (more than 2 minutes) > - systemd waits for device add events; after 1:30 minutes, it times out > waiting for the device add event for the disks given in /etc/fstab, dropping > into the emergency shell > > > Expected results: > clean and expeditious boot > > Additional info: > I solved my problem by switching to sssd, maybe it's time to drop nss_ldap? Yes, I agree. nss_ldap is dead upstream and there is nss-pam-ldapd for users who wish to stay away from SSSD for one reason or another (such as a NSS map support missing in SSSD). I would like to retire nss_ldap in F-18/rawhide before it branches. > Maybe nss_ldap should distinguish transient errors from hard errors, like no > network present, and use a shorter timeout for no network present? Perhaps, but truth be told, I don't think investing time in nss_ldap development is worth it given the presence of both SSSD and nss-pam-ldapd
(In reply to comment #2) > In my case the server is an IPA server. I used nss_ldap because at the time > I installed the client, ipa-client-install wasn't able to configure sssd > such that it was able to connect securely to the dirserv. So I just used > nss_ldap in insecure mode because it was easier than to debug why sssd > wouldn't want to connect. > > Right now I don't think there are many users of nss_ldap left, because I > can't see how it doesn't result in a nonbooting machine with F17. Using the SSSD also gives you the ability to leverage HBAC access control, offline support and more. Using the SSSD where available is definitely the best approach for an IPA client.
(In reply to comment #3) > This shouldn't be the case for users who are in plan UNIX files which should > be the case for the likes of video or plugdev. > > Were the users who were looked up UNIX users stored in files? Yes. I have some self made udev rules files, I even moved them away to make sure it is not a bug in my own udev rules. > Perhaps, but truth be told, I don't think investing time in nss_ldap > development is worth it given the presence of both SSSD and nss-pam-ldapd Agreed. But if you don't want to remove it immediately, maybe the timeout should just be halved, so that the system at least boots?
It seems like there is not much opposition against retiring nss_ldap: https://lists.fedoraproject.org/pipermail/devel/2012-June/168365.html I'm going to be away now, but I'll retire the package when I'm back in mid-July.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.