OpenLDAP and libnss conflict

[Alain Spineux]

On Wed, May 21, 2008 at 6:38 PM, Neil Joseph Schelly
<neil.schelly at oasis-open.org> wrote:
> On Wednesday 21 May 2008 12:29, Alain Spineux wrote:
>> Which slapd segfault ? The openpkg or the debian one ? Are you trying
>> to run both at the same time ?
>
> The kolab one segfaults.  The Debian one isn't installed.  But libldap is part
> of a base install.

The base install ? the debian one ?

> If you enable LDAP logins to a system (with NSS), then
> that library

which library ?

> 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 ?
You mean make a call to a function dynamically loaded ?
Why do you want slapd to behave differently when the query is done
by an usual kolab's client than by any other application ?

> for an ldap function, the executable in memory has two of every ldap
Which executavle ? slapd ?
> function. It's the the statically compiled-in kolab ones and it's got the
> Debian ones that were used to load the process in the first place.

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

Try this

# ldd /kolab/libexec/openldap/slapd
        linux-gate.so.1 =>  (0x005d8000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x445f2000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x44630000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x446c2000)
        libpthread.so.0 => /lib/i686/nosegneg/libpthread.so.0 (0x0097a000)
        libc.so.6 => /lib/i686/nosegneg/libc.so.6 (0x443e6000)
        /lib/ld-linux.so.2 (0x443c4000)

They are all glibc libraries

>
>> When you make some ldap queries, the client should load the libraries
>> it want (probably the debian one)
>> and not disturb the openpkg sldapd process
>
> 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 ? :-)

> The slapd process cannot start as a
> result of this.  I agree that LDAP clients installed outside the /kolab tree
> would not be susceptible to this though as they load dynamic libraries.
>
>> I thing the problem is somewhere else than in a library problem.
>> Except if you have installed installed or upgraded some debian package
>> after kolab install ?
>
> There were no install/upgrades afterword.  It works fine until I enable LDAP
> logins to the system.  I can disable ldap in NSS and it works fine again.
> strace outputs show that the process crashes as soon as it tries to run any
> ldap functions

?? strace don't show the internal functions called by the process, but
only system call

> which are essentially loaded from both the system libraries
> and the slapd binary at the same time.

>
> Perhaps the better question I should be asking is why doesn't the openpkg
> installation use dynamically-loaded libraries?  I'll bet this can be solved
> very easily if it did.  Is there an easy option for that or would I have to
> modify the entire install script setup by hand to accomplish it?

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.


Regards.

>
> --
> 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"
>



-- 
Alain Spineux
aspineux gmail com
May the sources be with you