--On Tuesday, January 17, 2017 2:11 PM +0100 Marc Franquesa mark@l3jane.net wrote:
In the past I migrated some server, added some other node so is possible that a 'ghost' provider CSN is still on the DB ?
Yes. If you have any entries still in the DB that have an entryCSN from your old provider, it will be a valid contextCSN value. If you want that contextCSN gone, you'll need to slapcat your database and modify the LDIF accordingly before re-importing. I assume that was serverID 006, you would want to find all instances of #006# and replace them with one of #001#, #004#, or #005# (so they are consistent) and then reload all servers.
Hope that helps.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
On mié, 2017-01-18 at 14:46 -0800, Quanah Gibson-Mount wrote:
Yes. If you have any entries still in the DB that have an entryCSN from your old provider, it will be a valid contextCSN value. If you want that contextCSN gone, you'll need to slapcat your database and modify the LDIF accordingly before re-importing. I assume that was serverID 006, you would want to find all instances of #006# and replace them with one of #001#, #004#, or #005# (so they are consistent) and then reload all servers.
I can assume some downtime and be in safe place. My idea was to proceed as follows:
- Take slapcat Backup of all DITs (including cn=config) - Remove any contextCSN attribute from the resulting LDIFs - Stop all 3 servers - Remove entirely the DBs on the servers - Do a slapadd of the previous LDIFs - Start servers again (so re-replicating again with new contextCSN, now corret).
Should that work ? even for cn=config DB ?
Also to further confuse a bit more the scenario, today I realized that a new contextCSN appeared:
dn: dc=l3jane,dc=net contextCSN: 20170111084028.692133Z#000000#001#000000 contextCSN: 20170118224410.110554Z#000000#003#000000 contextCSN: 20161228225757.121969Z#000000#004#000000 contextCSN: 20160201102250.543748Z#000000#005#000000 contextCSN: 20150917152138.054326Z#000000#006#000000
Also the explanation that conextCSN attribute is = contextCSN#rid#sid#000000 seem not correct as I have rids 001, 002 and 003, and serverIds 1,2,3 so none of this matches with my results.
As summary of my setup: olcServerID: 1 ldap://ender.l3jane.net olcServerID: 3 ldap://continuity.l3jane.net olcServerID: 2 ldap://mona.l3jane.net
cn=config is replicated along 3 servers in mirror-mode, DB: olcSyncrepl: {0}rid=001 provider=ldap://ender.l3jane.net binddn="cn=Backup,ou=DSA,dc=l3jane,dc=net" bindmethod=simple credentials=X searchbase="cn=config" type=refreshAndPersist retry="10 6 600 +" timeout=2 olcSyncrepl: {1}rid=003 provider=ldap://continuity.l3jane.net binddn="cn=Backup,ou=DSA,dc=l3jane,dc=net" bindmethod=simple credentials=X searchbase="cn=config" type=refreshAndPersist retry="10 6 600 +" timeout=2 olcSyncrepl: {2}rid=002 provider=ldap://mona.l3jane.net binddn="cn=Backup,ou=DSA,dc=l3jane,dc=net" bindmethod=simple credentials=X searchbase="cn=config" type=refreshAndPersist retry="10 6 600 +" timeout=2
But I get this contextCSN values:
dn: cn=config contextCSN: 20170111084531.247823Z#000000#001#000000 contextCSN: 20161230165409.486624Z#000000#003#000000
Si I'm missing one contextCSN? (there are 3 providers) ?
Also for the other DIT dc=l3jane,dc=net: olcSyncrepl: {0}rid=001 provider=ldap://ender.l3jane.net binddn="cn=Backup,ou=DSA,dc=l3jane,dc=net" bindmethod=simple credentials=X searchbase="dc=l3jane,dc=net" type=refreshAndPersist retry="10 6 600 +" timeout=2 olcSyncrepl: {1}rid=002 provider=ldap://mona.l3jane.net binddn="cn=Backup,ou=DSA,dc=l3jane,dc=net" bindmethod=simple credentials=X searchbase="dc=l3jane,dc=net" type=refreshAndPersist retry="10 6 600 +" timeout=2 olcSyncrepl: {2}rid=003 provider=ldap://continuity.l3jane.net binddn="cn=Backup,ou=DSA,dc=l3jane,dc=net" bindmethod=simple credentials=X searchbase="dc=l3jane,dc=net" type=refreshAndPersist retry="10 6 600 +" timeout=2
But I get 5 contextCSNs:
# ldapsearch -LLL -x -s base contextCSN dn: dc=l3jane,dc=net contextCSN: 20170111084028.692133Z#000000#001#000000 contextCSN: 20170118224410.110554Z#000000#003#000000 contextCSN: 20161228225757.121969Z#000000#004#000000 contextCSN: 20160201102250.543748Z#000000#005#000000 contextCSN: 20150917152138.054326Z#000000#006#000000
????
Thanks much
openldap-technical@openldap.org