Fedora-Server: Wie lange gibt es Sicherheitsupdates?

Wie lange erhält ein Fedora-Release Sicherheitsupdates?

Ein Fedora-Server benötigt ungefähr einmal pro Jahr ein Versions-Upgrade, solange die Maschine betrieben wird. Fedora veröffentlicht ungefähr alle sechs Monate ein neues Release. Jedes Release wird bis etwa vier Wochen nach der Veröffentlichung des Releases zwei Versionen später unterstützt. Das entspricht ungefähr 13 Monaten mit Updates. Danach erhält das Release keinerlei Sicherheitskorrekturen mehr. Der Server läuft weiter, aber niemand aktualisiert die darauf installierten Pakete 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. Sein Support-Ende ist für Juni 2027 geplant. Fedora 42 wurde im April 2025 veröffentlicht und erreichte im Mai 2026 sein Support-Ende, 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 einer LTS-Version, 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: das Datum, an dem die Patches eingestellt werden. Hier sehen Sie, welche Supportzeiträume 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 13 Monate Support pro Version. Eine Ubuntu LTS-Version bietet 60, und ein Enterprise-Rebuild wie AlmaLinux bietet 120. Die zweite Spalte zeigt den Aufwand. Über zehn Jahre erfordert 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 Supportzeiträume, geprüft im August 2026, keine gemessenen Verfügbarkeitswerte. Warum sich die Zyklen unterscheiden, wird unter dem Unterschied zwischen Ubuntu LTS und Interim-Versionen auf einem Server erläutert. Entscheidend ist hier der Aufwand, den jede Variante für Sie verursacht.

Was ein Fedora-Versionsupgrade tatsächlich umfasst

DNF 5 ist seit Fedora 41 der standardmäßige Paketmanager, und dnf führt es aus. Der Befehl system-upgrade ist Bestandteil von dnf5 selbst. Sie müssen daher kein Plugin installieren. Wenn Sie von einem Debian- oder Ubuntu-Server kommen, haben die meisten Befehle, die Sie im Alltag verwenden, ein direktes apt-zu-dnf-Gegenstück. Das Versionsupgrade ist eine der wenigen Aufgaben ohne echte Entsprechung. Beginnen Sie mit der aktuellen Version und installieren Sie zunächst alle verfügbaren Updates:

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 installiertes Kernel- oder glibc-Update macht den nächsten Schritt schwerer nachvollziehbar. Bereiten Sie jetzt die neue Version vor. Ersetzen Sie 44 durch die Version, auf die Sie aktualisieren:

sudo dnf system-upgrade download --releasever=44

Dabei wird die gesamte Transaktion aufgelöst und jedes Paket heruntergeladen. Am laufenden System wird noch nichts geändert. Auf einem kleinen Server müssen Sie mit einigen tausend Paketen und einem bis drei Gigabyte rechnen. 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 das System 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, bei 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 das System erneut mit der neuen Version. Planen Sie zwei Reboots und ein Zeitfenster ein, in dem SSH nicht antwortet.

Wenn das System wieder verfügbar ist:

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 Subkommando log gibt das Transaktionsprotokoll dieses Offline-Bootvorgangs aus. Es ist der einzige Nachweis darüber, was während der Zeit ohne Shell geschehen ist. distro-sync aktualisiert alle zurückgebliebenen Pakete auf die Versionen der neuen Version. repoquery --extras listet installierte Pakete auf, die sich in keinem aktivierten Repository mehr befinden. Dort finden Sie beispielsweise Überreste eines Repositorys, das keine Pakete für die neue Version 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. Wenn sie beim Offline-Boot fehlschlägt, ist SSH nicht erreichbar. Der einzige Zugang ist dann die Konsole des Providers, VNC oder eine serielle Verbindung. Vergewissern Sie sich vor dem Start, 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 ausliefert und Sie die bisherige Datei geändert haben, überschreibt RPM Ihre Datei nicht. Stattdessen schreibt es die Paketversion daneben als .rpmnew. Dadurch verhalten sich sshd oder nginx weiterhin genau wie in der alten Version, während die neuen Standardwerte ungenutzt auf der Festplatte liegen. Lesen Sie diese Dateien nach jedem Upgrade. Installieren Sie rpmconf und führen Sie sudo rpmconf -a aus. Die Dateien werden dann nacheinander angezeigt, einschließlich ihrer Unterschiede.

Die Drittanbieter-Repositorys verhindern das Upgrade

Die Pakete von Fedora selbst werden am Veröffentlichungstag gemeinsam aktualisiert. Alles außerhalb von Fedora folgt dem Zeitplan eines anderen Anbieters. Die meisten Hersteller-Repositorys enthalten $releasever in ihrer URL. Sobald Sie das Upgrade starten, fragt dnf daher nach einem Pfad, der möglicherweise noch nicht existiert.

Listen Sie Ihre Repositorys auf:

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

Testen Sie jedes Repository, das nicht zu Fedora gehört, gegen die Zielversion, bevor Sie den Vorgang starten:

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

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

Sie haben 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 die zugehörigen Pakete nicht entfernt. Sie bleiben installiert und werden nicht mehr 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 sehen Sie, ob ein Datenbankserver entfernt wird, den Sie behalten wollten.

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

Am betreffenden Tag passiert nichts. Der Fehler tritt auf, sobald Sie den Paketmanager das nächste Mal verwenden. Releases nach ihrem End of Life 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 dann den Statuscode 404:

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

Der Rechner stellt weiterhin Netzwerkverkehr bereit. Das macht die Situation unauffällig und gefährlich. Er erhält keine Security-Updates. Außerdem kann er nichts installieren. Sobald eine Sicherheitsmeldung zu OpenSSH oder nginx erscheint, gibt es daher keine unterstützte Möglichkeit, den Server zu patchen.

