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

Re: back-config

Hallvard B Furuseth wrote:

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.

There isn't, but now that you mention it, I think it might be a good idea. We could just define an attribute whose contents are written directly to the DB_CONFIG file, uninterpreted. It would only be written if no DB_CONFIG file already existed. That would allow us to perform all relevant configuration from one place, without having to constantly add new BDB APIs to the back-bdb code.

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

Definitely would not want to disturb the underlying data by 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

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

Don't go there. If the admin tool is going to be useful, it needs to be remotely accessible. Having gone through the pain of installing iPlanet a few years ago, I think it's ridiculous to have to install a full-blown web server just to be able to complete the configuration of the LDAP server. It's even more ridiculous considering that the admin server is as unstable as the directory server, and without the admin server the directory server is rendered inert. Requiring a separate admin server just makes the overall workload of administering a directory server harder.

If the back-config solution can't be used to administer everything then it's pointless. Anyone working with LDAP already has a complete LDAP toolset at their disposal, there's no reason not to use it for the server administration. As I already noted, I can create a fully running configuration right now using JXplorer, and I imagine there are plenty of other LDAP gui tools available that would work as well. There's no reason to bring a new tool in the picture (and I have no interest in spending the considerable time to develop such a companion tool).

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.

I would not want to create such an open-ended command. The opportunity for abuse, and the potential damage from accidents is mind-boggling. We've got some very special-case requirements here, all the actions of which can be hardcoded. There's no reason to open up a gaping security vulnerability like that.

 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support