OpenLDAP and libnss conflict

[Alain Spineux]

On Wed, May 21, 2008 at 7:54 PM, Neil Joseph Schelly <
neil.schelly at oasis-open.org> wrote:

I just understood slapd was segfaulting at startup !
You never spoke about statup before !
This would have helped a bit !

I thing that when slapd start, it call a function related to NSS and
regarding
the configuration in nsswitch.conf try to get the answer from LDAP that is
not
yet started !

Maybe slapd need to know uid of kolab, kolab-s, kolab-r users and groups to
start !
Then you must configure your NSS to look first into your existing passwd and
group file,
or something like that.


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


ldap_bind() is part of the LDAP api and should not be used by slapd
and don't event exist in slapd. Then slapd could not "load" this "symbol"
Why do you thing ldap_bind or any other functions part of the LDAP api
is used by slapd


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



-- 
Alain Spineux
aspineux gmail com
May the sources be with you
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/users/attachments/20080521/3b66b72b/attachment.html>