[Date Prev][Date Next]
Hallvard B Furuseth wrote:
I was thinking of both creating and updating (and reading) it throughWell, 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.
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.
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
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 overlayImplementation 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.
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.
Sorry, I should have clarified that I was mostly thinking of anOK, that makes sense. Certainly some new documentation would help
establish a frame of reference, before we go there.
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. 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.
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.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support