Re: back-config

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

Howard Chu writes:
>Hallvard B Furuseth wrote:
>
>> 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.

I was thinking of both creating and updating (and reading) it through
LDAP, but I hadn't thought of what to do with an existing file.
Writing a DB_CONFIG over LDAP and _not_ having it take effect might
be as annoying as losing an existing file, though.

One might want to
1. send a file which would silently overwrite any existing file,
2. send a file to only write if none already exists,
   2a. with an error response if it exists / 2b. without error,
3. delete any existing file,
   3a. with error if none exists / 3b. without error.

With a SINGLE-VALUE attribute which automatically exists if the file
exists (once the directory attribute is set), the Modify request
supports 1, 2a and 3a, and one can hack 3b with changetype replace
followed by delete.  But then I don't see how to get 2b which is
probably the one you suggested:-(

Not sure how to implement it though.  A sort of backend-specific overlay
which is automatically included when the backend is specified?  And I
imagine it would be easier if it exists in a separate entry rather than
the backend's "root" entry, but maybe that's because I haven't looked
much at the source yet.

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

Yuck.  Yes, such a tool should be helpful but not necessary to use.

Sorry, I should have clarified that I was mostly thinking of an
OpenLDAP-specific LDAP _client_ which would perform these operations,
with a bit more friendly interface than writing LDIF data with controls
for them or whatever.  The actual LDAP operations needed to do some of
this stuff sound rather more unintuitive to me than the current way of
editing config files.  What I was thinking was that then it doesn't
matter if some of the requests and controls are cumbersome to use, the
client will take care of it.

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

That sounds ridiculous enough, yes.  Some day I'd like to have a
server-side thing in OpenLDAP to do a few tasks like monitor the server
and alert someone and maybe try to take it up if it fails, but the
server should be independent 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.
>>
>> 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.

Relax, I did not mean a shell command.  I meant a command which would be
recognized by the server and would mean precisely what you intended to
use ManageDSAit for.  And maybe other commands later, if needed.

-- 
Hallvard