Die Welt freier Betriebssysteme teilt sich seit Jahrzehnten in zwei Bereiche auf. Wer Linux auf dem Desktop nutzt, setzt dazu meist auf openSUSE, Fedora, Ubuntu, Arch Linux oder auf ein System, das von einer dieser Distributionen abstammt. Im Serverraum sehen die Dinge aber anders aus. Hier dominieren bis heute die Enterprise-Systeme, die Unternehmen mit dem Versprechen besonders langer Updateverfügbarkeit und hoher Stabilität durch möglichst wenige Änderungen ködern.

Für die Linux-Distributoren mit großer Marktmacht, vorrangig also Red Hat, SUSE und Canonical, stellen ihre jeweiligen Serversysteme bis heute das kommerzielle Fundament dar. Oder anders formuliert: Wenn einer der Hersteller sich mit einer neuen Version dieser Systeme auf den Markt traut, sollte der Schuss besser sitzen. Nach Canonical im April war Red Hat kurze Zeit später an der Reihe und brachte in Form von Red Hat Enterprise Linux 9 (RHEL 9) eine neue Major-Version der eigenen Enterprise-Distribution auf den Markt.

Bei der Installation der neuen RHEL-Version fällt auf, dass sich im Vergleich zur Vorversion relativ wenig verändert hat. Wer einzelne Systeme "zu Fuß" installiert, landet in einer grafischen Installationsroutine, die jener in RHEL 8 weitgehend gleicht (Bild 1). Red Hat selbst sähe freilich lieber, dass die eigene Klientel Systeme automatisiert ausrollt, im Tandem mit einem Lifecycle-Management.

An Kickstart und Anaconda hat Red Hat aus diesem Grund etliche vor allem kleinere Änderungen vorgenommen. Aus Sicht des Anbieters wohl die wichtigste: Ein frisch installierter RHEL-Host lässt sich nun noch direkt aus der Installationsroutine heraus am Red Hat Service Management (RHSM) anmelden. Das ging bisher nur nach dem Reboot des Systems (Bild 2) oder im Installer per Skript. Dabei fielen aber stets die Rückgabewerte des Register-Tools unter den Teppich, falls es mal nicht funktionierte. Die native Integration unterbindet das und verrät dem Admin im Fehlerfall klar, was Sache ist.

Aus Administratorensicht ist die wichtigere Nachricht, dass es nur wenige Änderungen im RHEL-9-Installer gibt, die zu vorherigen Konfigurationen inkompatibel sind. Und jene wenigen betreffen fast nur absolute Nischensetups, deren Admins auf etwaige Inkompatibilitäten üblicherweise ohnehin eingestellt sind. Wer eine umfassende Kickstart- und Anaconda-Konfiguration für RHEL 8 hat, soll diese in der allergrößten Mehrheit der Fälle wie bisher unverändert nutzen können.

Was bekommt ein Administrator nun aber eigentlich, wenn er RHEL 9 erstmals auf ein eigenes System bügelt? Fest steht: Vor allem an der Art und Weise, wie Red Hat seine Enterprise-Distribution entwickelt und versioniert, hat das Unternehmen stark geschraubt – aber ohne, dass sich das auf die Nutzbarkeit auswirkt: In den meisten Aspekten ist RHEL 9 kompatibel zu RHEL 8 oder führt eventuell nötige Migrationen im Hintergrund selbst durch. Trotzdem lohnt es sich, auf die neue Art der Entwicklung in RHEL 9 einen genaueren Blick zu werfen.

Mit dem neuen Entwicklungsschema war vor knapp zwei Jahren vor allem eines verbunden: ein massiver Aufschrei der öffentlichen Empörung. Den meisten Admins von Red-Hat-Systemen dürfte auch CentOS ein Begriff sein. Einst als unabhängiges Projekt Freiwilliger gestartet, entwickelte CentOS einen binärkompatiblen Klon von Red Hat Enterprise Linux, der zwar ohne Red-Hat-Logo daherkam, einem RHEL ansonsten aber vollständig glich. Der Deal: CentOS-Nutzer hatten keinen Anspruch auf Support seitens des Herstellers, konnten dafür RHEL in (irrelevant) abgewandelter Form nutzen. Einer neuen RHEL-Version folgte bald eine neue CentOS-Version mit gleichen Neuerungen. Und Red Hat fand daran durchaus Gefallen – so viel, dass es CentOS irgendwann kurzerhand aufkaufte.

