Remove legacy UDM / LDAP objects with upgrade to UCS-5.2

Knowledge Base Supported
1

With UCS-5.2 several legacy Univention Directory Manager (UDM) modules have been removed. Previously they were used to manage certain entries in LDAP, which become unmanageable after the upgrade: The data remains stored in LDAP, but the modules to create / show / modify / move / delete them is no longer available. In many cases this is unproblematic, but leads to long-term problems as folders containing such objects become un-removable, un-movable or un-renamable.
Therefore those entries should be deleted before the upgrade to UCS 5.2. This is checked during the upgrade procedure, which by default aborts if any such object is found.

Checking for legacy entries

  1. Download the script as file check.sh, for example by using wget.
  2. Execute it as the user root: sudo bash check.sh update_check_legacy_objects
  • If the script outputs nothing, your system does not contain any legacy entries (anymore) and you are safe to upgrade.
  • If any legacy objects are found, they are printed to output:
Starting check.sh (Mo 13. Nov 11:30:49 CET 2023):
        The following objects are no longer supported with UCS 5.2:
                dn: cn=24x7,cn=nagios,dc=test,dc=intranet
                dn: cn=WorkHours,cn=nagios,dc=test,dc=intranet
                dn: cn=NonWorkHours,cn=nagios,dc=test,dc=intranet
                dn: id=default-saml-idp,cn=univention,dc=test,dc=intranet
                dn: SAMLServiceProviderIdentifier=google.com,cn=saml-serviceprovider,cn=univention,dc=test,dc=intranet
                dn: SAMLServiceProviderIdentifier=https://saml.salesforce.com,cn=saml-serviceprovider,cn=univention,dc=test,dc=intranet
                dn: SAMLServiceProviderIdentifier=https://sp.testshib.org/shibboleth-sp,cn=saml-serviceprovider,cn=univention,dc=test,dc=intranet
                dn: SAMLServiceProviderIdentifier=https://ucs-4421.test.intranet/univention/saml/metadata,cn=saml-serviceprovider,cn=univention,dc=test,dc=intranet

        They must be removed before the update can be done.
        See <https://help.univention.com/t/16227> for details.

        This check can be disabled by setting the UCR variable 'update52/ignore_legacy_objects' to 'yes'.

There are two types of entries:

  1. STRUCTURAL object classes define the structure of each entry. As each entry has exactly one such class defining its purpose, it’s easy to identify those entries and to remove the complete entry.
  2. AUXILIARY object classes are add-on classes, which can be added on top of any other classes. In most cases they are used for Extended Attributes, which allow them to store arbitrary data with each entry. In this case only the associated attributes should be deleted, not the complete entry!

Deleting entries

Danger: deleting the objects cannot be undone easily. At least make sure you have a recent backup of your LDAP database, which is by default created daily by the cron-job /etc/cron.d/univention-ldap-server invoking /usr/sbin/univention-ldap-backup and stored in /var/univention-backup/.

  • Either go through that list manually and use the corresponding udm "$module" remove --dn "$dn" command to delete the entries.
  • As an alternative you can also use ldapdelete -x -D "cn=admin,$(ucr get ldap/base)" -y /etc/ldap.secret "$dn", which saves you from looking up the required UDM module name for each entry.
  • You can also invoke the same script again with the alternative command line argument delete_legacy_objects to delete all legacy objects:
    sudo bash check.sh delete_legacy_objects

Deleting auxiliary classes

Deleting auxiliary classes is more complicated as they function as add-ons to other entries: Instead of deleting the complete entry only the additional attributes and the objectClass must be removed from the entry. The procedure is described in detail in

This is also performed as part of sudo bash check.sh delete_legacy_objects.

Optional: Schema removal

Deleting the entries is sufficient, but the LDAP schema definitions can also be removed after all entries based on them have been deleted. As OpenLDAP does not allow schema removal, this requires a complete “dump-restore” cycle, which is described in more detail in

Alternative: keep entries

If you cannot or don’t want to remove the objects now and still want to manage them, you can still use an UCS-5.0 system to do so.
Just make sure to delete those objects before you upgrade your last system to UCS-5.2. Otherwise you have to setup a new system based on UCS-5.0 and then can use that system again to manage those objects.

Quoting the warning from above again:

Your may experience problems when renaming, removing or moving containers containing those legacy objects.

You have been warned!

The update check can be disabled by setting the UCR variable update52/ignore_legacy_objects to yes on each system before the update to UCS-5.2 is started.

List of affected LDAP Object classes and their UDM modules

Each entry names the “LDAP Object class”, the name of the managing UDM module (if any) and a short description to give you a hint for what the information is used.

TODO

3 Likes