RE: back-config

["Matthew Hardin" <mhardin@symas.com>]

> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org [mailto:owner-openldap-
> devel@OpenLDAP.org] On Behalf Of Howard Chu
> Sent: Sunday, March 27, 2005 12:46 PM
> To: Howard Chu
> Cc: openldap-devel@OpenLDAP.org
> Subject: Re: back-config
> 
> On a related topic, there's a question of whether to incorporate certain
> side-effects into particular operations. E.g., when defining a database
> on the server, back-bdb requires the data directory to already exist. It
> would be convenient in some situations for these dependencies to be
> created automatically in the course of processing the LDAP request. So
> LDAPadd of a Database entry creates the underlying data directory if it
> is missing. 

This makes sense- it carries a big chunk of functionality brought by the
creation of databases via LDAP and, by extension, the notion of configuring
an OpenLDAP server exclusively via LDAP, through to completion.

> Likewise, LDAPdelete of a Database entry (if it's ever
> supported, not sure yet) would delete the underlying files and
> directories.

Deleting LDAP databases and automatically removing the underlying database
files is scary but, I think, necessary. One concern I have is that, in an
attempt to deactivate a database, and in the absence of another mechanism to
do so, an admin deletes a db using an LDAPdelete command. It would be
unfortunate to inadvertently lose one's data as a result (true, it would
only happen once;). That being said, I think the side-effect is still
important in the context of server configuration via LDAP. I have the
following thoughts:

1) Add a config attribute that deactivates the database. This would be the
functional equivalent of commenting out a database definition in slapd.conf
and would immediately take the database offline. Slapadd/slapcat would still
be able to access it, though.

2) Use a control to determine execution of the side-effect, but invert its
sense from what you described below i.e., its presence causes the
side-effect to be executed. I don't like this because it doesn't follow the
use of the control in the LDAPadd case below. On the plus side, it makes you
go through some extra effort to cause the data to be deleted, somewhat akin
to the prompt "Are you sure you want to delete this file?" seen in
command-line contexts.

3) Add a global config attribute that controls the deletion of database
files. I added this after some thought on numbers 1 and 2 because it is
useful to be able to delete the underlying database files in a replica
server. I actually like this better than number 2, but this certainly
doesn't need to be exclusive of it.

> Probably there should be a control present to specify whether the
> side-effects should be executed, or whether the operation applies only
> to the DIT and not to the underlying system. It seems to me that the
> ManageDSAit control could reasonably be interpreted to fit this role.
> (I.e., if the control is present, the operation applies only to the DIT
> itself. If the control is absent, then side-effects are also executed.)

This makes sense, subject to my comments about LDAPdelete above.
 
> Howard Chu wrote:
> 
> > I've actually created a fully working slapd now with multiple bdb and
> > hdb databases and syncrepl replication using just a stub slapd.conf
> > and JXplorer to do the rest. 
> > If I didn't have to provide a rootpw for
> > cn=config I could configure the whole thing dynamically. (Perhaps we
> > should provide a default rootpw that is only valid until some explicit
> > configuration step occurs?)

What if the rootpw must be changed before cn=config becomes useful? As to
the initial value of rootpw, I don't see much difference between no initial
rootpw and a "well-known" default rootpw.

Another thought is to have the concept of a default rootpw (maybe "") but
make it settable at build time during the configure step.

Matthew Hardin
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
http://www.symas.com