Im Rahmen der RHEL-9-Entwicklung ging es dem klassischen CentOS nun aber an den Kragen, und zwar aus praktischen Überlegungen heraus. Red Hat war bekanntlich bis dato nicht sonderlich gut darin, die Zeit zwischen zwei RHEL-Releases einigermaßen kurz zu halten. Vor 15 Jahren war das noch kein sonderlich großes Problem. Doch heute ist es Admins kaum noch zu vermitteln, dass sie mit einer fünf Jahre alten Apache-Version vorliebnehmen müssen, weil es eine aktuellere Version im gesamten Red-Hat-Portfolio mit kommerziellem Support schlicht nicht gibt.

In Raleigh gerieten die Manager hier obendrein unter Druck seitens der Konkurrenz. Denn während sich auch SUSE regelmäßig viel Zeit zwischen zwei Releases von SUSE Linux Enterprise (SLE) lässt, zog Canonical das Tempo von Anfang an ordentlich an. Dass alle zwei Jahre eine neue LTS-Distribution von Ubuntu erscheint, ist fast schon in Stein gemeißelt. Die roten Hüte und die Chamäleons in Nürnberg geraten da fix in Rückstand und in Erklärungsnot. Und insbesondere die fünf Jahre sind bei RHEL nicht aus der Luft gegriffen: So lange dauerte es seit RHEL 7, bis RHEL 8 erschien.

Das ist jedoch Vergangenheit. Geht es nach Red Hat, gleicht die RHEL-Entwicklung künftig einem TGV statt eines Bummelzugs. Als Vehikel ist nun ausgerechnet CentOS vorgesehen. Das ist nach Raleighs Wille künftig kein RHEL-Klon mehr, der nach RHEL-Releases regelmäßig aktualisiert wird. Stattdessen ist Cent-OS zwischenzeitlich zur Staging-Distribution für RHEL 9 geworden, was im Klartext bedeutet: CentOS soll sich zu jedem Zeitpunkt in einem Zustand befinden, in dem sich ISO-Abbilder erstellen lassen und die Distribution als RHEL 10, 11 oder als was auch immer veröffentlichen lässt.

Bisher nutzte Red Hat als Vehikel für RHEL-Entwicklung vor allem Fedora Core, das diese Rolle nun einbüßt. Was nicht heißt, dass Features aus Fedora es künftig nicht mehr in RHEL schaffen – doch fehlt der Automatismus, der bisher galt. Und gleichzeitig ist es denkbar, dass Funktionen zwar in CentOS landen, weil dieses einen eigenen Entwicklungszyklus hat, nicht aber in Fedora. Wer bis dato also die Fedora-Entwicklung verfolgt hat, um sich über künftige Neuerungen in RHEL zu informieren, muss seinen Fokus stattdessen künftig auf CentOS legen. Das "klassische" CentOS lebt immerhin einstweilen unter anderen Namen fort, denn als Nachfolgeprojekte haben sich AlmaLinux sowie Rocky Linux etabliert.

Während Administratoren von den massiven Änderungen im RHEL-Unterbau jedoch nicht allzu viel merken werden, sind andere Veränderungen offensichtlicher und invasiver. Klar zu erkennen ist etwa, dass sich in RHEL 9 auch Red Hats Kommerzflaggschiff in Richtung Container-Betrieb entwickelt, und mehr noch, den Fokus klar auf diesen legt. Erste Vorbereitungen dazu hatte Red Hat bereits in RHEL 8 getroffen. So war es etwa in "dnf" von RHEL 8 möglich, neben normalen RPM-Paketquellen auch Container als "Streams" wie Pakete zu verwalten. Dadurch wurde es möglich, einzelne Komponenten des Systems leichter zu aktualisieren als bisher, weil jeder Container autark lauffähig ist und die übrige Software auf dem System nicht berührt.

In RHEL 9 hat Red Hat diese Fähigkeiten in der Paketverwaltung nicht nur nochmal weiter aufgemöbelt, sondern setzt die Containerisierung seiner Distribution konsequent fort. Standardmäßig liegt jedem RHEL beispielsweise eine komplette Umgebung von Podman bei, der von Red Hat miterfundene und mitentwickelte Docker-Ersatz. Dadurch wird RHEL 9 natürlich automatisch auch zum Fundament anderer Produkte des Anbieters wie OpenShift.

