[Date Prev][Date Next]
Re: (ITS#5942) URI matching of "self" in add_syncrepl is incomplete
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#5942) URI matching of "self" in add_syncrepl is incomplete
- From: firstname.lastname@example.org
- Date: Wed, 29 Jul 2009 07:07:42 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
> 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:
>>> 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
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/