Re: back-config

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Matthew Hardin writes:
>> To: Howard Chu
>>
>> 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.

Is there an attribute in back-config which reads/updates the DB_CONFIG
file in the database directory?  Otherwise I think this feature would
encourage the use of unconfigured bdb databases.

Also, even assuming I intended to delete the database files (we
regenerate them from LDIFs anyway), I might be upset if an LDAPdelete
unexpectedly deleted a DB_CONFIG I had been sweating to produce.  In
particular if the database was deleted due to a reorganization and I
intended to recreate a similar database afterwards.  I might have saved
the old config entry but not the file...

Anyway, I think these might be useful options, but they'd be a bad
default.

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

Though I suspect some of this in any case would be much nicer
along with a companion tool to administer the database.

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

Overloading the meaning of controls sounds like a bad idea to me.
Better create another control, e.g. a 'server command' control which can
contain implementation-specific textual commands.  An alternative would
be to let updates of attributes in a "cn=:control:,cn=config" entry
perform such operations.

-- 
Hallvard