Fullmoon System

Von CentOS 7 auf Rocky Linux 8 migrieren: Neuaufbau als bevorzugter Weg

EdwardMoon

Für die Migration von CentOS 7 auf Rocky Linux empfiehlt dieser Artikel vorrangig einen neuen Rocky-Linux-8.10-Server, auf den Anwendungen und Daten schrittweise übertragen werden. Der Support für CentOS Linux 7 endete am 30. Juni 2024; Sicherheitsupdates werden nicht mehr bereitgestellt. Die Anbindung eines Produktionsservers an das Vault-Repository stellt den Support nicht wieder her.

Die aktuelle offizielle ELevate-Anleitung verweist auf ausdrücklich unterstützte Migrationspfade. Gehen Sie nicht ungeprüft davon aus, dass Rocky Linux als Ziel einer In-place-Konvertierung unterstützt wird. Fehlt das Ziel in der aktuellen Unterstützungsmatrix, wählen Sie Neuaufbau und Datenmigration. Erforderliche Ausnahmen für eine In-place-Umstellung müssen zuerst in einer separaten geklonten Umgebung nachvollzogen werden.

Migration von CentOS 7 auf Rocky Linux: Neuaufbau bevorzugen und Ausnahmeverfahren anhand der aktuellen Unterstützungsmatrix prüfen
Entscheidung für einen Rocky-Linux-8.10-Neuaufbau; In-place-Verfahren nur nach Prüfung der aktuellen Unterstützungsmatrix

Empfohlene Migrationsarchitektur

Vorgehen Bewertung Wesentliche Voraussetzungen
Rocky 8.10 neu aufbauen und anschließend migrieren Empfohlen Sauberes Betriebssystem, klarer Rückkehrweg und schrittweise Prüfung
In-place-Werkzeug Ausnahmefall Aktuell unterstütztes Ziel, Upgrade-Hindernisse und Wiederherstellungskonsole prüfen
CentOS 7 weiterbetreiben Nicht empfohlen Sicherheitsrisiko außerhalb einer isolierten, kurzzeitigen Wiederherstellung

Schritt 1: Systeme und Abhängigkeiten erfassen

sudo install -d -m 0700 /root/migration-inventory
cat /etc/centos-release | sudo tee /root/migration-inventory/release.txt
uname -r | sudo tee /root/migration-inventory/kernel.txt
sudo rpm -qa --qf '%{NAME}|%{VERSION}-%{RELEASE}|%{ARCH}\n'   | sort | sudo tee /root/migration-inventory/packages.txt >/dev/null
sudo systemctl list-unit-files --state=enabled   | sudo tee /root/migration-inventory/enabled-units.txt >/dev/null
sudo ss -lntup | sudo tee /root/migration-inventory/listeners.txt >/dev/null
sudo crontab -l 2>/dev/null | sudo tee /root/migration-inventory/root-crontab.txt >/dev/null

Ein Vergleich der Paketlisten allein reicht für die Migration nicht aus. Erfassen Sie gemeinsam mit den Verantwortlichen auch systemd-Overrides, Zertifikate, Firewall-Regeln, eigene SELinux-Richtlinien, Cronjobs, numerische UID/GID, Datenbankzeichensätze, externe Speicher und Überwachungsagenten.

Netzwerk- und Sicherheitsausgangszustand dokumentieren

ip -br address
ip route
sudo firewall-cmd --list-all-zones
getenforce
sudo semanage port -l | sudo tee /root/migration-inventory/selinux-ports.txt >/dev/null
sudo getsebool -a | sudo tee /root/migration-inventory/selinux-booleans.txt >/dev/null
sudo find /etc/systemd/system -type f -print   | sort | sudo tee /root/migration-inventory/systemd-local-files.txt >/dev/null

Schritt 2: Sicherung und Wiederherstellung testen

Erstellen Sie für jeden Dienst eine konsistente Sicherung. Verwenden Sie für Datenbanken einen vom Produkt unterstützten Dump oder ein geeignetes Sicherungswerkzeug statt einer einfachen Dateikopie. Sichern Sie die Zugriffsrechte auf Verschlüsselungsschlüssel und Zertifikate gesondert.

