Re: [nssldap] release 0.2 of nss-ldapd

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

Klaus Steinberger wrote:
> Am Montag 18 Juni 2007 schrieb Ralf Haferkamp:
> > On Monday 18 June 2007 17:39, Buchan Milne wrote:
>
> > > In disucssions with Howard Chu, he indicated that if he were to re-design
> > > nss_ldap, it would be a slapd caching proxy ...
> > Or even a local syncrepl replica instead of a proxy (when the source is a
> > syncrepl aware LDAP Server). But this would still mean that the NSS module
> > needs to link against some LDAP client library, which will get you back to
> > the symbol clashing issue (unless you link statically, which has other
> > disadvantages).
>
> A syncrepl replica would not be a good choice, as it would only talk with 
> OpenLDAP. There are other LDAP Servers out there (and for some good reason) 
> like Novell's Edirectory.

It doesn't have to only use syncrepl.

> Also I think a proxy slapd is a bad choice too for those reasons:
>
> - a too big thing for every workstation , like shooting with guns on little 
> birds

Considering that slapd has been embedded into cell phones I don't think this is 
a valid concern.

> - too complicated setup

For dedicated use as an nss_ldap mechanism the setup can be totally canned and 
automated.

> - it will have maybe also trouble with some other LDAP servers

Nonsense.

> So please do it "KISS"
>
> From what I have read in the discussion, a daemonized nss_ldap sounds like a 
> interesting solution, it looks like it really solves some of the trouble I 
> see with nss_ldap (even blocking the whole net on a dead nameserver). And it 
> seems to be a simple enough setup.

Your definition of "Simple" is broken though; a special-purpose nss_ldap daemon 
still doesn't solve the pam_ldap problem which has just as many conflict issues 
as nss_ldap. The problem remains the same, no matter what labels you stick onto 
it. You need an IPC mechanism to link the pam application to the daemon. You 
need to define a protocol for communication over this IPC. Any good solution 
that you come up will have to address the same set of issues. In the end what 
seems like a compact, simple idea will bloat. The only way to control the bloat 
is to limit yourself to a very small set of protocol operations, and use a very 
small API. Currently a lot of #ifdef hell in the pam/nss_ldap source is there 
to accommodate multiple target servers and multiple LDAP APIs. Standardize on a 
single API and that simplifies things immensely.
--
  -- 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/