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

Re: (ITS#5942) URI matching of "self" in add_syncrepl is incomplete



jclarke@linagora.com 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/