© kritchanut, 123RF

Red Hat Enterprise Linux ist das Flaggschiff der roten Hüte aus Raleigh und die Basis für viele weitere Produkte der Firma. Wenn der Marktführer nun also die Version 8 testet, steht viel auf dem Spiel.

Der Autor dieses Artikels ist seit über 15 Jahren Debian-Entwickler und aus dieser Zeit einiges an Häme gewohnt: “Debian Stale” als Verballhornung des stabilen Debian-Zweigs “Stable” ist da eher noch eine höfliche Variante.

Schaut man sich allerdings die Intervalle an, die bei den Enterprise-Distributionen gang und gäbe sind, fällt auf: Debian gehört hier mittlerweile eher zu den flinken Distributionen. Einzig Canonical hält sich sklavisch an den Plan, alle zwei Jahre eine Version mit Long Term Support zu veröffentlichen, ansonsten sind eher fünf Jahre zum Standard geworden.

Nach über vier Jahren ist es bei den roten Hüten nun an der Zeit, eine neue Version des eigenen Flaggschiffs auf den Markt zu bringen: Red Hat Enterprise Linux 8, kurz RHEL 8, folgt der 2014 veröffentlichten Version 7 und soll viele alte Zöpfe abschneiden. “Volle Cloud voraus” lautet dabei das Motto – Grund genug, dem neuen Produkt im Vorserientest auf den Zahn zu fühlen.

Vorserientest bedeutet, dass zum Zeitpunkt des Schreibens dieses Artikels lediglich die öffentliche Betaversion von RHEL 8 verfügbar war, die naturgemäß noch Schnitzer hat. In diesem Text geht es vorrangig um die neuen Features, die RHEL 8 mitbringt – dass die finale Version die üblichen Red-Hat-Standards in Sachen Stabilität erfüllen wird, darf der zahlende Kunde annehmen.

Verschiedene Zielgruppen

Wenn Red Hat “tiefgreifende” Veränderungen verspricht, lohnt es sich, eben dieses Versprechen genauer zu betrachten. In den vergangenen vier Jahren ist technisch viel passiert, und viele neue Konzepte sind groß geworden, etwa Kubernetes. In RHEL 7 war Docker und mit ihm Support für die Containerplattform von Red Hat noch gar nicht zu bekommen, denn Docker selbst war nur eine Technology Preview. Es darf freilich als sicher gelten, dass viele Firmen Docker auf RHEL 7 trotzdem und vermutlich mit den Paketen von Docker selbst betrieben haben – nunmehr hat die Lösung aber auch einen offiziellen Sanktus von Red Hat. Hier macht die neue RHEL-Version also einen Sprung nach vorne.

Dass in RHEL 8 alles anders wird, war von vornherein eher unwahrscheinlich. Red Hat steht hier vor der undankbaren Aufgabe, zwei völlig verschiedene Welten unter einen Hut zu bringen – einerseits die angestammte Klientel, die in RHEL vorrangig ein Werkzeug sieht, um einen Server verlässlich mit einem Betriebssystem auszustatten. Hier spielen neue Funktionen kaum eine Rolle, Stabilität ist das höchste Gut. Admins solcher Systeme reagieren sehr allergisch, wenn Updates vorhandene Funktionen beeinträchtigen. Dieser Gruppe ist das alte Update-Mantra von Debian das liebste: Neue Pakete für ein Programm gibt es nur, um Sicherheitslücken oder kritische Funktionsprobleme zu beseitigen.

Die andere Gruppe von Kunden ist die Fraktion, die voll auf Automation und Cloud und Container und Virtualisierung setzt. Weil hier das Prinzip des “Immutable Underlay” wirkt, ist es nicht unbedingt nötig, jeden Host der Plattform stets in perfektem Zustand zu halten. Fällt ein System aus, übernimmt ein anderes die Aufgaben, später stellt der Admin das System per Automation wieder her. Neue Features bei der genutzten Management-Software (Open Shift, Open Stack oder Kubernetes) erhalten den Vorzug vor bedingungsloser Stabilität.

Viel steht auf dem Spiel

All jene Zielgruppen möchte Red Hat mit RHEL 8 irgendwie ansprechen, wobei das nur zum Teil direkt passiert. Denn für Kubernetes, Open Stack, Open Shift, Ceph und andere Produkte fährt der Hersteller eine alternative Strategie: Hier kommt RHEL die Aufgabe zu, ein Grundsystem zur Verfügung zu stellen, das im Anschluss um Pakete aus Zusatzverzeichnissen ergänzt wird. Das bedeutet im Umkehrschluss freilich auch: Stellt RHEL 8 sich nicht als das stabile System heraus, das alle erwarten, bekommen früher oder später auch die auf der neuen Version basierenden Add-ons Probleme.

