Fedora-Server auf VPS: Warum alle 13 Monate upgraden?

Wie lange erhält eine Fedora-Version Sicherheitsupdates?

Ein Fedora-Server benötigt ungefähr einmal pro Jahr ein Versionsupgrade, solange die Maschine betrieben wird. Fedora veröffentlicht etwa alle sechs Monate eine neue Version. Jede Version wird bis ungefähr vier Wochen nach der Veröffentlichung der übernächsten Version unterstützt. Das entspricht etwa 13 Monaten mit Updates. Nach diesem Datum erhält die Version überhaupt keine Sicherheitskorrekturen mehr. Der Server läuft weiter, aber niemand pflegt die darauf installierte Paketauswahl noch.

Die Daten machen das konkret. Im August 2026 werden Fedora 43 und Fedora 44 unterstützt. Fedora 44 wurde am 28. April 2026 veröffentlicht. Das Ende des Supports ist für Juni 2027 geplant. Fedora 42 wurde im April 2025 veröffentlicht und erreichte im Mai 2026 das Ende des Supports, vier Wochen nach der Veröffentlichung von Fedora 44. Ein Server, der aus einem Fedora-42-Image erstellt wurde, war daher dreizehn Monate später nicht mehr unterstützt, ohne dass jemand etwas falsch gemacht hatte.

Fedora im Vergleich zu LTS, in Monaten

LTS steht für Long-Term Support: eine Version, die der Anbieter über Jahre statt über Monate mit Patches versorgt. EOL steht für End of Life, also den Zeitpunkt, an dem die Patch-Versorgung endet. Hier sehen Sie, was die einzelnen Projekte für die Version veröffentlichen, die Sie heute installieren würden.

[
  {
    "distro": "Fedora 44",
    "support_window": 13,
    "upgrades_per_decade": 10
  },
  {
    "distro": "Ubuntu 26.04 LTS",
    "support_window": 60,
    "upgrades_per_decade": 2
  },
  {
    "distro": "Debian 13 stable",
    "support_window": 36,
    "upgrades_per_decade": 3
  },
  {
    "distro": "AlmaLinux 10",
    "support_window": 120,
    "upgrades_per_decade": 1
  }
]

Fedora bietet Ihnen pro Version 13 Monate Support. Ubuntu LTS bietet 60, und ein Enterprise-Rebuild wie AlmaLinux bietet 120. Die zweite Spalte zeigt den erforderlichen Aufwand. Über zehn Jahre verlangt Fedora ungefähr 10 Upgrades des gesamten Betriebssystems, gegenüber 2 bei Ubuntu LTS. Der Debian-Wert von 36 Monaten bezeichnet den regulären Security Support. Ein separates LTS-Team verlängert den Support der meisten Versionen auf etwa fünf Jahre.

Dies sind veröffentlichte Support-Zeiträume, geprüft im August 2026, keine gemessenen Verfügbarkeitswerte. Warum sich die Release-Zyklen unterscheiden, wird unter dem Unterschied zwischen Ubuntu LTS und Interim-Versionen auf einem Server erklärt. Entscheidend ist hier, welchen Aufwand die jeweilige Variante für Sie verursacht.

Was ein Fedora-Versionsupgrade tatsächlich umfasst

DNF 5 ist seit Fedora 41 der Standardpaketmanager, und dnf führt es aus. Der Befehl system-upgrade ist Bestandteil von dnf5 selbst. Sie müssen daher zuerst kein Plugin installieren. Beginnen Sie mit dem aktuellen Release, vollständig aktualisiert:

sudo dnf upgrade --refresh
sudo reboot

Der Reboot ist wichtig, weil das Upgrade anhand der installierten und laufenden Software aufgelöst wird. Ein nur teilweise angewendetes Kernel- oder glibc-Update erschwert die Bewertung des nächsten Schritts. Bereiten Sie nun das neue Release vor. Ersetzen Sie 44 durch das Release, auf das Sie aktualisieren:

sudo dnf system-upgrade download --releasever=44

Dabei wird die gesamte Transaktion aufgelöst und jedes Paket heruntergeladen. Das laufende System wird nicht verändert. Rechnen Sie auf einem kleinen Server mit einigen tausend Paketen und einem bis drei Gigabyte. Kann dnf die Transaktion nicht auflösen, bricht es an dieser Stelle ab und nennt das Paket, das die Auflösung verhindert. Das ist der günstige Fall, weil der Fehler auftritt, während der Rechner noch läuft und Sie weiterhin eine Shell haben.

Führen Sie sie anschließend aus:

sudo dnf offline status
sudo dnf system-upgrade reboot

