tl;dr CentOS ist seit fast 15 Jahren die Linux Distribution der Wahl für alle Linux Server der Netfonds Gruppe. Alle unsere Webserver, Mail Relays und vieles mehr basiert auf dieser Distribution. Die CentOS Projektleitung hat nun entschieden, das bisherige Modell des CentOS als freie Downstream Linux Distribution für Red Hat Enterprise Linux einzustellen. Statt dessen wird CentOS zukünftig der Upstream für die RHEL Point Releases werden.
Ich erkläre was das genau bedeutet, welche Ursachen es gibt, welche Folgen zu erwarten sind und wo sich Netfonds in dieser Thematik einsortiert.
Prolog
Eine Linux Distribution ist ein ständig weiterentwickeltes riesiges Bündel von Software. Als Kern das Unix-ähnliche Betriebssystem mit seinem Linux-Kernel, drum herum diverse Betriebssystem-Dienste, Server- und Clientanwendungen, grafische Benutzeroberflächen und vieles mehr. Ein exorbitant riesiger Haufen Arbeit.
Eine erfolgreiche Linux Distribution, das heißt eine, die auch von Leuten genutzt wird, wird für einen Nutzerkreis erstellt, der ein spezielles Bedürfnis hat, dass zuvor nicht, oder nur unvollständig, befriedigt werden konnte. Es gab zum Beispiel schon immer Bastel-Distributionen, die einzig dazu da waren, Interessierten eine Plattform zu bieten Ihr Wunschsystem zusammen zu bauen, dabei Spaß zu haben und viel zu lernen. Je individueller und komplizierter umso besser. Daher stammt auch der Spruch, Linux wäre nicht kompliziert, sondern nur wählerisch in der Auswahl seiner Nutzer. Der derzeit populärste Vertreter dieses Genres ist sicher Arch, aber auch Gentoo gehört in diese Kategorie. Diese Distributionen sind für Ihren Einsatzzweck hervorragend geeignet, für andere Dinge dagegen nicht.
Ich startete meine “Linux-Karriere” 1994 mit einem Slackware-Derivat namens S.u.S.E. und das Erlebnis war mehr schmerzhaftes Abenteuer, als dass ich wirklich Nutzen aus dem Einsatz ziehen konnte, weil die Distribution eigentlich nur eine Ansammlung von Sourcecode plus (immerhin teilweise deutsch kommentierten) Scripten auf 68 Disketten (geraten.. ich weiß nicht mehr wie viele es waren) war.
Es gibt zum Beispiel auch Distributionen, die sich auf die reine Fortentwicklung eines Distributionsuniversums spezialisiert haben, wie zB. Fedora für Red Hat oder Debian Unstable für Debian. Dazu später mehr.
Und dann gibt es da die sogenannten Enterprise Linux Distributionen, deren Ziel es ist, maximal stabil in Enterprise Umgebungen als Plattform zu fungieren um Enterprise Anwendungen zu betreiben.
Das wichtigste Feature einer Enterprise Distribution ist der Support-Zeitraum. Der Anbieter der Distribution gibt einen Support Zeitraum an, in dem seine Software gepflegt wird, dass heißt Fehler, insbesondere Sicherheitsprobleme, behoben werden, ohne dabei die Kompatibilität des Gesamtkonstruktes zu gefährden. Wenn also eine Library in Version 1.3 einen Fehler hat, der aber vom Ersteller der Software erst in Version 1.9 behoben wurde, ist es die Aufgabe des Distributors eine Version 1.3.1 zu erstellen und als Update zur Verfügung zustellen, die die Funktion der Library auf dem alten Stand beibehält, den Fehler aber behebt. Die nennt man Backports und diese sind vor allem wegen sogenannter dynamisch verlinkten Libraries von größter Bedeutung.
Wenn man ein Programm schreibt, dass zum Beispiel eine verschlüsselte Verbindung aufbauen soll, schreibt man die Funktionalität dafür entweder selber und integriert dies im eigenen Code, oder man benutzt eine bereits vorhandene Library, die diese Funktionalität mitbringt. In diesem Fall zum Beispiel die Open Source Library OpenSSL. Um diese Lib jetzt nutzen zu können gibt es grob zwei unterschiedliche Methoden. In der Windows-Welt ist es durchaus üblich statisch zu verlinken, das heißt das Programm wird mit einer Kopie der Library ausgeliefert und untrennbar mit dieser verbunden. Dies hat den Vorteil, dass externe Einflüsse, wie zum Beispiel Updates des Betriebssystems, keinen Einfluss auf die Funktionalität des Programms haben können, aber den Nachteil, dass der Maintainer des Programms dafür sorgen muss, dass die Lib auch immer up to date ist. Was leider selten geschieht.
Bei “unixoiden” Betriebssystemen, wie zum Beispiel Linux, ist genau das Gegenteil der Fall, statische gelinkte Libs sind eher unüblich bis verpönt, dynamisch verlinkt ist der richtige Weg. Das heißt Libraries wie zum Beispiel die besagte OpenSSL Lib wird unabhängig auf dem Betriebssystem installiert und kann so von allen Programmen dynamisch gelinkt und somit genutzt werden. Der Maintainer des Programm muss sich so um die Pflege der Funktionalität keine Sorge mehr machen, sondern muss nur noch angeben, welche Version der Lib sein Programm voraussetzt. Die Aufgabe der Distribution ist es dann, diese Abhängigkeit in seinem Paketmanager abzubilden, damit sichergestellt ist, dass die Lib auch vorhanden ist, sobald das besagte Programm genutzt werden soll. Und zwar exakt in der Version, die der Maintainer vorgesehen hat und dies muss nicht immer die aktuellste Version sein. Womit wir wieder bei den Backports sind.
Erfolgreichster (am Gewinn gemessen, über andere Kriterien kann man streiten) Vertreter dieses Genres ist Red Hat. Der Vollständigkeit halber sei erwähnt, dass es zum Beispiel auch noch SuSE und Ubuntu als Enterprise Distributionen gäbe, darum soll es hier aber im Wesentlichen nicht gehen.
Red Hat bietet diverse Produkte für Cloud Computing, Middleware, Storage und vieles mehr an, Kern der Produktfamilie ist aber die Linux-Distribution Red Hat Enterprise Linux (RHEL), die mit Garantien und Service zu stattlichem Preis verkauft, bzw. eher vermietet, wird.
1. Akt: Wo kommen wir her?
Als ich am 02.01.2001 bei meinem neuen Arbeitgeber netfonds24.de GmbH aufschlug, fand ich fünf selbstgebastelte Server mit Red Hat Linux 6.0 (nicht mit RHEL 6 zu verwechseln) darauf vor. Ein Samba Fileserver, ein Apache Webserver, eine MySQL Datenbank, eine iptables Firewall, ein Sendmail/IMAP Server und noch ein wenig Kleinkram. Und so unprofessionell das aus heutiger Konzern-Sicht vielleicht klingt, so sehr war das der Grund, warum ich damals dort angefangen habe.
Aus meinem vorherigen beruflichen Umfeld kannte ich VMS, OSF/1, NetWare und Windows NT, meine Erfahrungen bezüglich Linux basierte aber alleine auf privatem Interesse. Mal abgesehen davon, dass es damals noch nicht die Auswahl wie heute gab, hatte ich also auch noch nicht die nötige Erfahrung, um zu beurteilen, ob das die richtige Distribution für unseren Einsatzzweck war. Also kauften wir damals, nachdem ich mich mit Red Hat gut arrangiert habe, zum Release (damals konnte man das noch kaufen, richtig mit einmaligem Preis, im Karton mit Handbüchern) die neue Version Red Hat 7.0 und seit dem ist die Netfonds Gruppe weitestgehend der Red Hat Familie treu geblieben. Es stellte sich heraus, dass die Auswahl des damaligen Dienstleisters korrekt war, das Red Hat Linux Universum leistete uns immerhin 20 Jahre gute Dienste; wir waren sehr zufrieden und wären es auch heute noch – hätte Red Hat nicht andere Pläne gehabt.
Zugegebenermaßen ist das weite Feld der Linux-Distributionen oben aus “dramatikalischen” Gründen nur sehr lückenhaft umrissen. Es soll dokumentieren, dass es in dem Universum Red Hat bald eine Lücke zwischen RHEL und Fedora gab.
2. Akt: Wo wollen wir hin?
Denn 2003 kündigte Red Hat einen großen Umbruch an. Die Distribution Red Hat Linux würde es zukünftig in der Form nicht mehr geben, stattdessen wird eine Entwickler-Distribution namens Fedora gestartet, dessen Community die Entwicklung für das zukünftige Red Hat Enterprise Linux leisten soll, das dann nicht mehr gekauft, sondern auf Subscription-basis gemietet werden soll.
Dies war nicht allen Kunden Recht, uns auch nicht. Zu diesem Zeitpunkt gab es bereits Klone der Red Hat Distribution, denn Red Hat veröffentlichte, in Übererfüllung der verwendete Lizenz GPL, alle gebauten Pakete als Source-Pakete. Diese konnten von der Community ganz legal aufgegriffen und in eine neue Distribution gepresst werden. Nach der Ankündigung fanden sich also schnell Leute zusammen, die eine freie Version von RHEL bauen würden und nannten diese Distribution CentOS (Community Enterprise Operating System). Damit schlossen die Macher dieser Distribution die große Lücke für Professionals, die eine Enterprise Distribution für den produktiven Einsatz von Linux-Servern und Enterprise Software brauchten, aber weder den Service noch die Garantien, die RHEL lieferte, und entsprechend teuer bezahlt werden mussten.
Weil die Distribution fast ausschließlich auf Source Paketen der Distribution RHEL beruhte, war CentOS byte-kompatibel mit dieser und somit konnte Enterprise Software, die für RHEL zertifiziert wurde, eins zu eins auch auf der entsprechenden Version aus CentOS genutzt werden. Der einzige Nachteil, der aus dieser Verfahrensweise erwuchs, war die Tatsache, dass das nachgelagerte Release von CentOS naturgemäß immer erst weit nach dem Release von RHEL erfolgen konnte. Somit hing CentOS immer etwas hinterher, das hatte aber auch den Vorteil, dass die Releases entsprechend abgehangen, das heißt stabil, waren.
Obwohl man meinen könnte, dass Red Hat nicht allzu glücklich darüber war, dass CentOS unter Ihren Kunden wilderte, war dem nicht so. Von Anfang an kooperierte Red Hat mit der CentOS-Community und somit baute sich eine stabile Partnerschaft auf, von der auch Red Hat langfristig profitierte, denn Red Hat war schon immer ein klassisches Open Source Unternehmen. Solche Firmen sind erfolgreich, weil sie den heiklen Spagat zwischen kommerziellem Interesse der Investoren und den Interessen der Community hinbekommen. Und umso besser dieser Spagat gelingt, um so erfolgreicher ist das Unternehmen. Es gilt maximal von der Community zu profitieren, in dem diese Code liefert, testet und fixt, dieser Community aber auch etwas zurückzugeben, damit sie dabei bleibt. CentOS war deutlich über 10 Jahre lang ein Geben und Nehmen und ja, das Ganze klingt natürlich zu gut um von Dauer zu sein.
3. Akt: Wo bleiben wir?
2014 kündigte Red Hat an, noch näher mit CentOS zu kooperieren zu wollen und hat diverse CentOS-Macher eingestellt und somit die Leitung des Projekts quasi komplett übernommen.
Red Hat hatte das große Problem, dass Ihr Entwicklungs-Distribution Fedora erstens zu weit entfernt (in der Entwicklung voraus) von dem Stable Release RHEL war, was in der Weiterentwicklung von RHEL sicher problematisch war und zweitens kaum von der Professionals Community genutzt wurde, was problematisch im Sinne der qualifizierten Rückmeldung ist.
Entsprechend brauchte Red Hat dringend eine Zwischendistribution, die oben genannte Aufgaben übernimmt. 2019 wurde dafür CentOS Stream 8 geboren, was eine Quasi-Rolling Release von CentOS 8 war, und zukünftig der Upstream für RHEL Point Releases sein sollte.
Kurz zur Begriffsklärung: Ein Rolling Release ist das Prinzip eine Software herauszugeben und diese eine Version immer weiter zu entwickeln und dafür Patches rauszubringen, ohne einzelne Versionierung der Gesamt-Distribution. Also eine kontinuierliche Weiterentwicklung ohne Milestones. Point Releases sind die Milestones innerhalb eines Major Releases. Also zum Beispiel die Version RHEL8 ist ein Major Release und unterteilt sich in Point Releases 8.1, 8.2 und so weiter. CentOS Stream soll jetzt also ein Rolling Release innerhalb eines Major Releases werden und dazu dienen die Point Releases für RHEL vorzubereiten, quasi eine Beta für RHEL. Das klingt etwas hart, immerhin gehen die CentOS Stream Pakete komplett durch den Qualitätsmanagement-Prozess bei Red Hat, dennoch ist das Ganze ein Paradigmenwechsel und entsprechend wenig begeistert war wieder einmal die CentOS Community. Aber es gab ja noch das normale CentOS “Downstream” Release, in so fern ‘no harm done’.
Leider bleibt es dabei nicht, denn, wie oben schon beschrieben, sind CentOS User zu CentOS gekommen, um eine Enterprise Distribution zu nutzen, nicht um Red Hat mit einer Beta zu unterstützen. Entsprechend hatte Red Hat immer noch das Problem, dass zu wenige Ihre Beta nutzt, um zu Testen und zu Reporten.
Kommen wir zur Pointe. Am 08.12.2020 hat der CentOS Lead angekündigt, dass CentOS Releases zukünftig nicht mehr weitergeführt werden. CentOS7 wird wie bei Release versprochen bis Juni 2024 unterstützt, CentOS8 jedoch vorzeitig zum 31.12.2021 abgekündigt. 8 Jahre vor der ursprünglichen Ankündigung, was die Kuriosität zur Folge hat, dass CentOS7 jetzt tatsächlich 3 Jahre länger supportet wird, als die neuere Version 8. Dazu kam zu allem Überfluss dann noch der Spruch “If you are using CentOS Linux 8 in a production environment, and are concerned that CentOS Stream will not meet your needs, we encourage you to contact Red Hat about options.”.
Red Hat hat den oben besprochenen Spagat kapital in den Sand gesetzt und es folgte nicht nur ein epischer Shitstorm und Ankündigungen von neuen Community Projekten, sondern auch Androhungen von Massen-Abwanderungen.
Man muss sich das mal auf der Zunge zergehen lassen, was so ein Release Wechsel von hunderttausenden VMs für eine Firma wie Facebook (die bisher CentOS genutzt haben) kostet. Man stelle sich nur mal vor (nur vorstellen, ob das so ist weiß man nicht), dass die gerade Millionen Dollars ausgegeben haben um von 7 auf 8 zu migrieren um dann plötzlich vor dem Quasi-Nichts zu stehen. Dazu dann der Spruch, wenn’s nicht passt, kauf doch RHEL.
Epilog
„Was tun?“, spricht Zeus, „die Welt ist weggegeben”.
Es bleiben einige Alternativen, die durchdacht sein wollen.
Man könnte zu RHEL wechseln. Das würde minimalen Arbeitsaufwand bedeuten, aber leider auch maximalen finanziellen Aufwand. RHEL ist wirklich exorbitant teuer und für den Nutzen den wir dadurch erhalten leider niemals zu rechtfertigen. Insbesondere weil wir den inkludierten Support vermutlich nie nutzen würden, weil wir das Know How im Hause haben.
Bleiben wir bei CentOS und leben mit dem Konstrukt Stream? Ein Rolling Release ist eigentlich ein no-go im Enterprise Umfeld. Wir brauchen sichere Support-Zeiträume und zuverlässige, zügige Backports. Wir müssen uns darauf verlassen können, dass 3rd Party Software stabil auf unseren System läuft und es zu keinen Versionkonflikten kommt. Und was kommt als nächstes? Red Hat hat sich, im Zusammenhang mit CentOS, nach langer Partnerschaft als nicht mehr zuverlässig herausgestellt. Hätte Red Hat das ganze für CentOS9 angekündigt und CentOS8 wie versprochen zu Ende geführt, hätte es sicher Gemoser gegeben, aber alles in allem wäre niemand böse. Insbesondere da Red Hats Anliegen ja durchaus nachvollziehbar, vielleicht sogar legitim, ist. Aber das Versprechen CentOS8 zu brechen ist unentschuldbar.
Sollte man auf andere Enterprise Distributionen wechseln? Oracle hat die Ankündigung von CentOS zum Anlass genommen noch einmal massiv für Ihren eigenen RHEL Klon Oracle Linux zu werben. Aber Oracle, der Schreck aller Open Source Projekte, ist nicht der Partner mit dem ich persönlich zusammenarbeiten möchte. Oracle fehlt es von Grund auf an Integrität, zu viele aufgekaufte Firmen (Sun) und Open Source Projekte (MySQL) leiden unter Ihnen. Dann gäbe es da auch noch SUSE Linux Enterprise Server (SLES), aber SuSE schlägt bereits 20 Jahre zu häufig den falschen Weg ein, was auch durch Ihre holprige Firmengeschichte sehr gut dokumentiert wird. Und wer einmal YaST in der Hand hatte, will von SuSE eigentlich nichts mehr wissen.
Eine langfristige Alternative wären eventuell die neu angekündigten Clones von RHEL namens Rocky Linux und CloudLinux. Aber eben nur langfristig, denn wir müssen uns bis zur Einstellung von CentOS8 zu Ende 2021 eine Alternative überlegen und es ist zweifelhaft, dass diese Distributionen bis dahin eine echte Alternative sind. Zumal es bei einer Distribution auch sehr viel um Vertrauen geht, dass man sich erst einmal über Jahre verdienen muss.
Es bleiben Debian und das Debian Derivat Ubuntu. Ubuntu hat in den letzten Jahren, meiner Meinung nach, ebenfalls zu viele Irrwege beschritten (Unity, Mir, Snappy) anstatt einfach an den verbreiteten Lösungen mit zu entwickeln. Dies hat niemandem geholfen, ganz im Gegenteil; wer weiß wie viele Millionen an Entwicklerleistungen da den Bach runter gegangen sind, von dem die Linux Community hätte profitieren können. Wer weiß, welche Fortschritte Gnome oder Wayland gemacht hätten, wenn Ubuntu sich an der Entwicklung früher beteiligt hätte. Und man weiß nicht, was sich Mark Shuttleworth als nächstes ausdenkt – wieder das Thema Vertrauen.
Es bleibt die alte Dame Debian stable. Früher einmal war Debian stable hauptsächlich dafür bekannt, dass es die stabilste Distribution war, um mit Ihr gestellte Aufgaben NICHT lösen zu können, weil alles bis zur Unbenutzbarkeit veraltet (stabil) war. Dies hat sich inzwischen allerdings wesentlich gebessert. Ein Vergleich der Versionsstände von uns häufig genutzter Pakete zeigt, dass Debian stable in etwa auf dem Stand CentOS 8 ist und die von uns eingesetzte Enterprise Software ebenfalls unterstützt wird.
Als einziger Nachteil von Debian stable ist dann eigentlich nur noch die geringeren Support-Zeiträume zu nennen. Im Gegensatz zu RHEL oder Ubuntu unterstützt Debian Ihre Releases statt 10 nur 2 Jahre plus mindestens 1 Jahr oldstable in der man Zeit hat ein Upgrade durchzuführen. Neuerdings gibt es bei Debian auch eine LTS (Long Term Support), dieser hängt aber wieder massiv in den Versionsständen hinterher.
Es ist noch keine Entscheidung getroffen worden, in welche Richtung sich Netfonds in Zukunft entwickeln wird. Dennoch ist klar, dass 2021 das Jahr sein wird, in dem wir eine Entscheidung und daraus resultierend auch eine Lösung aus diesem Drama liefern müssen. Je früher desto besser.
Ich persönlich tendiere derzeit dazu, in Zukunft noch fokussierter auf Infrastruktur-Automatisierung und Konfigurations-Management zu setzen, sodass uns alle 2-3 Jahre mal ein Versionswechsel der aktuellen Distribution nicht mehr so sehr stört.
Und dann halt Debian. Die einzige Distribution die sich als Fels in der Brandung erwiesen hat, auf die man langfristig setzen kann, vor allem, weil es außerhalb des Zugriffs einer Firma mit Profitinteressen steht und dort auch verbleiben wird. Wenn ich das selbst lese, muss ich alter Debian-Hater laut lachen. Aber es ist wie es ist.
Bild: Canva
