Syncrepl of portions of glued database - problems (in HEAD)

[Pierangelo Masarati <ando@sys-net.it>]

I'm trying to set up a tutorial about syncreplication of portions of 
glued databases, and I found it very tricky to determine what sequence 
each brick must be stacked to get it work.  I'm working with HEAD, so 
there might some issue with syncrepl provider features being provided by 
the syncprov overlay, and with the glue feature being provided by the 
glue overlay.

The setup is (without non-essential details; mostly cut'n'pasted from 
tests 012 and 018):

<DSA1 slapd.conf>
database        bdb
suffix          "ou=Information Technology 
Division,ou=People,dc=example,dc=com"
directory       ./testrun/db.1.a
rootdn          "cn=Manager 1,dc=example,dc=com"
index           objectclass     eq
overlay         syncprov

database        bdb
suffix          "ou=Groups,dc=example,dc=com"
directory       ./testrun/db.1.b
rootdn          "cn=Manager 1,dc=example,dc=com"
index           objectclass     eq
syncrepl        rid=1
               provider=ldap://:9012
               binddn="cn=Manager 2,dc=example,dc=com"
               bindmethod=simple
               credentials=secret
               searchbase="ou=Groups,dc=example,dc=com"
               filter="(objectClass=*)"
               attrs="*,+"
               schemachecking=off
               scope=sub
               type=refreshAndPersist
               retry="10 3 300 +"
updateref       ldap://:9012
overlay         syncprov

database        bdb
suffix          "dc=example,dc=com"
directory       ./testrun/db.1.c
rootdn          "cn=Manager 1,dc=example,dc=com"
rootpw          secret
index           objectclass     eq
overlay         syncprov
overlay         glue
glue-sub        "ou=Information Technology 
Division,ou=People,dc=example,dc=com"
glue-sub        "ou=Groups,dc=example,dc=com"
</DSA1 slapd.conf>

<DSA2 slapd.conf>
database        bdb
suffix          "ou=Information Technology 
Division,ou=People,dc=example,dc=com"
directory       ./testrun/db.2.a
rootdn          "cn=Manager 2,dc=example,dc=com"
index           objectclass     eq
syncrepl        rid=1
               provider=ldap://:9011
               binddn="cn=Manager 1,dc=example,dc=com"
               bindmethod=simple
               credentials=secret
               searchbase="ou=Information Technology 
Division,ou=People,dc=example,dc=com"
               filter="(objectClass=*)"
               attrs="*,+"
               schemachecking=off
               scope=sub
               type=refreshAndPersist
               retry="10 3 300 +"
updateref       ldap://:9011
overlay         syncprov

database        bdb
suffix          "ou=Groups,dc=example,dc=com"
directory       ./testrun/db.2.b
rootdn          "cn=Manager 2,dc=example,dc=com"
index           objectclass     eq
overlay         syncprov

database        bdb
suffix          "dc=example,dc=com"
directory       ./testrun/db.2.c
rootdn          "cn=Manager 2,dc=example,dc=com"
rootpw          secret
index           objectclass     eq
overlay         syncprov
overlay         glue
glue-sub        "ou=Information Technology 
Division,ou=People,dc=example,dc=com"
glue-sub        "ou=Groups,dc=example,dc=com"
</DSA2 slapd.conf>

All databases need to have the syncprov overlay installed to recognize 
the LDAP Sync control; however, it appears that the presence of the glue 
overlay prohibits the replication to occur as expected (there's also a 
chicken and egg problem of what server is starting first; for the 
purpose I had to add the retry statement to the syncrepl).

The "overlay syncprov" in the glue database must appear __before__ the 
"overlay glue", otherwise I get "findbase failed! 32". If there is no 
"overlay syncprov" in the glue database, it fails because the control 
appears to be unsupported by the glue database.  With this 
configuration, if the system starts with the glue database set up, and 
with the shadow databases empty, the synchronization occurs as expected. 
Owever, further updates are not sync'ed; same with refreshOnly.

Since this setup is very important for us (it allows to implement 
detached updates in a context in which each DSA is master for its own 
data and resync as soon as connection is back), I think this feature 
should always be available regardless of the software development.  As 
such, I think I should commit a test for it, which is likely to be a 
rather transversal case, i.e. it requires the simultaneous availability 
of different features.

p.



   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497