Linux Enterprise: Was Checkmk-Admins jetzt wissen müssen zu Debian 13, RHEL 10 & Co.

Die Basis der neuen Linux-Betriebssysteme wurde teils grundlegend erneuert. Insbesondere beim Kernel fallen Gemeinsamkeiten und Unterschiede auf:

SUSE setzt nicht auf den neuesten Upstream-Linux-Kernel, sondern stattet SLES 15 SP7 mit dem bereits 2023 erschienenen Linux-Kernel 6.4 aus – das Projekt setzt mit Backports einen älteren stabilen LTS-Kernel ein, der damals neue BPF-Funktionen und verbessertes Speichermanagement erhielt, aber eben nicht mehr ganz auf dem neusten Stand ist. Backports sind angepasste (“zurückportierte”) neue Gerätetreiber und Patches, um neue Hardware auf älteren Kernel-Versionen zu betreiben. Damit lässt sich die Umstellung auf aktuellere Kernel-Versionen eine Weile lang abfedern. Die aktuelle Linux-Kernel-Entwicklung steht jedoch seit November 2025 bereits bei Version 6.18 (LTS) – bei Debian und RHEL ist die Entwicklungslücke kleiner:

Debian 13 Trixie und RHEL 10 enthalten den vorherigen LTS-Kernel 6.12 aus November 2024. Seit Kernel 5.14, den das Vorgänger-Release RHEL 9.6 verwendet, sowie Kernel 6.1 in Debian 12 Bookworm und dem jetzt verwendeten Kernel 6.12 hat sich einiges getan: Besserer Hardware-Support und verbesserter Performance für Dateisysteme, aktualisierte Grafiktreiber, Optimierungen im Strommanagement und neue Funktionen für Architekturen wie RISC-V sowie offizielle Unterstützung der Programmiersprache Rust (dies seit Kernel 6.1). Verbesserungen gab es auch an der Block-I/O – der Übertragung von Input/Output-Daten in festen Blöcken, die seit der Erstveröffentlichung 1991 durch Linus Torvalds Kernbestandteil des Linux-Kernels war.

Der Linux-Kernel 6.12 unterstützt neue Treiber sowie neuere Hardware und stellt das Ressourcenmanagement auf die Control Group Version 2 (Cgroup v2) um: eine Kernelfunktion, die Prozesse hierarchisch organisiert und CPU, Arbeitsspeicher oder Netzwerkbandbreite priorisiert, begrenzt sowie zuweist. Gegenüber der älteren Version 1 verfügt die Cgroup v2 über ein vereinheitlichtes Hierarchie-Design, das für Container-Laufzeitumgebungen wie Docker und Kubernetes besonders interessant sein dürfte. Echtzeitfähigkeiten und ein dynamischer Scheduler machen den LTS-Kernel zukunftsfähig für Desktop- und Serversysteme.

RHEL 10 setzt einen starken Fokus auf Sicherheit (dazu mehr weiter unten), SLES und Debian pflegen ihre eigenen Security-Stacks. Beim Upgrade auf eine Version 10.x sind zwei Punkte für alle hier besprochenen Linux-Betriebssysteme von Belang:

• Mindestanforderung der Checkmk-Version: Für die volle und offizielle Unterstützung aller drei aktuellen Releases (RHEL 10, Debian 13, SLES 15 SP7) ist eine aktuelle Major-Version von Checkmk erforderlich. Die beiden Enterprise-Betriebssysteme unterstützt Checkmk mit den Versionen 2.3.0 und 2.4.0, Debian 13 Trixie nur mit Checkmk 2.4.0. Eine Portierung von Checkmk 2.3.0 ist gemäß unserer OS Support Policy nicht vorgesehen.

• Verschlüsselung: Der Checkmk Agent Controller und der Agent Receiver verwenden für verschlüsseltes Monitoring (Pull- oder Push-Modus) nur Versionen von TLS-Bibliotheken, die Checkmk mitliefert. So stellen wir sicher, dass die eingesetzte Checkmk-Server-Version die modernen Verschlüsselungsbibliotheken des Hosts korrekt unterstützt.

