back-config design considerarions - Admin Guide fodder

[Howard Chu <hyc@symas.com>]

Some more explanation of the difference between 2.2 slapd.conf and 2.3 
would probably be helpful...

In slapd.conf there is the notion of global directives, some of which 
may be overridden in specific database clauses. This notion has been 
there in all OpenLDAP releases up to and including 2.2, and it is still 
emulated in 2.3. Which directives may be overridden, and which are 
strictly global, has never been clearly documented. In 2.3 the 
configuration is more orthogonal - only directives pertinent to actual 
backends may have an overridable global scope, and they are implemented 
using a pseudo-backend called "frontend."

The 2.3 implementation allows some ambiguities in the old system to be 
removed. In the old slapd.conf, any directives preceding the first 
"backend" or "database" directive were implicitly global scope. In 2.3, 
that is still true (for backward compatibility) but it's also possible 
to explicitly define the global directives by writing a "database 
frontend" clause and setting the directives there. Internally, these 
global directives are stored in the frontendDB structure anyway, and it 
may help clarify things if we raise awareness of this new feature. At 
least, it becomes possible to get a clearer understanding of how the 
configuration is managed under the covers. This concept is further 
reinforced by the presence of the olcDatabase=frontend entry in the 
cn=config tree.

The discussion about the default_search_base has me thinking this 
directive was in the wrong scope to begin with; it is really a feature 
of the frontendDB.

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.

All of the global config directives that are not backend-specific are 
exposed in the cn=config entry in back-config, with special exceptions 
for include files, schema, and dynamically loaded modules, which get 
their own entries underneath cn=config. In slapd.conf these directives 
can appear anywhere at all, but I have tried to encourage admins to 
gather these directives at the head of their config files. Again, it's a 
(probably vain) attempt to establish a mental model that groups all of 
these directives together. The aggregation of these directives in the 
cn=config entry further reinforces the model.

For the most part this works pretty cleanly, but there is one wart - 
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. 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.

In the actual back-config DIB there is no corresponding 
olcDatabase=config entry, and the rootpw is just exposed as an attribute 
of the cn=config root entry, along with the global directives. It may 
have been cleaner to just expose an olcDatabase=config entry with the 
rootpw attribute. While back-config currently does no ACL checking, 
exposing it as its own database object would also give us a place to 
define ACLs for it down the road, and it now occurs to me that we also 
need a place to hang overlays for the config backend as well.

I'm going to have to think some more about what it means to have a 
backend whose data is really server metadata, and expose its own 
metadata in its data.

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