Strategie & Migration

CentOS 7 ist am Ende: So findest du den richtigen Nachfolger

Rocky Linux und AlmaLinux sind die naheliegenden Ziele: binärkompatibel, kostenlos, mit Support bis weit in die 2030er. Ein direkter In-Place-Weg von CentOS 7 existiert nur über ELevate, und bei stark angepassten Systemen bist du mit einem sauberen Neuaufbau schneller.

6 Kapitel mit allen Befehlen
IT-Entscheider besprechen eine Infrastruktur-Roadmap im Besprechungsraum
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

Warum ein abgelaufenes CentOS 7 im Betrieb schnell teuer wird

CentOS 7 hat mit dem 30. Juni 2024 sein Maintenance-Ende erreicht. Seitdem erscheinen keine Errata, keine Kernel-Updates und keine Backports mehr, auch nicht für kritische CVEs. Ein System, das noch läuft, ist deshalb nicht unauffällig, sondern nur nicht gepatcht. In der Praxis fällt das spätestens beim nächsten Schwachstellenscan oder beim Audit auf, wenn jemand nach dem Patchstand fragt.

Der eigentliche Druck kommt aber selten von der Sicherheit allein. Neue Hardware wird von einem Kernel aus der 3.10er-Linie nicht mehr sauber unterstützt, aktuelle Agenten für Backup, Monitoring und EDR liefern keine EL7-Pakete mehr, und moderne TLS-Gegenstellen sprechen nicht mehr mit der alten OpenSSL-Version. Jede dieser Baustellen kommt einzeln und meist genau dann, wenn keine Zeit dafür ist.

Der typische Fehler ist, die Migration als reines Betriebssystem-Thema zu behandeln. Kaputt geht in der Regel nicht die Basis, sondern alles, was daran hängt: Pakete aus EPEL, IUS oder Remi, selbst gebaute RPMs, Skripte gegen Python 2 und Firewall-Regeln, die noch mit iptables statt nftables gepflegt werden. Wer diese Abhängigkeiten nicht vorher erfasst, entdeckt sie im Wartungsfenster.

Miniatur-Szene: Spielbrett, auf dem eine Server-Figur von einer alten auf eine neue Plattform zieht, daneben eine Roadmap
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Von CentOS 7 zum gepflegten Zielsystem

  1. 01 Bestand und Fremdrepos erfassen
  2. 02 Zielsystem festlegen
  3. 03 Anwendungen gegen neue Basis testen
  4. 04 Neuinstallation automatisieren
  5. 05 Daten und Konfiguration übernehmen
  6. 06 Betrieb und Patchprozess umstellen
Was du mitnimmst

Der Weg von CentOS 7 auf ein gepflegtes System

Die Migration zerfällt in eine Entscheidung und eine Umsetzung. Zuerst legst du das Zielsystem fest, danach entscheidest du pro Server, ob konvertiert oder neu gebaut wird. Beides bleibt beherrschbar, wenn du in dieser Reihenfolge vorgehst.

Zielsystem nach Support-Bedarf wählen

RHEL bringt Herstellersupport, ISV-Zertifizierungen und Werkzeuge wie Satellite und Insights, kostet dafür Subscriptions. Rocky Linux und AlmaLinux sind binärkompatibel und kostenfrei, der Support kommt aus der Community oder von Dritten. SUSE Linux Enterprise passt, wenn SAP-Workloads oder ein bestehender SUSE-Bestand im Haus sind, Debian passt für Infrastrukturdienste ohne Zertifizierungsdruck.

CentOS Stream richtig einordnen

CentOS Stream ist kein Ersatz für CentOS 7. Es liegt entwicklungsseitig vor RHEL, ist also eine rollende Vorabversion und keine nachgelagerte Kopie. Für Entwicklungs- und Testsysteme, die früh gegen kommende RHEL-Minor-Releases prüfen sollen, ergibt das Sinn, für einen langlebigen Produktionsserver eher nicht.

Bestand inventarisieren, besonders Fremdrepos

Erfasse pro Host die aktivierten Repos, alle Pakete ohne Distributionsherkunft, kompilierte Software unter /usr/local und alles, was auf Python 2 oder eine alte glibc angewiesen ist. Ein Durchlauf mit rpm -qa --qf und yum list extras liefert die Liste, die später darüber entscheidet, wie aufwendig ein Host wirklich ist.

