In meinem vorherigen Beitrag hatte ich ja schon geschrieben, dass mich die Sicherheitslücke PHP2Shell dazu „motiviert“ hat, unter anderem bei meinem Heimserver endlich die lange überfälligen Upgrade über mindestens drei Debian Releases hinweg, startend bei „Stretch“ durchzuführen.
Natürlich hatte ich bei Bekanntwerden von PHP2Shell zunächst einmal Sofortmaßnahmen dahingehend ergriffen, dass ich in der inzwischen vorgeschalteten Fritzbox die Weiterleitung von Port 80 und 443 unterbunden habe, der Webserver also nicht mehr vom Internet aus erreichbar war. Eine öffentliche Webseite im engeren Sinn betreibe ich auf dem Heimserver ohnehin nicht, allerdings sorgte das Abklemmen dafür, dass praktische jegliche Synchronisation mit meinem Smartphone über selbstgehostetesWebDAV, CalDAV und CardDAV sowie die Roundcube-Installation erst einmal nicht mehr funktioniert(e).
Beim Durchführen der Updates sah ich zwei prinzipielle Möglichkeiten:
- Den „klassischen“ Weg mittel mehrfachem dist-upgrade
- Komplette Neu-Installation direkt von Debian Trixie
Ich hatte das auch auf der Debian-User-Mailingliste andiskutiert und habe mich dann nach einigem inneren Hin und Her sozusagen zu einem hybriden Ansatz entschieden: Ich habe mir, nachdem die alte auch schon wieder 10 Jahre alt war, eine neue SSD besorgt.
Exkurs an dieser Stelle: die aktuelle KI-induzierte Speicherkrise ist wirklich unangenehm und Hirnfasching-würdig. Die alte SSD ware eine Samsung 850 EVO mit 500 GB habe ich im Mai 2016 €136,90 bezahlt. Für die neue SSD, eine Samsung 870 EVO ebenfalls mit 500 GB habe ich nun im Oktober 2026, also gut 10 Jahre später, €179,95 bezahlt. 🙄
Aber zurück zum Debian Upgrade: bereits gestern habe ich die alte SSD mit DiskGenius auf die neue geklont, die neue SSD in den Server eingebaut und konnte problemlos davon booten. Heute war es dann soweit, den ersten Upgrade-Schritt zu tun: zunächst also die Repositories in /etc/apt/sources.list ändern (danke an dieser Stelle an diese Webseite für das Auflisten aller möglichen Debian-Archiv-Einträge!) und ein „aptitude update“ durchführen. Danach dann leicht nervös „aptitude dist-upgrade“ aufrufen.
Relativ früh im Prozess maulte zunächst GRUB, weil sich die ID des Bootlaufwerks durch das Klonen geändert hatte. Eine per Menü ausgewählte Neuinstallation auf /dev/sda (statt /dev/sda1) erwies sich dann im Nachhinein als die richtige Wahl.
Die weitere Abarbeitung mit diversen Rückfragen lief dann zunächst einmal unspektakulär, bis zu dem Punkt als arno-iptables-firewall ‚dran war, sich wegen eines Fehler nicht neustarten lassen wollte ich infolge dessen die SSH-Verbindung vom meinem Desktop aus verlor. Als unorthodoxe Lösung bin ich dann direkt zum Server and die „Notfall-Konsole“, habe noch ein wenig gewartet, bis ich mir einigermaßen sicher war, dass aptitude nicht auf irgendeine Eingabe wartet (und nicht weiterhin Pakete auspackt) und habe dann mit kill den aptitude-Prozess abgeschossen. Ein erneutes Aufrufen von „aptitude dist-upgrade“ brachte dann die wenig überraschende Fehlermeldung, dass der vorherige Durchlauf nicht korrekt beendet worden sei und brachte dankenswerter Weise gleich den Hinweis, dass das wohl mit „dpkg –configure -a“ zu beheben sei. Dem war auch in der Tat so: dieser Befehl lies die noch offenen Paket-Konfigurationen durchlaufen und ein abermaliges „aptitude dist-upgrade“ zur Kontrolle danach zeigte keine offenen Punkte mehr.
Auch wenn ich vorherigen Problems mit arno-iptables-firewall ziemlich nervös war, entschloss ich mich an dieser Stelle zum Neustart. Und siehe da: der lief glatt durch, nach dem Neustart scheinen soweit alle Dienste wieder korrekt gestartet zu sein, insbesondere die Firewall funktioniert auch. Lesson learned: die nächsten Upgrades mache ich wohl besser gleich von der „Notfall-Konsole“ aus.
Damit wäre der erste Schritt getan und der Heimserver läuft nun erstmal auf Debian Buster. Hoffentlich gleich morgen kann ich dann das Upgrade auf Debian Bullseye in Angriff nehmen.
Nachtrag: eine Sache funktionierte doch nicht direkt – der Courier-IMAP Daemon. Des Rätsels Lösung war die Zertifikatsdatei /etc/courier/imapd.pem . Die hatte als Eigentümer root:courier und Zugriffsrechte 600. Da aber Courier auf Buster unter dem User „courier“ läuft, mussten die Zugriffsrechte auf 640 angepasst werden. Das habe ich dann auch gleich im Certbot post-renew-hook-Skript für Courier ergänzt, damit das dann auch Zukunft korrekt bleibt.
Update 03.11.2026: Ein weiterer Fehler hat sich noch im Nachgang gezeigt: der ClamAV-Daemon wollte ebenfalls nicht starten. In diesem Fall lag es den nicht mehr unterstützten „StatsEnabled“, „StatsPEDisabled“, „StatsHostID“ und „StatsTimeout“ in der /etc/clamav/clamd.conf.