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

Re: back-config

Hallvard B Furuseth wrote:

Howard Chu writes:


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.


Or just document that some changes only take effect after the server
has been restarted.


Right. Ultimately I would try to eliminate these cases, but we'll probably have a lot of them the first time 'round.

Could get fancy and put such config parameters in a separate subtree, or
return both attr:new_value and attr;x-effective:old_value to searches,
but I suspect that quickly gets more complicated than is useful.


Hm. That would certainly be informative, I like that. Something to think about.

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.


We've been thinking of different functionality:-)
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.


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.

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.

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.

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