Re: syncrepl push model with searchbase=""

> [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.