[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
cn=config defaults (was: cn=config: sharing, conditionals)
Howard Chu writes:
>Hallvard B Furuseth wrote:
>> Can translucent be made to combine with back-relay and rwm? Then the
>> other database need only maintain differences from the main config, and
>> there's less problem with keeping the two config databases in sync.
>
> Translucent is currently a bit too limited here; it only allows customizing of
> entries that exist in the master. It doesn't allow creating new entries that
> only exist in the local/translucent DB.
Oh well. One could set up a cron job which merges data "by hand" then.
>> All this reminds me of another wish/gripe of mine, though not one to
>> address in RE24: cn=config modifies input data and adds default values
>> to the user-provided data. I'd much prefer it to only do ordinary
>> attribute normalization.
>
> I would have preferred not to generate the default values either, but
> as Ando frequently reminds me, relying on unstated defaults is
> error-prone...
Unstated in which regard? We've done fine with defaults in slapd.conf,
except some defaults needed to be better documented.
Hmm... X-DEFAULT 'value' and X-INHERIT 'source database' extensions to
config attribute descriptions would be nice. Spells out defaults more
explicitly, instead of having them somewhere in C code.
Though it's a nice feature to be able to read the defaults from
cn=config, which is why I suggested the dynamic read-only database with
defaults and inherited attributes included. (A control to ask for
them might be yet another way, with the X-* options above.)
One of the problems with _storing_ defaults is that the sensible value
changes over time, like 'threads'. back-config can end up storing
defaults that made sense last decade.
>> I've suggested ;x-original attribute options or something to show what
>> was really written, but a cleaner alternative would be to have two
>> config databases: One database with just the data stored by the admin,
>> and one read-only in-memory which back-config builds from the stored
>> data. Changes to inherited data would be iffy though, since they'll
>> apply to several databases and may need to be reverted in early
>> databases if they fail in late ones.
>
>> Back to this discussion, that would also allow for variables and simple
>> conditionals to be stored in the read-write database, which would be
>> expanded when copied to the read-only config database. Also if
>> back-config builds the real configuration from several entries through
>> inheritance anyway, that might be expanded to build the config from
>> multiple config trees - the main config + the server-specific config as
>> above. No, definitely not for RE24:-)
>
> Now that sounds like overkill... We also want something that we can easily
> document and explain to people....
Seems simple enough to me except the "you don't need to know/use this"
parts. Simpler than a "show defaults" control. And simpler than to
figure out where a value comes from - the sysadmin, back-config default,
or back-config cleverness like slapd's removing inherited defaults from
stored limits.
--
Hallvard