So, while we can fully replicate cn=config for the case where all syncrepl
participants are masters/peers, things are still a bit sticky if we only want
the replicas to remain in slave mode.
Instead of going thru complicated mapping/virtual directory redirections, it
seems to me that all we need is to tag certain config objects with the
serverIDs to which they apply. As such, I'm considering adding an
olcServerMatch attribute to the olcDatabaseConfig and olcOverlayConfig
objectclasses. This would take a regexp to match against the current server
ID; if the pattern matches then the config entry is processed otherwise it is
ignored. This attribute would be absent/empty by default, making the entry
always enabled.
Likewise it may be useful to add a boolean olcDisabled attribute to these
classes, to allow databases and overlays to be switched on and off without
needing to delete them. Again, it would default to absent/FALSE...
We'd also want these controls for syncrepl stanzas. (Too bad the patch to turn
syncrepl into an overlay was never committed....)
For example, we may have a cluster of servers in MMR with a pool of other
servers operating as slaves. We'd want the syncprov overlay active on all of
the masters, the syncrepl consumer active on all of the servers, and the chain
overlay active on all of the slaves. Setting olcServerMatch on the syncprov
and chain overlays would allow things to behave as desired, without needing to
create a parallel config tree just for the slaves.
Comments?
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