Für Red Hat steht insofern sehr viel auf dem Spiel: Eigentlich muss schon der erste Schuss mit RHEL 8 sitzen, und zwar für beide zuvor beschriebenen Szenarien.

Fedora als Basis

Kritiker behaupten, Red Hat habe durch die Einführung von Fedora die Arbeit an der Hauptdistribution in die Community abgeschoben und picke sich für die eigene Enterprise-Distribution bloß noch die Rosinen heraus. Das stimmt so aber nicht. Zwar basiert Red Hat Enterprise Linux 8 tatsächlich wie üblich auf Fedora – in diesem Falle auf Fedora 28 aus dem vergangenen Sommer – doch ist es keinesfalls so, dass Red Hat zu Fedora nichts beisteuert.

Ganz im Gegenteil: Die meiste Arbeit, die an Fedora stattfindet, erledigen bis heute Leute von Red Hat. Über gelegentliche Community-Zulieferungen freut man sich zwar, das Gros der Arbeit übernimmt die Community aber definitiv nicht. Derweil freuen sich freilich die Fedora-Fans, dass wie ein Nebenprodukt der Arbeit an Red Hats Enterprise-System noch eine Desktop-Distribution abfällt, die viel regelmäßiger mit Updates versorgt wird als die Enterprise-Variante.

Von Fedora 28 erbt RHEL 8 alle relevanten Systemparameter. Die Grundlage des Systems bildet ein leidlich aktueller Kernel 4.18, der schon von den Linux- Entwicklern offiziell mit Long-Term-Support ausgestattet ist. Zum Zeitpunkt der Veröffentlichung von RHEL 8 wird der aber auch schon wieder einige Monate auf dem Buckel haben, Linux 5.0 dürfte dann schon lange bereitstehen.

Die Krux: RHEL 8 wird über seine gesamte Lebensdauer kein Major-Update eines neuen Kernels erhalten. Während Ubuntu die LTS-Kernel anbietet und die aktuelle LTS-Version mit Kerneln neueren Datums versieht, geht Red Hat einen anderen Weg und portiert viele Bugfixes und Treiber auf den alten Kernel.

Das führt nach einiger Zeit freilich zu einem echten Oldie, den eine bunte Mischung von Portierungen aufpeppt. Dem Admin ist’s häufig wurscht – wer Red Hat in der Enterprise-Variante kauft, bekommt ohnehin Support dazu und öffnet einfach ein Ticket, falls der Kernel nicht tut, wie er soll.

Vier Architekturen

Den besagten Kernel 4.18 kann der Admin in RHEL 8 auf vier Architekturen betreiben: Natürlich steht AMD 64 als Standard-Ansatz zur Verfügung. Hinzu gesellen sich die 64-Bit-Version von ARM sowie die Little-Endian-Variante von IBM Power und IBM Z. Für die Mehrzahl der Nutzer dürften allerdings ohnehin nur AMD 64 und vielleicht noch ARM 64 eine Rolle spielen – mit den beiden Ports für IBM-Architekturen bedient Red Hat ein eher kleines, aber hochspezialisiertes Kundensegment.

Auch ein Desktop

Was viele bei Enterprise-Distributionen gern vergessen: Eigentlich sind die Systeme sowohl für Desktops als auch für Server gedacht. Aber einerseits ist Linux auf dem Desktop ja ohnehin so ein Thema und andererseits ziehen die meisten Nutzer die typischen Desktop-Distributionen wie Fedora oder Open Suse den Enterprise-Versionen vor.

Trotzdem liefert RHEL 8 auch in Sachen Grafik: Teil des Pakets ist der Xorg-Ersatz Wayland samt Gnome 3.28, das auch Standarddesktop ist. Die Bindung von Red Hat und Gnome ist traditionell eng, sodass diese Entscheidung nicht weiter verwundert. Den klassischen X-Server nach Xorg-Bauart gibt es aber auch noch für jene Nutzer, die diese Variante der neuen Wayland-Option vorziehen.

