[Date Prev][Date Next]
Hallvard B Furuseth wrote:
Howard Chu writes:Right. Ultimately I would try to eliminate these cases, but we'll
probably have a lot of them the first time 'round.
Hallvard B Furuseth wrote:Or just document that some changes only take effect after the server
I was thinking of both creating and updating (and reading) it throughWell, that's a more interesting problem, because we would have to close
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.
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.
has been restarted.
Could get fancy and put such config parameters in a separate subtree, orHm. That would certainly be informative, I like that. Something to think
return both attr:new_value and attr;x-effective:old_value to searches,
but I suspect that quickly gets more complicated than is useful.
Reading from DB_CONFIG directly would make sense. Currently all of
back-config's content is cached though, would have to rework the search
code to fetch attributes in realtime.
Once the information is represented in an attribute the runtime behaviorWe've been thinking of different functionality:-)
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
I imagined to not have an attribute corresponding to DB_CONFIG in the
server-side LDIF file, but to let read operations generate it from
DB_CONFIG and write operations to update DB_CONFIG directly.
I would implement it such that an update via LDAP updates both the LDIF
and the DB_CONFIG file. Since back-ldif is operating underneath
back-config, the LDIF update is going to happen automatically; it would
be more work to special case it to not update it.
I can see it would be useful to have it in the initial LDIF too, though.
If it exists in both places, the server could just give a warning at
startup if they are not equal, and if it is updated over LDAP (if that
is supported) refrain from updating the LDIF version.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support