sudo install -d -m 0700 /backup
sudo tar --xattrs --acls --selinux -C /   -czf /backup/centos7-etc-home-$(date +%F).tgz etc home
sudo find /backup -maxdepth 1 -type f -name 'centos7-etc-home-*.tgz' -exec sha256sum {} \; | sudo tee /backup/SHA256SUMS >/dev/null

# PostgreSQL-Beispiel: anhand des offiziellen Wiederherstellungsverfahrens der jeweiligen Version prüfen
set -o pipefail
sudo -u postgres pg_dumpall --clean --if-exists | sudo tee "/backup/postgresql-all-$(date +%F).sql" >/dev/null
Eine erfolgreich erzeugte Sicherungsdatei beweist noch keine erfolgreiche Wiederherstellung. Erst wenn die Sicherung auf einem isolierten Testserver tatsächlich zurückgespielt wurde und Anwendungstransaktionen funktionieren, gilt sie als belastbarer Rückkehrweg.

Schritt 3: Den Rocky-Linux-Zielserver aufbauen

Prüfen Sie die Prüfsumme des Rocky-Linux-8.10-ISO-Abbilds und installieren Sie einen minimalen Paketumfang. Richten Sie zunächst Hostname, Zeitsynchronisierung und DNS ein und prüfen Sie Speicherleistung sowie SELinux im Modus Enforcing. Fügen Sie erst danach die Anwendungs-Repositories hinzu.

cat /etc/rocky-release
sudo dnf upgrade --refresh -y
sudo systemctl --failed --no-pager
timedatectl status
chronyc tracking
getenforce
sudo firewall-cmd --state
df -hT
df -i

Schritt 4: Konfigurationen gezielt übernehmen

Wird das gesamte /etc-Verzeichnis von CentOS 7 über Rocky Linux 8 kopiert, können PAM, Kryptografierichtlinien, systemd und Netzwerkeinstellungen beschädigt werden. Vergleichen Sie ausschließlich die benötigten Anwendungseinstellungen mit den neuen Standarddateien und entfernen Sie nicht mehr unterstützte Direktiven.

diff -u /srv/migration/old/app.conf /etc/example/app.conf || true
sudo rsync -aHAXn --numeric-ids   /srv/migration/app-data/ /var/lib/example/

# Erst nach Prüfung des Probelaufs tatsächlich kopieren
sudo rsync -aHAX --numeric-ids   /srv/migration/app-data/ /var/lib/example/
sudo restorecon -RFv /var/lib/example

Schritt 5: Daten synchronisieren und die Ausfallzeit begrenzen

Übertragen Sie die Daten in vier Schritten: erste vollständige Kopie, Synchronisierung der Änderungen, abschließender Schreibstopp und letzte Synchronisierung. Prüfen Sie bei Datenbankreplikation oder logischen Dumps, ob die Kombination der Hauptversionen von Quelle und Ziel unterstützt wird.

# Erste Synchronisierung der Dateidaten: zunächst ein Probelauf
sudo rsync -aHAXn --delete --numeric-ids   /srv/app-data/ rocky8:/srv/app-data/

# Erste Synchronisierung nach Freigabe
sudo rsync -aHAX --delete --numeric-ids   /srv/app-data/ rocky8:/srv/app-data/

# Abschließendes Umschaltfenster: Anwendungsschreibzugriffe stoppen und Änderungen erneut synchronisieren
sudo systemctl stop example-app
sudo rsync -aHAX --delete --numeric-ids   /srv/app-data/ rocky8:/srv/app-data/

Schritt 6: Funktion und Leistung vor der Umschaltung testen

curl --fail --silent --show-error https://staging.example.com/health
openssl s_client -connect staging.example.com:443   -servername staging.example.com -verify_return_error </dev/null
ssh rocky8 'systemctl --failed --no-pager'
ssh rocky8 'journalctl -p err -b --no-pager'
ssh rocky8 'ss -lntup'
ssh rocky8 'getenforce'