Darüber hinaus hat der Distributor in den vergangenen Monaten immer wieder deutlich gemacht, dass er in der Con­tainerisierung von Anwendungen eine Hauptaufgabe der kommenden Jahre sieht. Was Sinn ergibt: Wenn Red Hat "nur noch" ein basales Rumpfsystem bereitstellen muss, weil Anwendungscontainer ohnehin von den Anbietern einer jeweiligen Software kommen, erspart das Red Hat unendlich viel Aufwand. Denn dann ist zum Beispiel überhaupt kein MariaDB mehr zu pflegen, wo vorher diverse MariaDB-Versionen für die noch unterstützten RHEL-Releases zu warten waren.

Insgesamt scheint es, als sei RHEL 9 hier eine Art Zwischenwelt. Denn eine Mikro-Distribution für ausschließlichen Container-Betrieb hat Red Hat bereits im Portfolio: CoreOS by Red Hat. Gut möglich, dass RHEL die Systeme in RHEL 10 verschränken oder sogar verschmelzen wird, um der Container-Ideologie auch die verbliebenen Systemwerkzeuge zu unterwerfen.

So weit ist es in RHEL 9 aber noch nicht, und es gibt andere handfeste Neuerungen. Was im Kontext des neuen Releases immer wieder auffällt, ist die massive Modellpflege, die der Anbieter beim System betrieben hat. Das geht schon mit dem Kernel los. RHEL 9 liegt der Linux-Kernel in der Version 5.14 bei, oder zumindest ist das die Version, die Red Hat seinem Kernel verpasst. Damit bringt der Distributor zum Ausdruck, dass die Grundversion für den RHEL-Kernel eben dieser Version entsprach; doch heißt das noch lange nicht, dass von Linux 5.14 im genutzten RHEL-Kernel nicht viel übrig sein muss.

Denn einerseits gilt bei RHEL die strikte Regel, dass eine einmal als Teil einer Enterprise-Distribution ausgelieferte Kernel-Version für den gesamten Zyklus des jeweiligen Produktes gilt. Anders als Ubuntu, das für seine LTS-Releases auch die Kernel späterer Non-LTS-Versionen in Form des "Hardware Enablement"-Stacks (HWE) mit eingeschränktem Support anbietet, wird RHEL 9 also stets mit Linux 5.14 daherkommen.

Gleichzeitig portiert Red Hat jedoch Patches aus späteren Kernels regelmäßig auf den existierenden RHEL-Kernel zurück. Während auf der Verpackung also 5.14 steht, dürfte es sich beim RHEL-Kernel schon bald um einen wilden Mix aus zahllosen Patches von späteren Kernel-Versionen handeln. Was aus Admin-Sicht nicht ganz glücklich ist, denn ein RHEL-Kernel lässt sich realistisch ohne den Hersteller debuggen. Weil RHEL aber ohnehin nicht ohne Anbietersubskription zu bekommen ist, fällt dieser Faktor nur bedingt ins Gewicht.

Interessanterweise vermarktet Red Hat RHEL 9 ganz offiziell auch als Betriebssystem für den Einsatz auf Desktops. Etliche Desktopanwendungen liegen in leidlich aktuellen Versionen bei, etwa GNOME 40, LibreOffice oder Firefox. Anders als RHEL 8 setzt Version 9 nicht mehr auf PulseAudio, sondern auf dessen deutlich moderneren Nachfolger PipeWire. Obendrein lassen sich auf RHEL-Desktops die sogenannten Flatpaks installieren. Dabei handelt es sich um Desktopanwendungen, die als fertiger Container daherkommen und sich in RHEL 9 ähnlich wie RPM-Pakete nutzen lassen. Wer mit der gar zu alten Software in RHEL 9 auf Desktops hadert, kann also zumindest einzelne Teile davon per Flatpak aktualisieren, ohne gleich den Support für das gesamte System zu verlieren.

Den endgültigen Heldentod sterben in RHEL 9 die Network Scripts. Gemeint ist damit die Toolchain, die Konfigurationsdateien in "/etc/sysconfig/network-scripts" ausliest (Bild 3) und daraus eine valide Netzwerkkonfiguration für das System während des Bootvorgangs zimmert. Überraschend kommt das keinesfalls, denn bereits in RHEL 8 hatte Red Hat den Supportstatus der Werkzeuge auf "deprecated" gesetzt – ein deutliches Zeichen an Admins, die bestehende Konfiguration hin zum NetworkManager zu migrieren.

