Distributionen & Auswahl

Wie lange bekommt dein Linux noch Updates?

Deine Refresh-Planung hängt an einem Datum, nicht an einem Gefühl: RHEL zehn Jahre, Ubuntu LTS fünf plus fünf über Pro, Debian rund fünf Jahre inklusive LTS. Wer diese Termine nicht im Budget hat, zahlt sie später als Notfall.

5 Kapitel mit allen Befehlen
Zwei IT-Fachleute vergleichen Optionen an mehreren Bildschirmen
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team
Worum es geht

Das Support-Ende kommt nie überraschend, es wird nur zu spät geplant

Ein Linux-Release hat selten nur ein Datum. Red Hat trennt bei RHEL zwischen Full Support, in dem noch Hardware-Enablement und neue Treiber nachkommen, und Maintenance Support, in dem im Wesentlichen nur noch sicherheitsrelevante und kritische Fixes erscheinen. Danach lässt sich die Laufzeit über Extended Life Cycle Support kostenpflichtig verlängern. Ubuntu LTS liefert fünf Jahre regulären Support für das Main-Repository, alles darüber hinaus und der komplette Universe-Bereich hängen an Ubuntu Pro mit Expanded Security Maintenance. Debian übergibt nach dem regulären Security-Support an das LTS-Team, das nur noch ausgewählte Architekturen und Pakete abdeckt. SLES rechnet in General Support und anschließendem LTSS, das je Service Pack zugebucht wird. Wer diese Phasen gleichsetzt, plant an der Realität vorbei.

Der Schmerz entsteht selten beim Hauptsystem, sondern in den Nebenbaustellen. Ein Ubuntu-Server gilt intern als unterstützt, die kritische Komponente stammt aber aus Universe und ist ohne Ubuntu Pro nie in den fünf Jahren mit drin gewesen. Ein RHEL-Host hängt auf einer alten Minor-Version fest, weil eine Applikation zertifiziert ist, und bekommt damit nur noch über Extended Update Support Fixes. Bei SLES läuft der General Support des eingesetzten Service Packs aus, während das Team gedanklich noch mit der Laufzeit der Major-Version rechnet. Das Ergebnis sind Systeme, die im Audit als gepatcht gelten und trotzdem offene CVEs tragen.

CentOS 7 hat 2024 vorgeführt, wie teuer eine späte Reaktion wird: Migrationen wurden unter Zeitdruck durchgezogen, Anwendungen mussten parallel auf neuere Python- und OpenSSL-Stände gehoben werden, und für die Restlaufzeit kaufte man Drittanbieter-Patches. Wer den Lebenszyklus dagegen als rollierende Planung führt, verteilt Upgrades über mehrere Quartale, testet sie regulär und braucht keine Notfallbudgets.

Miniatur-Szene: drei Server-Podeste nebeneinander, davor eine Waage zum Vergleich zweier Optionen
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Die Phasen eines Enterprise-Linux-Lebenszyklus

  1. 01 Release
  2. 02 Voller Support mit neuen Features
  3. 03 Maintenance nur mit Sicherheitsfixes
  4. 04 Kostenpflichtige Verlängerung: ELS, ESM, LTSS
  5. 05 End of Life ohne Patches
  6. 06 Migration abgeschlossen
Was du mitnimmst

So baust du einen belastbaren Lifecycle-Plan

Der Weg von der Inventarisierung bis zum Refresh-Fahrplan besteht aus wenigen, gut automatisierbaren Schritten. Entscheidend ist, dass du nicht mit Distributionsnamen arbeitest, sondern mit exakter Version, Repository-Herkunft und aktueller Supportphase.

Bestand auf Versionsebene erfassen

Sammle je Host die Angaben aus /etc/os-release, bei RHEL zusätzlich die Minor-Version und den Subscription-Status, bei SLES die Service-Pack-Nummer über SUSEConnect. Ein Ansible-Fact-Lauf oder eine Abfrage in SUSE Multi-Linux Manager beziehungsweise Red Hat Satellite liefert das in einem Durchgang und bleibt wiederholbar.

