RE: Yet Another Beginner Question

[Jan-Piet Mens <jpm@Retail-SC.com>]

Hello Howard,

that is an interesting view; I hadn't thought of that one. What comes to mind
though, is that if your source of data is (e.g.) /etc/passwd directly, how
do you, if at all, synchronize it on other systems ? What I mean is that using
NSS for example, I can have a multitude of LDAP slave servers as backups. I
don't immediately see the possibility of doing that with your solution. Can you
give us a little insight as to how you cope with failures on your master /etc/passwd
system ?

Why did you develop your UnixAuth agent ? Is it because the passwd backend back-passwd
doesn't support writing ? Would it not have been easier to implement that ?
And of course: is UnixAuth available to us mortals ? :-)

Regards,
	-JP


On Fri, 29 Mar 2002, Howard Chu wrote:

> > -----Original Message-----
> > From: owner-openldap-software@OpenLDAP.org
> > [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Mark Lehrer
>
> > Also, what is the best way to deal with keeping both the ldap database
> > and /etc/passwd, /etc/shadow, and /etc/group, /etc/aliases in sync?  I
> > would prefer to keep using the standard adduser tools, and vi to
> > handle the aliases; would it make sense to have an periodic cron job
> > blow away the LDAP info and re-load it, or is it better to re-generate
> > these files from the LDAP database?
>
> The best thing to do is to avoid the synchronization step in the first
> place.
> PAM/NSS solutions have already been discussed in someone else's reply. To
> keep your existing standard adduser tools working, I suggest using an LDAP
> backend that parses /etc/passwd et. al directly. Symas Corp. has a UnixAuth
> agent that does exactly this, presenting an LDAP read/write interface to
> the /etc/passwd, /etc/shadow, and /etc/group files. Ours is fairly
> efficient,
> written in C, but you could achieve most of the functionality using
> back-shell or back-perl and some parsing scripts. We also handle
> /etc/aliases and several
> other sendmail config files directly. PAM has got a lot of momentum behind
> it, but we believe there's value and security in non-invasive solutions that
> keep your existing infrastructure intact, while still making it more
> manageable.
> Reliability is a big reason to take our approach; you'll always be able to
> login even if your LDAP service or network connection dies. Compatibility
> and performance are two more reasons; NSS searches thru LDAP can be slow and
> the NS Cache Daemon is not known for its reliability, and there are still
> programs out there that like to use fgetXXent() to walk thru the tables.
>
> Note that rolling your own solution here probably isn't something you should
> do as an LDAP beginner, unless you're already proficient with shell or perl
> programming, and you're comfortable setting up slapd ACLs to protect the
> information you're exposing. Making a mistake on the ACLs could be
> disastrous.
>
>   -- Howard Chu
>   Chief Architect, Symas Corp.       Director, Highland Sun
>   http://www.symas.com               http://highlandsun.com/hyc
>   Symas: Premier OpenSource Development and Support
>
>