> [email protected] 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.