Paketherkunft mitprüfen

Der Supportstatus hängt am Repository. Prüfe mit apt-cache policy beziehungsweise dnf repoquery, welche Pakete aus Main, Universe, BaseOS, AppStream, EPEL oder einem Drittanbieter-Repo stammen. Alles außerhalb der unterstützten Kanäle brauchst du in einer eigenen Liste mit eigenem Patch-Weg.

Supportphasen in eine Zeitachse übertragen

Trage je Release die Endtermine der einzelnen Phasen ein, also Full Support, Maintenance, LTS beziehungsweise ESM und den kostenpflichtigen Nachlauf über ELS, ESM oder LTSS. Erst diese Ansicht zeigt, welche Systeme wirklich zuerst dran sind und wo du dir noch ein Jahr erkaufen kannst.

Zwischen Upgrade und Neuaufbau entscheiden

In-Place-Upgrades über Leapp bei RHEL oder do-release-upgrade bei Ubuntu sind sinnvoll bei gewachsenen Einzelsystemen mit lokalem Zustand. Wo Konfiguration in Ansible, Terraform oder Container-Images liegt, ist der Neuaufbau schneller und hinterlässt weniger Altlasten. Beides gehört vorher an einer Kopie getestet.

Verlängerungen bewusst und befristet kaufen

ELS, ESM über Ubuntu Pro oder LTSS sind legitime Werkzeuge, wenn ein Migrationsprojekt sonst über das Support-Ende hinausläuft. Kaufe sie mit festem Zieldatum und nicht als Dauerlösung, weil der Umfang mit jeder Verlängerungsstufe kleiner wird und die Kosten pro System steigen.

Den Zyklus automatisiert überwachen

Ein monatlicher Report aus deinem Konfigurationsmanagement, der Hosts nach verbleibender Supportdauer sortiert, verhindert Überraschungen. Kombiniert mit einem Patch-Fenster und einer Testumgebung wird aus dem Einzelprojekt eine Routine.

Tutorial

Vom Serverbestand zur belastbaren Lebenszyklus-Übersicht

Hier geht es um den Weg, den du für ein tragfähiges Refresh-Budget brauchst: Bestand maschinell erfassen, den Supportstatus direkt am System abfragen, die Paketherkunft prüfen, dann zwischen Upgrade und Neuaufbau entscheiden und den Schritt sauber durchziehen. Am Ende steht ein Skript, das dich sechs Monate vor dem Supportende von selbst anspricht, statt dass du einmal im Jahr nachschlägst.

01

Bestand maschinell erfassen

Eine gepflegte Tabelle ist nach zwei Wochen falsch. Die einzige Datenquelle, die stimmt, ist die Maschine selbst.

Version je Host und über die Flotte
# Auf einem einzelnen Host: die maschinenlesbare Quelle
. /etc/os-release && echo "$ID $VERSION_ID"
hostnamectl | grep -E 'Operating System|Kernel'

# Über die Flotte, ohne Agent auf den Zielsystemen
ansible all -i inventory -m setup \
  -a 'filter=ansible_distribution*' --tree /tmp/facts

