Distributionen & Auswahl

RHEL, Rocky Linux oder AlmaLinux: Was trägt deine Serverlandschaft?

Brauchst du Herstellersupport, Zertifizierungen oder SAP-Freigaben, führt kein Weg an RHEL vorbei. Für alles andere sind Rocky Linux und AlmaLinux technisch gleichwertig und kosten nichts. Zwischen den beiden entscheidest du nach Governance, nicht nach Technik.

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

Drei fast identische Systeme, drei sehr verschiedene Risikoprofile

Auf der Kommandozeile fällt der Unterschied kaum auf. RHEL, Rocky Linux und AlmaLinux nutzen dieselben Paketnamen, denselben dnf-Stack, dieselben systemd-Units, SELinux-Policies, LVM-Werkzeuge und Verzeichnisstrukturen. Ein Playbook, das auf RHEL 9 läuft, läuft in aller Regel unverändert auf Rocky 9 und AlmaLinux 9. Genau diese Ähnlichkeit verleitet dazu, die Auswahl als reine Kostenfrage zu behandeln, und dabei gehen die Punkte unter, die im Störfall zählen.

Die Unterschiede liegen nicht im Dateisystem, sondern im Vertrag und in der Lieferkette. Eine RHEL-Subscription bringt Supportfälle mit Reaktionszeiten, Zugriff auf Errata und den Life Cycle mit Extended Update Support, dazu die Zertifizierungen, an denen Dritthersteller hängen. SAP zertifiziert HANA-Betrieb für RHEL for SAP Solutions und für SLES for SAP, nicht für die Klone. Ähnliches gilt für Teile der Oracle-, Storage- und Hardware-Welt. Wer eine zertifizierungspflichtige Last auf einen Rebuild stellt, verliert im Zweifel nicht die Funktion, aber die Herstellerunterstützung.

Typische Fehler sehen wir vor allem an drei Stellen. Erstens wird pauschal eine Distribution für alle Workloads gesetzt, statt zertifizierungspflichtige Systeme von Web-, Build- und Testknoten zu trennen. Zweitens wird unterschätzt, dass AlmaLinux seit Version 9 bewusst ABI-kompatibel statt strikt 1:1-binärkompatibel baut und eigene Patches sowie zusätzlichen Hardware-Support mitliefert, während Rocky Linux näher am reinen Rebuild bleibt. Drittens wird die Hardware-Baseline übersehen: RHEL 10 setzt x86-64-v3 voraus, ältere Server fallen damit raus, und AlmaLinux 10 bietet als einziger der drei zusätzlich einen x86_64_v2-Build an.

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

Entscheidungskriterien für die RHEL-kompatible Welt

  1. 01 Zertifizierung von Anwendung und Hardware
  2. 02 Supportvertrag mit Reaktionszeiten
  3. 03 Lebenszyklus und Extended Update Support
  4. 04 CPU-Baseline und Hardware-Alter
  5. 05 Migrationspfad und Rückweg
  6. 06 Betriebskosten je Workload-Klasse
Was du mitnimmst

So triffst du die Entscheidung nachvollziehbar

Statt einer Grundsatzdebatte hilft eine Einteilung nach Workload. Die folgenden Punkte sind die Kriterien, mit denen du deinen Bestand sortierst und eine Mischstrategie sauber begründest.

Zertifizierungspflicht zuerst prüfen

Kläre je Anwendung, ob ein Hersteller eine bestimmte Distribution als Supportvoraussetzung nennt. SAP HANA, viele Datenbank- und Backup-Produkte sowie einzelne Treiber-Stacks binden dich an RHEL. Alles andere ist frei wählbar, und genau dort liegt das Einsparpotenzial.

Verstehen, was in der Subscription steckt

Bezahlt wird nicht das Betriebssystem, sondern Support mit Reaktionszeiten, Errata und Security-Advisories mit Bewertung, Extended Update Support für längere Minor-Stände, Red Hat Insights, der leapp-gestützte In-Place-Upgrade-Pfad und die Haftungszusagen im Vertrag. Für Entwicklung und Labor gibt es zusätzlich die kostenfreie Developer Subscription für Einzelpersonen mit begrenzter Systemzahl.

Rocky und AlmaLinux im Detail unterscheiden

Rocky Linux verfolgt weiter das Ziel des möglichst deckungsgleichen Rebuilds und bezieht Quellen unter anderem über frei verfügbare Cloud- und Container-Images. AlmaLinux hat sich für ABI-Kompatibilität entschieden, schließt Lücken teils früher, hält Hardware-Unterstützung länger drin, die RHEL entfernt hat, und liefert eigene Builds. Beide geben zehn Jahre Lebenszyklus je Major-Release an.