Python-Zäsur: Da RHEL 10 und Debian 13 (Trixie) auf Python 3.12 als Standard wechseln, müssen alle verwendeten Python-basierten Plugins auf Kompatibilität geprüft und gegebenenfalls überarbeitet werden. An selbstgeschriebenen oder von Dritten bezogenen Agenten-Plugins und Local Checks könnten Anpassungen erforderlich sein hinsichtlich Schreib- und Leserechten für den Agenten, da SE Linux sonst beim Sammeln von Monitoring-Daten stören kann. Bei Firewall oder SELinux (Security-Enhanced Linux) können ebenfalls Änderungen notwendig sein, damit der Checkmk-Server den Agenten erreicht oder umgekehrt. Der letzte Punkt betrifft primär RHEL.

Der KI-Assistent für die Kommandozeile wurde von Red Hat mit der umfangreichen RHEL-Dokumentation und der RHEL Knowledge Base gefüttert und lässt sich wie bei solchen Tools gewohnt in natürlicher Sprache steuern – direkt in Ihrem Terminal. Linux-Neulinge können ihn als niederschwelligen Tutor nutzen, um ihre RHEL- und Monitoring-Kenntnisse zu erweitern, erfahrene Mitarbeiter sollten mit ihm ihre Arbeit beschleunigen und vertiefen können. Richtig spannend wird es mit dem Image Mode und dem Image Builder samt Lightspeed, die wir Ihnen nun etwas ausführlicher vorstellen möchten.

Mit dem Image Mode bietet Red Hat Ihnen die Möglichkeit, Red Hat Enterprise Linux als Boot-Container-Image zu bauen (bootc). RHEL wird im Image Mode in ein Image gepackt, das sich von Bare Metal bis zu hybriden Cloud-Settings in jeder Umgebung ausführen lässt. Das erleichtert das Teilen und Bearbeiten über Team- und Systemgrenzen hinweg. Durch den Image Mode lässt sich Red Hat Enterprise Linux 10 relativ einfach in DevOps- und CI/CD-Arbeitsabläufe einbinden. Für den Einsatz in hybriden Umgebungen bietet RHEL ein betriebsbereites Cloud-Image. Auch hier kommt der Image Mode von RHEL zum Zuge: Mit ihm können Sie Laufzeitumgebungen und Abhängigkeiten in ein umfassendes einziges Image packen und in Ihrer hybriden Cloud-Umgebung zur Verfügung stellen.

Falls mal etwas schiefgeht, können Sie frühere Images rasch wiederherstellen. Updates lassen sich als komplette Images ausliefern, was zu konsistenterem Systemverhalten führt. Updates und Rollbacks lassen sich auf diese Weise einfacher bewerkstelligen. Wenn Sie einen größeren Server-Cluster betreuen, entfällt die Notwendigkeit, RPM-Pakete einzeln zu aktualisieren. Mit dem Image Builder (etwa einem bootc-Tool) erstellen Sie ein neues RHEL-Image, laden es in eine Registry und weisen die Server an, das neue Image von dort zu beziehen. Die Installation oder Bereitstellung ist dabei eine einmalige Sache. Sie können automatische Updates aktivieren, Wartungsfenster konfigurieren (oder deaktivieren). Versionskontrolle und automatisierte Abläufe helfen Ihnen im Image Mode dabei, manuelle Eingriffe zu reduzieren und Verwaltungstätigkeiten zu automatisieren. Mit dem Image Mode können Sie auch vorgehärtete Images erstellen, indem Sie für die Build-Phase gezielt Leitplanken vorgeben. So lassen sich Sicherheits- und Compliance-Anforderungen in einer frühen Projektphase berücksichtigen und fallen einem später nicht auf die Füße.

