OpenLDAP and libnss conflict

[Neil Joseph Schelly]

On Thursday 22 May 2008 06:00, Bernhard Reiter wrote:
> On Wednesday 21 May 2008 19:54, Neil Joseph Schelly wrote:
> > 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.
>
> did you try compiling the Kolab Server/OpenPKG from sources completely
> while NSS ldap being enabled? With my limited understanding of the problem
> this has a chance of the symbol issues to be resolved because they might
> always come from the "host" system in this case.

I did not have LDAP enabled in NSS when I compiled it, but I did have a 
similar problem on a past system where I did, so I suspect that would not 
help.  I'll try it again, if my current line of thinking does not help.

> Another idea would be to give OpenPKG's openldap another
> copy of glibc without nss enabled. Might be archievable at least with
> chroot, but maybe with other options. Sounds like a hardcore solution ,
> though.

Along those lines, I'm trying to give OpenPKG different LDAP libraries than it 
comes with, rather than different glibc libraries.  My thinking is that this 
may be resolved by installing the Debian package for libldap2-dev and 
creating a "dummy" package of openldap in the Kolab source RPMs based on it.  
At least this way, the static and dynamic libldap* files that are present 
will all be exactly the same version.

> > 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.
>
> Recommendation is to not have local users on the Kolab Server machine
> for security reason.
> Once it serves a significant number of users,
> having a single machine for this is advisable.

It's not a machine that has multiple "users" in the common sense, but LDAP is 
used for our logins as more than one person may at times login to it. It will 
be a single dedicated machine for Kolab, but it will be administered. 
Security is maintained through LDAP users, group memberships, and sudo.  Even 
in a relatively small organization like ours, I would not want to go 
backwards to having local users for all system administrators or potential 
system administrators on each machine.  That just doesn't scale, even to our 
relatively small number of users and servers.

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