Die Linux-Gemeinschaft lässt sich grob in drei Lager unterteilen. Dabei nimmt ein Lager den Extremwert „stabil wie ein Fels“ mit z.B. Debian oldstable ein, während der andere Extremwert „bleeding edge“ durch Anhänger z. B. von Arch Linux besetzt wird. Das dritte Lager besetzt die Mitte, in der sich unzählige weitere Distributionen tummeln, die mehr zu dem einen oder dem anderen Extremwert hin tendieren.
Warum das so ist und welche Distribution einen, wie ich finde, ganz interessanten Mittelweg eingeschlagen hat, möchte ich in diesem Artikel beleuchten. Bierernst bin ich dabei allerdings nicht. Die ein oder andere Ausführung ist durchaus mit einem Augenzwinkern zu verstehen. ;-)
Stabil wie ein Fels
So soll eine Linux-Distribution aus Sicht vieler Systemadministratoren sein. Gut getestet, alle Komponenten perfekt aufeinander abgestimmt und über ihren Lebenszyklus nur wenigen — am besten gar keinen — Änderungen unterworfen. Einzig Sicherheitsaktualisierungen dürfen und sollen zeitnah geliefert werden.
Distributionen, die sich diesem Paradigma unterwerfen, versprechen geringe Wartungsaufwände und sind des Sysadmins Freund. In meinen Augen dürfen Debian, RHEL, SLES, etc. dieser Kategorie zugeordnet werden.
Doch bergen diese Distributionen paradigmenbedingt auch einige Nachteile. Da Kernel und Bibliotheken meist schon etwas älter sind — manche sagen dazu steinalt, andere gut abgehangen — wird neue Hardware evtl. nicht in vollem Umfang unterstützt. Oder die mitgelieferten Bibliotheken und Laufzeitumgebungen sind schlicht zu alt, um mit aktuellen Versionen verfügbarer Software noch kompatibel zu sein.
Um den Nachteilen zu begegnen, bleibt Sysadmins häufig nichts anderes übrig, als das wohlige Heim der Distribution zu verlassen und Laufzeitumgebungen aus Upstream- oder Drittanbieter-Repos zu installieren, Software selbst zu übersetzen oder sich Container in die heilige Halle zu stellen. Die Distributionen versuchen dem zu begegnen, in dem sie unter Umständen zu Minor-Releases neuere Software-Versionen als sogenannte Rebases oder Backports nachliefern. Das dies passiert ist jedoch keineswegs garantiert und stellt im Zweifel ein Risiko für die Stabilität dar.
Wenn die Distribution dann aber doch eine neue Softwareversion ausliefert, hat der Sysadmin meist keine Wahl. Entweder er bleibt auf der alten Version und erhält voraussichtlich keinerlei Sicherheitsupdates mehr für diese oder installiert die aktuelle Version und lernt die Neuerungen lieben bzw. damit zu leben.
Bleeding Edge
Mit diesem Beinamen werden häufig Distributionen bezeichnet, welche dem Rolling-Release-Modell folgen und Software mitliefern, die sehr nah am aktuellen Stand der Upstream-Entwicklung ist (the latest and greatest). In dieser Ecke findet man z. B. Distributionen wie Arch Linux, Manjaro, Fedora Rawhide, etc. wobei diese Liste keinen Anspruch auf Vollständigkeit erhebt.
Der Betrieb dieser Distributionen ist geprägt von häufigen Updates. Die stetige Weiterentwicklung birgt das Risiko, dass auch mal etwas kaputt geht und plötzlich nicht mehr funktioniert. Doch versprechen die Distributionen meist, dass gerade durch den schnellen Entwicklungszyklus gefundene Fehler auch schnell behoben werden. Wohingegen die Nutzer stabiler Version häufig Monate, wenn nicht Jahre oder gar vergebens auf einen Bugfix warten müssen.
Blöd wird es, wenn man Software betreiben muss, die nur für eine bestimmte Version einer Laufzeitumgebung, oder bestimmter Bibliotheken freigegeben ist und unterstützt wird. Wer solche Software betreibt, sollte sich jedoch von vornherein fragen, ob er bei rollenden Releases richtig aufgehoben ist.
Dann sind da auch noch jene unter uns, die für den Betrieb auf gewisse Zertifizierungen ihrer Betriebssysteme angewiesen sind. Hier sind die Zertifizierungsverfahren häufig länger, als die Lebensspanne eines Bleeding-Edge-Release.
Das Mittelfeld
Dieses Feld ist weitgespannt. Hier tummeln sich Distributionen wie Fedora, Ubuntu sowie viele weitere. Ihnen allen unterstelle ich, dass sie den besten Kompromiss suchen, um so stabil wie möglich und so aktuell wie nötig zu sein.
So habe auch ich in der Vergangenheit auf Ubuntu LTS gesetzt, da ich es für den besten Kompromiss hielt. Leider waren unsere Entwickler mit den mitgelieferten Software-Versionen nicht lange zufrieden und ließen sich nicht bis zum nächsten Release hinhalten. Also wurden auch hier wieder {Dritanbieter,Upstream}-Repos eingebunden und die Software von dort installiert. Eine Erfahrung die ich bisher unter jeder Distribution machen durfte.
Genauso gut kenne ich den umgekehrten Fall, wo Paket XY auf gar keinen Fall aktualisiert werden darf, da sonst ein Dienst unrettbar kaputt geht. Lasst euch gesagt sein, man hat es schon nicht leicht in der Systemadministration. ;-)
Appstreams und Module
Mit RHEL 8 hat Red Hat eine interessante Neuerung eingeführt, die sog. Module im Appstream-Repository. Nun ein Listing sagt vermutlich mehr, als viele Sätze:
$ sudo dnf module list nginx php postgresql
Updating Subscription Management repositories.
Last metadata expiration check: 0:27:21 ago on Mi 21 Apr 2021 05:41:58 CEST.
Extra Packages for Enterprise Linux Modular 8 - x86_64
Name Stream Profiles Summary
nginx mainline common nginx webserver
Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)
Name Stream Profiles Summary
nginx 1.14 [d] common [d] nginx webserver
nginx 1.16 common [d] nginx webserver
nginx 1.18 common [d] nginx webserver
php 7.2 [d] common [d], devel, minimal PHP scripting language
php 7.3 common [d], devel, minimal PHP scripting language
php 7.4 common [d], devel, minimal PHP scripting language
postgresql 9.6 client, server [d] PostgreSQL server and client module
postgresql 10 [d] client, server [d] PostgreSQL server and client module
postgresql 12 client, server [d] PostgreSQL server and client module
Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalledWie ihr sehen könnt, hat man damit die Auswahl aus mehreren Versionen ein und der selben Anwendung. Das kannte ich so bisher noch nicht, ohne zusätzliche Repos einbinden zu müssen, oder mich gar mit den berüchtigten Red Hat Software Collections beschäftigen zu müssen.
Als Sysadmin habe ich damit etwas Flexibilität dazugewonnen. Ich kann z. B. eine Altlast mit NGINX 1.14, PHP 7.2 und PostgreSQL 9.6 auf einem Host und eine aktuelle Anwendung mit NGINX 1.18, PHP 7.4 und PostgreSQL 12 auf einem anderen Host betreiben, dabei aber das gleiche stabile Release RHEL 8 nutzen.
Allerdings kann man nicht zwei verschiedene Versionen von z. B. PHP oder PostgreSQL parallel auf dem gleichen Host betreiben. Wer dies wünscht, kann die entsprechenden Anwendungen lokal in Podman-Containern ausführen. Auch hier stehen Images für die verschiedenen Versionen bereit.
Red Hat verspricht, neue Versionen von Anwendungen, Sprachen und Werkzeugen auf diesem Weg verfügbar zu machen. So sind in der Beta des kommenden RHEL 8.4 zum Beispiel PostgreSQL 13, Python 3.9 und Podman 3.0.1 enthalten. Zu beachten ist jedoch, dass die jeweiligen Streams ihre eigenen Life-Cycles besitzen, die es im Auge zu behalten gilt. Hier hilft ein Blick in die offizielle Dokumentation weiter:
- Installing, managing, and removing user-space components
- Red Hat Enterprise Linux 8 Application Streams Life Cycle
Fazit
Ob diese Neuerung und die damit einhergehenden Vorteile in der Praxis von Relevanz sein werden, kann ich heute noch nicht sagen. Dafür fehlt mir noch etwas Erfahrung mit diesem neuen Konzept.
Ich persönlich glaube, dass sich Application Streams und das Konzept zur Verwendung von Containern nicht gegenseitig ausschließen, sondern sinnvoll ergänzen können. In meinen Augen gelingt es Red Hat mit Appstreams, seine stabile Distribution etwas in Richtung Aktualität zu schieben, ohne dabei Stabilität aufgeben zu müssen.