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

back-config design considerarions - Admin Guide fodder

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/