dnf offline status bestätigt, dass eine Transaktion vorbereitet wurde und wartet. dnf system-upgrade reboot startet den Rechner in eine Offline-Transaktion neu. Dabei handelt es sich um einen minimalen Bootvorgang, in dem die RPM-Transaktion eigenständig ausgeführt wird. Das ist erforderlich, weil das Ersetzen von glibc und systemd unter laufenden Diensten zu einem teilweise installierten System führen kann. Ihr Server ist während der gesamten Transaktion nicht erreichbar. Auf einem kleinen VPS dauert sie normalerweise mehrere Minuten. Danach startet der Server erneut in das neue Release. Planen Sie zwei Reboots und ein Zeitfenster ein, in dem SSH nicht antwortet.

Nach dem erneuten Start:

cat /etc/fedora-release
sudo dnf system-upgrade log --number=-1
sudo dnf distro-sync
sudo dnf repoquery --extras

/etc/fedora-release sollte eine Zeile wie Fedora release 44 (Forty Four) ausgeben. Das Unterkommando log gibt das Transaktionsprotokoll dieses Offline-Boots aus. Es ist das einzige Protokoll der Vorgänge, während Sie keine Shell hatten. distro-sync übernimmt alle zurückgebliebenen Komponenten in die Versionen des neuen Releases. repoquery --extras listet installierte Pakete auf, die in keinem aktivierten Repository mehr vorhanden sind. Dort finden Sie Überreste eines Repositorys, das noch kein Repository für das neue Release veröffentlicht hat.

Erstellen Sie vor dem Download-Schritt einen Snapshot der Festplatte. Die Transaktion läuft ab, während Sie den Bildschirm nicht sehen können. Falls sie während des Offline-Boots fehlschlägt, kommt SSH nicht zurück. Ihr einziger Zugangsweg ist dann die Konsole des Providers, VNC oder eine serielle Verbindung. Stellen Sie vor dem Start sicher, dass Sie Zugriff auf eine Konsole oder einen Snapshot haben, nicht erst danach.

Eine weitere Prüfung wird häufig übersprungen:

sudo find /etc -name '*.rpmnew' -o -name '*.rpmsave'

Wenn ein Paket eine neue Standardkonfigurationsdatei bereitstellt und Sie die alte Datei geändert haben, überschreibt RPM Ihre Datei nicht. Es schreibt die Version aus dem Paket daneben als .rpmnew. Ihr sshd oder nginx verhält sich dadurch weiterhin genau wie im alten Release, während die neuen Standardeinstellungen ungelesen auf der Festplatte liegen. Lesen Sie diese Dateien nach jedem Upgrade. Installieren Sie rpmconf und führen Sie sudo rpmconf -a aus, um die Dateien nacheinander zu prüfen und die Unterschiede anzuzeigen.

Die Drittanbieter-Repositorys verhindern das Upgrade

Die Pakete von Fedora selbst werden am Veröffentlichungstag gemeinsam aktualisiert. Alles, was von außerhalb von Fedora stammt, folgt dem Zeitplan des jeweiligen Anbieters. Die meisten Anbieter-Repositorys enthalten $releasever in ihrer URL. Direkt nach dem Upgrade versucht dnf daher möglicherweise, einen Pfad aufzurufen, der noch nicht existiert.

Listen Sie die vorhandenen Repositorys auf:

sudo dnf repo list --enabled
grep -R -e baseurl -e metalink /etc/yum.repos.d/

Prüfen Sie jedes Repository, das nicht zu Fedora gehört, gegen das Ziel-Release, bevor Sie Änderungen durchführen:

sudo dnf --releasever=44 --repo=docker-ce-stable makecache

Wenn der Anbieter Pakete für dieses Release veröffentlicht hat, lädt dnf die Metadaten herunter und wird ohne Fehlermeldung beendet. Andernfalls erhalten Sie einen 404-Fehler für einen Pfad wie https://download.docker.com/linux/fedora/44/x86_64/stable/repodata/repomd.xml. Derselbe Fehler verhindert später auch system-upgrade download. In den ersten Wochen nach einem Fedora-Release ist dies der häufigste Grund dafür, dass ein Upgrade nicht startet.

Dafür gibt es zwei Möglichkeiten. Warten Sie einige Wochen, bis der Anbieter die Pakete veröffentlicht. Das ist normalerweise die richtige Entscheidung. Oder führen Sie das Upgrade ohne dieses Repository durch:

sudo dnf system-upgrade download --releasever=44 --disable-repo=docker-ce-stable

Durch das Deaktivieren eines Repositorys werden dessen Pakete nicht entfernt. Sie bleiben installiert und werden nicht mehr durch ein Repository verwaltet. Wenn sie die Transaktion blockieren, weist dnf darauf hin. Mit --allowerasing kann dnf installierte Pakete entfernen, um den Konflikt aufzulösen. Prüfen Sie daher die Liste der zu entfernenden Pakete, bevor Sie den Vorgang bestätigen. In dieser Liste findet sich häufig ein Datenbankserver, den Sie eigentlich behalten wollten.