Ein Ausstieg ist möglich, aber langsam. Sie können die Repositorys auf das Fedora-Archiv unter https://dl.fedoraproject.org/pub/archive/fedora/linux/ umstellen und das Upgrade von dort ausführen. Fedora erwartet normalerweise einen Sprung um ein oder zwei Releases. Ein Server, der vier Releases zurückliegt, benötigt daher mehrere aufeinanderfolgende Upgrades. Jedes Upgrade kann fehlschlagen. Außerdem läuft jeder Schritt bei einem Offline-Boot ohne laufende Überwachung. Bei einem VPS ist es in der Regel schneller und sicherer, das System mit einem aktuellen Image neu aufzubauen und die Daten zu übertragen. Das entspricht dem Vorgehen in den 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 zeitgesteuert 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 aber nichts. 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, weil ein Versions-Upgrade ein separater, bewusst geplanter Vorgang ist, der in eine Offline-Transaktion rebootet. Das ist der praktische Unterschied zu einem LTS-Release. 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, etwa das Upgrade von 24.04 auf 26.04, das alle paar Jahre durchgeführt wird.

Wenn Fedora der richtige Server ist

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

• Sie benötigen einen neueren Kernel oder Userspace, als jede LTS-Version 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 bildet die Grundlage für CentOS Stream, und CentOS Stream bildet die Grundlage für RHEL. Software, die heute unter Fedora erstellt wird und läuft, wird damit auf der Enterprise-Plattform der nächsten Jahre getestet.
• Die Maschine ist absichtlich nur 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 das System 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 einem benannten Verantwortlichen und einem Kalendereintrag. Für ein System, das alle vergessen haben, ist Fedora schlecht geeignet.

Der Mittelweg: aktuelle Pakete auf einer stabilen Basis

Die meisten Nutzer, die Fedora auf einem Server einsetzen möchten, brauchen zwei oder drei aktuelle Pakete, kein aktuelles Betriebssystem. Beides lässt sich trennen. Verwenden Sie eine LTS-Version 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 Hersteller-Repository für das einzelne benötigte Paket, etwa PostgreSQL oder nginx, aktualisiert genau diese Komponente 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. Er hilft daher nicht, wenn Sie den Kernel aktualisieren müssen. Ein Hersteller-Repository stellt ein neues Paket auf einer Basis bereit, die der Hersteller weniger umfassend getestet hat. In beiden Fällen laufen 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 Release-Zyklus in einen Kalender ein. Warten Sie nach dem Release einige Wochen, bis die Hersteller-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 an das Upgrade erinnern, nachdem bereits etwas ausgefallen ist.

FAQ

Wie lange wird eine Fedora-Version unterstützt?

Etwa 13 Monate. Fedora veröffentlicht ungefähr alle sechs Monate eine neue Version und unterstützt jede Version bis etwa vier Wochen nach der Veröffentlichung der zwei Versionen später folgenden Version. Fedora 44 wurde am 28. April 2026 veröffentlicht; das Ende des Lebenszyklus ist für Juni 2027 geplant. Nach diesem Datum erhält die Version keine Sicherheitsupdates mehr. Ihre Pakete werden von den Mirrors in das Fedora-Archiv verschoben.

Kann ich eine Fedora-Version überspringen und zwei Versionen auf einmal aktualisieren?

Ja, innerhalb bestimmter Grenzen. dnf system-upgrade download --releasever= akzeptiert als Ziel eine Version, die eine oder zwei Versionen neuer ist. Ein Sprung um zwei Versionen entspricht genau einem Upgrade-Rhythmus von einmal pro Jahr. Ein größerer Sprung wird nicht unterstützt. Mit jeder weiteren übersprungenen Version steigt die Wahrscheinlichkeit, dass eine Paketumbenennung oder eine Änderung am Konfigurationsformat die Transaktion verhindert. Wenn ein System bereits mehrere Versionen zurückliegt und das Ende des Lebenszyklus überschritten hat, ist eine Neuinstallation mit einem aktuellen Image normalerweise schneller als eine Kette von Upgrades.

Was passiert, wenn mein Fedora-Server das Ende des Lebenszyklus erreicht?

Er läuft weiter, erhält aber keine Patches mehr. Der nächste dnf upgrade schlägt mit einem 404-Fehler bei der Metalink-URL Ihrer Version fehl, weil Versionen nach dem Ende des Lebenszyklus in das Archiv unter dl.fedoraproject.org verschoben werden. Sie können die Repository-Dateien auf dieses Archiv umstellen und in mehreren Schritten aktualisieren. Alternativ können Sie den Server mit einer unterstützten Version neu aufsetzen. Bis Sie eine dieser beiden Maßnahmen durchführen, erreicht kein Sicherheitsupdate das System und kein Paket lässt sich installieren.

Ist Fedora eine schlechte Wahl für einen Produktionsserver?

Als Standardwahl ist Fedora ungeeignet, mit einem konkreten Grund jedoch eine vertretbare Wahl. Der Nachteil besteht darin, dass Sie das vollständige Betriebssystem jedes Jahr dauerhaft aktualisieren müssen. Das betrifft möglicherweise ein System, das Sie lieber unverändert lassen würden. Wählen Sie Fedora, wenn Sie einen neueren Kernel oder Userspace benötigen, als eine LTS-Version bereitstellt, oder wenn der Server von vornherein nur kurzzeitig eingesetzt wird. Wählen Sie eine LTS-Version oder eine Enterprise-Neuimplementierung, wenn Sie einen Server über Jahre patchen möchten, ohne seine Version zu ändern.