Der ein oder andere Admin wird sich vermutlich schon lange den 30. Juni 2024 im Kalender vorgemerkt haben, denn dann ist für CentOS Linux 7 das „End of Life“ erreicht. Aber auch Benutzer von Red Hat Enterprise Linux 7 sollten sich Gedanken machen, denn auch dieses verlässt an dem Tag die „Maintenance Support 2 Phase“ und geht in den „Extended life cycle“ über.
Was bedeutet das nun?
„End of Life“ ist relativ einfach erklärt, ab diesem Termin wird die Unterstützung für das Produkt eingestellt und somit gibt es hier keine Updates mehr. Insbesondere das Fehlen von Sicherheitsupdates spricht dann ganz klar gegen einen Weiterbetrieb.
„Extended life cycle“ ist dagegen etwas komplizierter. Auf der einen Seite stellt auch Red Hat hiermit das Updaten ein, supported bestehende Systeme aber weiter und bietet auch Migrationsunterstützung. Auf der anderen Seite ermöglicht es bei Red Hat hier ein Support-Addon hinzu zu kaufen, welches dann Zugriff auf kritische und schwerwiegende Sicherheitsupdates und ausgewählte Bugfixes sowie andere Supportbedingungen gibt. Wer also aus irgendwelchen Gründen darauf angewiesen ist, kann für einen nicht gerade kleinen Betrag einen sicheren Weiterbetrieb sicherstellen und damit die Migration weiter hinauszögern. Für die meisten Nutzer dürfte es aber gleichbedeutend mit dem „End of Life“ sein.
Was soll ich nun tun?
Der übliche Weg bei Software ist der Weg nach vorne, also ein Upgrade auf die nächste Version des Betriebssystems. Hier wird es allerdings in diesem Fall deutlich komplizierter denn mit der Einstellung von CentOS Linux gibt es den klaren Weg nach vorne nicht mehr, sondern einen echt verzwickte Weggabelung!
Wer weiterhin dem CentOS-Projekt sein Vertrauen schenkt, hat als direkten Nachfolger CentOS Stream 8. Dieses ist aber nicht länger ein Downstream von Red Hat Enterprise Linux und auch nicht mehr den kompletten Support-Lifecycle unterstützt, sondern EoL bereits am Ende des „Full support“ was dem Release der Minorversion 10 und somit 5 Jahren statt 10 entspricht! Damit ist das EoL für CentOS Stream 8 allerdings bereits am 31. Mai 2024, also vor dem von CentOS Linux 7. Somit sollte der Weg schnell beschritten werden und dann direkt weiter zu CentOS Stream 9.
Der ein oder andere sollte auch überlegen ob die eigenen Anforderungen nicht den Wechsel zum Enterprise-Support rechtfertigen. Red Hat supportet den Wechsel hier nicht nur, sondern stellt auch entsprechende Werkzeuge zur Verfügung. Damit lässt sich auch das Upgrade bei Bedarf raus zögern, auch wenn ich nach dem Wechsel eigentlich direkt den Schritt zu RHEL 8 empfehlen würde bzw. man auch hier direkt mit Version 9 überlegen kann.
Eine andere Alternative mit direktem Enterprise-Support aber auch unbegrenzter freier Verfügbarkeit ist Oracle Linux. Hierbei lässt sich quasi das gleiche bezüglich Migration sagen. Aber bei diesem Wechsel empfehle ich sich mit den Besonderheiten von Oracle Linux ausführlich auseinander zu setzen. Ich habe da in der Vergangenheit durchwachsene Erfahrungen gesammelt. Zum einen haben wir Kunden, die mit teils recht großen Umgebungen komplett auf Oracle Linux sehr gut fahren. Zum anderen hatte ich mit zusätzlichen Repositories und dort enthaltener Software teils Probleme, da Oracle teilweise andere Kompiler-Flags setzt und auch EPEL (Extra Packages for Enterprise Linux) nachbaut, aber dies nicht im vollen Umfang.
Dann gibt noch die Forks, die aufgrund der Einstellung von CentOS Linux entstanden sind. Hier müssen für mich alle noch beweisen wie ihnen der veränderte Umgang von Red Hat mit den Quellen gelingt und wie das ganze nach dem EoL von CentOS Stream aussieht. Da sehe ich aktuell bei AlmaLinux, dass das Projekt sehr vieles richtig macht, sowohl technisch als auch in anderen Bereichen. Rocky Linux wirkt hier auch sehr solide. Alle anderen habe ich quasi aus den Augen verloren, da sie weder bei uns im Kundenstamm relevant geworden sind noch mein persönliches Interesse durch etwas geweckt wurde. Das Schöne hier ist, dass sowohl Werkzeuge zur Migration in Version 7, als auch direkt von 7 zu 8 existieren.
Den kompletten Distributionswechsel lasse ich in der Betrachtung mal außen vor, da hier dann deutlich mehr Planung notwendig ist. Auch dieser Aufwand ist zu stemmen, aber dann doch eher keine Lösung für einen Zeitraum von etwa 3 Monaten.
Wie gehe ich nun vor?
Nachdem die Entscheidung für das Ziel gefallen ist, stellt sich als nächste Frage üblicherweise ob man das System überhaupt upgraden oder lieber direkt neu erstellen will. Hier habe ich mich mittlerweile tatsächlich zu einem Befürworter von In-Place-Upgrades entwickelt, was auch an dem Tool Leapp bzw. ELevate liegt. Mit diesem und den Möglichkeiten wie ich es auch in größeren Umgebungen sinnvoll nutze, habe ich mich schon vor einer Weile in meinem Artikel „Leap(p) to Red Hat Enterprise Linux 9“ beschäftigt.
Worauf ich damals nur am Beispiel von Foreman eingegangen bin, sind hier der Umgang mit zusätzlicher Software. Foreman war für den Artikel ein gutes Beispiel, da hier extra Migrationen für Leapp gebaut wurden. Bei anderer Software ist dies nicht der Fall. Also müssen wir hier von zwei Szenarios ausgehen. Zum einen von Software, die aus einem zusätzlichen Repository in Form von Paketen installiert wurde, und zum anderen solcher die manuell installiert wurde. Software in Containern oder ähnlichem können außen vor lassen, da diese unabhängig vom Betriebssystem sind.
Software aus zusätzlichen Repositories sollte mit Leapp/ELevate kein Problem darstellen, solang ein Repository für die neuere Version verfügbar ist. In diesen Fällen muss nur das zusätzliche Repository während des Upgrades verfügbar gemacht werden. Dass es auch hier Stolpersteine gibt ist klar, ein Beispiel wäre hier Icinga wo ab EL8 nur noch Subscription-pflichtige Repositories zur Verfügung stehen. Also auch hier sollte etwas Zeit in Planung und Tests investiert werden bevor es an produktive Systeme geht.
Bei manuell installierter Software ist nach dem Betriebssystem-Upgrade sehr wahrscheinlich einmal neu kompilieren angesagt, damit die Software mit neueren Version der Systembibliotheken läuft. In manchen Fällen wird auch ein Update der Software notwendig sein, wenn die Kompatibilität sonst nicht mehr gegeben ist. Das gilt auch in vielen Fällen für nicht zu kompilierende Software, da sich auch Perl-, Python-, Ruby- oder ähnliche Laufzeitumgebungen ändern. Da hier ein Vorteil des In-Place-Upgrades weg fällt und eh ein manueller Schritt übrig bleibt, ist hier ein paralleler Neuaufbau schon eher verlockend. Was am Ende sinnvoller ist, entscheidet sich meist je nach Menge der Laufzeitdaten.
Ist damit alles getan?
In vielen Umgebungen wird hier gerne noch vergessen wo das Betriebssystem noch so eine Rolle spielt und auch hier ist die Migration wichtig. Zum einen ist es sinnvoll sich bei Containern oder Images wie beispielsweise bei Vagrant die Basis anzuschauen und hier auf neuere Versionen zu wechseln. Und dann haben wir zum anderen CI/CD-Pipelines, hier kann im Vorfeld über eine Erweiterung der Matrix schon oft eine Kompatibilität sichergestellt werden und nach abgeschlossenem Upgrade können dann die alten Systeme entfernt und damit verbundene Restriktionen gelockert werden, was sicher einige Entwickler freut.
Fazit
Wie hoffentlich jeder sieht, hier steht uns allen Arbeit bevor und zwar nicht nur beim eigentlichen Doing. Aber es kann auch als Chance für Innovation gesehen werden. Beispielsweise hat beim Foreman-Projekt ein regelrechter Frühjahrsputz eingesetzt nachdem mit dem Wegfall des Supports für EL7 und damit dem Bedarf an Support für EL9 der ganze Technologie-Stack modernisiert werden kann. Wenn ich nun jemand aufgeschreckt habe oder allgemein jemand bei dem Thema Hilfe benötigt gerne unterstützen unsere Consultants bei der Planung egal ob es um das richtige Vorgehen oder den Einsatz der Tools geht. Über ein Outsourcing-Kontingent unterstützen die Kollegen auch gerne beim eigentlich Upgrade. Und auch wegen einer Icinga-Subcription darf sich bei Bedarf an unser Vertriebsteam gewendet werden.
Als erstes Teilziel für diesen Artikel soll Icinga 2 nebst Plugins enthalten sein. Bei den Plugins soll auch berücksichtig sein, dass es Plugins wie check_icmp oder check_dhcp gibt, die erweiterte Berechtigungen benötigen. So dürfen ICMP-Pakete oder auch DHCP-Request auf Unix nur im Ring-0 erzeugt werden. Auf RedHat wird dies über das Setzen des setuid-Bits erreicht, unter Debian mittels 
