Hello,

Since updating our LDAP infrastructure to OpenLDAP 2.5 (2.5.13 from the Debian repository), we have encountered desynchronization issues with certain objects. The synchronization in place is in push mode as documented in the official documentation (https://www.openldap.org/doc/admin25/replication.html#Syncrepl%20Proxy). The problem seems to stem from the fact that we are using dynamic attributes via the dynlist overlay, and the master server attempts to push these dynamic attributes to the slave servers when modifications are made to these objects, which the slaves refuse.

Log extract from one of our slave servers:

Aug 13 10:12:28 volubilis slapd[2005636]: conn=20983 op=54 MOD dn="uid=ele-ladon-test,ou=contracts,o=easter-eggs" Aug 13 10:12:28 volubilis slapd[2005636]: conn=20983 op=54 MOD attr=eeTechnicalContact eeStartDate eeStorageDisks entryCSN modifiersName modifyTimestamp eeContractId eeContractIncludedService Aug 13 10:12:28 volubilis slapd[2005636]: conn=20983 op=54 RESULT tag=103 err=16 qtime=0.000022 etime=0.000536 text=modify/delete: eeContractId: no such attribute

Note: The attribute eeContractId is a dynamic attribute of the object in question.

Previously, with OpenLDAP 2.4, we did not have this issue, and the attributes were dynamic (and therefore managed by dynlist) on both our master server and slave servers. To immediately resolve this problem, we have removed the dynlist configuration on our slave servers. These attributes are therefore "static" on our slave servers, and desynchronizations are potentially possible.

How can we correctly manage this situation? Please note that some of the affected attributes are both static on certain objects and dynamic on others, so we cannot simply exclude them completely from synchronization.

Thank you in advance.