Re: back-config

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

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.

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.

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

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.

-- 
Hallvard