That's probably the easiest thing to do. Sorry for this; OpenLDAP clearly
deviated from the intention of RFC4533 here. I.e., the cookie was meant to be
an opaque value that is not interpreted by the consumers. I believe in the
usual case, a consumer that needed to "know" the replication state was
supposed to generate its own private state, independent of the cookie that the
Unfortunately this intention simply doesn't work in the real world. The view
of entities as being only providers or only consumers is too simplistic. Even
when syncrepl was first being developed, we had the notion of cascaded
replication, where a consumer was itself a provider to other downstream
consumers. When you have multiple entities participating in replication, it's
important to be able to see that each one's notion of the replication state
agrees with everyone else's. It's also important to be able to determine this
without knowing in advance whether an entity is a provider or a consumer.
Particularly since in cascading or multi-master replication, the entity is both.
So in OpenLDAP we abandoned the notion that consumers could just stash the
provider's cookie without peeking inside, and could generate their own cookies
independently if they were going to serve as providers to other servers.
I believe we could have made it work correctly, with each server generating
its own state and leaving received cookies as opaque values, but then it would
have been impossible to do a simple query to see if two entities are in sync.
– Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/