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

Re: back-config design considerarions - Admin Guide fodder

Michael Ströder wrote: 
 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.

I thought the slapd(8) manpage was pretty clear about this. If you use both -f and -F together then the slapd.conf file is converted and written to the config dir. You are expected to only use this combination of switches once, for bootstrapping, and then never use the slapd.conf file ever again. (Rename it, delete it, whatever.)

 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.

For now I'm opposed to creating a new tool specifically for this purpose. (Note that any of the slap* tools will also provide this functionality. I use slaptest since it has no other side effects.) I think if the point of the -f / -F combination isn't clear enough then we should just update the docs to make it more clear.

 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 would be pretty much impossible without hard-coded schema...

Perhaps we should change the OpenLDAP install step to always create a new schema directory and install its files there. (Rename any existing schema directory to something else to move it out of the way.) This is a pretty trivial problem, we shouldn't have to keep dealing with the support issues over and over.

> 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.

I don't think we can do these things by default; it's likely that user 'root' is explicitly mapped at some sites. And it's pointless if slapd isn't listening on ldapi. Probably instead, we should allow the hardcoded rootdn to be overridden.

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


Global.

> 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...

I don't think dropping slapd.conf completely will fly. For the moment, except for the "subordinate" keyword, OpenLDAP 2.3 is backward compatible with OpenLDAP 2.2 slapd.conf, and I think it's important to maintain compatibility as much as possible. While ultimately using the configdir is the right way to go, it is really an optional feature today - admins can totally ignore its existence and continue to use 2.3 in exactly the same way as they've used previous releases. It *has* to be optional in the current 2.3 release because configdir support doesn't exist for every backend/overlay yet. In this respect we're obviously in a transitional state. When we get to full configdir functionality, we can talk about dropping slapd.conf permanently.

re: deciding which route to go - anyone who adopts the configdir approach is expected to be on a one-way trip, never returning to use slapd.conf ever again. Ideally that would be 100% of deployments, but since we're still missing support for pieces, that's obviously not going to happen soon.

re: developing good setup tools - yes, absolutely. Whatever ideas you may have here, we can obviously use already.

--
 -- Howard Chu
 Chief Architect, Symas Corp.  http://www.symas.com
 Director, Highland Sun        http://highlandsun.com/hyc
 OpenLDAP Core Team            http://www.openldap.org/project/