RHEL und kompatible

Siehe auch

RHEL vs. CentOS vs. Fedora

Red Hat Enterprise Linux wird der Einfachheit halber RHEL abgekürzt, wobei es sich um eine nicht-offizielle Abkürzung handelt. Im Jahr 2003 stellte Red Hat sein Red Hat Linux ein und spaltete es in Fedora und RHEL auf.

Der Linux-Kernel steht seit 1992 unter der GNU General Public License. Da sich die Mitarbeiter von Red Hat an diese Lizenz halten müssen, veröffentlichen sie den Source Code, verbieten jedoch verständlicherweise die Nutzung ihrer Red Hat Trademarks. Zwar veröffentlichen sie sogar Source Code für Software, wo sie es gar nicht müssten, jedoch ist ein RHEL-System nur bei Abschluss eines Support-Vertrages zu erwerben und sinnvoll einsetzbar. Dafür ist die Qualität der Software exzellent und auf ungezählten Servern erprobt.

Fedora ist die Distribution, in welche die neuesten technischen Entwicklungen einfliessen. So erscheint ca. alle sechs Monate eine neue Fedora-Version - stabile und sinnvolle Erweiterungen fliessen dann mit Verzögerung in die RHEL-Distributionen ein. Fedora ist richtungsweisend und gibt den Takt für künftige Entwicklungen in Red Hat Enterprise Linux vor. In Fedora sieht man also meist heute schon, was auf einen RHEL-Admin in ein paar Jahren zukommt, weswegen wir es persönlich als Workstation schätzen.

Bis CentOS 8.3 / 2021-12-31:

CentOS (Community ENTerprise Operation System), ursprünglich von Gregory Kurtzer als freies Projekt gegründet, besitzt den gleichen Funktionsumfang wie Red Hat Enterprise Linux und bietet volle Software-Kompatibilität. 2014 wurde das Projekt von Red Hat übernommen.

Ein kleines Team um Karanbir Singh ersetzt im Prinzip RHEL-Logos, Trademarks und RHEL-spezifische Pakete wie das Lizenzmanagement, und übernimmt sogar bewusst Fehler aus dem RHEL-Quellcode, um die vollständige Binärkompatibilität zu gewährleisten. CentOS wird allerdings von grossen Software-Lieferanten wie Oracle und IBM nicht als Betriebssystemplattform ihrer Produkte unterstützt. Wer auf Support seitens Red Hat oder anderer grosser Software-Lieferanten verzichten kann, kann zu CentOS greifen. Ein CentOS x.y entspricht einem RHEL x.y.

CentOS ist kein Upstream-Projekt, da es vom kommerziellen RHEL abgeleitet wird. Das Upstream-Projekt zu CentOS ist RHEL. Das Upstream-Projekt zu RHEL ist dagegen Fedora. Der Workflow ist wie folgt:

Nach einem RHEL-Release arbeitet Red Hat stärker als üblich an Fedora.

  1. Nach ein paar Monaten wird aus Fedora die kommende RHEL-Version abgeleitet, die intern weiterentwickelt wird.

  2. Nach ein paar Monaten wird RHEL veröffentlicht. Nach ein paar Wochen erscheint CentOS.

  3. Pflege. Updates für RHEL (und damit CentOS) stammen teilweise auch aus dem Fedora-Projekt, obwohl es dazu keine sichtbare Verbindung mehr gibt (Backports).

Nach CentOS 8.3 / ab 2022-01-01:

Fedora bleibt das Haupt-Upstream-Projekt für RHEL, Red Hat arbeitet also nach wie vor an Fedora.

  1. Nach ein paar Monaten wird wie bisher auch aus Fedora die kommende Major-Version von RHEL abgeleitet, also beispielsweise RHEL 9.

  2. Innerhalb der Major-Version ist dann CentOS Stream 9 der Upstream für RHEL 9.

CentOS Stream

