Anzahl und Umfang der unterstützten Betriebssysteme sind ein wesentlicher Faktor für den Aufwand, der in CI, Packaging und viele Tests investiert werden muss. Daher muss ein Kompromiss eingegangen werden, der die Belange möglichst vieler Nutzer mit einer effizienten CI in Einklang bringt. Früher wurde das Ergebnis kurz vor Release einer Checkmk-Version festgesetzt. Seit Checkmk 2.2.0 haben wir stattdessen eine Richtlinie zur Unterstützung von Betriebssystemen (OS Support Policy). Diese gibt Ihnen Planungssicherheit für kommende Updates von Checkmk und die damit unterstützten Betriebssysteme. Vor allem Nutzer von Ubuntu sollten diesen Artikel lesen.

Bis Checkmk 2.1.0 basierte die Festlegung der unterstützten Betriebssysteme auf Nutzerumfragen und der Analyse von Downloadzahlen. So kam es einerseits vor, dass auf Kundenwunsch eigentlich abgekündigte (respektive nach ESM überführte) Ubuntu-Versionen noch unterstützt wurden. Andererseits jedoch Enterprise-Distributionen herausfielen, die zwar schon lange auf dem Markt waren, aber während des Lebenszyklus der anstehenden Checkmk-Version Updates erhalten hätten.

Klare Zeitrahmen statt individuelle Entscheidungen

Seit der Veröffentlichung der Version 2.2.0 lösen klare Zeitrahmen die bisherigen Entscheidungen kurz vor Release ab. Von einem neuen Checkmk-Release werden nur Distributionen unterstützt, deren angekündigtes Support-Ende durch den Distributor mindestens drei Monate nach Release-Datum der Checkmk-Major-Version liegt. Hierbei berücksichtigen wir folgende Support-Zeiträume:

  • Bei Enterprise-Distributionen (RHEL und Derivate, sowie SLES)  gilt der typischerweise bis zu 10 Jahren umfassenden Support durch den Distributor
    • RHEL: Maintenance Support
    • SLES: LTSS
  • Bei Community-Distributionen (Ubuntu und Debian) gilt der typische Zeitraum von 5 Jahren des kostenlosen Community-Supports. Kostenpflichtige Updates nach diesem Zeitraum (beispielsweise Ubuntus ESM) werden ausdrücklich nicht berücksichtigt.
    • Ubuntu: LTS
    • Debian: LTS

Distributionsversionen mit weniger als zwei Jahren gesamtem Support durch den Distributor unterstützt Checkmk nicht mehr.

Des Weiteren möchten wir die Zahl der Versionen pro Distributor nicht ausufern lassen: Ergeben sich mehr als vier gleichzeitig zu unterstützende Versionen einer Distribution, unterstützt Checkmk die zuerst aus dem Support laufenden nicht. Sollten wir hiervon eine Ausnahme machen, besteht Support nur über einen begrenzten Zeitraum, der bei Checkmk Release bekannt gegeben wird. Das Beispiel von SLES zeigt, dass wir nach dieser Richtlinie Version 15 SP1 bei der Veröffentlichung von Checkmk nicht hätten unterstützen müssen.

illustration showing the Checkmk support cycle of 2.2.

Der rote Balken „12 SP4“ kennzeichnet die in Checkmk 2.2 nicht mehr unterstützte SUSE-Version, deren Support-Ende in den Dreimonatszeitraum nach Release fällt. Von den grünen Balken der 12 SP5 und 15 SP1 bis SP4 ist 15 SP1 die mit der kürzesten Restlaufzeit und hätte daher bereits bei Release von 2.2 nicht mehr berücksichtigt werden müssen.

Der Wegfall sehr kurz unterstützter Distributionsversionen betrifft vor allem Ubuntus halbjährlich erscheinende STS-Versionen („Short Term Support“), die lediglich neun Monate lang Updates erhalten. Die immer im April gerader Jahre veröffentlichten LTS-Versionen werden nach wie vor voll unterstützt.

Nie mehr STS?

Keine Regel ohne Ausnahme – oder besser gesagt: wohlüberlegter Transitionsperiode. Bei Vorstellung der OS Support Policy auf der Checkmk-Konferenz im Juni 2023 waren Checkmk 2.1.0 und 2.2.0 bereits für Ubuntu 22.10 STS veröffentlicht. Angesichts des nicht offiziell unterstützten Downgrades einer Ubuntu STS auf die davor veröffentlichte LTS war uns schnell klar, dass die Durchsetzung der Richtlinie für diejenigen Nutzer, die 2.1.0 und 2.2.0 bereits auf Ubuntu 22.10 einsetzten, zu unnötigen Härten führen würde. Denn letztlich wären Backup, Neuinstallation und Restore der einzig praktikable Weg gewesen.

