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.
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:
reading the contextCSN from ""
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.
openldap-software@openldap.org
-
Howard Chu -
masaratiļ¼ aero.polimi.it