ml+openldap@esmtp.org wrote:
I'm trying to replace OpenLDAP 2.3.x with 2.4.18 (this project started before 2.4..19 came out). The old configuration uses slurpd, hence I have been tasked to set up a producer/consumer replication via syncrepl using the push model. I'm following the example from the admin guide but I have to modify the suffix/searchbase to be "" (as we allow pretty much anything in the DB).
Doing this causes these log messages (loglevel 0x4000):
on the master: do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - REFRESH_DELETE do_syncrep2: cookie=rid=001,sid=001,csn=20091014205621.868761Z#000000#001#000000 slap_queue_csn: queing 0x2aaaac001d90 20091014205621.868761Z#000000#001#000000 null_callback : error code 0x35 syncrepl_updateCookie: rid=001 be_modify failed (53)
on the consumer: slap_queue_csn: queing 0xd8e3a30 20091014205621.868761Z#000000#001#000000 slap_graduate_commit_csn: removing 0xd8e3b00 20091014205621.868761Z#000000#001#000000 conn=0 op=42 do_modify: root dse!
This seems to be a problem with ``searchbase=""'' (in ``syncrepl''). If it is changed to ``searchbase="dc=com"'' (and matching ``suffix "dc=com"'' for ``database ldap'') the error does not occur.
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.
Probably, we'd need a means to recognize searches with base="" and scope="base" that are actually directed to the context entry of a database rooted at "". This could be, say, the manageDSAit control (unless manageDSAit on a search for the rootDSE already has some specific meaning), or a specific control. This would probably solve your problem, and work for OpenLDAP-only setups. However, it would defeat the purpose of using push syncrepl with other vendors' products.
p.