Re: [nssldap] release 0.2 of nss-ldapd

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

On Monday 18 June 2007 17:39, Buchan Milne wrote:
> On Monday, 18 June 2007, Ralf Haferkamp wrote:
> > - 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)
>
> Would this really be useful ? I've been using nss_updatedb/nss_db to have
> offline support (in conjunction with pam_ccreds). 
I don't know nss_updatedb/nss_db tool well, but IIRC it just dumbs the whole 
user database into a db-file (using getent passwd, getent group). This might 
work in smaller setups but it something that you certainly want to avoid in 
larger enviroments. On the otherhand nss_updatedb/nss_db is a more generic 
approach (i.e. it should work with every NSS module out there) than 
implementing offline caching in directly in nss_ldap.
Probably what's needed is just a smarter way to create the cached database so 
that only those entries get cached that are really needed.
 
> The only shortcomings of this approach would require a real LDAP server 
> (e.g. slapd proxy). 
Hm, I don't quite understand what you mean here.

> > 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). 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).

regards,
        Ralf

-- 
SUSE LINUX Products GmbH, Maxfeldstrasse 5, D-90409 Nuernberg
T: +49-911-74053-0
F: +49-911-74053575 - Ralf.Haferkamp@suse.com