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

Re: syncrepl push model with searchbase=""



masarati@aero.polimi.it 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/