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