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 <ames...@rsh2.donotuse.de> 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 >
