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

Re: commit: ldap/tests/scripts test049-sync-config defines.sh



Howard Chu wrote:
The dilemma of how not to wipe out the consumer configuration once the complete master configuration is replicated onto it is solved with this trick: the master has both a provider and a consumer configured on it, and the consumer points at the master. The syncrepl config handler checks to see if its providerURI matches any of the current server's listenerURIs. If there's a match, the config is a no-op. (It gets parsed but no consumer task is triggered.)

It occurs to me that a more real-world approach may be to use a second DB on the provider and a modified translucent overlay that uses back-relay instead of back-ldap. E.g., create a back-ldif DB with suffix "cn=config,cn=slave" that is translucently relayed to the cn=config tree. This would allow the main config items to be passed through, but also provide the opportunity to override some settings (rootDNs, passwords, ACLs, indices) with slave-specific settings. Put a rewrite overlay on top of that to remap entry DNs from "cn=config,cn=slaves" to just "cn=config" on search replies. And then finally the syncprov overlay to actually handle the replication.

Of course, that first requires that slapo-rwm gets dynamic config support.
--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  OpenLDAP Core Team            http://www.openldap.org/project/