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.