Was passiert mit einem Fedora-Server, der das Zeitfenster verpasst?

Am Tag selbst passiert nichts. Der Fehler tritt beim nächsten Zugriff auf den Paketmanager auf. Releases, deren Support beendet ist, werden aus dem Mirror-Netzwerk in das Archiv verschoben. Daher schlägt dnf upgrade beim Abrufen der Metadaten fehl. Die Metalink-URL für Ihr Release liefert den HTTP-Status 404:

Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=fedora-42&arch=x86_64

Der Rechner stellt weiterhin Netzwerkverkehr bereit. Genau das macht den Zustand unauffällig und gefährlich. Er erhält keine Sicherheitsupdates. Außerdem kann er keine Pakete installieren. Wenn eine Sicherheitsmeldung zu OpenSSH oder nginx veröffentlicht wird, gibt es daher keine unterstützte Möglichkeit, den Server zu patchen.

Eine Wiederherstellung ist möglich, aber zeitaufwendig. Sie können die Paketquellen auf das Fedora-Archiv unter https://dl.fedoraproject.org/pub/archive/fedora/linux/ umstellen und das Upgrade von dort aus durchführen. Fedora erwartet normalerweise einen Sprung um ein oder zwei Releases. Ein Server, der vier Releases zurückliegt, benötigt daher mehrere aufeinanderfolgende Upgrades. Jeder einzelne Schritt kann fehlschlagen. Außerdem wird jeder Schritt in einem nicht unterstützten Zustand ausgeführt. Bei einem VPS ist es in der Regel schneller und sicherer, ihn mit einem aktuellen Image neu aufzusetzen und die Daten zu übertragen. Das entspricht derselben Arbeit wie die ersten zehn Minuten auf einem neuen VPS.

Automatische Updates installieren Patches für ein Release. Sie führen niemals ein Upgrade auf ein neues Release durch.

Fedora kann Updates nach einem Zeitplan installieren:

sudo dnf install -y dnf5-plugin-automatic
sudo systemctl enable --now dnf5-automatic.timer

Die Einstellungen befinden sich in /etc/dnf/automatic.conf. Sie überschreiben die mitgelieferten Standardwerte in /usr/share/dnf5/dnf5-plugins/automatic.conf. apply_updates ist standardmäßig deaktiviert. Direkt nach der Installation lädt der Timer daher Updates herunter, installiert sie aber nicht. upgrade_type wählt zwischen default und security. reboot akzeptiert never, when-changed oder when-needed.

Damit bleibt das System innerhalb eines Releases aktuell. Fedora 43 wird dadurch niemals auf Fedora 44 aktualisiert. Ein Versions-Upgrade ist ein separater, bewusst ausgeführter Vorgang, der das System für eine Offline-Transaktion neu startet. Das ist der praktische Unterschied zu einem LTS. Unter Ubuntu halten unbeaufsichtigte Sicherheits-Upgrades ein System während des gesamten Zeitraums von fünf Jahren aktuell, ohne die Version zu ändern. Der Versionswechsel selbst ist ein geplanter Vorgang, beispielsweise das Upgrade von 24.04 auf 26.04 alle paar Jahre.

Wenn Fedora der richtige Server für den Betrieb ist

Fedora ist eine gute Wahl, wenn Aktualität entscheidend ist.

• Sie benötigen einen Kernel oder Userspace, der neuer ist als alles, was ein LTS-Release bereitstellt: für aktuelle Hardware oder einen Container- und systemd-Stack, der noch ein Jahr von einem Enterprise-Release entfernt ist. Fedora wechselt außerdem während eines Releases auf neue Upstream-Kernel. Der Vorteil besteht daher nicht nur einmalig bei der Installation.
• Sie prüfen, was in RHEL (Red Hat Enterprise Linux) einfließen soll. Fedora ist die Grundlage für CentOS Stream, das wiederum die Grundlage für RHEL bildet. Software, die heute unter Fedora gebaut und ausgeführt wird, wird damit gegen die Enterprise-Plattform von in einigen Jahren getestet.
• Der Rechner ist absichtlich kurzlebig. Ein Build-Runner oder Testsystem, das nach zwei Monaten gelöscht wird, erreicht sein End-of-Life-Datum nie. Das gilt auch für wegwerfbare VMs, die Sie Coding-Agenten übergeben, wenn der Rechner deutlich häufiger neu erstellt wird, als Fedora Releases veröffentlicht.
• Jemand ist für das Upgrade verantwortlich. Fedora eignet sich für einen Server mit einer benannten verantwortlichen Person und einem Termin im Kalender. Für einen Rechner, den alle vergessen haben, ist Fedora eine schlechte Wahl.

