cn=config defaults (was: cn=config: sharing, conditionals)

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

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