Statt des Downgrades auf 22.04 streben wir daher das sanfte Upgrade an: nämlich 22.10 STS > 23.04 STS > 23.10 STS > 24.04 LTS. Und ab der 24.04 LTS sind die betroffenen Ubuntu-Nutzer wieder im Release- und Supportzyklus der LTS-Versionen, sodass wir dann den Support von STS vollständig auslaufen lassen werden.

Und was ist mit der Hardware-Unterstützung?

Ein gerne für Ubuntu STS gebrachtes Argument ist die Hardware-Unterstützung. Schließlich kommt Ubuntu 23.10 mit Kernel 6.5, während Ubuntu 22.04 Kernel 5.15 mitbringt. Der letztgenannte wurde im Oktober 2021 veröffentlicht. Daher ist die Unterstützung für Hardware, die in den letzten zwei Jahren veröffentlicht wurde, eher mau.

Canonical ist sich dieses Problems bewusst und portiert daher seit 2016 die Kernel der STS-Versionen einige Wochen nach STS-Release auf die neueste LTS zurück. Dort sind sie dann als zusätzliches Paket

linux-generic-hwe-22.04 

verfügbar. Beginnend mit dem Dot-Release .2 vier Monate nach der ersten auf eine LTS folgende STS stellt Canonical darüber hinaus Installations-Images mit dem STS-Kernel bereit. Konkret: Ubuntu 22.04.2 von Februar 2023 enthält den Kernel von Ubuntu 22.10, Ubuntu 22.04.3 von August 2023 enthält den Kernel 6.2 von Ubuntu 23.04 und 22.04.4 wird im Februar 2024 Kernel 6.5 von 23.10 enthalten.

Illustration of the ubuntu kernel support circle

Vier Monate nach Erscheinen von Ubuntu 24.04 LTS wird Ubuntu 22.04.5 dann dessen Kernel erhalten und keine weiteren STS-Kernel mehr bekommen. Der gesamte Prozess beginnt anschließend für Ubuntu 24.04 von vorne.

Wer auf die Unterstützung aktueller Hardware angewiesen ist, sollte also immer darauf achten, die aktuellsten Installationsimages zu verwenden. Falls Sie mit debootstrap oder mit Image-Building-Tools arbeiten, achten Sie darauf, den HWE-Kernel zu integrieren.

Flexible Optionen für Entwickler

Dass Entwickler gerne Bleeding-Edge-Distributionen verwenden, um einerseits neueste Technologien schnell verfügbar zu haben und andererseits früh erkennen zu können, welche Änderungen bei kommenden Distributionsversionen zu Problemen führen können, ist absolut nachvollziehbar.

Allerdings resultiert daraus nicht, dass Checkmk auch für jede STS-Version angeboten werden muss. Mit der Virtualisierung existiert die flexibelste Möglichkeit, ein LTS-Betriebssystem als Gast auch auf einem STS-Linux auszuführen. Wer es gerne bequemer hat, kann zu unseren fertigen Docker-Images greifen.

Bequeme Update-Planung

Auch wenn damit die Planung für die Zukunft abgesteckt ist: Vor der Aktualisierung einer älteren Checkmk-Installation, mussten Sie immer recherchieren, welche Checkmk-Version welche OS-Version unterstützt. Um diesen Vorgang zu vereinfachen, haben wir Update-Matrizen erstellt. Aus diesen können Sie ablesen, wann ein Checkmk-Update mit einem Betriebssystem-Update verbunden werden sollte und wie Updates, die mehrere OS- oder Checkmk-Versionen betreffen, sich in möglichst wenigen Schritten durchführen lassen. Hier z.B. ein Screenshot der Update-Matrix für 2.1.0 nach 2.2.0 unter Ubuntu:

screenshot of the Checkmk update matrix for 2.1.0 to 2.2.0 under Ubuntu

Gelegentlich erhalten wir Anfragen nach Builds von sehr alten Checkmk-Versionen auf recht neuen Versionen von Betriebssystemen oder umgekehrt – für ein relativ neues Checkmk in Kombination mit einer längst abgekündigten Distributionsversion. Um solche Anfragen zu beantworten, haben wir diese Schaubilder in alle im Handbuch enthaltenen Branches aufgenommen. Konkret bedeutet das, dass Sie alle Informationen vorfinden, um auch eine “irgendwo vergessene” Checkmk-Installation in Version 1.5.0 auf Ubuntu 14.04 auf eine aktuelle 2.2.0 auf Ubuntu 22.04 zu hieven.