NSS-LDAP group preventing proper boot

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

NSS-LDAP group preventing proper boot

Marc Franquesa
After making a clean install of Buster and setup it, the system doesn't boot propery and enters emergency mode with some systemd-udevd errors on timing out.

I tracked down and isolated the issue to be caused by nss-ldap group mapping: If I remove ldap from nsswtich.conf groups (only for groups table) the system boots fine (So I can use ldap for everything else except for group)

I already faced the same problem long time ago (not sure, but I think on jessie and ubuntu older releases) and the workarround/solution was to set nss_init_groups_ignore users to list all localacounts (so don't lookup for LDAP groups for local accounts). This time this didn't worked, as I updated my nss_init_groups_ignore_users to the list of current local users with no luck.

Some details tested/discarded:
- there are no custom udev rules making use of any LDAP user/group
- I tried setting various timeouts/soft_policy on LDAP configuration
- Also tried [UNAVAIL=return] and other similar optons on nsswitch.conf
- Exactly the same configuration works perfectly on Debain Stretch (as I configure them thru Ansible)

Note that while researching I found many similar bug reports (also on different distros) related to this issue, all of them providing workarrounds (which didn't worked) but none providing a permanent FIX or solution:

https://bugs.launchpad.net/ubuntu/+source/libnss-ldap/+bug/1024475
https://bugs.launchpad.net/ubuntu/+source/libnss-ldap/+bug/51315
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=318622
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=339797
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=349509
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=375077
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=375215
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=388729
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=391167
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=441458
https://bugzilla.redhat.com/show_bug.cgi?id=234541
https://bugzilla.redhat.com/show_bug.cgi?id=187852

So basically seems that NSS-LDAP is queried when is still not ready, either because LDAP server is down or the affected system didn't initialized network yet. Either the case, this shouldn't prevent the system to boot normally. More than a bug on libnss-ldap/udev seems a wrong/unstable integration on the init process. I don't know if any NSS network servicces (NIS?, winbind?) experience similar issues or how they avoid them.

Does any one faced same issue or can provide any help/workarround/clues?
Should I open a new bug report?

Thanks much for any hint/help

Reply | Threaded
Open this post in threaded view
|

Re: NSS-LDAP group preventing proper boot

Alex Mestiashvili-4
On 9/20/19 7:42 AM, Marc Franquesa wrote:

> After making a clean install of Buster and setup it, the system doesn't
> boot propery and enters emergency mode with some systemd-udevd errors on
> timing out.
>
> I tracked down and isolated the issue to be caused by nss-ldap group
> mapping: If I remove ldap from nsswtich.conf groups (only for groups table)
> the system boots fine (So I can use ldap for everything else except for
> group)
>
> I already faced the same problem long time ago (not sure, but I think on
> jessie and ubuntu older releases) and the workarround/solution was to set
> nss_init_groups_ignore users to list all localacounts (so don't lookup for
> LDAP groups for local accounts). This time this didn't worked, as I updated
> my nss_init_groups_ignore_users to the list of current local users with no
> luck.
>
> Some details tested/discarded:
> - there are no custom udev rules making use of any LDAP user/group
> - I tried setting various timeouts/soft_policy on LDAP configuration
> - Also tried [UNAVAIL=return] and other similar optons on nsswitch.conf
> - Exactly the same configuration works perfectly on Debain Stretch (as I
> configure them thru Ansible)
>
> Note that while researching I found many similar bug reports (also on
> different distros) related to this issue, all of them providing
> workarrounds (which didn't worked) but none providing a permanent FIX or
> solution:
>
> https://bugs.launchpad.net/ubuntu/+source/libnss-ldap/+bug/1024475
> https://bugs.launchpad.net/ubuntu/+source/libnss-ldap/+bug/51315
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=318622
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=339797
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=349509
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=375077
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=375215
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=388729
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=391167
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=441458
> https://bugzilla.redhat.com/show_bug.cgi?id=234541
> https://bugzilla.redhat.com/show_bug.cgi?id=187852
>
> So basically seems that NSS-LDAP is queried when is still not ready, either
> because LDAP server is down or the affected system didn't initialized
> network yet. Either the case, this shouldn't prevent the system to boot
> normally. More than a bug on libnss-ldap/udev seems a wrong/unstable
> integration on the init process. I don't know if any NSS network servicces
> (NIS?, winbind?) experience similar issues or how they avoid them.
>
> Does any one faced same issue or can provide any help/workarround/clues?
> Should I open a new bug report?
>
> Thanks much for any hint/help
>


That's interesting. I've been using libnss-ldap since Lenny and didn't
face the problems listed above, however since quite some time I've
switched to libnss-ldapd/libpam-ldpad. As far as I remember these are
drop-in replacements for libnss-ldap but you'll need to configure nslcd
daemon too. Another option would be to switch to sssd which "just
wokred" for my use cases.

Best,
Alex

Reply | Threaded
Open this post in threaded view
|

Re: NSS-LDAP group preventing proper boot

Marc Franquesa
Thanks for the feedback, I might give it a try to sssd (I was already planning to take a look).

I seen many docs recommending to move to nss/pam-ldapd however (also for sssd) this requires installing many other packages and run multiple daemons while I could achieve the same with simply a dynamic loaded library as libnss-ldap.

Regards


Missatge de Alex Mestiashvili <[hidden email]> del dia dv., 20 de set. 2019 a les 19:22:
On 9/20/19 7:42 AM, Marc Franquesa wrote:
> After making a clean install of Buster and setup it, the system doesn't
> boot propery and enters emergency mode with some systemd-udevd errors on
> timing out.
>
> I tracked down and isolated the issue to be caused by nss-ldap group
> mapping: If I remove ldap from nsswtich.conf groups (only for groups table)
> the system boots fine (So I can use ldap for everything else except for
> group)
>
> I already faced the same problem long time ago (not sure, but I think on
> jessie and ubuntu older releases) and the workarround/solution was to set
> nss_init_groups_ignore users to list all localacounts (so don't lookup for
> LDAP groups for local accounts). This time this didn't worked, as I updated
> my nss_init_groups_ignore_users to the list of current local users with no
> luck.
>
> Some details tested/discarded:
> - there are no custom udev rules making use of any LDAP user/group
> - I tried setting various timeouts/soft_policy on LDAP configuration
> - Also tried [UNAVAIL=return] and other similar optons on nsswitch.conf
> - Exactly the same configuration works perfectly on Debain Stretch (as I
> configure them thru Ansible)
>
> Note that while researching I found many similar bug reports (also on
> different distros) related to this issue, all of them providing
> workarrounds (which didn't worked) but none providing a permanent FIX or
> solution:
>
> https://bugs.launchpad.net/ubuntu/+source/libnss-ldap/+bug/1024475
> https://bugs.launchpad.net/ubuntu/+source/libnss-ldap/+bug/51315
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=318622
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=339797
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=349509
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=375077
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=375215
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=388729
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=391167
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=441458
> https://bugzilla.redhat.com/show_bug.cgi?id=234541
> https://bugzilla.redhat.com/show_bug.cgi?id=187852
>
> So basically seems that NSS-LDAP is queried when is still not ready, either
> because LDAP server is down or the affected system didn't initialized
> network yet. Either the case, this shouldn't prevent the system to boot
> normally. More than a bug on libnss-ldap/udev seems a wrong/unstable
> integration on the init process. I don't know if any NSS network servicces
> (NIS?, winbind?) experience similar issues or how they avoid them.
>
> Does any one faced same issue or can provide any help/workarround/clues?
> Should I open a new bug report?
>
> Thanks much for any hint/help
>


That's interesting. I've been using libnss-ldap since Lenny and didn't
face the problems listed above, however since quite some time I've
switched to libnss-ldapd/libpam-ldpad. As far as I remember these are
drop-in replacements for libnss-ldap but you'll need to configure nslcd
daemon too. Another option would be to switch to sssd which "just
wokred" for my use cases.

Best,
Alex
Reply | Threaded
Open this post in threaded view
|

Re: NSS-LDAP group preventing proper boot

Sven Hartge-5
Marc Franquesa <[hidden email]> wrote:

> Thanks for the feedback, I might give it a try to sssd (I was already
> planning to take a look).

> I seen many docs recommending to move to nss/pam-ldapd however (also for
> sssd) this requires installing many other packages and run multiple daemons
> while I could achieve the same with simply a dynamic loaded library as
> libnss-ldap.

nss-ldapd and pam-ldapd only require the nslcd daemon and not "multiple
daemons".

Also the design of nss-ldapd and pam-ldapd is vastly superior over the
older nss-ldap and pam-ldap approach, as you don't need to load the
whole libldap-machine into each and every program but just the thin
libnss-ldapd library, which acts as an interface to nslcd, which does
the heavy lifting.

Added bonus: your libldap configuration does not need to be
user-readable, which is critical in case you need to use any special
admin-DN to access the LDAP server.

Grüße,
Sven.

--
Sigmentation fault. Core dumped.