{"id":2808,"date":"2021-05-03T07:00:00","date_gmt":"2021-05-03T05:00:00","guid":{"rendered":"https:\/\/www.my-it-brain.de\/wordpress\/?p=2808"},"modified":"2021-10-03T19:59:45","modified_gmt":"2021-10-03T17:59:45","slug":"linux-distributionen-zwischen-stabilitaet-und-aktualitaet","status":"publish","type":"post","link":"https:\/\/www.my-it-brain.de\/wordpress\/linux-distributionen-zwischen-stabilitaet-und-aktualitaet\/","title":{"rendered":"Linux-Distributionen zwischen Stabilit\u00e4t und Aktualit\u00e4t"},"content":{"rendered":"\n

Die Linux-Gemeinschaft l\u00e4sst sich grob in drei Lager unterteilen. Dabei nimmt ein Lager den Extremwert „stabil wie ein Fels“ mit z.B. Debian<\/a> oldstable ein, w\u00e4hrend der andere Extremwert „bleeding edge“ durch Anh\u00e4nger z. B. von Arch Linux<\/a> besetzt wird. Das dritte Lager besetzt die Mitte, in der sich unz\u00e4hlige weitere Distributionen tummeln, die mehr zu dem einen oder dem anderen Extremwert hin tendieren.<\/p>\n\n\n\n

Warum das so ist und welche Distribution einen, wie ich finde, ganz interessanten Mittelweg eingeschlagen hat, m\u00f6chte ich in diesem Artikel beleuchten. Bierernst bin ich dabei allerdings nicht. Die ein oder andere Ausf\u00fchrung ist durchaus mit einem Augenzwinkern zu verstehen. ;-)<\/p>\n\n\n\n

Stabil wie ein Fels<\/h2>\n\n\n\n

So soll eine Linux-Distribution aus Sicht vieler Systemadministratoren sein. Gut getestet, alle Komponenten perfekt aufeinander abgestimmt und \u00fcber ihren Lebenszyklus nur wenigen — am besten gar keinen — \u00c4nderungen unterworfen. Einzig Sicherheitsaktualisierungen d\u00fcrfen und sollen zeitnah geliefert werden.<\/p>\n\n\n\n

Distributionen, die sich diesem Paradigma unterwerfen, versprechen geringe Wartungsaufw\u00e4nde und sind des Sysadmins Freund. In meinen Augen d\u00fcrfen Debian<\/a>, RHEL<\/a>, SLES<\/a>, etc. dieser Kategorie zugeordnet werden.<\/p>\n\n\n\n

Doch bergen diese Distributionen paradigmenbedingt auch einige Nachteile. Da Kernel und Bibliotheken meist schon etwas \u00e4lter sind — manche sagen dazu steinalt, andere gut abgehangen — wird neue Hardware evtl. nicht in vollem Umfang unterst\u00fctzt. Oder die mitgelieferten Bibliotheken und Laufzeitumgebungen sind schlicht zu alt, um mit aktuellen Versionen verf\u00fcgbarer Software noch kompatibel zu sein.<\/p>\n\n\n\n

Um den Nachteilen zu begegnen, bleibt Sysadmins h\u00e4ufig nichts anderes \u00fcbrig, als das wohlige Heim der Distribution zu verlassen und Laufzeitumgebungen aus Upstream- oder Drittanbieter-Repos zu installieren, Software selbst zu \u00fcbersetzen oder sich Container in die heilige Halle zu stellen. Die Distributionen versuchen dem zu begegnen, in dem sie unter Umst\u00e4nden 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\u00fcr die Stabilit\u00e4t dar.<\/p>\n\n\n\n

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\u00e4lt voraussichtlich keinerlei Sicherheitsupdates mehr f\u00fcr diese oder installiert die aktuelle Version und lernt die Neuerungen lieben bzw. damit zu leben.<\/p>\n\n\n\n

Bleeding Edge<\/h2>\n\n\n\n

Mit diesem Beinamen werden h\u00e4ufig Distributionen bezeichnet, welche dem Rolling-Release-Modell<\/a> 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<\/a>, Manjaro<\/a>, Fedora Rawhide<\/a>, etc. wobei diese Liste keinen Anspruch auf Vollst\u00e4ndigkeit erhebt.<\/p>\n\n\n\n

Der Betrieb dieser Distributionen ist gepr\u00e4gt von h\u00e4ufigen Updates. Die stetige Weiterentwicklung birgt das Risiko, dass auch mal etwas kaputt geht und pl\u00f6tzlich 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\u00e4ufig Monate, wenn nicht Jahre oder gar vergebens auf einen Bugfix warten m\u00fcssen.<\/p>\n\n\n\n

Bl\u00f6d wird es, wenn man Software betreiben muss, die nur f\u00fcr eine bestimmte Version einer Laufzeitumgebung, oder bestimmter Bibliotheken freigegeben ist und unterst\u00fctzt wird. Wer solche Software betreibt, sollte sich jedoch von vornherein fragen, ob er bei rollenden Releases richtig aufgehoben ist.<\/p>\n\n\n\n

Dann sind da auch noch jene unter uns, die f\u00fcr den Betrieb auf gewisse Zertifizierungen ihrer Betriebssysteme angewiesen sind. Hier sind die Zertifizierungsverfahren h\u00e4ufig l\u00e4nger, als die Lebensspanne eines Bleeding-Edge-Release.<\/p>\n\n\n\n

Das Mittelfeld<\/h2>\n\n\n\n

Dieses Feld ist weitgespannt. Hier tummeln sich Distributionen wie Fedora<\/a>, Ubuntu<\/a> sowie viele weitere. Ihnen allen unterstelle ich, dass sie den besten Kompromiss suchen, um so stabil wie m\u00f6glich und so aktuell wie n\u00f6tig zu sein.<\/p>\n\n\n\n

So habe auch ich in der Vergangenheit auf Ubuntu LTS gesetzt, da ich es f\u00fcr den besten Kompromiss hielt. Leider waren unsere Entwickler mit den mitgelieferten Software-Versionen nicht lange zufrieden und lie\u00dfen sich nicht bis zum n\u00e4chsten 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.<\/p>\n\n\n\n

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. ;-)<\/p>\n\n\n\n

