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