Beim Bauen Ihrer RHEL-10-Images scannt der integrierte Image Builder Ihre Paketauswahl, versorgt Sie mit relevanten Informationen zum Produktlebenszyklus (EOL-Daten) und empfiehlt Ihnen Pakete, die zu Ihrer Vorauswahl passen. So gewinnen Sie bereits zur Build-Zeit Überblick und können leicht Anpassungen vornehmen. Das Feature, das diese Informationen bereitstellt, nennt Red Hat “Lightspeed” (eine Weiterentwicklung der “Red Hat Insights”). Lightspeed kann Ihnen bevorstehende Änderungen sichtbar machen, neue und abgekündigte Features auf den Radar holen und daraus eine Roadmap erstellen, welchen Einfluss künftige Updates auf Ihre bestehende Umgebung haben.

Last, but not least: Sicherheitsfeatures wie FIPS und OpenSSL sind eine der größten beworbenen Neuerungen seitens Red Hat. Dabei ist OpenSSL Teil jeder neueren Linux-Distribution und so gesehen nichts Besonderes. Die Federated Information Processing Standards (FIPS) erfordern jedoch eine besonders strenge OpenSSL-Konfiguration. Im Verbund sollen die beiden Features mit RHEL 10.x betriebene Systeme künftig besser schützen hinsichtlich neuer Standards der Post-Quanten-Kryptografie. Damit ist der Umstand gemeint, dass durch laufenden Fortschritt beim Quantencomputing bestehende Verschlüsselungsmuster angreifbarer werden, da Angreifer Passwörter und Verschlüsselungen künftig immer schneller knacken könnten. Das ist in Teilen noch ein hypothetisches Szenario. Insbesondere Regierungsbehörden und große Organisationen sind jedoch gemäß FIPS an neuere Verschlüsselungstechniken gebunden. FIPS-Compliance herzustellen ist ein aufwendiger Prozess, der in Unternehmen und Behörden Ressourcen bindet und vorausschauende Planung erfordert.

Für Entwickler einer Monitoring-Software ist das eine besondere Herausforderung, da die Anforderungen an FIPS-Compliance mit den Bedürfnissen eines vollständigen Monitorings je nach Setup auseinanderlaufen. Für FIPS muss man veraltete Algorithmen hart abschalten, die man zum Monitoring von Legacy-Anwendungen oder Legacy-Hardware grundlegend braucht. 
Für Sie als RHEL-Administrator könnte es je nach Zustand der zu überwachenden Hardware und Anwendungen durchaus eine Herausforderung sein, die geeignete Balance für Ihre Organisation, interne Compliance-Vorgaben und ein möglichst umfassendes Monitoring zu finden. Checkmk arbeitet aktiv daran, mit den aktuellen und künftigen Paketen für RHEL und andere Enterprise-Linux-Betriebssysteme brauchbare Kompromisse anzubieten.

Auf dem Weg zur FIPS-Compliance ist der Checkmk-Server meist das letzte System, das System-Admins FIPS-konform machen – aufgrund der spezifischen Monitoring-Anforderungen von Legacy-Hardware und -Apps, die sich nicht immer mit den FIPS-Anforderungen in Einklang bringen lassen. FIPS-Compliance ist ein längerer Prozess: Es lohnt sich daher, bei dem Thema am Ball zu bleiben und aktiv zu beobachten, was Red Hat und andere Anbieter von hier an auf die Straße bringen. Red Hats Commitment zu strengerem OpenSSL und FIPS stellt eine Herausforderung in der Adaption dar, da Red Hat seine FIPS-Compliance schon fast fertig hat und die Adaption etwas hinterher hinkt. Gerade für Unternehmen, Behörden und Organisationen mit besonders strengem Regelwerk ist es wichtig, die neuesten Betriebssystemversionen wie RHEL 10 aktiv auf Stimmigkeit mit den eigenen wie äußeren Anforderungen zu testen. Red Hat verspricht in seinen Release Notes weitreichende Sicherheitsverbesserungen, die künftig auf RHEL 10 aufbauen sollen – wir behalten das im Blick und raten zum aktiven und vorausschauenden Ausprobieren.