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

[Howard Chu <hyc@symas.com>]

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/