Weil gerade das Thema Versionspflege auf der Tagesordnung steht: Auch sonst erbt RHEL 8 die meisten Versionsstände von der Desktop-Variante Fedora 28. Zum Paket gehören entsprechend Python 3.6, Maria DB 10.3, PostgreSQL 9.6 sowie 10, ein aktueller Apache und Nginx und auch darüber hinaus aktuelle Versionen der verschiedensten Tools. Wer nicht gerade auf der Suche nach einem bestimmten Feature ist, das erst nach Fedora 28 in ein Tool Einzug hielt, wird insofern keine Probleme bekommen.

Appstream für neue Versionen

Für RHEL 7 hätte der letzte Satz noch ein “zumindest am Anfang” enthalten müssen – und genau hier liegt ein zentraler Unterschied zwischen der alten und der neuen Version. Bisher hat der Hersteller die Programme in seinem System ähnlich behandelt wie seinen Kernel: Updates gab es nur in homöopathischen Dosen und sicher nicht für neue Programmversionen oder neue Features.

In RHEL 8 soll sich das fundamental ändern. Dafür hat der Hersteller gar seinen Paketmanager ordentlich umgebaut – was an und für sich schon einen eher seltenen Vorgang darstellt. Der Red Hat Package Manager (RPM) beherrscht in der aktuellen Version den Umgang mit Appstream-Metadaten.

Wichtig: Der Begriff Appstream geistert in der IT-Welt aktuell mindestens doppelt durch die Gegend: einerseits als Produkt von Amazon für AWS und andererseits als der Name für einen Standard zum Festlegen von Paketmetadaten. Der Appstream-Support in RPM bezieht sich offensichtlich auf letztere Technik: Es geht schlichtweg darum, aus einem zentralen Repository dynamisch Software zu beziehen. Wo früher RPM, Dpkg und die diversen anderen Werkzeuge ihre eigenen Metadaten nutzten, entsteht jetzt stattdessen ein zentrales Repository, das generische Metadaten enthält. Mit welchen Inhalten die Hersteller diese Datenstrukturen dann füllen, bleibt ihnen überlassen – genauso wie auch die Art und Weise, wie sie ihre Pakete dann konkret umsetzen.

Am Ende geht es genau um das Folgende: Der Appstream-Standard ermöglicht es, etwa auch eine in einem Docker-Container verpackte Applikation so zu behandeln, wie ein ganz normales Paket – und zwar aus der normalen Paketverwaltung auf dem lokalen System heraus.

Der Clou an der Sache ist: Es lassen sich auch mehrere Versionen desselben Pakets gleichzeitig auf einem System installieren – eben dafür waren die RPM-Anpassungen notwendig, denn alle heutzutage gängigen Paketmanager arbeiten bisher strikt nach dem Prinzip, dass von jedem Paket immer nur eine einzige Version installiert sein darf.

Nur zwei Repositories

In RHEL 8 sorgt die Einführung von Appstream dafür, dass für die diversen Paket-Werkzeuge bloß noch zwei Repositories auf dem System aktiviert sein müssen: Das Base-OS-Repository, das wie bisher alle Kernkomponenten des Betriebssystems enthält und denselben strikten Regeln unterworfen ist, wie es bei RHEL auch bisher schon der Fall war (Abbildung 1).

Abbildung 1: Nur noch zwei Repositories sind in RHEL 8 standardmäßig aktiv – Base OS enthält das Grundsystem, Appstream die meisten Applikationen.

Hinzu gesellt sich jetzt das Appstream-Repository, das die absolute Mehrzahl der Applikationen enthält, die meist im Userspace laufen (Abbildung 2). Und weil das Appstream-Verzeichnis auch verschiedene Versionen einer Software enthalten kann, hat der Admin bei der Installation die Wahl, welches Werkzeug er nutzen möchte.

Abbildung 2: Wayland ist der Standard-X11-Server in RHEL 8. Wer lieber Xorg will, findet ihn aber auch.

Der Lifecycle einer Appstream-Applikation ist vom Lifestream des Base OS komplett entkoppelt. Das Grundsystem funktioniert also wie bisher und dem Einspielen neuer Applikationen über den Appstream-Mechanismus steht nichts im Wege. Und weil Appstream nur eine Angabe zu den Metadaten der Software macht, aber nicht zu der Form, in der jene vorliegen müssen, sind hier Container durchaus denkbar.

In der Hauptsache schickt sich das Appstream-Format also an, eine Art Distributions-übergreifender Paketmanager für in Container verpackte Applikationen zu werden – was zwar zu weniger Diversität führen würde, technisch aber den Vorteil hätte, dass Docker-Container einigermaßen universell einsetzbar sind.

