I have multiple sites that I am trying to sync up to a global server. Each site is configured (striped down) as:
############################################################################ # mdb database for o=chi01,ou=studios,dc=methodstudios,dc=net ############################################################################ database mdb suffix "o=chi01,ou=studios,dc=methodstudios,dc=net"
# Save the time that the entry gets modified lastmod on
# Subordinate of the ou=studios,dc=methodstudios,dc=net database below subordinate advertise
overlay syncprov syncprov-reloadhint TRUE syncprov-checkpoint 100 5
############################################################################ # mdb database for ou=studios,dc=methodstudios,dc=net ############################################################################ database mdb suffix "ou=studios,dc=methodstudios,dc=net"
The above is my configuration for Chicago. I have similar ones for New York (ny01) and Los Angeles (la01) On my global server I am trying to use sync replication to clone each site. The global server is configured (striped down) as:
############################################################################ # mdb database for o=global,ou=studios,dc=methodstudios,dc=net ############################################################################ database mdb suffix "o=global,ou=studios,dc=methodstudios,dc=net"
# Save the time that the entry gets modified lastmod on
# Subordinate of the ou=studios,dc=methodstudios,dc=net database below subordinate advertise
overlay syncprov syncprov-reloadhint TRUE syncprov-checkpoint 100 5
############################################################################ # mdb database for o=chi01,ou=studios,dc=methodstudios,dc=net ############################################################################ database mdb suffix "o=chi01,ou=studios,dc=methodstudios,dc=net"
# Subordinate of the ou=studios,dc=methodstudios,dc=net database below subordinate advertise
syncrepl rid=1 provider=ldap://chi01.methodstudios.com type=refreshOnly retry="60 10 300 +" interval=00:00:10:00 searchbase="o=chi01,ou=studios,dc=methodstudios,dc=net" bindmethod=simple starttls=yes binddn="****" credentials=**** schemachecking=off
############################################################################ # mdb database for o=ny01,ou=studios,dc=methodstudios,dc=net ############################################################################ database mdb suffix "o=ny01,ou=studios,dc=methodstudios,dc=net"
# Subordinate of the ou=studios,dc=methodstudios,dc=net database below subordinate advertise
syncrepl rid=2 provider=ldap://ny01.methodstudios.com type=refreshOnly retry="60 10 300 +" interval=00:00:10:00 searchbase="o=ny01,ou=studios,dc=methodstudios,dc=net" bindmethod=simple starttls=yes binddn="****" credentials=**** schemachecking=off
############################################################################ # mdb database for ou=studios,dc=methodstudios,dc=net ############################################################################ database mdb suffix "ou=studios,dc=methodstudios,dc=net"
overlay glue overlay syncprov syncprov-reloadhint TRUE syncprov-checkpoint 100 5
Now that I have the configuration out of the way. Syncrepl on the global server is failing on chi01. The chi01 server syslog has
Oct 23 18:41:35 boote01-chi01 slapd[19324]: conn=1000 op=2 SRCH base="o=chi01,ou=studios,dc=methodstudios,dc=net" scope=2 deref=0 filter="(objectClass=*)" Oct 23 18:41:35 boote01-chi01 slapd[19324]: conn=1000 op=2 SRCH attr=* + Oct 23 18:41:35 boote01-chi01 slapd[19324]: conn=1000 op=2 SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is newer than provider! Oct 23 18:41:35 boote01-chi01 slapd[19324]: conn=1000 op=3 UNBIND
Looking at the ny01 server (ldapsearch -x -h ny01 -b o=ny01,ou=studios,dc=methodstudios,dc=net -s base +) where syncrepl is working # ny01, studios, methodstudios.net dn: o=ny01,ou=studios,dc=methodstudios,dc=net structuralObjectClass: organization entryUUID: 257c5408-717c-1032-9b24-31eddc101779 creatorsName: cn=admin,ou=studios,dc=methodstudios,dc=net createTimestamp: 20130625004432Z entryCSN: 20130625004432.932104Z#000000#000#000000 modifiersName: cn=admin,ou=studios,dc=methodstudios,dc=net modifyTimestamp: 20130625004432Z contextCSN: 20131023210335.999443Z#000000#000#000000 entryDN: o=ny01,ou=studios,dc=methodstudios,dc=net subschemaSubentry: cn=Subschema hasSubordinates: TRUE
Looking at the global server (ldapsearch -x -h global -b o=ny01,ou=studios,dc=methodstudios,dc=net -s base +): # ny01, studios, methodstudios.net dn: o=ny01,ou=studios,dc=methodstudios,dc=net structuralObjectClass: organization entryUUID: ccbe6442-d084-1032-8149-e14ce02952dd creatorsName: cn=admin,ou=studios,dc=methodstudios,dc=net createTimestamp: 20131023231549Z entryCSN: 20131023231549.982220Z#000000#000#000000 modifiersName: cn=admin,ou=studios,dc=methodstudios,dc=net modifyTimestamp: 20131023231549Z entryDN: o=ny01,ou=studios,dc=methodstudios,dc=net subschemaSubentry: cn=Subschema hasSubordinates: FALSE
Notice no contextCSN.
Looking at the chi01 server (ldapsearch -x -h chi01 -b o=chi01,ou=studios,dc=methodstudios,dc=net -s base +): # chi01, studios, methodstudios.net dn: o=chi01,ou=studios,dc=methodstudios,dc=net structuralObjectClass: organization entryUUID: 4b4f63f6-81bb-1032-97d3-7d320a684bf1 creatorsName: cn=admin,ou=studios,dc=methodstudios,dc=net createTimestamp: 20130715165653Z entryCSN: 20130715165653.289427Z#000000#000#000000 modifiersName: cn=admin,ou=studios,dc=methodstudios,dc=net modifyTimestamp: 20130715165653Z contextCSN: 20131018000127.430328Z#000000#000#000000 entryDN: o=chi01,ou=studios,dc=methodstudios,dc=net subschemaSubentry: cn=Subschema hasSubordinates: TRUE
Looking at the global server (ldapsearch -x -h global -b o=chi01,ou=studios,dc=methodstudios,dc=net -s base +): # chi01, studios, methodstudios.net dn: o=chi01,ou=studios,dc=methodstudios,dc=net structuralObjectClass: organization entryUUID: cc675698-d084-1032-8eb1-f1b765ca1756 creatorsName: cn=admin,ou=studios,dc=methodstudios,dc=net createTimestamp: 20131023231549Z entryCSN: 20131023231549.411641Z#000000#000#000000 modifiersName: cn=admin,ou=studios,dc=methodstudios,dc=net modifyTimestamp: 20131023231549Z entryDN: o=chi01,ou=studios,dc=methodstudios,dc=net subschemaSubentry: cn=Subschema hasSubordinates: FALSE
Notice no contextCSN.
Looking at the global server root of the glued database (ldapsearch -x -h global -b ou=studios,dc=methodstudios,dc=net -s base +): # studios, methodstudios.net dn: ou=studios,dc=methodstudios,dc=net structuralObjectClass: organizationalUnit entryUUID: cc769b12-d084-1032-86fe-a1b1821abdab creatorsName: cn=admin,ou=studios,dc=methodstudios,dc=net createTimestamp: 20131023231549Z entryCSN: 20131023231549.511823Z#000000#000#000000 modifiersName: cn=admin,ou=studios,dc=methodstudios,dc=net modifyTimestamp: 20131023231549Z contextCSN: 20131024000524.348070Z#000000#000#000000 entryDN: ou=studios,dc=methodstudios,dc=net subschemaSubentry: cn=Subschema hasSubordinates: FALSE
So after all that. Is the syncrepl from chi01 using the contextCSN from the root of the glued database? It seems all the syncrepl from all the sites fail unless they have the latest change. How do you handle syncrepl on glued databases?