(ITS#8589) cn=config replication plus DB replication can break replication

[quanah@openldap.org]

Full_Name: Quanah Gibson-Mount
Version: 2.4.44
OS: N/A
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (47.208.148.26)


Test059 can expose an interesting bug in OpenLDAP when replication is configured
for both cn=config and an underlying data DB.  I wouldn't call it a critical
issue for this scenario, but it's possible it could be critical in other
scenarios I'm not aware of.

The basic problem breaks down like this:

a) A modification to the schema is made in cn=config
b) An entry is added or modified to the data DB that makes use of the new schema
changes

The majority of the time, this is not an issue, as the change to the schema gets
replicated /before/ the change to the entry is honored.

However, if the modification to the entry is done *before* the schema changes
get replicated, the following happens:

a) The replica pauses cn=config replication
b) The replica attempts to replicate the changed entry
c) The replica fails to replicate the change due to the fact the schema is not
yet updated
d) The replica goes into an endless REFRESH loop

Because cn=config replication is never "unpaused", the REFRESH operation can
never succeed.  It essentially takes manual intervention to fix the replica.