On the Raspberry Pi for the nss_ldap package the library /lib/nss_ldap.so.1 is created and it is not working. On AMD64 the libraries are /lib64/libnss_ldap.so.2 and /usr/lib32/libnss_ldap.so.2 Creating a simlink on the Raspberry Pi to /lib/libnss_ldap.so.2 enables logging in. Next to that I have on the Raspberry Pi problems with an encrypted bindpw in /etc/ldap.conf. I have not jet pinpointed the cause. (missing kernel module/library?) Reproducible: Always Steps to Reproduce: 1.Install nss_ldap pam_ldap and openldap 2.enable linux login through ldap in pam.d, ldap.conf an nsswitch.conf 3.try to login
Forget my mentioning of the problem with encrypted bindpw. While examining and testing, /etc/openldap/ldap.conf and /etc/ldap.conf got mixed up. The first accepts an encrypted bindpw, the second not.
please attach the full build log of nss_ldap and your emerge info. all bugs reports should include these things. it is hard for us to triage/debug w/out them.
I can confirm this bug too. Workaround by creating the symlink as explained: /lib/libnss_ldap.so.2 -> /lib/nss_ldap.so Raspberry Pi2 (ARMv7) CFLAGS="-O2 -pipe -march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard" CHOST="armv7a-hardfloat-linux-gnueabi"
Btw: I guess using qemu and compiling nss_ldap will bring the issue up... If needed i'll rebuild nss_ldap again to provide the files.
Created attachment 435666 [details] emerge --info Sorry I missed your request
Created attachment 435668 [details] sys-auth:nss_ldap-265-r5:20160528-205134.log And the emerge log
I had to rerun it as my log had disappeared
nothing to do here for arm@
Hi all, I faced the same problem (4 years later) and found a correction which could be applied as a Gentoo patch. Actually, the configure script does not detect that we are running with a glibc because its way for such detection is: test "$target_os" = "linux" -o "$target_os" = "linux-gnu" and target_os is the end of the CHOST, which for a Pi used to be "armv7a-hardfloat-linux-gnueabi" and is now "armv7a-unknown-linux-gnueabihf". I managed to make it work adding -o "$target_os" = "linux-gnueabihf" in both configure (line 4489) and configure.in (line 118) file, so a quick patch could easily be made. Note that the downloaded source does not seem to be up to date with the visible sources under GitHub as the latter have an additional (but not working nowadays) -o "$target_os" = "linux-gnueabi"
Not sure if I've just been bitten by this, or a variation of this... but I've ended up with: $ qlist nss_ldap | grep lib | xargs ls -l -rwxr-xr-x 1 root root 89192 Mar 22 09:11 /usr/lib64/libnss_ldap-.so lrwxrwxrwx 1 root root 25 Mar 22 09:11 /usr/lib64/libnss_ldap.so. -> ../../lib/libnss_ldap.so. This was the result of installing nss_ldap-265-r6. I've binary installed my backup of -r5 but had no chance to do any further testing, but it has happened on 3 of my Gentoo installs.
(In reply to Dan Goodliffe from comment #10) > Not sure if I've just been bitten by this, or a variation of this... but > I've ended up with: > > $ qlist nss_ldap | grep lib | xargs ls -l > -rwxr-xr-x 1 root root 89192 Mar 22 09:11 /usr/lib64/libnss_ldap-.so > lrwxrwxrwx 1 root root 25 Mar 22 09:11 /usr/lib64/libnss_ldap.so. -> > ../../lib/libnss_ldap.so. > > This was the result of installing nss_ldap-265-r6. I've binary installed my > backup of -r5 but had no chance to do any further testing, but it has > happened on 3 of my Gentoo installs. Thanks, I can undo that part of my changes but not got time to investigate fully yet. I’ll undo it shortly so things continue to work, thanks!
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=46d10b9f93d82e1017711ee052b40d912e453b8c commit 46d10b9f93d82e1017711ee052b40d912e453b8c Author: Sam James <sam@gentoo.org> AuthorDate: 2021-03-22 18:10:05 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-03-22 18:10:29 +0000 sys-auth/nss_ldap: change libdir logic This restores the (odd-looking) previous behaviour for now, although it seems like _that_ still needs tweaking for ARM. Fixes: 8b5133c451fba89337cf87bea32a1aec61184b32 Bug: https://bugs.gentoo.org/581306 Signed-off-by: Sam James <sam@gentoo.org> sys-auth/nss_ldap/{nss_ldap-265-r6.ebuild => nss_ldap-265-r7.ebuild} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=70371278eb61ef1c4d2e0285bfecbe11dc542641 commit 70371278eb61ef1c4d2e0285bfecbe11dc542641 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-03-22 18:14:14 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-03-22 18:14:14 +0000 sys-auth/nss_ldap: actually stage the libdir change Bug: https://bugs.gentoo.org/581306 Signed-off-by: Sam James <sam@gentoo.org> sys-auth/nss_ldap/{nss_ldap-265-r7.ebuild => nss_ldap-265-r8.ebuild} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fd52dbeb4c26bcb6b5331def1eb65c1339f2036a commit fd52dbeb4c26bcb6b5331def1eb65c1339f2036a Author: David Seifert <soap@gentoo.org> AuthorDate: 2021-04-11 21:11:06 +0000 Commit: David Seifert <soap@gentoo.org> CommitDate: 2021-04-11 21:11:06 +0000 sys-auth/nss_ldap: Fix libdir symlinks Bug: https://bugs.gentoo.org/581306 Bug: https://bugs.gentoo.org/780108 Package-Manager: Portage-3.0.18, Repoman-3.0.3 Signed-off-by: David Seifert <soap@gentoo.org> sys-auth/nss_ldap/files/nss_ldap-265-libdir.patch | 31 ++++++++++++++++++++++ ...s_ldap-265-r8.ebuild => nss_ldap-265-r9.ebuild} | 10 +++---- 2 files changed, 36 insertions(+), 5 deletions(-)
Let us know if not resolved.
And the story continues. Again no symlink. This time not for lack of trying, but because the library name has changed from /lib/libnss_ldap.so.1 to /lib/nss_ldap.so.1. It gives an error: "QA Notice: Missing soname symlink(s): lib/libnss_ldap.so.2 -> nss_ldap.so.1" and a few line later: "QA Notice: Symbolic link /usr/lib/libnss_ldap.so.2 points to /lib/libnss_ldap.so.2 which does not exist." Creating the symlink: /lib/libnss_ldap.so.2 -> nss_ldap.so.1 gets it working. I do not have a log at present. I haven't yet installed a logger and emerge has cleaned /var/temp/portage/. I'll run it later when I have a logger installed. I emerged sys-auth/nss_ldap-265-r11
It's not clear to me why the library name would've suddenly changed.
(In reply to Sam James from comment #17) > It's not clear to me why the library name would've suddenly changed. This is the first time in 6 years I create a fresh raspberry pi installation and I now encounter in essence the same issue as 6 years ago. I now look again at my original post, six and a half years ago and I'm mistaken. Then already the library had the name without "lib" preceding it. I still do not understand why a different name is used on an ARM. It anyhow explains why the symlink creation fails. Is it possible to add an architecture dependent statement in the ebuild? Like: `dosym ../../$(get_libdir)/nss_ldap.so.1 libnss_ldap.so.2` Or possible on the presence of nss_ldap.so.1
Created attachment 825063 [details] emerge log Here is the emerge log. On looking further I see there is now an alternative package "nss-pam-ldap", a spinoff from "nss_ldap". Only it is masked on ARM.:-(
Ah, thanks.
tinderbox_arm has reproduced this issue with version 265-r11 - Updating summary.
