Full_Name: Rein Tollevik Version: CVS head OS: linux and solaris URL: ftp://ftp.openldap.org/incoming/rein-serverID.patch Submission from: (NULL) (81.93.160.250) Submitted by: rein
Syncrepl includes the serverID in the syncCookie in multi-master mode only, but there are other configuration that would benefit from it as well.
A case I have is where a consumer replicates a glue'ed database, with the exception of one subordinate backend where the consumer is the master. The subordinate backend is replicated back to the master of the glue'ed database. With the current code the master would send the content of the subordinate db back to its master.
I currently solve this problem with acl rules on the glue'ed master that prevents the slave from reading the subordinate db it is master for. Different rootdn's on the glue and subordinate db on the slave prevents syncrepl from succeeding in its attempts to remove the content of the subordinate db during the present phase. But it felt like I got a minor heartache the first time a saw the log of delete messages scroll by before I realized they were all error messages...
A patch that fixes this is at the referenced URL. As I am not sure of the consequences if a defaulted serverID=0 value was included in the syncCookie the patch changes the internal default slap_serverID value to -1 to make it possible to differentiate between a configured and defaulted serverID=0.
Btw, there are potential problems with using serverID=0, so it would be best if that value was reserved for the default unconfigured case. I.e, a default serverID=0 value could be chosen be slapadd when the two-argument form of serverID is used in the config, as resolving the URL needs the listener argument to slapd to succeed. Enforcing serverID>0 could require changes in existing configurations, but indicating it in the doc. could be a first step?
Rein Tollevik Basefarm AS