The system can not be updated to UCS 5.0 due to the following reasons:
minimum_ucs_version_of_all_systems_in_domain:
ldap_connection:
A LDAP connection to the configured LDAP servers with the machine
account has failed (invalid credentials)!
This MUST be fixed before the update can continue.
This problem can be corrected by setting the content of the file
/etc/machine.secret to the password of the computer object using
Univention Management Console.
Error: Please check “/var/log/univention/updater.log” for details.
ERROR: update failed. Please check /var/log/univention/updater.log
Its due to machine account password and /etc/machine.secret NOT matching …
root@host:~# ucr set ldap/master=$(ucr get ldap/master)
Setting ldap/master
Multifile: /etc/ldap/slapd.conf
File: /etc/default/ntpdate
Module: kopano-cfg
File: /etc/ntp.conf
root@host:~# univention-run-join-scripts --force --run-scripts 05univention-bind.inst
univention-run-join-scripts: runs all join scripts existing on local computer.
copyright (c) 2001-2023 Univention GmbH, Germany
- Running join scripts failed! *
- Message: The given joinscript ‘/usr/lib/univention-install/05univention-bind.inst’ does not exists
expected … this is not the 5.x way
cause is the UCS being a domain controller. It doesn’t join the domain, it IS the domain.
Regenerate the machine password the UCS 5.x way
univention-run-join-scripts --force
root@host:~# univention-run-join-scripts --force
univention-run-join-scripts: runs all join scripts existing on local computer.
copyright (c) 2001-2023 Univention GmbH, Germany
Running pre-joinscripts hook(s):
… nothing …
So… my main LDAP database is not being loaded because the database definition in cn=config is missing or broken. dn: cn=config is basically empty. a healthy UCS system should show multiple entries, including:
- olcDatabase={0}config,cn=config
- olcDatabase={1}mdb,cn=config (or hdb/bdb on older systems)
- olcBackend entries
- moduleload entries
slapd’s configuration is incomplete — the database definition is missing.
When slapd has no olcDatabase entry for your main DB, it:
- starts normally
- loads no data
- returns an empty tree
- rejects all binds
- breaks upgrades
check if any database definitions exist:
ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=config “(objectClass=olcDatabaseConfig)” dn
identify which MDB database is the real one
ldapsearch -Y EXTERNAL -H ldapi:/// -b “olcDatabase={1}mdb,cn=config” olcDbDirectory
ldapsearch -Y EXTERNAL -H ldapi:/// -b “olcDatabase={2}mdb,cn=config” olcDbDirectory
should prove there are two MDB databases defined in cn=config:
- {1}mdb → /var/lib/univention-ldap/ldap This is your real LDAP directory. It contains your actual
data.mdb(≈3 MB). - {2}mdb → /var/lib/univention-ldap/translog This is NOT a directory database. It is a transaction log directory, not meant to be a database. It should never be defined as an MDB database… the root cause of everything.
The actual failure
slapd is loading {2}mdb first instead of {1}mdb.
Why? Because slapd loads databases in numerical order:
{0}config{1}mdb{2}mdb
But {2}mdb is misconfigured as a full database, not an overlay or module. So slapd:
- loads
{2}mdb - sees an empty directory
- serves an empty LDAP tree
- ignores
{1}mdb - returns no entries
- rejects all binds
- breaks the upgrade
Now …
- Administrator bind fails
- machine bind fails
- base search returns nothing
- upgrade pre-check fails
- syslog shows no errors (because slapd thinks this is valid)
LDAP data is not corrupted but it is not being used
need to:
- disable or delete
olcDatabase={2}mdb - ensure only
{1}mdbremains as the main directory DB - restart slapd
- verify the directory loads
- fix Administrator bind
- fix machine bind
- resume the UCS upgrade
ldapsearch -Y EXTERNAL -H ldapi:/// -b “olcDatabase={1}mdb,cn=config”
ldapsearch -Y EXTERNAL -H ldapi:/// -b “olcDatabase={2}mdb,cn=config”
looks like there is no UCS directory tree in data.mdb … YIKES
ldapsearch -Y EXTERNAL -H ldapi:/// -b “” -s base “(objectClass=*)” dn
the stinking UCS directory ends up EMPTY …
Next time before trying an upgrade maybe … do stuff like
mdb_dump -a /var/lib/univention-ldap/ldap/data.mdb > /root/ldap-raw-dump.txt
Or have some form of backups or snapshots of th system. Examples:
- Hypervisor snapshot
- UCS backup (
/var/univention-backup/) - Filesystem backup of
/var/lib/univention-ldap/ - VM backup
- ZFS/Btrfs snapshot
- Anything at all
My box is ENTIRELY hosed. Even worse – the .sql file generated with dump which is a full backup somehow doesn’t have anything useful in it!
damn the luck
Now for some REAL perspective – 5.0-10 is MONTHS away from being fully deprecated. Kopano Core and its related packages are dead beef on 5.2 - their native Python versions do NOT support it at all. SO Next you get to decide between expensive options on UCS 5.2 like Kopano ONE, or kill yourself on functionality an capabilities. SOGo would technically install and run on UCS 5.2 BUT its a mostly different architecture and its ActiveSync stack SUCKS in comparison to Z-Push and there is NO Kopano Outlook Extension (KOE) possibility if you move to a platform that doesn’t provide a MAPI compatible interface.
So predictably, as soon as I can find a way to regain operational stability its goodbye Unvention. Nice knowing you all. And also F-you for that absolutely planned package “upgrade” that completely imploded my server. That bull-crap destroyed my data and caused a 4 day long outage. I hope to hear about you getting what you deserve for that!