Re: [nssldap] release 0.2 of nss-ldapd

[Howard Chu <hyc [at] highlandsun.com>]

Andreas Hasenack wrote:
> On Mon, Jun 18, 2007 at 03:29:15PM +0200, Ralf Haferkamp wrote:
> > On Tuesday 12 June 2007 09:39, Arthur de Jong wrote:
> > > > After reading your docs a bit...
> > > > Question: What is the benefit of using your nss-ldapd over the normal
> > > > padl software with nscd running?
> > [..]
> > > So in short, the biggest benefits are that nss-ldapd makes hostname
> > > lookups through LDAP work and speeds up namelookup failures if the LDAP
> > > server is not (yet) available (because the daemon part is started after
> > > the LDAP server is available).
> > There are some other advantages I can see from having a daemonized nss_ldap. 
> > Those are e.g.:
> > - No more symbol clashes when an application that uses nss_ldap is linked 
> > agains a different LDAP or SSL library (e.g. Thunderbird is a prominent 
> > example which normally uses the Mozilla LDAP libraries.). A work around for 
> > this is to link nss_ldap statically, but this creates a maintenance 
> > nightmare.
> > - Clients using nss_ldap will really only have one connection open to the LDAP 
> > Server. Now, even if using nscd, most of the time every client has multiple 
> > LDAP connection opened. (udevd being an example, because it is usually 
> > started before nscd. Or all binaries using any of the getXXent() calls, cause 
> > those are not handled by nscd).
> > - Additionally it might get easier to setup some features using a daemonized 
> > nss_ldap. (e.g. currently using nss_ldap in a kerberized enviroment is a bit 
> > of a hazzle)
> > - Some interesting new feature could be added. E.g. offline support in 
> > nss_ldap. (For that of course a caching feature would need to be added to 
> > nss_ldap)
>
> - one also doesn't have to worry about filedescriptors from the
>   application, like closing the wrong ones, etc

Depends on your communication method with the daemon. That IPC is still 
vulnerable.

> - no worries or precautions about the application forking, which is a
>   main source of grief in current nss_ldap. Same applies for threads
>   possibly.

Yes.

Still, just running a local slapd is a lot more flexible: it can be managed 
remotely, it can cache locally, and it can refresh dynamically.

--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP     http://www.openldap.org/project/