Generell lautet ja meine Empfehlung, bei produktiven Servern niemals ein Distributions-Upgrade durchzuführen, als z.B. ohne Neuinstallation von Ubuntu 22.04 auf 24.04 umzustellen. Manchmal halte ich mich aber selbst nicht an diese Regel. Testobjekt war ein Server mit Apache, MySQL, PHP, Mail (Postfix, Dovecot, OpenDKIM) und Docker.
Natürlich gab es Schwierigkeiten …
Fairerweise muss ich zugeben, dass do-release-upgrade
noch gar kein Server-Update auf Version 24.04 vorsieht. Das ist ein wenig überraschend, als Ubuntu 24.04.1 ja bereits freigegeben wurde. Normalerweise ist das der Zeitpunkt, ab dem do-release-upgrade
funktionieren sollte. Ich habe das Upgrade mit do-release-upgrade -d
erzwungen. Selbst schuld also.
Update: Canonical rät aktuell wegen APT-Problemen explizit davon ab, Upgrades von 22.04 auf 24.04 durchzuführen (siehe https://lists.ubuntu.com/archives/ubuntu-release/2024-September/006225.html).
Distributions-Upgrade
Zuerst habe ich ein letztes Mal alle 22.04-Updates installiert (also apt update
und apt full-upgrade
) und den Server dann neu gestartet.
Danach habe ich ein Backup des in einer virtuellen Maschine laufenden Servers durchgeführt. Zur Not hätte ich aus der gesicherten Image-Datei problemlos den bisherigen Zustand des Servers wiederherstellen können. Das war aber zum Glück nicht notwendig.
Das Distributions-Upgrade habe ich dann mit do-release-upgrade -d
eingeleitet, wobei -d
für --devel-release
steht und das Update erzwingt. Es dauerte ca. 1/4 Stunde und lief an sich überraschend flüssig durch. Ein paar Mal musste ich bestätigen, dass meine eigenen Konfigurationsdateien erhalten bleiben und nicht durch neue Konfigurationsdateien überschrieben werden sollten.
Der nachfolgende Reboot verursachte keine Probleme, ich konnte mich nach kurzer Zeit wieder mit SSH einloggen. So weit so gut!
Kein DNS
Die statische Netzwerkkonfiguration meines Servers erfolgt durch /etc/netplan/01.yaml
. Dort sind sechs Nameserver eingetragen, je drei für IPv4 und IPv6. Überraschenderweise funktioniert im aktualisierten 24.04-Server keine Namensauflösung mehr — ein wirklich grundlegendes Problem! ping google.com
führt also zum Fehler, dass die IP-Adresse von google.com unbekannt sei.
Ein kurzer Blick auf resolv.conf
zeigt, dass es sich dabei um einen Link auf eine gar nicht existierende Datei handelt.
ls -l /etc/resolv.conf
/etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf (existiert nicht)
dpkg -l | grep resolve
verrät, dass systemd-resolved
nicht installiert ist. Sehr merkwürdig!
Abhilfe schafft die Installation dieses Pakets. Die Installation ist aber ohne DNS gar nicht so einfach! Ich musste zuerst /etc/resolv.conf
löschen und dann einen Eintrag auf den Google-DNS dort speichern:
rm /etc/resolv.conf
echo "nameserver 8.8.8.8" > /etc/resolv.conf
apt install systemd-resolved
reboot
Nach einem Reboot läuft DNS. resolvectl
listet jetzt meine in /etc/netplan/01.yaml
aufgeführten Nameserver auf.
PHP-Probleme
Nächstes Problem: Apache startet nicht. systemctl status apache2
verweist auf einen Fehler in einer Konfigurationsdatei von PHP 8.1. Aber Ubuntu 24.04 verwendet doch PHP 8.3. Was ist da passiert?
Ein Blick in /etc/apache2/mods-enabled
zeigt, dass dort noch PHP 8.1 aktiviert ist. Abhilfe:
a2dismod php8.1
a2enmod php8.3
systemctl restart apache2
Apache und PHP laufen jetzt, aber ein Blick auf die Nextcloud-Statusseite zeigt, dass /etc/php/8.3/apache2/php.ini
sehr konservative Einstellungen enthält. Nach memory_limit=1024M
und ein paar weiteren Änderungen ist auch Nextcloud zufrieden.
OpenDKIM
Auf meinem 22.04-Server hatte ich DKIM aktiv (siehe auch https://kofler.info/dkim-konfiguration-fuer-postfix/). Nach dem Upgrade funktioniert die Signierung der Mails aber nicht mehr. Der Grund war einmal mehr trivial: Beim Upgrade sind die entsprechenden Pakete verloren gegangen. Abhilfe:
apt install opendkim opendkim-tools
Fazit
Keines der Probleme war unüberwindbar. Überraschend war aber die triviale Natur der Fehler. Beim Upgrade verloren gegangene oder nicht installierte Pakete, keine Synchronisierung zwischen den installierten Paketen und den aktivien Apache-Modulen etc. Ich bleibe bei meinem Ratschlag: Wenn Ihnen Stabilität wichtig ist, vermeiden Sie Distributions-Upgrades. Ja, die Neuinstallation eines Servers verursacht mehr Arbeit, aber dafür können Sie den neuen Server in Ruhe ausprobieren und den Wechsel erst dann durchführen, wenn wirklich alles funktioniert. Bei einem Upgrade riskieren Sie Offline-Zeiten, deren Ausmaß im vorhinein schwer abzuschätzen ist.
Links/Quellen