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.