[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: passwd backend and RFC 2307

> >> > Why doesn't the passwd backend do as rfc 2307 says things should be?
> >> RFC 2307 doesn't say how things "should be".  It's informational
> >> and should be viewed as "one way to do things".  There are obviously
> >> many ways one can represent users/accounts in a directory.
> >
> > Of course, but most RFC are that way.
> All Informational RFCs are that way.   My point is that RFC 2307
> is not Standard Track and should not be viewed as saying how things
> "should be."   This is not to say that RFC 2307 does not offer a
> reasonable way of doing things.

 I shouldn't have say "should". But I mean that this RFC gives a trivial way
to map the /etc/{passwd,shadow} information in a simple way, and that the
fact that isn't a standard track RFC doesn't mean much, as several important
RFCs aren't either.

> >And this RFC (if you search for
> >posixAccount) is implemented in several places. One interesting place where
> >it's implemented is in libnss-ldap...
> Many informational RFCs are widely implemented, including
> inetOrgPerson (RFC 2798).
> IIRC, back-passwd uses only Standard Track schema.

 Yep... I get coredumps if I don't include cosine & nis schema files.
back-passwd error handling should be improved too...

> > I have already done something that works. I will post a patch in a few
> >days (I'd like to reach the point when this can actually be used to
> >authenticate a user with pam/nss).
> One thing should be noted is that back-passwd only supports search.
> I think it would be generally interesting to add support for bind
> and other operatons (compare, passwd-change exop).

 That's the idea.

 With these changes, it will be posible to just drop OpenLDAP into any UNIX
machine and automatically have their users exported to the whole net. If the
only use of an LDAP server is to handle a few dozens of users, mandating a
ldiff database is overkill.