Linux-Distributionen zwischen Stabilität und Aktualität

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]nstalled

Wie 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:

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.

10 Gedanken zu „Linux-Distributionen zwischen Stabilität und Aktualität

  1. Dirk Deimeke

    Mir gefällt das Konzept als Idee auch sehr gut.

    Allerdings fehlen noch einige Appstream-Module, um komplett auf Fremdrepositories verzichten zu können. Module gibt es natürlich auch bei Fedora.

    Wie bereits vor einigen Monaten beschrieben, halte ich Container-Technologien für am besten geeignet, die Lücke zu schliessen.

    Wir werden vermutlich zwei „Lager“ bedienen müssen. Fremdapplikationen, die Zertifizierungen brauchen -> RHEL (und eventuell SLES). Eigene Apllikationen, die möglichst aktuelle Software auf einer stabilen Basis benötigen -> Containertechnologien auf schmalem OS -> CoreOS, Alpine mit Kubernetes oder OpenShift.

    Es wird auf lange Sicht nicht mehr „ein OS für alles“ geben.

    Antworten
  2. Jörg

    Ein Betriebssystem für alles klingt mir auch zu sehr nach „eierlegender Wollmilchsau“ und ist eher unrealistisch.

    Ich wünsche mir, dass Red Hat die Appstream-Module mit gleicher Priorität weiterverfolgt, wie sie gerade die Container-Werkzeuge vorantreiben. So habe ich Auswahl, muss aber nur einmal durch die Subskriptionshölle. 😀

    Antworten
    1. Dirk Deimeke

      Ja, sehr guter Punkt.

      Wir sind gerade dabei, Ubuntu als zweites Linux in unser Portfolio aufzunehmen. Der Preis mit dem höchsten Supportlevel ist super attraktiv und ich kann mir sehr gut vorstellen, dass wir für alles, was Zertifizierungen benötigt bei RHEL bleiben und bei allem anderen auf Ubuntu wechseln.

      Schauen wir einmal wie das angenommen wird.

      Antworten
      1. Jörg

        Was bedeutet das eigentlich genau? Kann man dann bei euch via Self-Service eine VM mit Ubuntu-Image provisionieren und ihr seid der Durchlauferhitzer für den Support, oder wie kann ich mir das vorstellen?

        Antworten
        1. Dirk Deimeke

          Ich verstehe die Frage nicht.

          Wir werden Ubuntu als zusätzliches OS anbieten, genauso, wie wir auch RHEL betreiben.

          Fragen gehen an uns und wenn wir nicht weiter wissen (was selten passiert), wird der Support eingeschaltet.

          Antworten
          1. Jörg

            Meine Frage geht in die Richtung, nach welchen Kriterien entschieden wird, ob RHEL oder Ubuntu ausgerollt wird.

            Ist das eine Frage des Geschmacks, oder nach dem Motto grundsätzlich Ubuntu und RHEL, wenn es um Zertifizierung geht?

            Die attraktiven Support-Konditionen hast du ja schon genannt. Aber das ist, wenn überhaupt, ja nur ein Kriterium.

  3. Dirk Deimeke

    Ah, verstehe.

    Das liegt bei den Applikationen und nicht bei uns. Sie entscheiden sich für die Plattform, auf der ihre selbst geschriebenen oder gekauften Anwendungen betrieben werden sollen. Wir bieten Solaris, OpenShift, RHEL und später Ubuntu. Sie könnten sich auch für Windows entscheiden.

    Antworten
      1. Dirk Deimeke

        Da fehlte natürlich noch – was auch in unseren Bereich fällt – dass sich die Applikationsteams auch für Docker/Podman auf einem Linuxsystem entscheiden können. (Docker auf RHEL 8 richten wir ein, supporten wir aber ohne Herstellerunterstützung).

        Antworten
  4. Pingback: Linkdump 18/2021 | Dirks Logbuch

Schreibe einen Kommentar zu Jörg Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.