[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: cn=config: sharing, conditionals

Hallvard B Furuseth wrote:

Howard Chu writes:

The other alternative, which is much simpler to implement, is just to
add a suffixmassage/rewrite keyword to the syncrepl config, allowing
it to pull from a particular remote base and map it to the local
base. Then it's up to the sysadmin to create a complete cn=config
hierarchy somewhere else on the master server and let the slaves pick
it up. That would address all of the issues of differentiation, at the
cost of a little bit of redundancy on the master.


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. 


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


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.... 
--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/