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.
moved from Incoming to Software Bugs
fixed in master
Commits: • f2740c79 by Howard Chu at 2021-03-21T17:41:19+00:00 ITS#8589 syncrepl: defer on REFRESH_REQUIRED