>>> 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. I suggest this issue is noted in the documentation of the "push" syncrepl. p.
