--On Wednesday, April 03, 2019 12:40 PM -0400 Dave Macias
we recently adjusted our sync from n-way multimaster replication of
tree (searchbase="dc=organization,dc=com") and now included our
Some concerns/questions I have:
Before with only tree replication, it was my understanding that one could
NOT add a new schema along with an object unless said schema already
existed in the other masters. yes?
Sort of. If you added the schema and then an object, the other masters
should halt replication at that point until they have a matching schema.
Our process was to turn off the sync add the schema to each master
normalize. Probably turning off the sync was unnecessary but just to be
safe. Regardless if a new object with new schemas was added then one
could ruin all the masters. Correct?
Not really, no. It does depend on the version of OpenLDAP in use, as there
were some bugs in older OpenLDAP versions that would allow the object to
partially replicate or the object to just get skipped, which could cause
headache. But those issues were fixed.
Ok, so now with cn=config synchronized as well. Does this issue, if
issue, go away?
I would say that by doing cn=config replication, you've added a wide
surface area for new issues to occur. I generally view cn=config
replication as more of a beta feature. There are still ongoing issues
being resolved and fixed for it (For example, ITS#8616 in the most recent
Also, if upgrading one masters openldap software, should the sync be
Generally, no. It's just a binary in place update to slapd. There was one
instance where a schema change to ppolicy was pushed into 2.4 that broke
existing installations that used cn=config if the ppolicy schema wasn't
also updated at the same time. I don't forsee something like that
happening again in the future as the awareness is there now about the
problems such a change can cause.
Packaged, certified, and supported LDAP solutions powered by OpenLDAP: