[Date Prev][Date Next]
Re: syncrepl push model with searchbase=""
> firstname.lastname@example.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
>> slap_queue_csn: queing 0x2aaaac001d90
>> null_callback : error code 0x35
>> syncrepl_updateCookie: rid=001 be_modify failed (53)
>> on the consumer:
>> slap_queue_csn: queing 0xd8e3a30
>> slap_graduate_commit_csn: removing 0xd8e3b00
>> 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.