Ubuntu oder Debian auf dem Server: Was passt zu deiner Umgebung?

. /etc/os-release && echo "$PRETTY_NAME ($VERSION_CODENAME)"

# Ubuntu: Abdeckung je Paketquelle, inklusive ESM
pro security-status
pro status --all
hwe-support-status --verbose

# Debian: welche Pakete das Security-Team nicht mehr trägt
sudo apt install -y debian-security-support
check-support-status

# Auf beiden: aus welcher Komponente kommt ein Paket wirklich
apt-cache policy postgresql-common

pro security-status liefert die unangenehme Zahl: wie viele installierte Pakete aus universe stammen und damit ohne Ubuntu Pro keinen garantierten Sicherheitssupport haben. check-support-status ist das Debian-Gegenstück und listet Pakete mit eingeschränktem oder beendetem Support.

// Debian
Unattended-Upgrade::Origins-Pattern {
  "origin=Debian,codename=${distro_codename},label=Debian-Security";
  "origin=Debian,codename=${distro_codename}-updates";   // optional
};

// Ubuntu, die ESM-Zeilen wirken nur mit angehängtem Pro-Abo
Unattended-Upgrade::Allowed-Origins {
  "${distro_id}:${distro_codename}-security";
  "${distro_id}ESMApps:${distro_codename}-apps-security";
  "${distro_id}ESM:${distro_codename}-infra-security";
};

Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Automatic-Reboot-Time "03:30";
Unattended-Upgrade::Mail "technik@example.de";

Die Debian-Zeile für -updates ist bewusst optional: Sie zieht auch nicht sicherheitsrelevante Korrekturen nach. Auf Arbeitsplatzrechnern ist das erwünscht, auf Servern mit engem Änderungsfenster eher nicht. Die Codenamen stehen als Variable da, damit die Regeln ein Release-Upgrade überleben.

# Trockenlauf mit voller Ausgabe, ändert nichts
sudo unattended-upgrade --dry-run --debug

# Sind die Zeitgeber überhaupt aktiv?
systemctl list-timers apt-daily apt-daily-upgrade
cat /etc/apt/apt.conf.d/20auto-upgrades

# Was ist tatsächlich passiert
sudo tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log
test -f /var/run/reboot-required && cat /var/run/reboot-required.pkgs

20auto-upgrades schaltet den Mechanismus überhaupt erst scharf. Steht dort APT::Periodic::Unattended-Upgrade "0";, ist die schönste Konfiguration in 50unattended-upgrades wirkungslos. Das ist der häufigste Grund für Server, die angeblich automatisch patchen.

Types: deb
URIs: http://deb.debian.org/debian
Suites: trixie trixie-updates trixie-backports
Components: main contrib non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Backports haben von Haus aus die Priorität 100 und werden deshalb nie automatisch installiert. Du holst gezielt einzelne Pakete mit sudo apt install -t trixie-backports linux-image-amd64. Eine bestehende sources.list wandeln neuere apt-Versionen mit sudo apt modernize-sources in dieses Format um.

# Grundsätzlich nichts aus dem Fremdrepo ...
Package: *
Pin: origin repo.hersteller.example
Pin-Priority: 100

# ... außer den Paketen, die du wirklich von dort willst
Package: hersteller-agent hersteller-agent-common
Pin: origin repo.hersteller.example
Pin-Priority: 600

Ohne Pinning zieht ein einziges Fremdrepo bei jedem apt upgrade Bibliotheken mit, die dein Release nicht vorsieht, und das nächste Distributions-Upgrade scheitert an unauflösbaren Abhängigkeiten. Kontrolliere die Wirkung mit apt-cache policy hersteller-agent, dort steht die tatsächlich gewählte Quelle mit Priorität.

Auf Ubuntu ist das Gegenstück zum Backport der HWE-Stack. Ein sudo apt install linux-generic-hwe-24.04 hebt den Kernel innerhalb desselben LTS auf den Stand des jeweils neueren Zwischenreleases und löst damit die meisten Probleme mit junger Serverhardware. Der Preis ist ein Kernel, der sich innerhalb der LTS-Laufzeit mehrfach ändert, du brauchst also planbare Reboot-Fenster. Wer das nicht will, bleibt beim GA-Kernel und akzeptiert ältere Treiber, genau wie unter Debian Stable.

sudoedit /etc/netplan/01-server.yaml
sudo chmod 600 /etc/netplan/01-server.yaml

sudo netplan generate   # nur erzeugen, noch nicht anwenden
sudo netplan try        # anwenden, ohne Bestätigung automatisch zurück
sudo netplan apply      # erst wenn die Verbindung nachweislich steht

netplan try ist der Grund, warum du dich unter Ubuntu deutlich seltener selbst aussperrst: Bestätigst du nicht innerhalb der Wartezeit, stellt netplan die vorherige Konfiguration wieder her. Unter Debian gibt es dieses Netz nicht, dort brauchst du einen zweiten Zugang über Konsole oder Out-of-Band-Management, bevor du an der Netzwerkkonfiguration drehst.

snap list --all
snap refresh --time                       # wann kommt das nächste Update
sudo snap set system refresh.timer=fri,22:00-23:00
sudo snap set system refresh.retain=2
sudo snap refresh --hold lxd              # einzelnes Paket anhalten

Snap aktualisiert sich standardmäßig selbst, ohne dein Wartungsfenster zu fragen. Auf Servern mit festen Änderungsfenstern gehört mindestens ein refresh.timer gesetzt, sonst tauscht sich Software an deinem Change-Prozess vorbei aus. Debian bringt snapd nicht mit, dort stellt sich die Frage gar nicht.

sudo apt update && sudo apt full-upgrade
sudo apt --purge autoremove

dpkg --audit                      # halb konfigurierte Pakete
apt-mark showhold                 # festgehaltene Pakete auflösen
apt list '?obsolete' 2>/dev/null  # Pakete ohne Quelle
df -h /boot /var /

Ein Upgrade auf einem System mit halb konfigurierten Paketen oder vollem /boot bricht mittendrin ab, und genau dieser Zustand ist der unangenehmste, den es gibt. Die fünf Befehle kosten zwei Minuten und sparen einen Abend.

# Immer in einer abgekoppelten Sitzung starten
tmux new -s upgrade

# Debian: Codenamen in den Quellen ersetzen, dann in zwei Schritten
sudo apt update
sudo apt upgrade --without-new-pkgs
sudo apt full-upgrade

# Ubuntu
sudo do-release-upgrade

# Danach auf beiden Systemen
. /etc/os-release && echo "$PRETTY_NAME"
systemctl --failed
sudo journalctl -p err -b

apt upgrade --without-new-pkgs vor dem full-upgrade ist die von Debian empfohlene Reihenfolge, sie hält die Zahl der gleichzeitig getauschten Pakete klein. do-release-upgrade startet zur Sicherheit einen zweiten SSH-Dienst auf Port 1022, verlass dich aber nicht darauf, sondern arbeite von vornherein in tmux oder screen.