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

Re: back-config

Hallvard B Furuseth wrote:

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.


Well, that's a more interesting problem, because we would have to close and reopen the DB environment in order to have a newly written DB_CONFIG file take effect. That would require going through all of backend_shutdown for that backend, and restarting. Which we can certainly do, if we really want this functionality.

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:-(


Once the information is represented in an attribute the runtime behavior is straightforward. My only concern is with server startup. After you set these config directives once, a DB_CONFIG file will exist. There's no reason to overwrite that file the next time the server starts, and if someone has edited the DB_CONFIG file instead of the slapd config data, then they'll lose those edits. One might argue that they should not be editing anything that is controlled by the slapd config. I'd be OK with that.

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.


Implementation isn't a big problem, and with the new config engine the feature will be supported in both slapd.conf format and in LDIF without any special effort.

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.


OK, that makes sense. Certainly some new documentation would help establish a frame of reference, before we go there.

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.

OK. So we define a control like ManageDB or ManageOS (or some appropriate name) and attach it to requests where we want some side-effects to execute.

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