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

cn=config: sharing, conditionals

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.

  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/