Exakt diesen Vorgang wickelt der NetworkManager beim Gros der Konfigurationen sogar selbst zuverlässig ab. Lediglich bei komplexen Setups mit geschachtelten Geräten kommt er schon einmal aus dem Tritt, etwa wenn eine physische Netzwerkkarte, Bonding, VLAN und Bridges zusammenkommen. Um Admins Möglichkeiten zu geben, selbst eine Migration anzustoßen, lag RHEL 8 das Paket für die "network-scripts" noch bei. Bei RHEL 9 fehlt es komplett, so dass RHEL-Administratoren in dieser Hinsicht keine Wahl mehr haben.

Wer von RHEL 8 mit Network Scripts auf RHEL 9 aktualisiert, sollte vor dem finalen Upgrade also einen Testlauf mit einer Beispielkonfiguration durchführen, damit das System nach dem Reboot im Rahmen des Updates nicht unverhofft vollständig ohne Netzwerkverbindung dasteht.

Ebenfalls Abschied nehmen heißt es in RHEL 9 vom altehrwürdigen iptables. Hier hat der Admin aber noch etwas mehr Zeit, denn iptables liegt RHEL 9 noch bei, ist aber – wie Network Scripts in RHEL 8 – als veraltet gebrandmarkt. Spätestens in der nächsten Version von RHE dürfte iptables also nicht mehr enthalten sein.

Zur Erinnerung: iptables ist ein Kommandozeilenwerkzeug, um den Paketfilter netfilter in Linux zu konfigurieren. Die Begriffe finden regelmäßig zwar synonym Verwendung, sind dies de facto aber nicht. iptables gilt unter Linux seit zwei Jahrzehnten als Standardwerkzeug für das Bearbeiten der Paketfilterregeln. Es stammt allerdings aus einer Zeit, in der von 400-GBit/s-Netzwerkschnittstellen noch niemand auch nur zu träumen wagte, und ist mithin auf kleinere Workloads ausgelegt. Immer häufiger kam es in den vergangenen Jahren deshalb zu Performanceengpässen, die auf iptables zurückzuführen waren. Ein Nachfolger steht in Form von nftables schon seit Jahren in den Startlöchern, und gerät nun endlich bei RHEL 9 zum Standard.

Wie Network Scripts hat nftables dabei eigentlich einen Modus, der das Regelwerk von iptables interpretieren und in eigene Regeln übersetzen kann. Und exakt wie bei Network Scripts kommt auch dieser Kompatibilitätsmodus manchmal ins Straucheln, wenn das Regelwerk allzu komplex wird. Hier stehen also Tests auf dem Plan, bevor ein finales Update stattfinden kann. Aus Admin-Sicht lohnt es sich aber, mit dieser Migration bereits zu beginnen, denn nftables bringt gerade in Sachen Performance viele Vorteile mit.

Die gute alte Modellpflege darf bei einer neuen Version eines Enterprise-Systems nicht fehlen, und RHEL 9 bildet von dieser Regel keine Ausnahme. Was aber auffällt: Viele Komponenten machen von RHEL 8 kommend zwar einen Versionssprung, doch fällt der vielerorts ziemlich kurz aus. Eine Menge Software, die in RHEL 9 bei dessen offizieller Vorstellung als "neu" angepriesen wurde, war realiter bereits ziemlich alt. Ein paar Beispiele machen das deutlich: Go 1.6.16, Rust 1.54 sowie Python 3.10 und Ruby 3 waren zum Zeitpunkt der RHEL-9-Release alle schon nicht mehr ganz frisch. Ähnliches gilt für andere Software: MariaDB liegt nur in der Version 10.5 vor, obwohl die deutlich aktuellere Version 10.8 verfügbar gewesen wäre. Bei PostgreSQL muss sich der Nutzer mit der Version 14 begnügen, obwohl auch die Version 15 bereits veröffentlicht war. Und wer Redis nutzt, klebt an Redis 6.2 fest statt an der deutlich aufgemöbelten Version 7. Das Phänomen zieht sich durch die gesamte Distribution wie ein roter Faden: Überall bekommt es der Admin mit Software zu tun, die zumindest das Prädikat "gut abgehangen" verdient.

Immerhin hat Red Hat ja über das bereits beschriebene Container-System angekündigt, verschiedene Programme aktualisieren zu wollen. Ob seitens des Anbieters für zentrale Komponenten demnächst also weitere Updates kommen, was für RHEL atypisch wäre, bleibt abzuwarten. Denkbar ist auch, dass Red Hat bereits davon ausgeht, Updates für diese Komponenten spielten Admins künftig direkt von den Herstellern ein. So oder so: Zumindest das offizielle Release von RHEL 9 ist keine Zierde hinsichtlich der Aktualität seiner Komponenten.

