troubles with replication using sync-repl

[Guillaume Rousse <Guillaume.Rousse@inria.fr>]

Hello.

I'm having troubles with replication using sync-repl.

I first configured my provider and consumer servers as explained on
http://www.openldap.org/doc/admin22/syncrepl.html.

Additional directives for the provider:
# replication management
sessionlog      001 500

Additional directives for the consumer:
access to dn.subtree="dc=village,dc=inria,dc=fr" attrs=userPassword
    by dn="cn=replicator,dc=village,dc=inria,dc=fr" write
    by anonymous auth
    by * read

access to dn.subtree="dc=village,dc=inria,dc=fr"
    by dn="cn=replicator,dc=village,dc=inria,dc=fr" write
    by * read

syncrepl rid=001
    provider=ldaps://yquem.inria.fr
    type=refreshOnly
    interval=01:00:00:00
    searchbase="dc=village,dc=inria,dc=fr"
    scope=sub
    schemachecking=off
    updatedn="cn=replicator,dc=village,dc=inria,dc=fr"
    bindmethod=simple
    binddn="cn=replicator,dc=village,dc=inria,dc=fr"
    credentials=*****

Additional LDAP entry:
dn: cn=replicator,dc=village,dc=inria,dc=fr
description: LDAP replicator
cn: replicator
objectClass: organizationalRole
objectClass: simpleSecurityObject
userPassword: ****

I then restarted the provider, and started the consumer, expecting from
my documentation understanding than synchronisation would take place
automatically... but nothing happened.

I then manually exported and imported provider content into consumer,
with slapcat/slapadd, and started consumer with explicit cookie (-c
sid=001,rid=001). Explicit index access errors lead me to add an
additional entryUUID index directive in the consumer configuration:
index entryUUID eq

The error message disapeard, and I now have consumer's request in the
provider's log:
[[5~Apr 12 15:26:59 yquem slapd[32057]: conn=16 fd=20 ACCEPT from
IP=128.93.8.193:33297 (IP=0.0.0.0:636)
Apr 12 15:26:59 yquem slapd[32057]: conn=16 op=0 BIND
dn="cn=replicator,dc=village,dc=inria,dc=fr" method=128
Apr 12 15:26:59 yquem slapd[32057]: conn=16 op=0 BIND
dn="cn=replicator,dc=village,dc=inria,dc=fr" mech=SIMPLE ssf=0
Apr 12 15:26:59 yquem slapd[32057]: conn=16 op=0 RESULT tag=97 err=0 text=
Apr 12 15:26:59 yquem slapd[32057]: conn=16 op=1 SRCH
base="dc=village,dc=inria,dc=fr" scope=2 deref=0 filter="(objectClass=*)"
Apr 12 15:26:59 yquem slapd[32057]: conn=16 op=1 SRCH attr=* +
Apr 12 15:26:59 yquem slapd[32057]: conn=16 op=1 SEARCH RESULT tag=101
err=0 nentries=0 text=
Apr 12 15:26:59 yquem slapd[32057]: conn=16 op=2 UNBIND

The first request on startup returns 308 entries, the following 0, which
seems to prove synchronisation is working as expected. However, neither
new entries nor modification appears in my consumer server :/

The only information I found using a loglevel of -1 was some curious
references to wrong ACLs denying write access:
Apr 11 18:40:27 julien slapd[8154]: => acl_mask: access to entry
"ou=users,dc=village,dc=inria,dc=fr", attr "children" requested
Apr 11 18:40:27 julien slapd[8154]: => acl_mask: to all values by "", (=0)
Apr 11 18:40:27 julien slapd[8154]: <= check a_dn_pat:
cn=replicator,dc=village,dc=inria,dc=fr
Apr 11 18:40:27 julien slapd[8154]: <= check a_dn_pat: *
Apr 11 18:40:27 julien slapd[8154]: <= acl_mask: [2] applying
read(=rscxd) (stop)
Apr 11 18:40:27 julien slapd[8154]: <= acl_mask: [2] mask: read(=rscxd)
Apr 11 18:40:27 julien slapd[8154]: => access_allowed: add access denied
by read(=rscxd)
Apr 11 18:40:27 julien slapd[8154]: bdb_add: no write access to parent
Apr 11 18:40:27 julien slapd[8154]: send_ldap_result: conn=-1 op=0 p=3
Apr 11 18:40:27 julien slapd[8154]: send_ldap_result: err=50 matched=""
text="no write access to parent"
Apr 11 18:40:27 julien slapd[8154]: bdb_modify: dc=village,dc=inria,dc=fr
Apr 11 18:40:27 julien slapd[8154]:
bdb_dn2entry("dc=village,dc=inria,dc=fr")
Apr 11 18:40:27 julien slapd[8154]: bdb_modify_internal: 0x00000001:
dc=village,dc=inria,dc=fr
Apr 11 18:40:27 julien slapd[8154]: acl: no-user-mod contextCSN: modify
access granted

However, my updatedn is supposed to have write access everywhere beneath
the root (included). I also checked it had read access anywhere in the
consumer by manual searches.

The provider has version 2.2.23, running on debian stable i586, while
the consumer has version 2.3.6, running on mandriva 2006.0 x86_64.