OpenLDAP and libnss conflict
Neil Joseph Schelly
neil.schelly at oasis-open.org
Wed May 21 19:54:41 CEST 2008
On Wednesday 21 May 2008 13:24, Alain Spineux wrote:
> > The kolab one segfaults. The Debian one isn't installed. But libldap is
> > part of a base install.
>
> The base install ? the debian one ?
Yes. apt depends on debian-archive-keyring, which depends on gnupg, which
depends on libldap2, which includes libldap_r.so.
> > If you enable LDAP logins to a system (with NSS), then
> > that library
>
> which library ?
libpam-ldap and libnss-ldap.
> > is used to start all processes, since those processes need an
> > identity (user/group rights). Then as soon as slapd (the Kolab one)
> > loads a symbol
>
> What do you mean by load a symbol ?
The functions provided by a library.
> You mean make a call to a function dynamically loaded ?
A function like ldap_bind() in libldap_r. It is part of the
system /usr/lib/libldap_r.so (and loaded when a process is started, if LDAP
NSS is used). It is also part of the openpkg version of libldap_r that is
compiled into the binaries under /kolab.
> Why do you want slapd to behave differently when the query is done
> by an usual kolab's client than by any other application ?
I want slapd to be able to start. I am not talking about client connectivity.
I want to run the openpkg-installed kolab setup on a server that uses LDAP
for it's users/groups.
> > for an ldap function, the executable in memory has two of every ldap
>
> Which executavle ? slapd ?
slapd, all the cyrus binaries, php, etc. Any package that has ldap compiled
into it rather than loading from dynamic libraries.
> A process dont inherit of the library loaded by the launcher.
> slapd use only the staticaly linked libraies compilide in it and the
> usual glibc libraries
If I load an application and NSS is using LDAP, then /lib/libnss_ldap comes
into play for that process. /lib/libnss_ldap.so.2 links
to /usr/lib/libldap_r.so.2 and that's where the overlap comes in. If I
disable LDAP in /etc/nsswitch.conf, the slapd process can start perfectly and
work perfectly.
> > LDAP clients never come into play here.
>
> Then if you have any LDAP client, how do you interact with the LDAP server
> ? And if you don't expect to query the LDAP server why do you need it ? :-)
I just mean that I'm not getting to that stage. The slapd process cannot
start. I'm not talking about a failure of a client to talk to slapd - I'm
talking about slapd not starting at all when LDAP is enabled
in /etc/nsswitch.conf.
> The OpenPKG team choose to do that that way. This reduce the problem
> and add only a small memory overhead.
>
> I things your problem should be discussed in the openpkg list.
> They have more the use to integrate openpkg into outside world. Maybe
> the already known the problem.
I'll try and contact them I guess. Nobody has tried to run Kolab on a server
with LDAP logins though? I find that hard to believe. I figured someone
would have run into this before.
--
Regards,
Neil Schelly
Senior Systems Administrator
W: 978-667-5115 x213
M: 508-410-4776
OASIS http://www.oasis-open.org
"Advancing open standards for the information society"
More information about the users
mailing list