Migrationspfade und Umkehrbarkeit planen

Zwischen den drei Systemen gibt es Konvertierungswerkzeuge wie migrate2rocky, almalinux-deploy und convert2rhel, dazu ELevate für Major-Upgrades der Klone. Teste den Weg an einer Kopie, prüfe Drittanbieter-Repositories, Subscription-Manager-Reste und SELinux-Kontexte, und lege fest, wie du im Ernstfall zurückkommst.

Betrieb und Automatisierung vereinheitlichen

Halte Ansible-Rollen, Kickstart-Profile, Image-Builds und Patch-Fenster distributionsneutral. Variablen für Repository-URLs und Subscription-Handling gehören in die Inventarebene, nicht in die Tasks. Dann kostet ein späterer Wechsel Konfiguration statt Neubau.

Wissen einmal aufbauen, überall nutzen

Die Administration ist auf allen drei Systemen dieselbe. Unsere Red-Hat-Linie mit RH124, RH134, dem Rapid Track RH199, AU294 für die Ansible-Automatisierung und RH436 für Pacemaker-Cluster ist damit auch für Rocky- und AlmaLinux-Umgebungen die passende Ausbildung, ergänzt um das RHEL 10 Upgrade Training für anstehende Major-Wechsel.

Tutorial

Bestand prüfen, konvertieren, einheitlich betreiben

Der Vergleich hilft dir erst, wenn du ihn an deinem eigenen Bestand nachvollziehst. Die folgenden Kapitel gehen den Weg von der Inventur über die harten Kompatibilitätsprüfungen bis zur Konvertierung und zeigen dir danach, wie du alle drei Systeme mit einer einzigen Automatisierung bedienst.

01

Was läuft da eigentlich, und woran hängt es

Bevor du über einen Wechsel nachdenkst, brauchst du drei Zahlen: Minor-Release, Anteil an Fremdpaketen und Anzahl externer Kernelmodule. Die dritte entscheidet meistens.

Fakten statt Annahmen sammeln
# Distribution und Minor-Release
cat /etc/os-release
rpm -q --whatprovides redhat-release

# Subscription-Status, nur auf RHEL vorhanden
sudo subscription-manager status
sudo subscription-manager repos --list-enabled

# Fremdpakete: alles, was nicht aus den Distributionsrepos stammt
dnf list --installed | grep -vE '@(baseos|appstream|crb|epel)'

# Kernelmodule, die nicht aus dem Kernel-Paket kommen
lsmod | awk 'NR>1{print $1}' | while read -r m; do
  modinfo -F filename "$m" | grep -qE '/extra/|/weak-updates/' && echo "extern: $m"
done

rpm -q --whatprovides redhat-release liefert auf allen drei Systemen eine Antwort, weil rocky-release und almalinux-release dieselbe Fähigkeit bereitstellen. Genau darauf bauen auch viele Installationsroutinen von Fremdsoftware auf.

02

Binärkompatibilität selbst nachmessen

Statt zu glauben, was auf einer Webseite steht, vergleichst du Paketstände und die Bibliotheken, an denen deine Anwendung wirklich hängt.

Zwei Systeme gegeneinander halten
# Auf beiden Systemen erzeugen, danach diff
rpm -qa --qf '%{NAME} %{VERSION}-%{RELEASE}\n' | sort > /tmp/pakete-$(hostname -s).txt

# Die Stände, an denen Fremdsoftware hängt
rpm -q glibc openssl kernel systemd

# Fehlen Symbole, wenn die Anwendung dynamisch gelinkt ist?
ldd /opt/hersteller/bin/dienst | grep -i 'not found'

Wenn du diesen Vergleich einmal für eine Rolle gemacht hast (Datenbank, Webserver, Applikationsserver), kannst du das Ergebnis auf alle Maschinen derselben Rolle übertragen. Ein Diff pro Host ist Zeitverschwendung.

Woran du die Entscheidung festmachst

KriteriumRHELRocky LinuxAlmaLinux
Support mit Vertrag und Eskalationvom Herstellerüber Drittanbieterüber Drittanbieter
Freigaben für SAP, Oracle und Co.direkt vorhandenin der Regel nichtin der Regel nicht
TrägerschaftRed Hat, IBMRocky Enterprise Software Foundation, Public Benefit CorporationAlmaLinux OS Foundation, gemeinnützig, Mitglieder wählen den Vorstand
Kompatibilitätsanspruchdas Originalso nah wie möglich am OriginalABI-kompatibel, eigene Korrekturen möglich
Werkzeug für den Wechsel dorthinconvert2rhelmigrate2rockyalmalinux-deploy
03

