Experience report and asking for hints: Upgrade from 5.0 with OX to UCS 5.2.2 errata 157 without OX

[johnny]

2025-07-27T22:00:00Z

Hi,
I upgraded my community edition of UCS from 5.0 (running as guest in a KVM environment, host OS=Arch Linux) to 5.2.2 yesterday, following all the documentation hints and procedures.

The server is standalone in VM, just for a small family installation (5 users).

This report shall be a comprehensive article for all who might be interested in upgrading and for those giving me hints how to solve the remaining issues described at the end of this note.

(Since the upgrade was done on the production system itself (I don’t have a playground of servers at home), I used

virsh backup-begin

to perform live-backups between each major step)

Here is what I did to get the migration / upgrade working:

• Be VERY SURE to have your network card (I just have on virtual NIC) always running properly, even when renamed by Host-OS oder Guest-OS (!!!). Otherwise, I suggest problems. My installation was just stopping and I had to use my last virsh backup!

• Check your /etc/Univention/base.conf and be sure, the network names are identical in this file, the registry and /etc/network/interfaces, please refer to #19591

• I don’t want to fool around with network card names, so I inserted a new udev-rule in my own new file

/etc/udev/rules.d/10-my-network.rules

and inserted:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="XX:XX:XX:XX:XX:XX", KERNEL=="eth*", NAME="enp1s0"

This kept my NIC name stable at enp1s0 (in my KVM environment)

• Disabling external access to email (closing external firewall ports for mailserver)

• I had to get rid of the OX suite and OX-connector, since there where no updates for month now. This was done by procedure mentioned in #6810 (Daniel Tröder).

• The /boot directory was pruned by implementing new UCS variable in registry:

update52/pruneoldkernel → „yes“

• Keycloak migration was done by following documentation chapter 6 by issuing:

#univention-keycloak-migration-status --delete --create-sso-uri-setting

• Checking Keycloak with

#univention-keycloak-migration-status

returns: “Migration to Keycloak complete.”

• I downloaded (to /tmp) and ran the

#check.sh

script described in:

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

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…

• After finding the described legacy objects in the output, I just ran the script again (as root!) with:

./check.sh delete_legacy_objects

• I did not delete any auxiliary classes as described in #22252

• After running the upgrade from the portal (which took ~ 40 minutes(!)), the server was restarted and tested starting with internal connections

Test results 1:

• The server does not accept any email from internal.
• There are still OX entries in /etc/postfix/main.cf as follows:

Reason in file : /etc/postfix/main.cf
Please find the ox entries, which are senseless…

virtual_alias_maps = unionmap:{hash:/etc/postfix/virtual,
        ldap:/etc/postfix/ldap.groups,
        ldap:/etc/postfix/ldap.ox-distlist,
        ldap:/etc/postfix/ldap.ox-sharedfolder,
        ldap:/etc/postfix/ldap.ox-virtual,
        ldap:/etc/postfix/ldap.external_aliases,
        ldap:/etc/postfix/ldap.ox-sharedfolder_mailbox,
        ldap:/etc/postfix/ldap.ox-virtual_mailbox,
        ldap:/etc/postfix/ldap.ox-functionalaccount}

virtual_mailbox_maps = ldap:/etc/postfix/ldap.**ox-sharedfolder_mailbox**,
        ldap:/etc/postfix/ldap.**ox-virtual_mailbox**

Solution: Change the UCS registry entries as follows follwed by the needed post-commands:

ucr set "mail/postfix/virtual/alias/maps=unionmap:{hash:/etc/postfix/virtual, ldap:/etc/postfix/ldap.groups, ldap:/etc/postfix/ldap.distlist, ldap:/etc/postfix/ldap.virtual, ldap:/etc/postfix/ldap.external_aliases, ldap:/etc/postfix/ldap.sharedfolderremote, ldap:/etc/postfix/ldap.sharedfolderlocal_aliases, ldap:/etc/postfix/ldap.virtual_mailbox, ldap:/etc/postfix/ldap.sharedfolderlocal}"

ucr commit /etc/postfix/main.cf

postmap …

systemctl restart postfix

Test 2: with internal connections only:

• Systems accept email and delivers to local mailboxes as expected

Test3:

• Opening firewall ports for external connections (e.g. TCP 25, 110, 465, 587, 993, 995, what ever you prefer)
• use an external email sender (friend or website sender)

But external connections will not be accepted (log entries from /var/mail/mail.log):

2025-07-27T21:31:22.069780+02:00 ucs1 postfix/smtpd[7637]: Anonymous TLS connection established from web.heise.de[193.99.144.71]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature ECDSA (prime256v1) server-digest SHA256

2025-07-27T21:31:22.956851+02:00 ucs1 postfix/smtpd[7637]: warning: connect to 127.0.0.1:10023: Connection refused

2025-07-27T21:31:22.957270+02:00 ucs1 postfix/smtpd[7637]: warning: problem talking to server 127.0.0.1:10023: Connection refused

2025-07-27T21:31:23.958561+02:00 ucs1 postfix/smtpd[7637]: warning: connect to 127.0.0.1:10023: Connection refused

2025-07-27T21:31:23.959885+02:00 ucs1 postfix/smtpd[7637]: warning: problem talking to server 127.0.0.1:10023: Connection refused

2025-07-27T21:31:23.960066+02:00 ucs1 postfix/smtpd[7637]: NOQUEUE: reject: RCPT from web.heise.de[193.99.144.71]: 451 4.3.5 user@domain.tld: Recipient address rejected: Server configuration problem; from=devnull@heise.de to=john@fitzgerald.eu proto=ESMTP helo=<web.heise.de>

2025-07-27T21:31:23.970284+02:00 ucs1 postfix/smtpd[7637]: disconnect from web.heise.de[193.99.144.71] ehlo=2 starttls=1 mail=1 rcpt=0/1 data=0/1 quit=1 commands=5/7
[…]

My findings:

• I was first puzzled and searching in postfix entries, but this is not the problem. In fact. the mailserver is unable to reach port 127.0.0.1:10023 and therefore stops accepting external email. Port 10023 seems to be the Greylisting plugin, so as a first try, I’ve deactivated this feature by setting UCS registry variable mail/postfix/greylisting to “no”.
• After #systemctl restart postfix the server is accepting external email and was put into (family environment) production again.

I did not check the iptables firewall so far, I was too tired yesterday night

Other issues found so far:

1. From the logs, I still find problems with old ox entries in registry (?):
   2025-07-27T21:52:43.335636+02:00 ucs1 postfix/smtpd[3459]: error: open /etc/postfix/ldap.ox-sharedfolder_mailbox: No such file or directory
   2025-07-27T21:52:43.335985+02:00 ucs1 postfix/smtpd[3459]: error: open /etc/postfix/ldap.ox-virtual_mailbox: No such file or directory
   (I am researching, where they come from, if anybody has a hint, please tell me)

2. Fail2ban is mot working properly (not blocking anymore, and entries are not injected in iptables firewall) – this has to be solved.

Hopefully, I did not miss anything of my steps from yesterday .

If you have any improvements and hints, please send me a note.

Cheers!