Testen Sie Anmeldung, Lese- und Schreibzugriffe, Stapelverarbeitung, Sicherung, Überwachung, Benachrichtigungen und Leistungsanforderungen über reale Benutzerabläufe. Die bloße Erreichbarkeit einer IP-Adresse ist kein ausreichendes Abschlusskriterium.

Schritt 7: DNS und Load-Balancer umschalten und die Rückkehr absichern

dig +short app.example.com
curl --resolve app.example.com:443:192.0.2.80   --fail --silent --show-error https://app.example.com/health

# Nach der Umschaltung DNS und Zertifikat prüfen
dig +trace app.example.com
openssl s_client -connect app.example.com:443   -servername app.example.com -verify_return_error </dev/null

Senken Sie die TTL vor der Umschaltung planmäßig ab. Löschen Sie den bisherigen Server nicht sofort, sondern bewahren Sie ihn ohne Schreibzugriffe als Rückkehrmöglichkeit auf. Dokumentieren Sie messbare Fehlerkriterien und den spätesten Rückkehrzeitpunkt im Änderungsplan. Sobald der neue Server Schreibzugriffe angenommen hat, kann ein bloßes Zurücksetzen von DNS zum Verlust aktueller Daten führen. Stoppen Sie vor einer Rückkehr Schreibzugriffe auf beiden Seiten und prüfen Sie, ob neue Änderungen konsistent auf den bisherigen Server übertragen werden können. Geben Sie den alten Server nicht unmittelbar wieder zum Schreiben frei, solange Rückwärtsreplikation oder Rückübertragung der Daten nicht geprüft sind.

Wann eine In-place-Umstellung geprüft werden kann

Verwenden Sie Werkzeuge wie ELevate nur, wenn alle Inhibitors aus dem preupgrade-Bericht behoben sind und die Kombination aus Quell- und Zielsystem in der aktuellen Unterstützungsmatrix steht. Beschreibt die offizielle Dokumentation aktuell AlmaLinux als Ziel, ist dies kein Nachweis für eine Konvertierung zu Rocky Linux.

# Für Ausnahmeverfahren gelten die Befehle aus der aktuellen offiziellen Dokumentation
cat /etc/centos-release
sudo yum repolist enabled
sudo rpm -Va | sudo tee /root/preupgrade-rpm-verify.txt >/dev/null
findmnt -T /
df -hT / /var /boot
df -i / /var /boot
Ein In-place-Verfahren sollte erst freigegeben werden, nachdem der gesamte Ablauf auf einem separaten Klon wiederholt und Systemstart, Anwendungen sowie Wiederherstellung aus Sicherungen geprüft wurden. Erzwingen Sie kein in der Unterstützungsmatrix nicht aufgeführtes Rocky-Ziel durch beliebigen Paketaustausch.

Prüfliste für die Migration

  1. Die Risiken des CentOS-7-Support-Endes im Änderungsprotokoll festhalten.
  2. Systembestand, Abhängigkeiten, UID/GID und Sicherheitsausgangszustand erfassen.
  3. Sicherungen in einer isolierten Umgebung wiederherstellen.
  4. Einen neuen Rocky-Linux-8.10-Server auf aktuellem Paketstand aufbauen.
  5. Konfiguration und Daten gezielt migrieren.
  6. Echte Transaktionen und die Leistung testen.
  7. DNS-/Load-Balancer-Umschaltung und messbare Rückkehrkriterien umsetzen.
  8. Nach der Beobachtungszeit den Zugang zu CentOS 7 sperren und das Altsystem außer Betrieb nehmen.

Offizielle Quellen und weitere Artikel

Ein planbarer Migrationsweg

Am besten planbar ist die Migration durch einen neuen Rocky-Linux-8.10-Server mit erprobter Sicherung und Wiederherstellung, gezielter Konfigurationsübernahme, Datensynchronisierung, Dienstprüfung und vorbereitetem Rückkehrweg. Vault verlängert den Support von CentOS 7 nicht. Ebenso wenig darf ein In-place-Pfad vorausgesetzt werden, der in der aktuellen Unterstützungsmatrix fehlt.