# Aus den Fakten eine CSV bauen, die in die Planung wandert
jq -r '.ansible_facts | [.ansible_fqdn, .ansible_distribution, .ansible_distribution_version] | @csv' \
  /tmp/facts/* | sort -t, -k2,3

/etc/os-release gibt es auf jeder aktuellen Distribution, lsb_release nicht. Nimm deshalb immer die erste Variante, sonst fehlen dir ausgerechnet die minimal installierten Systeme.

02

Supportstatus je Distribution direkt abfragen

Jede Distribution beantwortet die Frage anders, und zwei von ihnen antworten auf Paketebene statt auf Releaseebene. Genau dort entstehen die Lücken, die in Release-Tabellen nicht auftauchen.

Vier Distributionen, vier Befehle
# RHEL: gepinntes Minor-Release und Subskriptionsstatus
subscription-manager release --show
subscription-manager status

# Ubuntu: Standard-Support, ESM und Pro-Status in einem Aufruf
pro status --all
pro security-status

# Debian: welche installierten Pakete fallen aus der Sicherheitsunterstützung?
sudo apt install debian-security-support
check-support-status

# SLES: Supportende pro Paket, nicht nur pro Release
sudo zypper lifecycle

subscription-manager gibt es nur auf RHEL mit gültiger Subskription. Auf Rocky und Alma prüfst du stattdessen /etc/os-release gegen die Release-Ankündigung des jeweiligen Projekts.

Supportfenster und der Befehl, der es beantwortet

DistributionRegulärKostenpflichtige VerlängerungPrüfbefehl
RHEL 8 und 9Full Support und Maintenance Support, zusammen zehn JahreELS als Add-onsubscription-manager status
Ubuntu LTSfünf Jahre Standard-SupportUbuntu Pro mit ESM auf zehn Jahrepro security-status
Debianrund drei Jahre regulär, danach LTSELTS von Freexiancheck-support-status
SLESGeneral Support über zehn JahreLTSS je Service Packzypper lifecycle
03

Paketherkunft prüfen, nicht nur die Release-Nummer

Ein Server kann formal im Support stehen und trotzdem Software fahren, die seit Jahren niemand mehr pflegt. Fremdquellen, umgepackte Herstellerpakete und alles unter /usr/local fallen durch jede Release-Betrachtung.

Woher kommt jedes installierte Paket?
# RHEL-Familie: Verteilung über die Repositories
dnf repoquery --installed --qf '%{from_repo}' | sort | uniq -c | sort -rn

# Pakete, für die es kein Repository mehr gibt
dnf list extras          # unter dnf5: dnf list --extras

# Herstellerübersicht, findet umgepackte Fremdsoftware
rpm -qa --qf '%{VENDOR}\n' | sort | uniq -c | sort -rn

# Debian und Ubuntu: Herkunft eines Pakets und alle eingebundenen Quellen
apt policy nginx
grep -rhE '^(deb |Types:|URIs:)' /etc/apt/sources.list /etc/apt/sources.list.d/

Alles, was per make install oder als Tarball unter /usr/local und /opt liegt, taucht in keiner Paketdatenbank auf. Diese Verzeichnisse musst du von Hand durchgehen und je Eintrag einen Verantwortlichen benennen.

04

Upgrade oder Neuaufbau, und wie du es durchziehst

In-Place lohnt sich bei gewachsenen Systemen mit viel lokalem Zustand. Wo Konfiguration und Daten getrennt sind und die Installation aus Automatisierung entsteht, ist der Neuaufbau schneller und liefert dir nebenbei einen getesteten Wiederanlauf.

Vor jedem Major-Upgrade

  • Backup vorhanden und Restore einmal wirklich durchgespieltEin Upgrade kann mitten in der Transaktion abbrechen. Ein Backup, dessen Rückweg nie geprüft wurde, ist an dieser Stelle kein Backup, sondern eine Hoffnung.
  • Snapshot der virtuellen Maschine direkt vor dem StartDer Snapshot ist der einzige Rückweg, der in Minuten statt in Stunden funktioniert. Lösche ihn erst, wenn der Dienst zwei Werktage stabil gelaufen ist.
  • Fremd-Repositories deaktiviertSonst zieht der Paketmanager mitten im Upgrade Pakete aus einer Quelle, die für die neue Version gar nicht gebaut wurde, und die Abhängigkeitsauflösung bricht an einer völlig anderen Stelle ab.
  • Konsolenzugang über iDRAC, iLO oder die Hypervisor-Konsole getestetNach dem ersten Reboot können Netzwerkschnittstellen anders heißen oder die Firewall-Regeln neu aufgebaut sein. Ohne Konsole ist das System dann nicht mehr erreichbar.
  • Freier Platz auf /boot geprüftDer neue Kernel und das Initramfs brauchen Platz. Läuft /boot voll, bricht der Bau des Initramfs ab und das System bootet in eine Notfall-Shell.
In-Place-Upgrade je Distribution
# RHEL, Rocky und Alma: In-Place immer nur ein Major-Release weit
sudo dnf install leapp-upgrade
sudo leapp preupgrade
less /var/log/leapp/leapp-report.txt    # zuerst alle inhibitor abarbeiten
sudo leapp upgrade && sudo reboot

# Ubuntu von LTS auf LTS
grep Prompt= /etc/update-manager/release-upgrades   # muss auf lts stehen
sudo do-release-upgrade

# Debian: Quellen umschreiben, dann in zwei Stufen
sudo apt update && sudo apt upgrade      # erst minimal, ohne Entfernungen
sudo apt full-upgrade                    # dann vollständig

Für Rocky und Alma liefert das ELevate-Projekt die Migrationsdaten für leapp. Bei Debian liegen die Quellen seit Debian 13 im deb822-Format unter /etc/apt/sources.list.d/debian.sources, dort musst du auch die Suite umschreiben.

05

Den Zyklus überwachen statt jährlich nachzuschauen

Das Supportende ist ein Datum. Etwas, das ein Datum kennt, kann dich auch von selbst warnen.

/usr/local/sbin/eol-check.sh
#!/bin/bash
# Exit 2, wenn weniger als 180 Tage Support bleiben
set -euo pipefail
. /etc/os-release

zyklus="$VERSION_ID"
# endoflife.date fuehrt eigene Produktschluessel, die nicht immer der $ID entsprechen
produkt="$ID"
case "$ID" in
  rhel|rocky|almalinux|centos) zyklus="${VERSION_ID%%.*}" ;;
esac
case "$ID" in
  rocky) produkt="rocky-linux" ;;
  almalinux) produkt="almalinux" ;;
  rhel) produkt="rhel" ;;
esac

eol=$(curl -fsS "https://endoflife.date/api/${produkt}.json" \
  | jq -r --arg v "$zyklus" '.[] | select(.cycle == $v) | .eol')

[[ "$eol" =~ ^[0-9]{4}-[0-9]{2}-[0-9]{2}$ ]] || exit 0

tage=$(( ( $(date -d "$eol" +%s) - $(date +%s) ) / 86400 ))
echo "${PRETTY_NAME}: Support endet am ${eol}, noch ${tage} Tage"
[ "$tage" -lt 180 ] && exit 2
exit 0

Die RHEL-Familie meldet in VERSION_ID das Minor-Release, die API kennt nur den Major-Zyklus. Deshalb die Kürzung mit ${VERSION_ID%%.*}. endoflife.date ist ein Gemeinschaftsprojekt und keine Herstellerzusage, die Zahl gehört vor dem Budgetantrag gegen die offizielle Lifecycle-Seite geprüft.

/etc/systemd/system/eol-check.timer
[Unit]
Description=Monatliche Prüfung des Supportendes der Distribution

[Timer]
OnCalendar=monthly
RandomizedDelaySec=6h
Persistent=true

[Install]
WantedBy=timers.target

Die passende Unit ist ein Type=oneshot mit ExecStart=/usr/local/sbin/eol-check.sh. Aktivieren mit systemctl enable --now eol-check.timer, prüfen mit systemctl list-timers eol-check.timer.

Gut zu wissen

Häufige Fragen zu Support-Zeiträumen von Linux

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt
Wie lange bekommt ein Ubuntu LTS Updates?
Ein Ubuntu LTS erhält fünf Jahre regulären Sicherheitssupport für die Pakete aus dem Main-Repository. Mit Ubuntu Pro verlängert Canonical das über Expanded Security Maintenance auf insgesamt zehn Jahre und deckt dabei auch Universe ab, für ältere Releases gibt es darüber hinaus kostenpflichtige Legacy-Optionen. Ubuntu Pro ist für den privaten Gebrauch auf einer begrenzten Zahl an Maschinen kostenlos, im Unternehmen ist es abonnementpflichtig.
Was ist der Unterschied zwischen Full Support und Maintenance Support bei RHEL?
Im Full Support liefert Red Hat neben Sicherheits- und Fehlerkorrekturen auch neue Minor-Releases mit Hardware-Enablement und ausgewählten Funktionserweiterungen. Im anschließenden Maintenance Support gibt es im Wesentlichen nur noch Fixes für kritische Fehler und Sicherheitslücken, keine neuen Funktionen und kein Enablement für neue Hardware. Danach endet der reguläre Lebenszyklus, und nur ein Extended Life Cycle Support liefert weiter Patches.
Wie lange wird ein Debian-Release unterstützt?
Das Debian-Security-Team betreut ein Stable-Release ungefähr drei Jahre, danach übernimmt das Debian-LTS-Team für weitere Jahre, so dass in der Summe etwa fünf Jahre zusammenkommen. In der LTS-Phase sind allerdings nicht mehr alle Architekturen und nicht mehr alle Pakete abgedeckt, und für einzelne Pakete kann der Support vorzeitig enden. Für stark abhängige Systeme lohnt sich deshalb ein Blick in die Liste der nicht unterstützten Pakete.
Was bedeutet LTSS bei SLES?
SLES hat einen langen Lebenszyklus mit General Support und anschließendem Long Term Service Pack Support. LTSS wird als kostenpflichtige Erweiterung je Service Pack gebucht und liefert weiterhin Sicherheits- und kritische Fixes für Systeme, die noch nicht auf ein aktuelles Service Pack gehoben werden können. Wichtig ist, dass sich der Support auf das eingesetzte Service Pack bezieht und nicht pauschal auf die Major-Version.
Lohnt sich eine kostenpflichtige Supportverlängerung oder besser gleich migrieren?
Eine Verlängerung ist sinnvoll, wenn ein Migrationsprojekt bereits terminiert ist und nur über das Support-Ende hinausreicht, etwa wegen einer zertifizierten Applikation oder eines Wartungsfensters im Produktionsbetrieb. Als Dauerlösung ist sie teuer, weil der Leistungsumfang mit jeder Stufe schrumpft und du die Migration trotzdem noch vor dir hast. Als Faustregel gilt: Verlängerung kaufen, wenn du damit ein konkretes Zieldatum absicherst, sonst direkt migrieren.

Zuletzt geprüft am 26. Juli 2026.

Das sagen Teilnehmer

Echte Stimmen aus unseren IT-Kursen

Erwartungen wurden erfüllt. Angekündigte Themen in hinreichender Tiefe bearbeitet. Zudem gutes Zeitmanagement.
Rückmeldung aus dem Kurs „Source Code Management und CI / CD (DO4)“
Gut vorbereitete professionelle Vermittlung der komplexen Inhalte innerhalb von nur drei Tagen.
Rückmeldung aus dem Kurs „Docker Grundkurs für Einsteiger“
Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.

Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.

Nächster Schritt

Lifecycle planen und die Upgrades sauber durchziehen

Wenn du den Fahrplan stehen hast, geht es an die Umsetzung. Für den Sprung auf die aktuelle Red-Hat-Generation gibt es bei cmt das RHEL 10 Upgrade Training, für den SUSE-Bestand die Kurse rund um SUSE Linux Enterprise Server 15 Administration und SUSE Multi-Linux Manager, und für Debian-Umgebungen das Debian Administration Training. Wer Upgrades wiederholbar automatisieren will, ist im Ansible Kompaktkurs richtig. Alle Kurse laufen wahlweise Live-Online oder vor Ort, und wir beraten dich vorab gern dazu, welcher Weg zu deinem Bestand passt.