Version 7 lässt sich nicht direkt konvertieren

Die Werkzeuge migrate2rocky und almalinux-deploy setzen ein bereits gleichwertiges Release voraus, sie wandeln also CentOS 8 oder eine Stream-Installation um, nicht CentOS 7. Von 7 aus ist der saubere Weg eine Neuinstallation des Zielsystems und das Zurückspielen von Daten und Konfiguration. Der Umweg über 8 lohnt fast nie, weil dieses Release selbst schon abgelaufen ist.

Reinstallation automatisieren statt Server einzeln anzufassen

Ab einer Handvoll Hosts baust du das Zielsystem über Kickstart oder ein Image aus und rollst die Konfiguration mit Ansible aus. Dann ist die Migration wiederholbar, im Testsystem prüfbar und pro Server eine Frage von Minuten statt von Stunden. Der Aufwand für die Playbooks rechnet sich meist schon beim fünften Server.

Anwendungsstack vorher gegen die neue Basis testen

Zwischen EL7 und EL9 oder EL10 wechseln systemd-Version, OpenSSL, Python, die Standard-Crypto-Policy und die Firewall-Werkzeuge. Alte TLS-Versionen und kurze Schlüssel werden über crypto-policies abgelehnt, Legacy-Anwendungen fallen dabei zuerst auf. Diese Tests gehören vor das erste Produktionsfenster, nicht hinein.

Tutorial

Von der Inventur bis zur Abnahme: der Weg von EL7 nach EL9

Der Ablauf ist immer derselbe: erst inventarisieren, dann je Host zwischen Neuaufbau und In-Place entscheiden, dann umsetzen, und zum Schluss die Nacharbeiten, die in keiner Anleitung stehen. Die Reihenfolge ist keine Empfehlung, sondern die Bedingung dafür, dass du nicht mitten in einem Wartungsfenster feststeckst.

01

Inventur auf dem CentOS-7-Host

Bevor irgendetwas angefasst wird, brauchst du eine Momentaufnahme. Das kostet zehn Minuten je Host und ist später die Grundlage jeder Fehlersuche.

Momentaufnahme sichern
# Vollständige Paketliste, inklusive Hersteller
rpm -qa --qf '%{NAME}\t%{VERSION}-%{RELEASE}\t%{VENDOR}\n' \
  | sort > /root/inventar-pakete.tsv

# Welche Pakete stammen NICHT aus den Basisrepos?
yum list installed | grep -vE '@(base|updates|extras|anaconda|centos)'

