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