Neues Yum

Einiges getan hat sich auch bei Yum. Das basiert in RHEL 8 jetzt auf DNF und damit auf einem komplett neuen Framework, das Red Hat speziell um RPM herum gebaut hat. Im Test hat das gar nicht zu großen Effekten geführt, laut Hersteller ist Yum jetzt aber robuster und vor allem schneller als in der vorherigen Variante. Wobei die Performance eines Werkzeugs wie Yum freilich auch von der Hardware abhängt, die vor Ort zur Verfügung steht (Abbildung 3).

Abbildung 3: Weiterhin lässt sich der Befehl »yum« zwar aufrufen, doch es handelt sich nur um einen Link auf DNF.

Einen Vorteil hat DNF gegenüber Yum jedenfalls: Es bietet eine definierte und standardisierte API-Schnittstelle, falls andere Komponenten mal auf seine Funktionalität zurückgreifen wollen. Bei Yum blieb zuvor nur der Ausweg über die Kommandozeile und das Aufrufen des Yum-Kommandos – was freilich alle unschönen Nachteile impliziert, die Shell-Aufrufe aus Skripten und Programmen heraus mit sich bringen.

Viel Neues beim Netzwerk

Wer auf Basis von RHEL bisher eine Firewall betreibt, muss sich auf diverse Veränderungen einstellen. Die größte betrifft den Packet Filter: Offiziell ist in RHEL 8 NFtables der Nachfolger von IPtables, das Red Hat in Rente schickt. Wer es von dort zurückbeordern möchte, findet die Tools und auch die Kernelmodule natürlich weiterhin im System. Der Admin tut aber gut daran, sich diesen Schritt gut zu überlegen – denn Red Hat ersetzt das in die Jahre gekommene IPtables ja nicht aus Versehen.

Zur Erinnerung: NFtables ist ein Nachfolger von »iptables«, der zum größten Teil auf die Initiative von Red Hat zurückgeht. Er löst das Problem, dass »iptables« im Kernel de facto am Ende ist. Immerhin ist das Werkzeug jetzt 20 Jahre alt. 1998 ersetzte es das unbeliebte IPchains, das seinerseits gar nicht so lange zuvor IPFW abgelöst hatte.

Für die Anforderungen der folgenden Jahre war IPtables gut. Doch für die Anforderungen der Gegenwart mit Netzwerkkarten, die 200 GBit/s und mehr schaffen, ist die Architektur von IPtables im Kernel ungeeignet. Längst haben sich die Kernel-Entwickler mit allerlei schmutzigen Tricks beholfen, um auch noch das letzte Quäntchen Performance aus IPtables zu pressen. In Cloud-Setups ist nicht mehr selten IPtables die Komponente, die den Durchsatz limitiert.

NFtables ist der Ansatz der Kernel-Entwickler, das Problem zu lösen. Das Linux-Magazin ist auf NFtables bereits ausführlich eingegangen [1] und hat dabei auch einen der größten Vorteile der Lösung erwähnt: Nicht länger hat es der Admin mit verschiedenen Userspace-Programmen zu tun (»iptables«, »ip6tables«, »ebtables« und noch viele andere). NFtables bietet alle Funktionalität unter einer einheitlichen Oberfläche.

Und die Integration in »firewalld« liefert der Hersteller auch gleich mit – wer bisher also seine Firewalls per »firewalld« konfiguriert hat, sollte sich gar nicht groß umgewöhnen müssen. Da bleibt eigentlich nur die spannende Frage übrig, ob NFtables – dessen Inkompatibilität zu IPtables lange als größte Schwachstelle galt – nun länger aktuell bleibt oder ob es in näherer Zukunft vom Berkeley Packet Filter (BPF) abgelöst wird, den das Linux-Magazin ebenfalls bereits ausführlich vorgestellt hat [2].

Übrigens: Die berühmt-berüchtigten Network-Skripte, die in RHEL 7 noch in »/etc/sysconfig/networking« zu finden sind, gibt es bei RHEL 8 so nicht mehr. Dafür kümmert sich jetzt ausschließlich der Networkmanager um die Konfiguration der Schnittstellen.

In RHEL 8 gehört die Software Cockpit zum Standardlieferumfang: Cockpit ist eine Alternative zu Webmin und ermöglicht den Zugriff auf die wichtigsten Teile der Systemkonfiguration per Browser. Es ist also ein Administrations-GUI, das Red Hat selbst in weiten Teilen entwickelt hat. Auf Wunsch lässt sich die Komponente aber freilich auch abstellen, eine Pflicht zu ihrer Nutzung besteht also nicht (Abbildungen 4 und 5).

