TIMESTAMP#COUNT#SID#MOD
My question is on the SID part: ServerID.
I have the following serverID configuration in our 4-server Multi-Master PoC setup:
serverID 222 ldaps://ldapm01.company.com
serverID 221 ldaps://ldapm02.company.com
serverID 212 ldaps://ldapm03.company.com
serverID 211 ldaps://ldapm04.company.com
And when I (quick and dirty) check contextCSN using slapcat (I know that ldapsearch is the better way) I get:
[root@ldapm04 ~]# slapcat | grep contextcsn -i
contextCSN: 20180917142109.765066Z#000000#000#000000
contextCSN: 20230622151102.137085Z#000000#001#000000
contextCSN: 20230622151105.174343Z#000000#002#000000
contextCSN: 20230627112536.529432Z#000000#0dd#000000
contextCSN: 20230627112536.529512Z#000000#0de#000000
The first 2018 contextCSN is irrelevant (it has alwas been there, and I should probably try to get rid of it) but the last four seem to be the "actual" configured replication 'lines' on each node to the other three, like this:
syncrepl rid=2?4 provider=ldaps://ldapm0?.company.com:636 bindmethod=simple binddn="cn=replication,ou=Directory Access,o=company,c=com" credentials=very_secret searchbase="o=company,c=com" filter="(objectClass=*)" scope=sub schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+" tls_reqcert=demand
syncrepl rid=2?4 provider=ldaps://ldapm0?.company.com:636 bindmethod=simple binddn="cn=replication,ou=Directory Access,o=company,c=com" credentials=very_secret searchbase="o=company,c=com" filter="(objectClass=*)" scope=sub schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+" tls_reqcert=demand
syncrepl rid=2?4 provider=ldaps://ldapm0?.company.com:636 bindmethod=simple binddn="cn=replication,ou=Directory Access,o=company,c=com" credentials=very_secret searchbase="o=company,c=com" filter="(objectClass=*)" scope=sub schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+" tls_reqcert=demand
Now the actual question:
contextCSN displays these SID's: 001, 002, 0dd, 0de. None of which I have configured *anywhere*. Not as a SID, not as a RID, as can be seen above.
Yet: all info I can find tells me that the third field of contextCSN is "the SID".
Can anyone explain? Are they perhaps HEX? If why the large gap between to consequtive pairs..?
Curious :-)
Thanks!