Kernel-Update auf einem Live-Webserver nach über einem Jahr Uptime (Plesk auf AlmaLinux)

Neben meinem Homelab habe ich einen Dedicated Server bei einem Hoster. Darauf laufen AlmaLinux 9 und Plesk Obsidian mit 22 Websites, darunter auch Seiten von Freunden. Als ich mir den Server genauer angeschaut habe, stand bei uptime 1 Jahr und 17 Wochen. Das klingt erst mal gut, heißt aber auch: Der Kernel war so alt wie der letzte Reboot.

Die Userspace-Pakete wurden die ganze Zeit automatisch aktualisiert. Der Kernel wird erst nach einem Reboot aktiv, und den hat nie jemand gemacht. needs-restarting -r hat das bestätigt, und von den rund 500 offenen Security Advisories betrafen die meisten den Kernel.

uptime
needs-restarting -r
dnf updateinfo summary
dnf updateinfo list --security

Ein Reboot auf einem Server, der seit über einem Jahr nicht neu gestartet wurde, ist kein Routine-Job. Wenn dabei etwas schiefgeht, sind gleich 22 Websites offline, und ein paar davon gehören nicht mir. Ich bin deshalb in festen Schritten vorgegangen und habe nach jedem Schritt geprüft, ob noch alles läuft, bevor der nächste kam.

Schritt 1: Backups prüfen

Bevor ich irgendwas anfasse, will ich wissen, ob ich zurückkomme. Ich war zuerst überzeugt, dass es kein Offsite-Backup gibt, und wollte eins einrichten. Beim Nachsehen in Plesk stellte sich heraus, dass die Extension „Google Drive Backup“ schon täglich läuft und eine Kopie außerhalb des Servers ablegt. Schau also erst nach, was schon da ist, bevor du etwas Neues baust.

Schritt 2: Die SSDs checken

Nach so langer Laufzeit ist ein Reboot auch der Moment, in dem eine müde Disk nicht mehr hochkommt. smartmontools war nicht installiert, also habe ich das nachgeholt und smartd gleich dauerhaft aktiviert:

dnf install smartmontools
systemctl enable --now smartd

smartctl -H /dev/sda
smartctl -A /dev/sda
smartctl -H /dev/sdb
smartctl -A /dev/sdb

Im Server stecken zwei Samsung PM883 im Software-RAID1. Beide meldeten „PASSED“, 94 % Lebensdauer übrig und rund 33.800 Power-on Hours. Damit konnte es weitergehen.

Schritt 3: Plesk zuerst

Als Nächstes kam das Minor-Upgrade von Plesk. Das ändert nichts am Kernel, und die Websites liefen währenddessen normal weiter. So hatte ich beim späteren Reboot eine Baustelle weniger.

Schritt 4: Alles außer dem Kernel

Danach habe ich alle Updates eingespielt, die keinen Reboot brauchen. Wenn dabei etwas kaputtgeht, weiß ich, dass es nicht am Kernel liegt:

dnf upgrade --exclude='kernel*'

Schritt 5: Kernel-Update und Reboot

Für den eigentlichen Reboot habe ich mir ein ruhiges Zeitfenster gesucht, in dem auf den Seiten wenig los ist. Dann Kernel installieren und neu starten:

dnf upgrade
reboot

Nach 219 Sekunden war der Server wieder erreichbar. Die alten Kernel bleiben installiert. Falls der neue nicht sauber bootet, kann ich im Bootmenü auf einen alten zurückgehen.

Schritt 6: Checks nach dem Reboot

Zuerst das RAID. In /proc/mdstat muss bei jedem Array [UU] stehen, also beide Disks aktiv:

cat /proc/mdstat
needs-restarting -r
systemctl --failed

needs-restarting -r meldete jetzt, dass kein Reboot mehr nötig ist, und alle Services waren aktiv. Den DNS-Server findest du auf Plesk unter dem Service-Namen named-chroot. Wer wie ich zuerst named abfragt, bekommt ein falsches Bild:

systemctl is-active named-chroot

Zum Schluss wollte ich nicht 22 Seiten von Hand im Browser öffnen. Eine kleine Schleife fragt bei jeder aktiven Domain den HTTP-Status ab:

for d in $(cat domains.txt); do
  code=$(curl -s -o /dev/null -L --max-time 15 -w '%{http_code}' "https://$d")
  echo "$code  $d"
done

In domains.txt steht eine Domain pro Zeile. Alles, was nicht mit 200 zurückkommt, schaue ich mir einzeln an.

Bonus: Abgelaufenes Zertifikat per CLI fixen

Bei der Schleife fiel eine Seite mit abgelaufenem Zertifikat auf. Die Let’s-Encrypt-Extension von Plesk lässt sich auch auf der Kommandozeile aufrufen:

plesk bin extension --exec letsencrypt cli.php -d example.de -m admin@example.de

Danach hatte die Seite wieder ein gültiges Zertifikat.

Root-Zugang für Automatisierung absichern

Für solche Wartungen nutze ich einen eigenen SSH-Key mit Root-Zugriff. Damit der allein nicht reicht, ist er in authorized_keys auf meine Heim-IP beschränkt. Von jeder anderen Adresse wird der Key abgelehnt:

from="<deine-heim-ip>" ssh-ed25519 AAAA... automation

Fazit

Automatische Updates halten die Pakete aktuell, den neuen Kernel lädt aber erst der Reboot. Bei mir hat der ganze Ablauf aus Backup-Check, SSD-Check, Plesk-Upgrade, Updates und Reboot ohne Probleme geklappt. Der Server läuft auf dem neuen Kernel, das RAID steht auf [UU], und smartd überwacht die beiden SSDs jetzt dauerhaft.

Wie oft startest du deine Server neu? Schreib es in die Kommentare.