Abbildung 4: Offiziell ist Cockpit ein eigenständiges Produkt, Red Hat leistet aber die meiste Arbeit.

Abbildung 5: Cockpit ist ein Webinterface ähnlich Webmin, das RHEL 8 ab Werk ausliefert – wer es aber nicht will, muss es auch nicht nutzen.

Aufgebohrtes KVM und Docker im Visier

Die RHEL 8 beiliegende Qemu-KVM-Version 2.12 bringt Support für diverse, im High Performance Computing gern genutzte Erweiterungen. Der Q35-Maschinentyp, der die PCIe-Features neuerer Intel-Chipsätze effektiv nutzt (ICH9 und neuer), gehört ebenso zum Lieferumfang wie bessere Unterstützung für die GPUs von Nvidia.

Ceph kann nun auf allen CPU-Architekturen, die RHEL 8 unterstützt, als Storage für KVM-VMs zum Einsatz kommen. Virtuelle CPUs (V-CPU) lassen sich nun aktivieren und entfernen, ohne die jeweilige VM anzuhalten. Und wer UEFI innerhalb einer VM nutzen möchte, findet in Qemu-KVM nun ein entsprechendes UEFI-Bios, das dies ermöglicht.

Red Hat will das Thema Container nicht nur im Kontext von Open Shift & Co. behandeln, sondern lässt keinen Zweifel daran, dass Container ein integraler Bestandteil von RHEL 8 sein sollen. Die Art, wie das technisch umgesetzt ist, dürfte allerdings zum Stirnrunzeln besonders bei den Docker-Leuten führen.

Klar, deren Verdienste um Container unter Linux sind unbestritten – bis zu einem gewissen Grad hat die Firma das Thema aus dem Reich der Toten zurück ins Diesseits geholt. Das hat aber auch dazu geführt, dass “Container unter Linux” und “Docker” bisweilen synonym genutzt werden – und eben das ist Red Hat ein Dorn im Auge. Denn einerseits nutzen de facto alle Container-Implementierungen für Linux dieselben Kernel-Features, zum Beispiel Namespaces und Cgroups. Und an deren Entwicklung ist Red Hat natürlich beteiligt.

Andererseits kann Red Hat kein Interesse daran haben, dass Docker als einzelne Firma den Container-Markt unter Linux dominiert. Flugs machte man sich in Raleigh deshalb daran, ein eigenes Containerformat zu entwickeln und es pflichtschuldigst unter eine offene Lizenz zu stellen, die Open Container Infrastructure (OCI).

Mit RHEL 8 drückt Red Hat nun eben dieses Format mit Macht in den Markt und liefert gleich auch die Werkzeuge dazu, die – ganz im Stil von Docker – das Verwalten von Containern, das Bauen von Container-Registries und auch das Bauen von Containern selbst ermöglicht.

Drei Werkzeuge

Dazu liefert der Distributor drei Werkzeuge aus: Buildah, Skopeo und Podman. Buildah bildet – nomen est omen – die Funktionalität nach, die Admins aus Dockerfiles vielleicht schon kennen. Eine Datei namens Dockerfile mit den für den Bau eines Containers nötigen Arbeitsschritten ist ja bekanntlich alles, was der Admin für diesen Vorgang benötigt. Und Buildah ahmt diese Funktionalität nach, hier allerdings für Container im OCI-Format.

Skopeo ist so etwas wie ein Umschlagplatz für Container: Das Werkzeug hilft dabei, Container-Images zu finden, und kann dabei ganz verschiedene Quellen anzapfen. Unterstützt werden neben echten Docker-Registries auch andere OCI-Registries und darüber hinaus sogar auch noch lokale Verzeichnisse mit Abbildungen.

Podman schließlich ist ein Kommandozeilen-Werkzeug, mit dem Container sich im lokalen System steuern lassen, und zwar ohne einen Kontroll-Daemon zu benötigen, wie es bei Docker der Fall ist. Das nimmt einerseits eine angreifbare Komponente aus der Gleichung und sorgt andererseits für weniger Administrationsaufwand.

