Bug 827677 - enabling nss_ldap results in nonbootable system
enabling nss_ldap results in nonbootable system
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: nss_ldap (Show other bugs)
17
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Nalin Dahyabhai
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-02 04:24 EDT by Thomas Sailer
Modified: 2013-08-01 01:34 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-01 01:34:06 EDT
Type: Bug
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 Thomas Sailer 2012-06-02 04:24:49 EDT
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?
Comment 1 Dmitri Pal 2012-06-05 22:35:08 EDT
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.
Comment 2 Thomas Sailer 2012-06-06 03:50:15 EDT
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.
Comment 3 Jakub Hrozek 2012-06-07 01:34:12 EDT
(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
Comment 4 Jakub Hrozek 2012-06-07 01:36:58 EDT
(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.
Comment 5 Thomas Sailer 2012-06-07 03:32:07 EDT
(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?
Comment 6 Jakub Hrozek 2012-06-14 17:40:32 EDT
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.
Comment 7 Fedora End Of Life 2013-07-03 21:16:10 EDT
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.
Comment 8 Fedora End Of Life 2013-08-01 01:34:11 EDT
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.

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