Deutlich besser gefallen da schon die Änderungen, die Red Hat in Sachen Sicherheit vollzieht. Nach Jahrzehnten des nachträglichen Editierens ist in der Konfiguration des SSH-Daemons in RHEL 9 endlich der direkte Login als Root deaktiviert. Wer als Root auf seinem System hantieren möchte, loggt sich also als normaler Benutzer und idealerweise mittels SSH-Schlüssel ein und holt sich danach mit "sudo" die nötigen Berechtigungen.

Veränderungen ergeben sich zudem bei SELinux: Das lässt sich künftig nicht mehr so leicht wie bisher durch "disabled" in "/etc/selinux/config" deaktivieren, sondern nur noch über den Kernelparameter "selinux=0" beim Booten. Wer per Automation das "disabled" in "/etc/selinux/config" hinterlegt, sollte diesen Boot-Parameter zu seiner Bootloader-Konfiguration unbedingt hinzufügen. Denn andernfalls wird SELinux vom Kernel zwar noch geladen, aber ohne aktive Policy. Und das sorgt für manch sehr eigenartigen Effekt beim versuchten Zugriff auf Dateien.

Nicht gegeizt haben die Entwickler in Sachen Aktualität bei OpenSSL, denn das kommt in der aktuellen Version 3 daher. Wie üblich markiert diese etliche alte und heute als unsicher geltende Algorithmen als "veraltet" und entfernt solche, die in vorherigen OpenSSL-Versionen bereits als veraltet gekennzeichnet waren. Im Regelfall kommen derartige Algorithmen ohnehin nirgendwo zum Einsatz. Doch schadet es vor dem Update auch nicht, das eigene System auf etwaige Algorithmen bei SSL zu untersuchen, bevor das Update anläuft. Denn andernfalls kommen möglicherweise die den Algorithmus benutzenden Dienste nicht mehr hoch.

Obendrein aufgerüstet hat Red Hat in Sachen Sicherheit bei der Virtualisierung. Hier gilt für klassische Voll- oder Paravirtualisierung weiterhin KVM als Mittel der Wahl, das nun aber in einer mit CLANG kompilierten Form beiliegt. CLANG unterstützt eine Reihe von Sicherheitsfeatures namens SafeStack, die KVM künftig noch besser dazu in die Lage versetzen, strikt zwischen Host- und Gastsystem zu trennen.

Bei einem abschließenden Blick auf die Darreichungsformen von RHEL 9 fällt ein Faktor schnell auf: Die Distribution kommt zwar als klassische ISO-Datei für die Installation auf Servern oder Desktops daher, doch ist das ganz offenkundig nicht der einzige Einsatzzweck, der Red Hat vorschwebt. Denn komplementär dazu finden sich fertige Abbilder für den Betrieb in KVM, kuratierte Images sowohl für AWS als auch Azure und von Red Hat offiziell genehmigte Container-Abbilder.

Die Nachricht ist deutlich: RHEL 9 soll eine Plattform für alle Zielanwendungen sein, ganz gleich ob ganz klassisch im Rechenzentrum, in der Cloud oder in Edge-Setups. Gerade für jene bietet Red Hat nicht versehentlich weitere Werkzeuge an, etwa um große Flotten von IoT-Geräten zu administrieren. Geht es nach dem Willen des Distributors, sollen Firmen RHEL 9 als technische Grundlage für sämtliche Entwicklungen nutzen und gar nicht erst auf die Idee kommen, bei der Konkurrenz zu schauen. Ob das klappt wie erhofft, wird sich aber erst noch herausstellen müssen. Denn ähnliche Bestrebungen finden sich auch bei SUSE und bei Canonical. Das Buhlen der großen Linux-Firmen endet also keineswegs, es verlagert sich aber zunehmend auf andere Plattformen und ebenfalls auf andere Darreichungsformen.

In Summe präsentiert RHEL 9 sich als solides Update mit wenigen Überraschungen im Gepäck. Es ist erkennbar, dass Red Hat die Distribution für eine Zeit vorbereitet, in der das Abspielen von Container-Abbildern die Hauptaufgabe eines Systems sein wird. Im Augenblick aber lässt RHEL 9 sich weiterhin auch ganz klassisch betreiben, also auf Basis von RPM-Paketen. Wer RHEL 8 nutzt, dem verspricht Red Hat wie üblich ein nahtloses Update ohne Scherereien. Technisch spricht nichts dagegen, den Hersteller beim Wort zu nehmen und ein Update zeitnah in Angriff zu nehmen.