# Welche Repos sind überhaupt eingebunden?
grep -h '^\[' /etc/yum.repos.d/*.repo

# Dienste, die tatsächlich laufen und lauschen
systemctl list-units --type=service --state=running --no-pager
ss -tulpn

Die zweite Zeile ist die eigentliche Risikoliste. EPEL, Remi, Nux, IUS oder ein Hersteller-Repo für den Backup-Agenten haben unter EL9 andere Paketnamen oder existieren gar nicht mehr. Jede Zeile dort ist eine Aufgabe, kein Nebeneffekt.

Handarbeit sichtbar machen
# Konfigurationsdateien, die vom Auslieferungszustand abweichen
rpm -Va | grep '^..5' | grep ' c '

# Alles, was am Paketmanager vorbei installiert wurde
find /usr/local /opt -maxdepth 2 -mindepth 1 -printf '%p\t%TY-%Tm-%Td\n'

# Eigene systemd-Units und Overrides
ls -1 /etc/systemd/system/ /etc/systemd/system/*.d/ 2>/dev/null

# Cronjobs, die niemand mehr kennt
ls -1 /etc/cron.d/ /etc/cron.daily/
for u in $(cut -d: -f1 /etc/passwd); do crontab -lu "$u" 2>/dev/null | sed "s/^/$u: /"; done

rpm -Va mit dem Filter auf c zeigt genau die Konfigurationsdateien, die jemand angefasst hat. Das ist die Liste, die du auf dem neuen System nachziehen musst, und sie ist fast immer länger als die Dokumentation vermuten lässt.

02

Je Host entscheiden: Neuaufbau oder In-Place

Die Entscheidung fällt nicht für den ganzen Bestand, sondern für jeden Host einzeln. Die Kriterien sind erfreulich hart.

Entscheidungsraster

SituationWegBegründung
Standardserver aus Kickstart, wenige FremdpaketeNeuaufbauSchneller als zwei leapp-Läufe, und du bekommst ein System ohne Altlasten aus zehn Jahren Betrieb.
Über Jahre handgepflegt, Dokumentation lückenhaftIn-Place erwägenDer Neuaufbau scheitert daran, dass niemand mehr weiß, was auf der Maschine konfiguriert wurde.
Physischer Host ohne FernkonsoleNeuaufbau vor Ort planenEin abgebrochener In-Place-Lauf ohne iDRAC, iLO oder IPMI bedeutet eine Fahrt ins Rechenzentrum.
Anwendung ist nur für RHEL zertifiziertRHEL statt kostenfreiem KlonOhne Herstellerfreigabe verlierst du den Anwendungssupport genau dann, wenn du ihn brauchst.
Viele gleichartige ServerNeuaufbau mit AutomatisierungDer Aufwand für Kickstart und Ansible amortisiert sich ab dem dritten Host, danach skaliert er kostenlos.
03

In-Place mit ELevate durchführen

ELevate erweitert das Red-Hat-Werkzeug leapp um die Daten für die Klone. Der Ablauf ist immer gleich, und die eigentliche Arbeit steckt in der Vorprüfung.

Vorbereitung und Vorprüfung
# Snapshot oder Vollsicherung anlegen, erst dann weiter
sudo yum update -y && sudo reboot        # EL7 muss aktuell sein

# Platz in /boot schaffen, alte Kernel entfernen
sudo package-cleanup --oldkernels --count=2
df -h /boot

sudo yum install -y https://repo.almalinux.org/elevate/elevate-release-latest-el7.noarch.rpm
sudo yum install -y leapp-upgrade leapp-data-almalinux   # oder leapp-data-rocky

sudo leapp preupgrade
sudo less /var/log/leapp/leapp-report.txt

leapp legt eine eigene Initramfs für den Umbau in /boot ab. Sind dort nur noch wenige Megabyte frei, bricht der Lauf mitten im Neustart ab, und der Host bootet nicht mehr. Deshalb steht package-cleanup vor allem anderen.

Blocker beantworten und umstellen
# Inhibitoren einzeln bestätigen, nicht pauschal wegklicken
sudo leapp answer --section remove_pam_pkcs11_module_check.confirm=True

sudo leapp upgrade
sudo reboot          # der eigentliche Umbau läuft während des Neustarts

# Nach dem Neustart
cat /etc/os-release
sudo less /var/log/leapp/leapp-upgrade.log
rpm -qa | grep -c el7          # Reste aus EL7 aufspüren

Die letzte Zeile ist der wichtigste Prüfschritt: Pakete mit el7 im Namen sind nach dem Umstieg übrig geblieben, meist aus Fremdrepos. Diese Pakete laufen oft noch, blockieren aber den nächsten Sprung nach EL9 und liefern keine Sicherheitsupdates mehr.

04

Neuaufbau automatisieren und Daten übernehmen

Beim Neuaufbau entscheidet die Datenübernahme über den Erfolg. Rechte, ACLs und Nummern müssen mitkommen, nicht nur die Dateien.

Daten mit allen Attributen umziehen
# Benutzer und Gruppen mit identischen IDs übernehmen
awk -F: '$3 >= 1000 && $3 < 65534' /etc/passwd > /root/passwd.migration
awk -F: '$3 >= 1000 && $3 < 65534' /etc/group  > /root/group.migration

# Nutzdaten inklusive ACLs, erweiterten Attributen und Hardlinks
sudo rsync -aHAX --numeric-ids --delete \
  -e 'ssh -o StrictHostKeyChecking=accept-new' \
  /srv/daten/ root@neu01:/srv/daten/

# Gegenprüfen, statt zu hoffen
sudo rsync -aHAXn --numeric-ids --itemize-changes /srv/daten/ root@neu01:/srv/daten/
getfacl -R /srv/daten > /root/acl-alt.txt

--numeric-ids ist der entscheidende Schalter: Ohne ihn ordnet rsync die Eigentümer über Namen zu, und wenn die Benutzer auf dem neuen System andere Nummern bekommen haben, gehören danach Dateien den falschen Leuten. Der zweite Lauf mit -n ist ein Trockenlauf und zeigt, was noch abweicht.

Datenbanken über mehrere Hauptversionen bringen
# MariaDB springt von 5.5 auf die Version aus dem EL9-AppStream.
# Ein direktes Kopieren des Datenverzeichnisses funktioniert dabei nicht.
mysqldump --all-databases --single-transaction --routines --events \
  --result-file=/backup/alle-db.sql

# Auf dem neuen Host einspielen und danach zwingend nacharbeiten
mysql < /backup/alle-db.sql
sudo mariadb-upgrade          # aktualisiert Systemtabellen und prüft alle Tabellen

MariaDB unterstützt In-Place-Upgrades nur über eine Hauptversion hinweg. Zwischen CentOS 7 und EL9 liegen mehrere, also ist der logische Dump der einzige verlässliche Weg. Bei PostgreSQL gilt dasselbe, dort heißt das Werkzeug pg_dumpall oder pg_upgrade.

05

Die Nacharbeiten, die niemand einplant

Zwischen EL7 und EL9 haben sich Voreinstellungen geändert, die im Alltag nicht auffallen, bis sie auffallen. Diese vier arbeitest du direkt nach dem Umstieg ab.

SELinux, Krypto und Netzwerk nachziehen
# SELinux einmal komplett neu labeln
sudo touch /.autorelabel && sudo reboot
getenforce
sudo ausearch -m AVC -ts today | audit2why | head -30

# Kryptorichtlinie prüfen
update-crypto-policies --show

# NetworkManager-Profile ins Keyfile-Format überführen
sudo nmcli connection migrate
nmcli -f NAME,DEVICE,TYPE,STATE connection show

Der Relabel-Lauf dauert je nach Datenmenge deutlich länger als ein normaler Start, plan ihn ins Wartungsfenster ein. audit2why übersetzt die AVC-Meldungen in Klartext und sagt dir, ob ein Boolean fehlt oder ein Dateikontext falsch ist.

Was es unter EL9 nicht mehr gibt
# firewalld arbeitet auf nftables, iptables ist nur noch eine Übersetzungsschicht
sudo firewall-cmd --list-all
sudo nft list ruleset | head -40

# Diese Pakete existieren nicht mehr, ihre Aufgaben sind umverteilt
rpm -q python2 network-scripts 2>&1

# Timer statt Cron prüfen, viele Pakete haben umgestellt
systemctl list-timers --all --no-pager

Selbst geschriebene Skripte mit #!/usr/bin/python laufen unter EL9 nicht mehr, weil es dort kein Python 2 gibt. Setz die Interpreterzeile auf #!/usr/bin/python3 und prüf die Skripte einzeln, statt auf eine Sammelmeldung zu warten.

06

Abnahme und Rückweg

Erst wenn das alles steht, ist der Host migriert

  • Die Fachanwendung ist mit einem echten Geschäftsvorfall geprüft, nicht nur mit der StartseiteEin erreichbarer Webserver beweist nichts. Fehler durch SELinux-Kontexte, fehlende Bibliotheken oder geänderte TLS-Vorgaben zeigen sich erst beim Schreibzugriff, beim Druck oder beim Aufruf einer Schnittstelle.
  • Alle Cronjobs und systemd-Timer sind einmal durchgelaufenNächtliche Läufe scheitern nach einer Migration gern still, weil ein Pfad, ein Interpreter oder ein Benutzer nicht mehr existiert. Bemerkt wird das erst, wenn ein Bericht fehlt oder ein Backup leer bleibt.
  • Der Backup-Agent ist für EL9 freigegeben und eine Rücksicherung ist getestetEin Agent, der zwar startet, aber die neue Kernelversion nicht unterstützt, sichert unvollständig. Das merkst du sonst erst bei der Wiederherstellung, und dann ist es zu spät.
  • Monitoring und Patchmanagement kennen den Host unter der neuen VersionNach dem Umstieg passen alte Checks häufig nicht mehr, weil Dienste anders heißen. Ein Host, der im Monitoring grün ist, weil gar nichts mehr geprüft wird, ist gefährlicher als einer, der rot ist.
  • Der Snapshot wird erst nach der Abnahme gelöscht, mit festem DatumSnapshots kosten Speicher und bremsen den Hypervisor, deshalb verschwinden sie oft zu früh. Setz ein Datum, das nach dem ersten vollständigen Monatslauf der Anwendung liegt.
Gut zu wissen

Häufige Fragen zu CentOS-7-Migration

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

Frag uns direkt
Kann ich CentOS 7 direkt auf Rocky Linux oder AlmaLinux konvertieren?
Nicht mit migrate2rocky oder almalinux-deploy, die ein Release der Generation 8 oder neuer voraussetzen. Für den Sprung von CentOS 7 gibt es das Projekt ELevate von AlmaLinux, das ein In-Place-Upgrade auf ein Nachfolgesystem ermöglicht. In produktiven Umgebungen ist die Neuinstallation trotzdem meist der sichere Weg, weil sie Altlasten aus Fremdrepos und handgepflegten Konfigurationen mit ausräumt.
Ist CentOS Stream ein Ersatz für CentOS 7?
Für Produktionssysteme in der Regel nicht. CentOS Stream läuft der jeweiligen RHEL-Minor-Version voraus und wird fortlaufend aktualisiert, es gibt also keine über Jahre eingefrorene Paketbasis. Als Vorabtest für kommende RHEL-Releases ist Stream sinnvoll, als stabiler Nachfolger für langlebige Server eher nicht.
Rocky Linux oder AlmaLinux, was ist der Unterschied?
Beide sind zu RHEL kompatibel und kostenfrei. Rocky Linux orientiert sich streng an der Bit-für-Bit-Kompatibilität zum Upstream, AlmaLinux setzt auf ABI-Kompatibilität und liefert Fixes dadurch teilweise früher aus. Für die meisten Standard-Workloads ist die Entscheidung eher eine Frage der Community und des verfügbaren Drittsupports als der Technik.
Wann lohnt sich RHEL statt eines kostenfreien Klons?
Immer dann, wenn du Herstellersupport mit zugesagten Reaktionszeiten brauchst, wenn ISV- oder SAP-Zertifizierungen ausdrücklich auf RHEL laufen müssen oder wenn du Werkzeuge wie Satellite, Insights und Leapp mitnehmen willst. Läuft dagegen eigene oder verbreitete Open-Source-Software auf den Systemen, reicht ein Klon in der Praxis aus.
Wie viel Zeit sollte ich für die Migration einplanen?
Der Aufwand steckt nicht im Installieren, sondern im Inventarisieren und Testen. Rechne pro Anwendungsstack mit einem eigenen Testdurchlauf und plane für jeden Server ein Rückfallszenario aus Snapshot oder Backup ein. Wenn die Neuinstallation über Kickstart und Ansible automatisiert ist, skaliert der Rest deutlich besser als eine Migration von Hand.

Zuletzt geprüft am 26. Juli 2026.

Das sagen Teilnehmer

Echte Stimmen aus unseren IT-Kursen

Qualitativ sehr guter Kurs. Ruhiger und wertschätzender Umgang. Keine Informationsüberlastung.
Rückmeldung aus dem Kurs „Ansible Kompaktkurs“
Für den Einsteigerkurs ganz gut umgesetzt. Passt soweit und kann man ohne Bedenken weiter empfehlen.
Rückmeldung aus dem Kurs „Linux Grundkurs (LPI01)“
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

Bring dein Team auf das neue Zielsystem

Wenn die Entscheidung für das Zielsystem gefallen ist, fehlt meist nur noch das Wissen im Team. Für die Red-Hat-Welt bilden RH124 und RH134 die Grundlage, RH199 ist der kompakte Weg für erfahrene Admins, und das RHEL 10 Upgrade Training deckt die Upgrade-Pfade ab. Für SUSE bieten wir SLE201v15 an, für Debian das Debian Administration Training, und mit dem Ansible Kompaktkurs automatisierst du die Massenmigration. Alle Kurse laufen Live-Online oder als Inhouse-Schulung bei dir vor Ort. Sprich uns an, wenn du unsicher bist, welcher Kurs zu eurem Migrationsplan passt.