Konvertieren, ohne neu zu installieren

Die drei Werkzeuge
# Nach Rocky Linux: Skript passend zur Major-Version aus
# github.com/rocky-linux/rocky-tools
sudo bash migrate2rocky.sh -h      # erst die Optionen lesen, dann -r

# Nach AlmaLinux: almalinux-deploy.sh aus
# github.com/AlmaLinux/almalinux-deploy
sudo bash almalinux-deploy.sh

# Nach RHEL: von Red Hat gepflegt und unterstützt
sudo dnf install -y convert2rhel
sudo convert2rhel analyze          # Trockenlauf mit Bericht, ändert nichts

# Danach in jedem Fall:
cat /etc/os-release && rpm -qa gpg-pubkey* --qf '%{SUMMARY}\n'

convert2rhel analyze ist der einzige der drei Wege mit einem sauberen Trockenlauf. Wenn du in die andere Richtung gehst, ersetzt du ihn durch einen Klon der Maschine, an dem du die Konvertierung einmal komplett durchspielst.

Vor der Konvertierung, ohne Ausnahme

  • Snapshot oder vollständige Sicherung, Wiederherstellung getestetDie Konvertierung tauscht Release-Pakete und GPG-Schlüssel aus und läuft ohne Rückwärtsgang. Der Snapshot ist der einzige Rollback, den du hast, und ein ungetesteter Snapshot ist keiner.
  • Fremdrepos und angepinnte Pakete auflisten und abschaltenPakete aus fremden Repos verweisen auf Abhängigkeiten des alten Release-Pakets. Sie bringen die Konvertierung mitten im Lauf zum Stehen, und dann ist das System weder das eine noch das andere.
  • Externe Kernelmodule ausbauen oder vorher freigeben lassenSie sind gegen die Kernel-ABI gebaut. Das System startet nach dem Wechsel, aber der Pfad zum Speicher kann fehlen, und dann steht die Anwendung ohne erkennbaren Zusammenhang zur Migration.
  • Konsolenzugang unabhängig vom Netz bereitlegenWenn NetworkManager oder der Bootloader beim ersten Neustart klemmen, hilft dir keine SSH-Sitzung mehr. Halte IPMI, iDRAC oder die Konsole des Hypervisors offen, bevor du startest.
  • Erst ein System, dann eine WelleEin einzelner Kandidat mit derselben Rolle deckt die Überraschungen auf. Danach ist die Wiederholung Routine und du kannst sie an das Team abgeben.
04

Eine Automatisierung für alle drei

Der Unterschied zwischen RHEL und den Klonen zeigt sich in der Automatisierung an genau zwei Stellen: bei den Repos und bei der Subscription. Überall sonst reicht die Familie.

Ansible: auf die Familie prüfen, nicht auf den Namen
- name: Zusatzrepos bereitstellen
  hosts: el_familie
  become: true
  tasks:
    - name: CRB aktivieren (Rocky, AlmaLinux)
      ansible.builtin.command: dnf config-manager --set-enabled crb
      when: ansible_facts['distribution'] in ['Rocky', 'AlmaLinux']
      changed_when: false

    - name: CodeReady Builder aktivieren (RHEL)
      community.general.rhsm_repository:
        name: "codeready-builder-for-rhel-{{ ansible_facts['distribution_major_version'] }}-x86_64-rpms"
      when: ansible_facts['distribution'] == 'RedHat'

    - name: EPEL installieren
      ansible.builtin.dnf:
        name: "https://dl.fedoraproject.org/pub/epel/epel-release-latest-{{ ansible_facts['distribution_major_version'] }}.noarch.rpm"
        state: present
        disable_gpg_check: true

Auf EL 8 heißt das Repo noch powertools, ab EL 9 crb. Wenn du beide Major-Versionen im Bestand hast, hängst du den Namen an distribution_major_version und nicht an den Distributionsnamen.

05

Sicherheitsaktualisierungen und die Errata-Falle

Prüfen, ob Sicherheitsmetadaten überhaupt ankommen
# Gibt es Errata-Daten in den eingebundenen Repos?
dnf updateinfo summary

# Nur sicherheitsrelevante Aktualisierungen einspielen
sudo dnf update --security

# Eine bekannte Schwachstelle gezielt schließen
sudo dnf update --cve CVE-2024-6387

