RE: back-config again

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]

> At 07:29 PM 3/28/2004, Howard Chu wrote:
> >More notes on LDAP-enabling the slapd configuration mechanism...
> >
> >One step towards making the slapd configuration easily
> presentable in LDAP is
> >to use LDIF for the config file format. There will be a
> cn=config backend
> >implicitly defined, and everything will branch out underneat this.
>
> Well, if we're assuming we only presenting the configuration file
> using LDAP, yes, that does seem like an early step.
>
> However, I question whether "presenting the configuration file using
> LDAP" is best approach.
>
> I instead thinking we should consider REPLACING the configuration file
> with a structured, object-oriented configuration base (e.g., directory
> objects) and (almost all) configuration would simply be done via LDAP.

I think we're talking about the same thing here. Yes, the configuration
mechanism itself is object-oriented.

> LDIF would only be used as input to slapadd/ldapmodify and output to
> slapcat/ldapsearch.  That is, slapd would not read any
> configuration file.
>
> (Now, maybe the configuration backend would sit atop a LDIF backend,
> but the configuration backend could just as well sit ontop of
> BDB/HDB/LDBM.)
>
> However, this is a far larger architectural shift than what
> you propose.

Clearly if there is a cn=config tree somewhere, we can execute an LDAPsearch
against it and save the result as an LDIF file. The actual implementation of
the database is definitely a separate issue, but for bootstrapping purposes
the LDIF file is useful to have around.

Having a real underlying database isn't particularly good or bad; the
important point is tying objects and objectclasses to actual code. I believe
that association of code to entries and objectclasses should be done in a
specialized backend in its own right. One key feature of this backend is an
implicit set of DIT Structure rules. E.g., entries of the OpenLDAPDatabase
objectclass can only be created under "ou=Databases,cn=Config". And so on...
We can tie a database backend underneath it if that proves to be useful, but
using overlays, that decision can be deferred till much later.

> >The idea is somewhat reminiscent of the back-ftree backend.
> >
> >There are still some issues regarding order-dependent config
> info (like ACLs,
> >sasl-regexp, database order). I have an idea to use
> attribute tagging to help
> >out here, e.g.:
>
> Yuk.
>
> I rather we just change the format to include a precedence field:
>         acls: 1: access to attrs=userPassword by anon auth
>         acls: 2: access to * by self write by users read

That's fine. Either way we have a renumbering issue when modifying these
things, which is the more annoying problem. Allowing fractions in the
precedence field would get around that I guess.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support