Wer sich die Architektur der Container-Implementierung in RHEL 8 anschaut, kommt schnell dahinter, dass es hier eigentlich keine Notwendigkeit mehr dafür gibt, sich überhaupt noch mit Docker zu beschäftigen. Zwar hat Docker selbst schon 2017 in einem Blogeintrag [3] darauf verwiesen, dass es OCI gelassen sehe – weil man selbst auch einer der größten Beitragenden sei. Obendrein, so Docker weiter, sei OCI ja nur ein Containerformat, während Docker eine komplette Werkzeugsammlung für das Erstellen und Verwalten von Containern bereitstelle.

Genau diesen Einwand hat Red Hat in RHEL 8 nun aber schlagend widerlegt – und diesen Schachzug darf man durchaus als einen frontalen Angriff auf Docker deuten. Hinzu kommt, dass RHEL 8 für die meisten Kunden, die gegenwärtig RHEL 7 nutzen, als Nachfolger gesetzt sein dürfte, sodass die beschriebenen Komponenten als integrale Bestandteile des Systems sich früher oder später ganz von alleine auf einer riesigen Menge an Systemen wiederfinden werden. Es dürfte also recht interessant sein, in Zukunft Dockers Reaktion auf diesen kritischen Umstand zu beobachten.

Storage-Manager Stratis

Eine wichtige Neuerung in RHEL 8 darf nicht unerwähnt bleiben: Ab Werk hat das System jetzt Stratis mit an Bord, einen Storage-Manager für Volumes und verschlüsselte Volumes. Stratis kann bestehende Dateisysteme verwalten, aber auch neue Dateisysteme erstellen; ebenso kann es verschiedene Komponenten des Blockdevice-Layer im Linux-Kernel – etwa LVM – kombinieren, um Effekte wie Verschlüsselung oder verbessertes Caching zu erreichen. Auch das Pooling von Geräten ist via LVM möglich.

Als Standard-Dateisystem nutzt Stratis XFS, was ja durchaus bemerkenswert ist: Btr-FS sollte doch längst in einem Zustand sein, in dem es das Standard-Dateisystem für RHEL 8 sein könnte. Alternativ ist auch ZFS denkbar, aber dessen Lizenzbedingungen machen den Einsatz in RHEL 8 unmöglich. So behilft sich Red Hat, indem es das äußerst robuste XFS mit verschiedenen Techniken kombiniert. Im Test funktionierte das auch ganz gut.

Installation: Einfach und gut wie immer

Noch keine Erwähnung fand in diesem Text bisher der Installer von RHEL 8, was keineswegs an dessen mangelnder Qualität liegt. In der Tat unterscheidet sich der Installer von RHEL 8 kaum von der Vorgängerversion. Wer also ein einzelnes RHEL-System aufsetzen möchte, kommt schnell und problemlos ans Ziel. Aber weil RHEL 8 auch die perfekte Plattform für Cloud Computing sein möchte, stehen wie bisher auch Kickstart und Anaconda bereit, die zusammen die automatische RHEL-Installation ermöglichen.

Wer etwa Red Hats Open-Stack-Plattform nutzt, kann aus den dortigen Werkzeugen heraus RHEL 8 direkt auf den Zielsystemen ausrollen, ohne den Installer auch nur zu Gesicht zu bekommen. Hier ändert sich im Grunde also nur die Version, die gut funktionierenden Features bleiben allesamt erhalten.

Fazit

Red Hat gelingt bei RHEL 8 der Spagat zwischen einem grundsoliden System auf der einen Seite und einer flexiblen Distribution auf der anderen, die auch aktuelle Trends aufgreift. Die Unterstützung von Appstream ist hier ausgesprochen nützlich, das Appstream-Repository, in dem Red Hat eine Vielzahl von Programmen (künftig auch in aktuellen Versionen) anbietet, tut ein Übriges. Dass man durch die RHEL-Installation in Zukunft nicht mehr genötigt ist, ein Software-Museum zu betreiben, ist die eigentliche Neuerung bei dieser neuen Version.

Auch der Container-Support macht Spaß: Das konsequente Setzen auf offene Standards (OCI) und das Management-Framework, das Red Hat für Container liefert, stellen eine sinnvolle Alternative zu Docker dar und graben damit dem Container-Platzhirsch unter Linux ein Stück weit das Wasser ab.

Darüber hinaus präsentiert die Distribution sich bodenständig: Updates wie der Umstieg auf NFtables entfalten im Alltag positive Effekte, auch wenn sie eher unscheinbar daherkommen. In Summe darf RHEL 8 als gelungen gelten – und als stabile Grundlage für Red-Hat-Produkte in den kommenden Jahren.