# Was braucht danach einen Neustart, was nur einen Dienst-Neustart?
sudo dnf install -y dnf-utils
needs-restarting -r
needs-restarting -s

needs-restarting -r beantwortet die Frage nach dem Reboot mit einem Rückgabewert und eignet sich damit direkt für die Automatisierung. -s listet die Dienste, die noch alte Bibliotheken im Speicher halten.

Gut zu wissen

Häufige Fragen zu RHEL, Rocky und AlmaLinux

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

Frag uns direkt
Sind Rocky Linux und AlmaLinux wirklich binärkompatibel zu RHEL?
Rocky Linux zielt weiterhin auf einen möglichst deckungsgleichen Rebuild der RHEL-Quellen ab. AlmaLinux hat sich nach der Änderung der Quellcode-Bereitstellung durch Red Hat 2023 bewusst auf ABI-Kompatibilität festgelegt, das heißt, gegen RHEL gebaute Anwendungen laufen weiter, einzelne Pakete können sich aber im Detail unterscheiden. Für den normalen Betrieb von Standarddiensten ist das praktisch nicht spürbar, für zertifizierte Anwendungen kann es relevant sein.
Gibt es RHEL kostenlos, und was kostet eine Subscription?
Red Hat bietet eine kostenfreie Developer Subscription für Einzelpersonen an, die auch für eine begrenzte Zahl von Systemen genutzt werden darf, allerdings ohne regulären Produktionssupport. Produktive Subscriptions werden je nach Variante nach Sockelpaaren, virtuellen Instanzen und Support-Level abgerechnet. Verbindliche Preise nennt nur die aktuelle Red-Hat-Preisliste oder dein Reseller, deshalb rechnen wir hier bewusst mit keinen Beispielzahlen.
Kann ich zwischen RHEL, Rocky Linux und AlmaLinux wechseln, ohne neu zu installieren?
Ja, für alle Richtungen gibt es Konvertierungswerkzeuge, etwa convert2rhel in Richtung RHEL sowie migrate2rocky und almalinux-deploy in die Gegenrichtung. Die Umstellung ersetzt die Basispakete und die GPG-Schlüssel im laufenden System. Praktisch scheitern Konvertierungen selten am Werkzeug, sondern an Drittanbieter-Repositories, angepassten Kerneln und Agenten, deshalb gehört jeder Wechsel vorher auf ein Testsystem mit Snapshot.
Welche Rolle spielt CentOS Stream heute noch?
CentOS Stream ist kein Klon mehr, sondern der kontinuierlich gepflegte Vorlauf zum nächsten RHEL-Minor-Release. Es eignet sich für Entwicklung, für frühes Testen kommender Änderungen und für Beiträge zur Plattform, ist aber wegen des rollenden Charakters keine direkte Ablösung für ein stabiles Produktionssystem mit festem Minor-Stand.
Gelten Red-Hat-Kurse und die RHCSA-Zertifizierung auch, wenn wir Rocky oder AlmaLinux einsetzen?
Inhaltlich ja. Paketverwaltung mit dnf, Storage mit LVM und Stratis, systemd, SELinux, nftables mit firewalld und die Automatisierung mit Ansible funktionieren auf allen drei Systemen gleich. Die Prüfungen RHCSA und RHCE selbst laufen auf RHEL, das erworbene Wissen setzt du danach ohne Umweg auf deinen Rebuild-Systemen ein.

Zuletzt geprüft am 26. Juli 2026.

Das sagen Teilnehmer

Echte Stimmen aus unseren IT-Kursen

Die Schulung war genau das richtige, um mein Verständnis zu erweitern. Vielen Dank an den Trainer!
Rückmeldung aus dem Kurs „Linux Grundkurs (LPI01)“
Trainer gut und verständlich. Unterlagen nur zum lesen (keine Kopierfunktion). Wissenstransfer erfolgreich.
Rückmeldung aus dem Kurs „SUSE Linux Enterprise 15 High Availability Deployment – HAE311v15“
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

Deine Enterprise-Linux-Strategie mit uns durchsprechen

Wenn du deinen Bestand sortieren oder dein Team auf einen einheitlichen Stand bringen willst, hilft dir unsere Red-Hat-Linie von RH124 über RH134 und RH199 bis zu AU294 und RH436 weiter, unabhängig davon, ob du RHEL, Rocky Linux oder AlmaLinux betreibst. Alle Kurse gibt es als Präsenztermin, Live-Online und als Inhouse-Schulung auf deiner eigenen Umgebung. Melde dich, dann klären wir gemeinsam, welcher Einstieg zu deiner Landschaft passt.