Univention Bugzilla – Bug 31048
remove cn=admin-settings,cn=univention,...
Last modified: 2021-05-25 16:01:56 CEST
AFAIK, the container admin-settings is not used anymore, yet it is still present on UCS 3.x installations.
*** Bug 24213 has been marked as a duplicate of this bug. ***
Still used in the following files: management/univention-directory-manager-modules/modules/univention/admin/handlers/users/user.py management/univention-ldap/10univention-ldap-server.inst management/univention-ldap/base.ldif management/univention-ldap/conffiles/etc/ldap/slapd.conf.d/10univention-ldap-server_schema management/univention-ldap/conffiles/etc/ldap/slapd.conf.d/64univention-ldap-server_acl-master-admin-settings management/univention-ldap/debian/univention-ldap-acl-master.univention-config-registry
*** Bug 27187 has been marked as a duplicate of this bug. ***
This issue has been filed against UCS 4.2. UCS 4.2 is out of maintenance and many UCS components have changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer UCS versions, please use "Clone this bug" or reopen it and update the UCS version. In this case please provide detailed information on how this issue is affecting you.
We really need to remove this cruft from UCS-2. [feature/ucs5] 5995f51e90 Bug #31048: Remove cn=admin-settings,cn=univention doc/changelog/changelog-5.0-0.xml | 2 +- .../univention/admin/handlers/users/ldap.py | 7 -- .../univention/admin/handlers/users/user.py | 7 -- management/univention-ldap/base.ldif | 7 -- ...nivention-ldap-server_acl-master-admin-settings | 29 ------ management/univention-ldap/debian/changelog | 6 ++ .../debian/univention-ldap-acl-master.maintscript | 1 + ...tion-ldap-acl-master.univention-config-registry | 6 -- .../tests/61_udm-users/30_user_admin_setting_acl | 114 --------------------- 9 files changed, 8 insertions(+), 171 deletions(-) Be careful as there exists two containers: cn=admin-settings,cn=univention,$LDAP_BASE cn=admin-settings,cn=users,cn=policies,$LDAP_BASE The 2nd one is Bug #47949
FYI: We cannot remove the schema as that would break old installations: OpenLDAP does not support Schema removal; that would require a complete slapcat | slapadd cycle.
Can't we just remove the existing objects in postup.sh? Or add the LDAP ACL: access to filter="objectClass=univentionAdminUserSettings" by * none stop Prior: nobody could see/search these objects. Now: everybody has read access to these objects. Resulting in multiple matches for the search filter 'uid=foo'. This might break existing implementation which rely on uid uniqueness and specify a broken ldap filter (e.g. without '(&(uid=...)(objectClass=person))') found a potential one with grep: services/univention-radius/modules/univention/radius/networkaccess.py: 153 » » users = self.ldapConnection.search(filter=filter_format('(uid=%s)', (uid, )), attr=['univentionNetworkAccess'])
(In reply to Florian Best from comment #7) > Can't we just remove the existing objects in postup.sh? I do want to remove things automatically as this can lead to unexpected data-loss as we cannot guarantee that there is nothing important left under that container (by accident). I would prefer adding a section about cleanup commands to be executed before an update to UCS-5 is allowed as there are more things to remove: fatclient thinclient managedclient policy/thinclient admin-settings As discussed I created Bug #51655 for that.
OK: changelog OK: depends on Bug #51655 OK: removal
Created attachment 10626 [details] updater.log
(In reply to Florian Best from comment #10) > Created attachment 10626 [details] > updater.log The updater is full of these messages: > Failed to process Subfile /etc/univention/templates/files/etc/ldap/slapd.conf.d/64univention-ldap-server_acl-master-admin-settings > Failed to process Subfile /etc/univention/templates/files/etc/ldap/slapd.conf.d/64univention-ldap-server_acl-master-admin-settings Can we get rid of them?
(In reply to Florian Best from comment #11) > (In reply to Florian Best from comment #10) > The updater is full of these messages: > > Failed to process Subfile /etc/univention/templates/files/etc/ldap/slapd.conf.d/64univention-ldap-server_acl-master-admin-settings ... > Can we get rid of them? Not easily and the message is only a warning and thus not fatal. During the Debiann package upgrade the following happens: 1. `preinst` renames the template /etc/univention/templates/files/etc/ldap/slapd.conf.d/64univention-ldap-server_acl-master-admin-settings → the file is now missing for any UCR call 2. `dpkg` unpacks the new info file /etc/univention/templates/info/univention-ldap-acl-master.info with suffix `.dpkg-new` 3. Many other packages may get unpacked as well 4. `dpkg` renames the new info file by stripping the suffix `.dpkg-new` to it final name 5. `postinst` finally removes the renamed template file 6. May other packages may get unpacked 7. `dpkg` triggers `ucr update`, which re-reads the `*.info` files to re-build its cache → ucr is now consistent again To re-iterate the important point: - `preinst` is called *before* the new `.info` file is unpacked, so you cannot tell UCR to "forget" the template already at this point. - `preinst` *must* rename the template to get it removed from `dpkg`s conffiles, so UCR now misses its file. - between `preinst` and `postinst` many other actions are triggered and the package itself has no option to intervene. - triggering `ucr update` from `postinst` explicitly will not solve the underlying problem. The right fix for this kind of problems would be Bug #28284, because the new `.info` file would be active directly after `unpack`.
OK: then let's keep those messages.
UCS 5.0 has been released: https://docs.software-univention.de/release-notes-5.0-0-en.html https://docs.software-univention.de/release-notes-5.0-0-de.html If this error occurs again, please use "Clone This Bug".