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

RE: back-config again



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

> At 08:40 PM 3/28/2004, Howard Chu wrote:
> >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.
>
> Here are some thoughts on a possible bootstrapping scheme:
>
> ldapadd -H ldapi:// -Y EXTERNAL
> dn: cn=config
> moduleDirectory: /path/to/modules
> modules: hdb bdb
> backend: foo OPTIONS
> directory: /path/to/
> ...
>
> This would create a configuration instance, backed by
> a particular kind of database backend (could be LDIF)
> with automagical creation of additional config entries:
>         cn=config,ou=modules
>         cn=config,ou=modules,cn=foo
>         cn=config,ou=backends,cn=foo
>         cn=config,ou=databases,cn=config
>
> Note that optional OPTIONS specified on the backend line
> would be used to bootstrap cn=config,ou=backends,cn=foo
> where that backend allowed such.  HDB, BDB, and LDBM don't
> backend-specific options (they do have database specific
> options), but other backends can.
>
> Also note the use of ldapi:// and -Y EXTERNAL for the
> initial add.  The add would be allowed if the client's
> uid was same as server's uid.

Some of the automagical stuff is OK. I wonder if some of those OUs are even
necessary; if they can be bootstrapped as attributes then it doesn't seem
they have any need to live in separate entries. The cn=config entry can carry
all the information that is part of slapd.conf's global configuration now. It
may be useful to subdivide a bit by tacking on various auxiliary classes,
e.g. collecting all the TLS config into an aux class, all the SASL config in
an aux class, etc. Or they can all be child entries of cn=config. I guess
keeping subsystems in their own entries makes the internal module boundaries
cleaner.

Support for ldapi is spotty, we should probably just continue to use slapadd.
One possible benefit from this approach is that bootstrapping a directory
only requires editing a single input LDIF file. I.e., currently you have to
define some things in slapd.conf, and then add some similar things in your
initial LDIF load. ("Did you remember to create an entry for the suffix/base
of your database?") Having all this done in a single pass may streamline that
a bit.

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