Appstreams und Module<\/h2>\n\n\n\n

Mit RHEL 8 hat Red Hat eine interessante Neuerung eingef\u00fchrt, die sog. Module im Appstream-Repository. Nun ein Listing sagt vermutlich mehr, als viele S\u00e4tze:<\/p>\n\n\n\n

$ sudo dnf module list nginx php postgresql\nUpdating Subscription Management repositories.\nLast metadata expiration check: 0:27:21 ago on Mi 21 Apr 2021 05:41:58 CEST.\nExtra Packages for Enterprise Linux Modular 8 - x86_64\nName            Stream        Profiles                        Summary                                 \nnginx           mainline      common                          nginx webserver                         \n\nRed Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)\nName            Stream        Profiles                        Summary                                 \nnginx           1.14 [d]      common [d]                      nginx webserver                         \nnginx           1.16          common [d]                      nginx webserver                         \nnginx           1.18          common [d]                      nginx webserver                         \nphp             7.2 [d]       common [d], devel, minimal      PHP scripting language                  \nphp             7.3           common [d], devel, minimal      PHP scripting language                  \nphp             7.4           common [d], devel, minimal      PHP scripting language                  \npostgresql      9.6           client, server [d]              PostgreSQL server and client module     \npostgresql      10 [d]        client, server [d]              PostgreSQL server and client module     \npostgresql      12            client, server [d]              PostgreSQL server and client module     \n\nHint: [d]efault, [e]nabled, [x]disabled, [i]nstalled<\/code><\/pre>\n\n\n\n
Wie ihr sehen k\u00f6nnt, hat man damit die Auswahl aus mehreren Versionen ein und der selben Anwendung. Das kannte ich so bisher noch nicht, ohne zus\u00e4tzliche Repos einbinden zu m\u00fcssen, oder mich gar mit den ber\u00fcchtigten Red Hat Software Collections besch\u00e4ftigen zu m\u00fcssen.<\/p>\n\n\n\n
Als Sysadmin habe ich damit etwas Flexibilit\u00e4t 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.<\/p>\n\n\n\n
Allerdings kann man nicht zwei verschiedene Versionen von z. B. PHP oder PostgreSQL parallel auf dem gleichen Host betreiben. Wer dies w\u00fcnscht, kann die entsprechenden Anwendungen lokal in Podman-Containern ausf\u00fchren. Auch hier stehen Images f\u00fcr die verschiedenen Versionen bereit.<\/p>\n\n\n\n
Red Hat verspricht, neue Versionen von Anwendungen, Sprachen und Werkzeugen auf diesem Weg verf\u00fcgbar 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:<\/p>\n\n\n\n