[Date Prev][Date Next]
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
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
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
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)
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
> 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/