Univention Bugzilla – Bug 55342
replication: failed.ldif generated from UDL cache incompatible with local LDAP server
Last modified: 2022-12-19 11:11:59 CET
When a large group was modified there was a TIMEOUT after 5 min in UDL. The replication.py modules failed to contact the local LDAP server during that time. In that case ucs44/management/univention-directory-replication/replication.py:859 defaults to use the data from its cache: > old = listener_old For some unknown reason the data from the local UDN cache was not synchronized with the data from the local LDAP server: the generated LDIF contained some users, which no longer existed in the local LDAP server. Thus the generated `failed.ldif` could not be applied to the local LDAP server: > /usr/sbin/univention-directory-replication-resync /var/lib/univention-directory-replication/failed.ldif The "right" thing was to just delete `failed.ldif` file and let UDN resume the last transaction, now being able to connect the local LDAP server again, build and apply the right LDIF and succeeding.
I will downvote this priority bug because from my understanding: It happened only once The reason is unknown A workaround exists And the workaround seems to be the viable solution (remove failed.ldif). I do not see a clear path to a product fix If this happens again, we should reinvestigate.
Taking Bug 48627 comment 4 into account `replication.py` not only the generating an invalid `failed.ldif` is an issue, but also the fact, that `replication.py` touches *all* LDAP entries which are thus put into the UDL cache on any BDC and RDC, which massively increases their size and leads to errors during join of large domains. We already added the UCRV `listener/cache/filter` to exempt certain LDAP classes from being added to the UDL cache, but this does not provide enough infrastructure for `replication.py` to opt-out from the caching. In addition to `handle_every_delete` a similar mechanism for _updating_ would also be needed.