[email protected] wrote: > On 14.02.2009 01:51, Howard Chu wrote: >> Jonathan Clarke wrote: >>> On 13.02.2009 01:23, Howard Chu wrote: >>>> There are valid reasons to point a syncrepl consumer at the same slapd >>>> (e.g., proxy syncrepl, automatic local backup/mirroring, rewriting a >>>> subtree of a main database, etc.). Using the exhaustive matching that >>>> serverID uses would preclude those cases from working. >>> I see. I understand you don't want to break existing functionality. >>> However, I still feel this is a bug, or at least that you need to "hack" >>> the setup to get things working as expected. >> >> The docs state that "syncrepl provider" is the LDAP URI of the master >> server. If you're not putting in the same URI as the master is using, >> that's a config error, not a bug. > > Understood. Nothing is broken, and we have worked around this issue > using explicit listeners to slapd -h. > > This behaviour did surprise me, considering the behaviour of serverID > matching. May I suggest that a note of warning is included in the admin > guide? For example: > http://milopita.phillipoux.net/jonathan-clarke-20090216.patch > >>> Would I be right in assuming that in all the "valid reasons to point a >>> syncrepl consumer at the same slapd" you mention, the syncrepl consumer >>> uses a different base DN than the base DN of the database that the >>> syncrepl consumer is configured on? If so, maybe the exhaustive matching >>> that serverID uses could be used, if and only if those two base DNs are >>> different?
Actually, the exhaustive matching is only needed if the two base DNs are the same. This is now patched in HEAD, please test. >> That sounds reasonable. Will think about it a bit more. Certainly if the >> two base DNs are the same, it will cause a loop... > > Indeed. For what it's worth, while testing on cn=config, I noticed this > having various consequences including: > 1) cn=config becoming read-only (shadow) and updates returning a referral. > 2) in a MMR setup, some updates not being replicated to all N servers. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