Der Mittelweg: aktuelle Pakete auf einer stabilen Basis

Die meisten, die Fedora auf einem Server einsetzen möchten, benötigen zwei oder drei aktuelle Pakete, aber kein aktuelles Betriebssystem. Beides lässt sich trennen. Verwenden Sie ein LTS-System oder einen Enterprise-Rebuild als Basis und beziehen Sie die neue Software nur dort, wo Sie sie tatsächlich benötigen. Ein Container-Image stellt die neue Version der Anwendung auf einem Host bereit, den Sie dafür nicht aktualisieren müssen (Docker auf einem VPS ausführen). Ein Anbieter-Repository für das einzelne benötigte Paket, etwa PostgreSQL oder nginx, aktualisiert dieses Paket und lässt die Basis unverändert.

Der Kompromiss ist in beide Richtungen eindeutig. Ein Container stellt einen neuen Userspace auf dem alten Kernel des Hosts bereit. Das hilft daher nicht, wenn Sie den Kernel aktualisieren müssen. Ein Anbieter-Repository liefert ein neues Paket auf einer Basis, die der Anbieter weniger umfassend getestet hat. In beiden Fällen richten sich die Sicherheitsupdates des Basissystems weiterhin nach dem LTS-Zeitplan. Dieser Zeitplan verursacht bei Fedora jedes Jahr ein Wartungsfenster.

Wenn Sie Fedora für einen Server auswählen, tragen Sie den Zyklus in einen Kalender ein. Warten Sie nach dem Release einige Wochen, bis die Anbieter-Repositories nachgezogen haben. Erstellen Sie einen Snapshot, führen Sie das Upgrade durch und prüfen Sie anschließend, ob die Dienste wieder gestartet sind. Dieser Ablauf kostet etwa eine Stunde pro Jahr und funktioniert. Problematisch ist der Ablauf, bei dem Sie sich erst dann an das Upgrade erinnern, wenn bereits etwas ausgefallen ist.

FAQ

Wie lange wird ein Fedora-Release unterstützt?

Etwa 13 Monate. Fedora veröffentlicht ungefähr alle sechs Monate ein neues Release und unterstützt jedes Release bis etwa vier Wochen nach der Veröffentlichung der zwei Versionen später erschienenen Ausgabe. Fedora 44 wurde am 28. April 2026 veröffentlicht; das Supportende ist für Juni 2027 geplant. Danach erhält das Release keine Sicherheitsupdates mehr, und seine Pakete werden von den Mirrors in das Fedora-Archiv verschoben.

Kann ich ein Fedora-Release überspringen und zwei Versionen auf einmal aktualisieren?

Ja, innerhalb bestimmter Grenzen. dnf system-upgrade download --releasever= akzeptiert als Ziel ein Release, das eine oder zwei Versionen neuer ist. Zwei Versionen auf einmal zu überspringen, entspricht genau einem jährlichen Upgrade-Rhythmus. Ein größerer Sprung wird nicht unterstützt. Mit jedem zusätzlichen Release steigt außerdem das Risiko, dass eine Paketumbenennung oder eine Änderung des Konfigurationsformats die Transaktion abbricht. Wenn ein System bereits mehrere Releases zurückliegt und das Supportende überschritten hat, ist eine Neuinstallation mit einem aktuellen Image normalerweise schneller als eine Kette von Upgrades.

Was passiert, wenn mein Fedora-Server das Supportende erreicht?

Er läuft weiter, erhält aber keine Patches mehr. Das nächste dnf upgrade schlägt mit einem 404-Fehler für die Metalink-URL Ihres Releases fehl, weil Releases nach dem Supportende in das Archiv unter dl.fedoraproject.org verschoben werden. Sie können die Repository-Dateien auf dieses Archiv umstellen und das Upgrade schrittweise durchführen oder den Server mit einem unterstützten Release neu aufsetzen. Bis eine dieser beiden Maßnahmen erfolgt, erreicht kein Sicherheitsupdate das System, und es lässt sich kein Paket installieren.

Ist Fedora eine schlechte Wahl für einen Produktionsserver?

Als Standardwahl ist Fedora ungünstig, mit einem konkreten Grund jedoch eine vertretbare Option. Der Nachteil besteht darin, dass Sie jedes Jahr ein vollständiges Upgrade des Betriebssystems durchführen müssen – dauerhaft und auf einem System, das Sie möglicherweise möglichst nicht verändern möchten. Wählen Sie Fedora, wenn Sie einen neueren Kernel oder Userspace benötigen, als ein LTS-Release bereitstellt, oder wenn der Server planmäßig nur kurze Zeit betrieben wird. Wählen Sie ein LTS-Release oder ein Enterprise-Rebuild, wenn Sie einen Server über Jahre patchen möchten, ohne seine Version zu ändern.