Re: [nssldap] release 0.2 of nss-ldapd

[Ralf Haferkamp <rhafer [at] suse.de>]

On Monday 18 June 2007 22:49, Howard Chu wrote:
> Ralf Haferkamp wrote:
> > On Monday 18 June 2007 17:39, Buchan Milne wrote:
> >> On Monday, 18 June 2007, Ralf Haferkamp wrote:
> >>> Note: Some of the above stuff could also get realized by setting up a
> >>> local instance of the OpenLDAP server as a caching proxy (having
> >>> nss_ldap talking to it via LDAPI), but I still like the idea of a
> >>> daemonized nss_ldap very much.
> >>
> >> 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).
>
> The two ideas aren't mutually exclusive. You could use syncrepl to keep a
> proxy cache up to date, and either pull down a complete DB or just refresh
> the entries you've already cached.
Yes.

> > 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).
>
> Yes, ultimately you still need some IPC mechanism and protocol to talk to
> whatever local daemon you choose. I think using LDAP is still better than
> inventing your own. As a purpose-built NSS module I would just locally
> hardcode a "send_search_request" function with a "read_search_reply"
> function and avoid using libldap directly. Sending queries over ldapi://
> would require very little additional code.
Hm, ok I got your points. But I am still not quite convinced yet :). 
I'd probably go for a protocol that maps closer to the API of NSS, e.g. 
similar to what winbind or nscd use "on the wire" (IIRC). Adding pam_ldap to 
the mix (which is of course a good candidate to also use such a daemon) would 
of course mean to add PAM specific operations as well. But in the end that 
will result in having the NSS and PAM modules really small and simple and 
having most of the intelligence inside the daemon. I'd probably prefer that. 

-- 
Ralf