CentOS Stream ist eine Rolling Release Distribution, in der laufend Neuerungen veröffentlicht werden, unter anderem aktuellere Kernel- und Applikations-Versionen. CentOS Stream stellt damit den Stand der Entwicklung dar. Mit CentOS 8 eingeführt, richtete es sich zunächst an Entwickler. Mehr und mehr und spätestens Ende 2021 ist es offiziell „Midstream“ zwischen Fedora und RHEL. Die fixen CentOS-Versionen 8.0 bis 8.3 werden Ende 2021 komplett durch CentOS Stream abgelöst, CentOS 8.3 ist dann also EOL. Spätestens dann steht ein Update von „CentOS Linux 8“ auf „CentOS Stream 8“ an.

Die Aktualisierungen sind in CentOS-Stream allerdings weniger dramatisch, als die „Rolling Release“-Kategorisierung vermuten lässt. Zum Vergleich Stand 2020-12-09, „CentOS Stream release 8“ vs. „CentOS Linux release 8.3“: beide Versionen unterscheiden sich an diesem Tag minimal.

Komponente

CentOS Stream release 8

CentOS Linux release 8.3

Bemerkung

Kernel

4.18.0-240

4.18.0-240.1.1

Apache

2.4.37-30

2.4.37-30

identisch

PHP

7.2.24-1

7.2.24-1

identisch, und immer noch steinalt

Um auf CentOS Stream zu wechseln, genügt:

dnf -y install centos-release-stream
dnf distro-sync

CentOS 7 bleibt unangetastet.

Für die Abkündigung von CentOS Linux siehe auch

Weiterführende Links

Wer lernen möchte, wie man mit Linux bei Null anfängt: http://www.linuxfromscratch.org

Klone

CentOS (bis Version 8.3), Scientific Linux, Oracle Linux und Amazon Linux bauen auf den Red Hat Quellen auf, wobei CentOS die einzig wirklich binärkompatible Plattform darstellte.

Rocky Linux

Gregory Kurtzer, heute bei HPCng.org (High Performance Computing Next Generation), hat aufgrund der Neuausrichtung des CentOS-Projektes das „Rocky Linux“ Projekt ins Leben gerufen, welches wieder 100% bug-für-bug-kompatibel zu RHEL werden soll. Der Name „Rocky“ ist dem verstorbenen CentOS-Mitgründer und einstigen Maintainer Rocky McGough gewidmet.

Siehe auch

AlmaLinux

Vom Team der Firma CloudLinux gebaut, ebenfalls als Antwort auf die Abkündigung von CentOS ins Leben gerufen.

Siehe auch

Oracle Linux

Oracle Linux wird mit zwei unterschiedlichen Kerneln angeboten, einem Red Hat kompatiblen Kernel sowie mit dem „Unbreakable“ Enterprise Kernel, der Oracle-spezifische Optimierungen enthält. Die Unterschiede zum Original RHEL werden jeweils in den Release Notes zu Oracle Linux beschrieben.

Scientific Linux

Dieser Klon ist um wissenschaftliche Programme angereichert und wurde vor allem am CERN in und um Genf gepflegt. 2019 eingestellt, verlief die Entwicklung aus Ressourcengründen langsamer als bei CentOS oder Oracle Linux, und auch nur bis Version 7.

System-Anforderungen

  • RHEL 8: mind. 1.5 GB RAM; 1.5 GB pro CPU-Core sind empfohlen

  • RHEL 7: mind. 1280 MB RAM; 1.0 GB pro CPU-Core sind empfohlen

  • RHEL 6: mind. 1.0 GB RAM; 1.0 GB pro CPU-Core sind empfohlen

Limits

Wo liegen die Hardware-Limits für Red Hat Enterprise Linux / RHEL auf x86_64-Systemen?

Eigenschaft

RHEL 6

RHEL 7

RHEL 8

Max Anzahl CPU-Cores

488

768

768

Max Memory (TB)

12

12

24

Max Anzahl sd*-Devices

8192

10000

10000

