[Date Prev][Date Next]
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/