[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
default.
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
completion.
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