Die Disk sollte mind. 10 GB gross sein, selbst wenn nicht viel darauf läuft - spätestens wenn ein Betriebssystem-Upgrade ansteht, ist man froh über das Mehr an Platz.

Sicherheitslücken

Wie gewöhnliche Software-Produkte unterliegen Sicherheitslücken in RHEL/CentOS (Security Vulnerabilities) ebenfalls einem Lebenszyklus.

Entdeckung

Wird eine Schwachstelle gemeldet, wird diese untersucht und bei Bestätigung und je nach globaler Auswirkung auf das System bewertet. Dieser Schritt wird als der wichtigste erachtet, da eine Fehleinschätzung zu unvollständigen Patches führen kann, die das System gegen ähnliche Probleme verwundbar lässt. Die Bewertung führt schlussendlich zu einer Priorisierung: als Critical eingestufte Sicherheitslücken werden sofort seitens Red Hat angegangen, während als Moderate und Low eingestufte Lücken nicht an Kunden berichtet werden, da diese in der Regel viel Zeit in die Validierung neuer und geänderter Pakete innerhalb ihrer Infrastruktur investieren müssen.

Research

Oft wird eine Schwachstelle nicht durch Red Hat, sondern durch die Community entdeckt. In diesem Fall muss die Lücke durch Red Hat nachgestellt und reproduziert werden, was teilweise auch zur Entdeckung von Folgefehlern führen kann.

Benachrichtigung

Ist eine Schwachstelle identifiziert, startet seitens Red Hat die Entwicklung des Patches. Die Sicherheitslücke wird in der CVE-Datenbank mit allen Details wie Beschreibung, Bugzilla-Ticket und betroffenen Plattformen vermerkt. Ist eine Software-Komponente betroffen, die Teil einer grösseren Software-Suite ist, wird diese als CVE-Referenz genannt. CVEs sind nicht Red Hat-spezifisch, sondern global ausgelegt.

Patch-Development

Die Entwicklung des Patches ist anspruchsvoll: der Fix soll einerseits das Problem komplett beheben, dabei aber keine neuen Probleme, Sicherheitslücken oder Inkompatibilitäten verursachen. Muss eine Sicherheitslücke mit einem Red Hat-spezifischen Fix behoben werden (was man in der Regel zu vermeiden versucht), wird er in das Master Software Repository zurückgemeldet - so hat der ursprüngliche Software-Lieferant die Chance, diesen an seine Software anzupassen. Liefert dagegen ein Hersteller einen Patch, der aus Versionsgründen nicht zu dem von Red Hat gelieferten (älteren) Produkt passt, wird er rückportiert (backport).

Qualitätssicherung

Red Hat führt neben Patch-Reviews auch (automatisierte) Regressionstests durch, für die die QE-Teams zuständig sind. Die Tests können je nach betroffenem Paket einiges an Zeit in Anspruch nehmen, die sich die Teams aber auch nehmen - schliesslich muss sichergestellt sein, dass die Lücken behoben und keine Inkompatibilitäten entstanden sind.

Dokumentation

Der Patch wird aus „Kunden“-Sicht dokumentiert, zusätzlich zu den Kommentaren, die die Entwickler im Source Code hinterlegen - welche Auswirkungen hat das Problem, welche Umgebungen sind betroffen, wie ist das Problem zu beheben etc. Siehe dazu den „Errata“-Teil in der CVE.

Patch-Deployment

Während die Patches auf die Mirror-Server synchronisiert werden, verteilt Red Hat und auch das CentOS-Projekt die RHSA (Red Hat Security Advisory), sofern man sich auf den jeweiligen Mailinglisten eingetragen hat. Ein RHSA liefert jetzt die Information, dass ein Patch bereitsteht, inkl. Link zum CVE. Es wird Zeit für ein yum update.

Support

Der Red Hat Support beantwortet Fragen zu Patches und Updates und kann helfen, diese einzuspielen und anzuwenden.

Built on 2024-11-18