Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1009223: sssd fails on startup: Module [memberof] not found - do you need to set LDB_MODULES_PATH
489 views
Skip to first unread message
Troy Telford
Apr 9, 2022, 3:20:03 AM4/9/22
to
Package: sssd
Version: 2.6.3-2
Severity: important
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
After upgrading, sssd wouldn't run - running in interactive/debug mode was somewhat helpful: 'sssd -i -d1' would give the message:
(2022-04-09 0:45:09): [sssd] [ldb] (0x0010): WARNING: Module [memberof] not found - do you need to set LDB_MODULES_PATH?
This eventually lead to a search for memberof.so, which is in /usr/lib/x86_64-linux-gnu/ldb/modules/ldb/memberof.so
As hinted at, setting LDB_MODULES_PATH="/usr/lib/x86_64-linux-gnu/ldb/modules/ldb" before running 'sssd -i -d1' allowed sssd to run.
I was able to apply a workaround by simply modifying the various systemd unit files (sssd-autofs.service sssd-nss.service sssd-pam.service sssd-ssh.service sssd-ifp.service sssd-pac.service sssd.service sssd-sudo.service in my case) to add:
Environment=LDB_MODULES_PATH="/usr/lib/x86_64-linux-gnu/ldb/modules/ldb/"
Then I ran 'systemctl daemon-reload; systemctl start sssd' and I am back up and running. I'm pretty sure there's a better way to inform the binaries where the LDB_MODULES_PATH is than having to update the environment modules at runtime -- I've definitely forgotten it, though. I also wouldn't be surprised if I may need to do something similar for the socket unit files for systemd -- but it's late & I'm tired...
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.16.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages sssd depends on:
ii python3-sss 2.6.3-2
ii sssd-ad 2.6.3-2
ii sssd-common 2.6.3-2
ii sssd-ipa 2.6.3-2
ii sssd-krb5 2.6.3-2
ii sssd-ldap 2.6.3-2
ii sssd-proxy 2.6.3-2
sssd recommends no packages.
sssd suggests no packages.
-- no debconf information
Version: 2.6.3-2
Severity: important
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
After upgrading, sssd wouldn't run - running in interactive/debug mode was somewhat helpful: 'sssd -i -d1' would give the message:
(2022-04-09 0:45:09): [sssd] [ldb] (0x0010): WARNING: Module [memberof] not found - do you need to set LDB_MODULES_PATH?
This eventually lead to a search for memberof.so, which is in /usr/lib/x86_64-linux-gnu/ldb/modules/ldb/memberof.so
As hinted at, setting LDB_MODULES_PATH="/usr/lib/x86_64-linux-gnu/ldb/modules/ldb" before running 'sssd -i -d1' allowed sssd to run.
I was able to apply a workaround by simply modifying the various systemd unit files (sssd-autofs.service sssd-nss.service sssd-pam.service sssd-ssh.service sssd-ifp.service sssd-pac.service sssd.service sssd-sudo.service in my case) to add:
Environment=LDB_MODULES_PATH="/usr/lib/x86_64-linux-gnu/ldb/modules/ldb/"
Then I ran 'systemctl daemon-reload; systemctl start sssd' and I am back up and running. I'm pretty sure there's a better way to inform the binaries where the LDB_MODULES_PATH is than having to update the environment modules at runtime -- I've definitely forgotten it, though. I also wouldn't be surprised if I may need to do something similar for the socket unit files for systemd -- but it's late & I'm tired...
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.16.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages sssd depends on:
ii python3-sss 2.6.3-2
ii sssd-ad 2.6.3-2
ii sssd-common 2.6.3-2
ii sssd-ipa 2.6.3-2
ii sssd-krb5 2.6.3-2
ii sssd-ldap 2.6.3-2
ii sssd-proxy 2.6.3-2
sssd recommends no packages.
sssd suggests no packages.
-- no debconf information
Timo Aaltonen
Apr 9, 2022, 9:10:03 AM4/9/22
to
Troy Telford kirjoitti 9.4.2022 klo 10.13:
> Package: sssd
> Version: 2.6.3-2
> Severity: important
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate ***
>
> After upgrading, sssd wouldn't run - running in interactive/debug mode was somewhat helpful: 'sssd -i -d1' would give the message:
> (2022-04-09 0:45:09): [sssd] [ldb] (0x0010): WARNING: Module [memberof] not found - do you need to set LDB_MODULES_PATH?
>
> This eventually lead to a search for memberof.so, which is in /usr/lib/x86_64-linux-gnu/ldb/modules/ldb/memberof.so
>
> As hinted at, setting LDB_MODULES_PATH="/usr/lib/x86_64-linux-gnu/ldb/modules/ldb" before running 'sssd -i -d1' allowed sssd to run.
>
> I was able to apply a workaround by simply modifying the various systemd unit files (sssd-autofs.service sssd-nss.service sssd-pam.service sssd-ssh.service sssd-ifp.service sssd-pac.service sssd.service sssd-sudo.service in my case) to add:
> Environment=LDB_MODULES_PATH="/usr/lib/x86_64-linux-gnu/ldb/modules/ldb/"
>
> Then I ran 'systemctl daemon-reload; systemctl start sssd' and I am back up and running. I'm pretty sure there's a better way to inform the binaries where the LDB_MODULES_PATH is than having to update the environment modules at runtime -- I've definitely forgotten it, though. I also wouldn't be surprised if I may need to do something similar for the socket unit files for systemd -- but it's late & I'm tired...
The reason if fails is probably that libldb got a new version and sssd
> Package: sssd
> Version: 2.6.3-2
> Severity: important
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate ***
>
> After upgrading, sssd wouldn't run - running in interactive/debug mode was somewhat helpful: 'sssd -i -d1' would give the message:
> (2022-04-09 0:45:09): [sssd] [ldb] (0x0010): WARNING: Module [memberof] not found - do you need to set LDB_MODULES_PATH?
>
> This eventually lead to a search for memberof.so, which is in /usr/lib/x86_64-linux-gnu/ldb/modules/ldb/memberof.so
>
> As hinted at, setting LDB_MODULES_PATH="/usr/lib/x86_64-linux-gnu/ldb/modules/ldb" before running 'sssd -i -d1' allowed sssd to run.
>
> I was able to apply a workaround by simply modifying the various systemd unit files (sssd-autofs.service sssd-nss.service sssd-pam.service sssd-ssh.service sssd-ifp.service sssd-pac.service sssd.service sssd-sudo.service in my case) to add:
> Environment=LDB_MODULES_PATH="/usr/lib/x86_64-linux-gnu/ldb/modules/ldb/"
>
> Then I ran 'systemctl daemon-reload; systemctl start sssd' and I am back up and running. I'm pretty sure there's a better way to inform the binaries where the LDB_MODULES_PATH is than having to update the environment modules at runtime -- I've definitely forgotten it, though. I also wouldn't be surprised if I may need to do something similar for the socket unit files for systemd -- but it's late & I'm tired...
needs a rebuild. Could you try building the current package against
current samba?
--
t
Timo Aaltonen
Apr 9, 2022, 9:40:04 AM4/9/22
to
--
t
Chris Boot
Apr 9, 2022, 12:00:03 PM4/9/22
to
On 09/04/2022 14:26, Timo Aaltonen wrote:
> Timo Aaltonen kirjoitti 9.4.2022 klo 16.01:
[...]
> Timo Aaltonen kirjoitti 9.4.2022 klo 16.01:
>> The reason if fails is probably that libldb got a new version and sssd
>> needs a rebuild. Could you try building the current package against
>> current samba?
>
> oh well, it actually fails to build now, so I need to fix that anyway
I spent some time on this today as I ran into the same issue. There are
>> needs a rebuild. Could you try building the current package against
>> current samba?
>
> oh well, it actually fails to build now, so I need to fix that anyway
two issues as you've probably already worked out:
1. The LDB module should probably be installed in
/usr/lib/$(DEB_HOST_MULTIARCH)/samba/ldb. symlinking memberof.so to that
directory on my system fixed that part of the problem for me.
2. The Samba 4.16 source uses C11 features now, which is why the build
fails. The following patch fixed that issue for me:
--- sssd-2.6.3.orig/Makefile.am
+++ sssd-2.6.3/Makefile.am
@@ -137,7 +137,7 @@ if HAVE_GCC
-Werror-implicit-function-declaration -Winit-self \
-Wmissing-include-dirs \
-fno-strict-aliasing \
- -std=gnu99
+ -std=gnu11
endif
CMOCKA_CFLAGS = -fno-lto
Thanks for maintaining sssd.
Cheers,
Chris
--
Chris Boot
bo...@debian.org
Chris Boot
Apr 9, 2022, 2:30:03 PM4/9/22
to
On 09/04/2022 16:54, Chris Boot wrote:
> On 09/04/2022 14:26, Timo Aaltonen wrote:
>> Timo Aaltonen kirjoitti 9.4.2022 klo 16.01:
> [...]
>>> The reason if fails is probably that libldb got a new version and
>>> sssd needs a rebuild. Could you try building the current package
>>> against current samba?
>>
>> oh well, it actually fails to build now, so I need to fix that anyway
>
> I spent some time on this today as I ran into the same issue. There are
> two issues as you've probably already worked out:
>
> 1. The LDB module should probably be installed in
> /usr/lib/$(DEB_HOST_MULTIARCH)/samba/ldb. symlinking memberof.so to that
> directory on my system fixed that part of the problem for me.
>
> 2. The Samba 4.16 source uses C11 features now, which is why the build
> fails. The following patch fixed that issue for me:
Actually it looks like this should be unnecessary with samba
> On 09/04/2022 14:26, Timo Aaltonen wrote:
>> Timo Aaltonen kirjoitti 9.4.2022 klo 16.01:
> [...]
>>> The reason if fails is probably that libldb got a new version and
>>> sssd needs a rebuild. Could you try building the current package
>>> against current samba?
>>
>> oh well, it actually fails to build now, so I need to fix that anyway
>
> I spent some time on this today as I ran into the same issue. There are
> two issues as you've probably already worked out:
>
> 1. The LDB module should probably be installed in
> /usr/lib/$(DEB_HOST_MULTIARCH)/samba/ldb. symlinking memberof.so to that
> directory on my system fixed that part of the problem for me.
>
> 2. The Samba 4.16 source uses C11 features now, which is why the build
> fails. The following patch fixed that issue for me:
2:4.16.0+dfsg-6. The failing static_assert() was a patch by Debian, now
reverted, so gnu11 is not needed after all.
--
Chris Boot
bo...@debian.org
0 new messages