Re: syncrepl push model with searchbase=""

[email protected] wrote:
>
>>>> Is it possible to achieve what we want using some other options?
>>>
>>> It might not be as soon as some internal searches rooted at<searchbase>
>>> with scope "base" need to be performed, because in this case they would
>>> actually return the rootDSE instead of the context entry of the database
>>> you're trying to replicate.  This is a mere speculation, I haven't
>>> looked at the code yet.
>>>
>>
>> Apparently, my guess was correct.  This is what the real consumer receives
>> from the syncrepl hidden in the provider at startup:
>>
>> conn=0 fd=14 ACCEPT from IP=127.0.0.1:34623 (IP=0.0.0.0:9012)
>> conn=0 op=0 BIND dn="cn=replicator" method=128
>> conn=0 op=0 BIND dn="cn=replicator" mech=SIMPLE ssf=0
>> conn=0 op=0 RESULT tag=97 err=0 text=
>> conn=0 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
>> conn=0 op=1 SRCH attr=contextCSN
>> conn=0 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
>>
>> It searches for contextCSN in the root entry with base scope.  Because of
>> the scope, the search actually gets to the rootDSE.
>
> What I see is that replication actually occurs; what really fails is:
>
> 1) reading the contextCSN from ""
>
> 2) writing the contextCSN to ""
>
> This is totally undesirable.  Probably, having context info in a subentry
> of the context entry, as it was initially, would not have caused the
> problem.

But the use of the subentry was always problematic on "normal" databases; 
there were race conditions all over that code in OpenLDAP 2.2.

Still, it would probably be best to use that approach whenever using a 
database with empty suffix.

> I suggest this issue is noted in the documentation of the "push" syncrepl.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/