Hi all!
I do have a multi-master replication setup. So I do have an olcServerID
attribute with multiple values, for example:
dn: cn=config
olcServerID: 1 ldap://ldapserver1.some.tld/
olcServerID: 2 ldap://ldapserver2.some.tld/
olcServerID: 3 ldap://ldapserver3.some.tld/
I understand that the meaning of this is:
Each server will pick the attribute value which matches its own URL to
determine the actual ServerID to be used in contextCSN generation,
right? So if the server listening to ldap://ldapserver2.some.tld/ will
come up, it will pick the attribute value "2
ldap://ldapserver2.some.tld/"; and thus decide that its serverID is 2 in
this case.
I also understand that this mechanism has been created to allow the
cn=config database to be replicated across all servers which are part of
the cluster.
Now obviously, if I made a mistake here, for example I make a typo:
dn: cn=config
olcServerID: 1 ldap://ldapserver1.some.tld/
olcServerID: 2 ldap://ldapsrever2.some.tld/
olcServerID: 3 ldap://ldapserver3.some.tld/
the server ldap://ldapserver2.some.tld/ will not find its entry and thus
its serverID will default to 0, right? And I guess this will lead to
results of the sychronization which are not what I expect.
Of course I can carefully watch the config to guess what the effective
ServerID *should* be. But would there be any way to actually query the
server for what it thinks its ID is?
I tried
ldapsearch -x -D 'cn=admin,cn=config' -w XXXX -b '' -s base olcServerID
but this also just gives me:
# config
dn: cn=config
olcServerID: 1 ldap://192.168.5.11:389/
olcServerID: 2 ldap://192.168.5.12:389/
olcServerID: 3 ldap://192.168.9.2:389/
in my case.
I guess I may have to query -b "", right?
Any hints are welcome.
I hope I was able to make my question clear.