(ITS#5536) Always use a configured serverID in the syncrepl cookie

[rein@OpenLDAP.org]

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