Univention Bugzilla – Bug 48182
OpenLDAP overlay module should not use UDM
Last modified: 2021-05-03 21:54:09 CEST
A dependency loop was introduced with patch openldap/.../70_ppolicy_udm_lock.patch univention-ldap-config Pre-Depends slapd slapd Depends: python-univention-directory-manager python-univention-directory-manager Depends: univention-ldap-config (>= 14.0.2-28) On existing UCS systems this is resolved by apt (probably using an existing python-univention-directory-manager package), but in a system without univention-ldap* and UDM - like our build system - this fails.
The change that triggered this was (fox Bug #47944): [4.3-2] 4e0da28cd1 Bug #47944: update dependencies
The circular dependency prevents building ucs-test in out build system and probably everything else that depends on UDM.
It actually also leads to UCS systems not being able to update, so a lot of our Jenkins tests failed tonight: http://jenkins.knut.univention.de:8080/job/UCSschool-4.3/job/Install%20Singleserver/ws/Config/s4/TestGroup/base1/test/updater.log
The slapd-patch is a gross layering violation, as it used the higher-level UDM API inside the lower-level LDAP server.
The dependency on the schema package (univention-ldap-config) was removed from python-univention-directory-manager und the dependency loop broken (88ebc08b in 4.3-2). While the schema in univention-ldap-config is actually required for UDM to work, it might not be installed on the same system (if it's not a DC master/backup), as it will be replicated through LDAP. So that requirement cannot be represented with Debian package dependencies. But I still think that the dependency of a OpenLDAP overlay module on UDM is a problem, so I'm relabeling this bug.
I reset the flags since it is no longer blocking Bug #47944.
Maybe we can do it with a HTTP client using the UDM REST API once.