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