Re: back-config design considerarions - Admin Guide fodder

[Michael Ströder <michael@stroeder.com>]

Howard Chu wrote:
> 
> I still find the juggling between back-config and frontendDB a bit
> confusing (and I wrote the darn thing...) which is another reason for
> writing out this explanation. It's a bit like a Klein bottle - the
> frontendDB encompasses all of the backends, but the config backend also
> contains the frontend and all the backends.

Howard, glad you come up with this discussion. While playing around with
web2ldap and its LDIF templates to ease creation of database backends
I'm still trying to make up my mind about back-config:

If I'm using option -f slapd.conf and -F configdir/ together which
config data is authorative? Well, everything from slapd.conf gets
automagically converted to LDIF in configdir/. But if something's
changed in slapd.conf and slapd is again started with -f and -F which
config data wins? I'd guess most users would expect slapd.conf to win
but this would violate the concept of changing the config via LDAP.

IMHO it's a can of worms. Maybe it's worth considering to disallow use
of -f and -F together and instead provide a separate config conversion
tool under sbin/ which is clearly used *once* by the server's admin.

Also consider the support cases regarding schema on openldap-software
list: Often people don't use the recent schema files and they experience
duplicate schema definitions if schema elements are hard-coded (moved to
schema_prep.c). With various LDIF files in configdir/ upgrading schema
might be harder.
(I'm against using hard-coded schema definitions anyway but we already
discussed that...)

> back-config only allows its rootdn user to access it, and a mechanism is
> needed to configure authentication credentials for this rootdn. (The
> rootdn itself is hardcoded to "cn=config" of course.) One possibility is
> to use a SASL Bind and use sasl-regexp/authz-regexp to map an admin's
> SASL username to the cn=config DN.

In case of using ldapi:// with SASL EXTERNAL I'd vote for mapping user
'root' (UID 0) and the user under which slapd was started (-u) to cn=config.

Err...are sasl-regexp/authz-regexp global or backend-specific directives?

> But for Simple Bind, we need a rootdn
> and rootpw. For bootstrapping from a slapd.conf file you can use a
> "database config" clause and set the rootpw there.

Hmm, again I'd vote for having a basic setup solely by LDIF files in
configdir/ and ignore slapd.conf completely. This isn't more complicated
to install than a small bootstrap-slapd.conf.

With back-config it's much easier to implement tools to either write a
basic setup to LDIF files in configdir/ or to tweak the configuration
via LDAP because one can use existing modules for LDAP/LDIF. But the
current situation mixing both config sources makes it hard to decide
which route to go.

My conclusion:
Drop -f slapd.conf completely in 2.3.x and rather develop good setup
tools...

Ciao, Michael.