Autorenarchiv: Jörg Kastning

RHEL CVE Monitor für arme Admins

2 Antworten

User Story: Als RHEL-Systemadministrator:in möchte ich für einige ausgewählte Kompontenten, wie z.B. kernel, openssl oder samba, über neue CVE für diese Komponenten informiert werden. Leider steht mir dazu keine Schwachstellenmanagementlösung zur Verfügung. Einen Red Hat Satellite Server habe ich nicht und den Vulnerability Service in der Hybrid Cloud Console kann bzw. darf ich nicht nutzen.

Transparenzhinweis: Ich arbeite als TAM für Red Hat. Die im Folgenden vorgestellte Anwendung habe ich als Open-Source-Projekt unter MIT-Lizenz veröffentlicht. Es steht in keiner offiziellen Verbindung zu Red Hat.

RHEL CVE Monitor ist ein Python-Tool, das die Red Hat Security Data API regelmäßig abfragt und neue Sicherheitslücken (CVEs) für eine konfigurierbare Liste von RHEL-Paketen meldet.

Die zu überwachenden Pakete werden in packages.txt festgelegt (z. B. kernel, openssl, samba, rear). Beim ersten Lauf werden CVEs der letzten 30 Tage ausgegeben; danach zeigt das Tool nur noch neue Einträge seit dem letzten erfolgreichen Durchlauf. Bereits gemeldete CVEs werden in einer lokalen Zustandsdatei (.cve_monitor_state.json) gespeichert, damit nichts doppelt erscheint.

Die Ausgabe kann als Text, JSON oder CSV erfolgen und eignet sich für manuelle Prüfungen, Cron-Jobs oder systemd-Timer. Mit --exit-code lässt sich das Tool auch in CI/CD-Pipelines einbinden, die bei neuen CVEs alarmieren sollen.

Wie benutzt man das?

Der folgende Code-Block zeigt die CVE im RHEL-kernel der letzten 5 Tage:

[host.example.com rhel_cve_monitor]$ python3 rhel_cve_monitor.py --initial-days 4
=== kernel (1 new CVE) ===
  CVE-2026-80725       important    2026-08-29  https://access.redhat.com/security/cve/CVE-2026-80725

Total: 1 new CVE across 1 package

Die Ausgabe ist bewusst spartanisch gehalten. Man erhält lediglich die CVE-Nummer, die Severity, das Erscheinungsdatum und die URL zur Red Hat CVE Datenbank, wo man weitere Informationen zur Schwachstelle findet.

Verfügbare CLI-Optionen findet man in der Hilfe:

[host.example.com rhel_cve_monitor]$ python3 rhel_cve_monitor.py --help
usage: rhel_cve_monitor.py [-h] [--packages PACKAGES]
                           [--state-file STATE_FILE]
                           [--initial-days INITIAL_DAYS] [--output OUTPUT]
                           [--exit-code] [--verbose] [--dry-run]
                           [--format {text,json,csv}]
                           [--reset-packages PACKAGE [PACKAGE ...]]
                           [--reset-after YYYY-MM-DD]

Monitor Red Hat Security Data API for new CVEs affecting given RHEL packages.

options:
  -h, --help            show this help message and exit
  --packages PACKAGES   Path to file with one package name per line (default:
                        packages.txt)
  --state-file STATE_FILE
                        Path to state file tracking last run time (default:
                        .cve_monitor_state.json)
  --initial-days INITIAL_DAYS
                        On first run (no state file), look back this many days
                        (default: 30)
  --output OUTPUT       Optional file path to write the report to (in addition
                        to stdout)
  --exit-code           Exit with code 2 when new CVEs are found (useful for
                        CI/automation)
  --verbose, -v         Enable verbose logging
  --dry-run             Preview what would be queried without hitting the API
  --format {text,json,csv}
                        Output format: text (default), json, or csv
  --reset-packages PACKAGE [PACKAGE ...]
                        Clear seen-CVE state for these packages (use 'all' for
                        every package) and exit
  --reset-after YYYY-MM-DD
                        When resetting, also set last_run to this date so next
                        run queries from here

Mehr kann die kleine Anwendung nicht.

Und wo gibt es das?

Unter der URL: https://github.com/Tronde/rhel_cve_monitor

Das englischsprachige README enthält weitere Beispiele und Hinweise zur Nutzung.

Falls ihr diese kleine Anwendung nützlich findet, freue ich mich, wenn ihr mir hier im Blog einen Kommentar hinterlasst und eure Erfahrung weiterverbreitet. Wenn ihr Fehler findet oder Verbesserungsvorschläge habt, meldet diese bitte im GitHub-Issue-Tracker des Projekts.

Meine FrOSCon 2026

Schreibe eine Antwort

Letzte Woche, um diese Zeit, öffnete die 21. FrOSCon ihre Tore für technik- und Open-Source-begeisterte Menschen. Nun ist sie bereits seit einer Woche vorbei und ich habe Konferenzblues überwunden.

Es hat mich sehr gefreut, Alexandra, Armin, Chris, Christian Thinkpadowik (den Museumsdirektor), Christof, Christoph (stoeps), Dirk, Henning, Jens und Sujeevan wiederzutreffen. Ebenso habe ich mich gefreut, einige neue Gesichter kennenzulernen. Wir werden uns sicher auf zukünftigen Konferenzen wieder über den Weg laufen und irgendwann, werde ich mir eure Namen auch merken können (bitte entschuldigt, mein Namensgedächtnis ist wirklich schlecht).

Vorträge gab es reichlich. Unbekannt heißt nicht unzugänglich – Warum OSS Nutzung Mut braucht von Silvia Deimeke ist tatsächlich der einzige Vortrag, den ich vor Ort gehört habe und ich finde ihn großartig. Sivlvia hat zum ersten Mal auf einer Open-Source-Konferenz gesprochen und einen interessanten Beitrag geleistet. Aus für gewöhnlich gut informierten Quellen kam mir zu Ohren, dass dies nicht ihr letzter Beitrag zu einer Open-Source-Konferenz gewesen sein soll.

Dass ich es nicht zu mehr Vorträgen geschafft habe, liegt zum einen an den schönen Gesprächen auf dem Gang, im Hof und an den Ständen und zum anderen, dass ich dieses Jahr gleich mit zwei Vorträgen und einem Workshop beigetragen habe. Allein sind drei Beiträge kaum zu stemmen, weswegen ich mich mit Christian Stankowic zusammentan habe, um folgende Beiträge abzuliefern:

Christian, es war mir eine große Freude, mit dir gemeinsam zu dieser Konferenz beizutragen.

Darüber hinaus habe ich ein Thema beigetragen, welches mir persönlich wichtig ist und Rückmeldungen zufolge einige Backlogs gefüllt hat:

Ich betrachte darin ein Unterthema aus dem digitalen Nachlass und wünsche mir, dass noch mehr Nerds auch in diesem Bereich Vorsorge betreiben.

Normalerweise finde ich nach einer Konferenz nicht die Zeit, mir Vortragsaufzeichnungen anzusehen. Dieses Mal haben es jedoch folgende Beiträge geschafft, mein Interesse zu wecken, so dass ich mir die Zeit genommen habe:

In letzterem findet ihr auch einige interessante Statistiken zur diesjährigen Konferenz.

Für mich heißt es nun: Nach der Konferenz ist vor der Konferenz. Ich freue mich als nächstes auf die Chemnitzer Linux-Tage 2027.

Nerds gefährden die digitale Souveränität ihrer Familie

7 Antworten

Dies ist der Begleit-Artikel zu meinem gleichnamigen Vortrag auf FrOSCon 2026 am Samstag um 11:15 Uhr in Raum HS 4. Ich möchte das Thema hier nochmals in Textform aufarbeiten und zur Diskussion stellen.

Worin besteht die Gefahr?

Für uns Nerds oder allgemein für technikaffine Personen ist der Umgang mit Technik interessant, spannend und häufig normal. Nicht selten betreiben wir in unserem Haus oder Wohnung eine komplexe Heimnetz-Infrastruktur. Viele von uns blicken gerne hinter die Technik und wollen sie verstehen. Diese Faszination teilen leider die meisten Menschen nicht.

Außerhalb unserer kleinen Nerd-Blase gibt es eine sehr große Gruppe von Menschen, die Technik benutzen, weil sie müssen oder die Nutzung digitaler Dienste Komfort verspricht und ihnen nützlich ist. Dass all dieser Kram funktioniert, wird häufig als selbstverständlich hingenommen und nicht selten mit schwarzer Magie in Zusammenhang gebracht. Und es mag einige unter uns überraschen, doch nicht alle Menschen finden Technik interessant und wollen diese verstehen. Die meisten Menschen wollen tatsächlich einfach nur keine Probleme damit haben.

Ein ganz normales Heimnetzwerk (ohne Nerd)

Abbildung 1 zeigt ein Bild von einem Heimnetzwerk, so wie es sich die meisten Internetdiensteanbieter und normale Menschen vorstellen.

dekorativ
Abb. 1: Ein einfaches Heimnetzwerk, wie es sich Internetdiensteanbieter und normale Menschen vorstellen.

Wer einen Internetanschluss bucht, erhält vom Anbieter meist eine Box und einen Brief mit Zugangsdaten. Letzterer ist optional und kann entfallen, wenn die Box schon komplett vorkonfiguriert ist. Während Kundige hierin einen WLAN-Router mit integriertem Kabel- oder DSL-Modem erkennen, beizeichnen andere Menschen diese Box schlicht als Das Internet. Das ist aus ihrer Perspektive nachvollziebar, denn funktioniert der Kasten nicht richtig, geht meist der Internetzugriff verloren. Dennoch ist diese Bezeichnung natürlich fachlich falsch. Doch was kümmert das den Menschen?

Alle netzwerkfähigen Geräte befinden sich in Abb. 1 in einem Netzwerk. Die Kaffeevollautomaten, Kühlschränke, Waschmaschinen und Wäschetrockner, Heizung, PV-Anlage, etc. habe ich rein aus Platzgründen weggelassen.

Während dieses einfache Setup viele Nachteile mit sich bringt, besitzt es allerdings auch einige Vorteile. Fast alle Internetdiensteanbieter, Elektronik-Fachmärkte und PC-Einzelhändler sind mit diesem Setup vertraut und nehmen an, dass es bei uns so aussieht. Die üblichen Boxen sind meist bekannt und können entsprechend konfiguriert oder im Fehlerfall ersetzt werden. Hierzu sind weder ein Informatikstudium noch 20 Jahre Berufserfahrung notwendig. Kurz gesagt, man findet leicht relativ günstige Hilfe, wenn es mal klemmt.

Ein (stark vereinfachtes) Nerd-Netzwerk

Ich verdiene mein Geld seit über 20 Jahren mit EDV/IT. Ich kenne sehr viele Menschen, die eine ähnliche Einstellung zu Technik haben, wie ich selbst. Glaubt mir bitte, wenn ich hier schreibe, dass das Netzwerk aus Abbilung 2 noch relativ einfach für Menschen unserer Profession ist.

dekorativ
Abb. 2: Beispiel eines stark vereinfacht dargestellten Nerd-Netzwerks

Das geschulte Auge erkennt, dass es hier nichts besonderes zu sehen gibt. Eine Firewall mit Dual-WAN-Konfiguration über zwei separate Internetdiensteanbieter (kanten- und knotendisjunkt) mit unterschiedlicher Technik, Mesh-WLAN, NAS, Linux-Hypervisor und eine Menge an Netzwerkgeräten.

Was in Abb. 2 nicht dargestellt ist, jedoch häufig ebenfalls vorzufinden ist, sind zentral verwaltete Switches mit Spanning-Tree-Protokoll, VLAN-Segmentierung für unterschiedliche Geräteklassen, diverse Netzwerkzonen und unterschiedliche WLAN-Netze für Bewohner, Besucher und Geräte aus Küche und Keller.

Nun stellen wir uns alle kurz vor, was es für unsere Familie bedeutet, wenn ein Dienst bzw. eine App auf dem Smartphone oder Tablet nicht mehr wie gewohnt funktionieren, wir nicht verfügbar sind und sie sich mit einer solchen Infrastruktur konfrontiert sehen. Tipp: Fragt eure Familie, wie sie im Fall einer IT-Störung ohne euch vorgehen würde und wie sicher sie wäre, diese Situation zu bewältigen, ohne ein tiefes Tal der Tränen durchschreiten zu müssen.

Um es einmal deutlich zu machen, mit unserer Nichtverfügbarkeit meine ich unsere Abwesenheit durch Scheidung, Krankheit, Knast oder Tod. Auf uns zu warten ist keine Option.

Vereinfacht dargestellt, sieht sich unsere Familie nun mit folgenden Herausforderungen konfrontiert:

  • Wie finde ich heraus, wo der Fehler liegt bzw. was nicht mehr funktioniert?
  • Wie greife ich auf diese vielen unterschiedlichen Geräte zu und wo finde ich die Zugangsdaten?

Exkurs: Ich erzähle immer gerne die Anekdote, dass ich in meiner Ausbildung zum Fachinformatiker FR. Systemintegration in Privathaushalten die DSL-Internetzugänge eingerichtet habe. Wenn ich an der entscheidenen Stelle um die Internetzugangsdaten bat, wurde mir häufig der Ordner mit den Telefonrechnungen gegeben. Es bedurfte dann weiterer Erklärung, was ich brauche und wie dies aussieht. Manchmal stellte sich dann heraus, dass der entsprechende Brief als unwichtig erachtet und bereits entsorgt wurde.

Der kleine Exkurs macht deutlich, dass es für „normale Menschen“ schon bei einer einfachen Umgebung die Chance zum Scheitern gab und gibt. Viel Spaß mit der Spielwiese eures Nerds. Vielleicht nutzt eure Familie eure selbstgehosteten Dienste wie z.B. Paperless-NGX und sind sogar darauf angewiesen. Doch weiß sie, dass dieser Anwendung durch mehrere rootless Podman-Container bereitgestellt wird, die in einer virtuellen Maschine auf eurem Linux-Server laufen?

Dabei muss sich eure Familie für ihre Unkenntnis nicht schämen. Denn bei OPNsense, Linux-Hypervisor mit virtuellen Maschinen und Containern und einer nicht ganz so weit verbreiteten WLAN-Mesh-Lösung sind auch die meisten Support-Abteilungen der Internetdiensteanbieter, PC-Einzelhändler und Elektronikmärkte überfordert. Zwar können hier häufig professionelle Systemhäuser weiterhelfen, doch dann wird es schnell sehr teuer (bei Tagessätzen zwischen 800-1400 Euro).

Hypothese: Wir basteln gern und probieren gerne Dinge aus. Die wenigsten von uns pflegen einen Servicekatalog für die Dienste im Heimnetzwerk.

Das Risiko ist groß, dass eure Familie den Zugriff auf Dokumente, Familienfotos und die Haussteuerung verliert, wenn ihr nicht mehr verfügbar seid und ein Fehler auftritt.

Lösungsansätze

Doch wie bereiten wir unsere Familie nun auf unsere Nichtverfügbarkeit vor?

In meinen Augen gibt es nicht die eine Lösung, die überall funktioniert. Ich stelle euch im Folgenden meine Lösungsansätze vor. Falls ihr denkt, dass diese auch für euch funktionieren, dürft ihr sie selbstverständlich gerne übernehmen. Versteht sie als Anregung, ohne Anspruch auf Vollständigkeit und Fehlerfreiheit.

Zugangsdaten

Ich verwalte meine Zugangsdaten in KeePassXC. Meine Familie hat weder auf die Geräte Zugriff, wo die KeePassXC-Datenbank liegt, noch auf die Datenbank selbst.

Einen gemeinsamen Passwort-Manager zu verwenden, wo wir den Zugriff auf bestimmte Zugangsdaten teilen können, funktioniert für uns nicht. Unsere Nutzungsgewohnheiten sind dafür aktuell einfach zu unterschiedlich.

Daher drucke ich alle wichtigen Zugangsdaten aus und stecke sie in einen Umschlag. Zu den Zugangsdaten gehören auch die Backup-Codes für Konten mit Multi-Faktor-Authentifizierung. Der Umschlag wird verschlossen, über der Verschlusslasche wird das Datum notiert und es kommt noch ein transparenter Klebestreifen darüber. Das ist eine einfache Sicherung, um zu erkennen, ob der Umschlag geöffnet wurde. Aus meiner Erfahrung ist es nicht möglich, den Klebestreifen zu entfernen und den Umschlag zu öffnen, ohne dass die Beschriftung erheblichen Schaden nimmt. Der Umschlag selbst wird an einem uns wohlbekannten Ort hinterlegt.

Falls der Umschlag mal geöffnet wurde und es niemand gewesen sein will, oder er gar weg ist, bedeutet das für mich einen Einmalaufwand zur Zugangsänderung. Das nehme ich in Kauf.

Meine Familie kann so im Notfall an die wichtigsten Zugangsdaten gelangen und sich Zugriff verschaffen.

Ein Risiko ist damit nicht abgesichert, nämlich dass der Umschlag und ich beide nicht verfügbar sind. Dieses Risiko akzeptieren wir.

Der Inhalt des Umschlags wird immer dann aktualisiert, wenn sich wichtige Zugangsdaten geändert haben. Glücklicherweise passiert dies nur ca. 1-2 Mal im Jahr.

Die Dokumentation für den Notfall

Jeder Systemadministrator schätzt eine gute Dokumentation.
Kein Systemadministrator schreibt gerne Dokumentation.

Meine Meinung

Es hilft aber alles nichts. Ich habe zu diesem Thema bereits die Artikel Dokumentation für den Notfall bzw. das digitale Erbe und das Update dazu geschrieben. Für den Vortrag habe ich eine Version erstellt, in der ich unsere echten Daten durch Platzhalter und Beispiele ersetzt habe. Diese habe ich als Datei in diesen Artikel eingefügt.

Bispiel-DokumentationHerunterladen

Ich hoffe, in dieser Dokumentation den richtigen Ton getroffen zu haben, so dass diese sowohl meiner Familie, als auch einer hinzugerufenen Fachkraft hilft.

Den Schreibtischtest hat diese Dokumentation bestanden. Meine Frau hat diese Dokumentation gelesen und sie für hilfreich befunden. Eine Notfall-Übung steht jedoch noch aus.

Fazit

Wir Nerds denken und funktionieren zum Teil anders als unsere Familienangehörigen. Es ist sinnvoll, mit diesen über das Theme der eigenen Nichtverfügbarkeit zu sprechen und zu erörtern, welche Informationen diese im Notfall benötigen.

Einigt euch bei der Dokumentation und Hinterlegung von Informationen auf Formate und Orte, die für alle Beteiligten funktionieren. Unsere Angewohnheiten unterscheiden sich teils deutlich.

Haltet die Notfall-Dokumentation aktuell, sonst nützt sie nichts. Dies ist vermutlich der schwierigste Punkt.

Führt Übungen durch. Sonst ist es ein Schrödingers-Notfall-Konzept.

Nächstes Wochenende ist wieder FrOSCon

2 Antworten

Die Free and Open Source Software Conference bringt am 15.–16. August wieder Open‑Source‑Begeisterte aus ganz Europa an der Hochschule Bonn‑Rhein‑Sieg zusammen – und online!

URL: https://froscon.org

2 Tage, 7 Vortragsstränge + 2 Workshops parallel, Live‑Streams, Social Event & mehr, bei kostenlosem Eintritt.

Wo? In der Hochschule Bonn-Rhein-Sieg. Die Adresse für’s Navi: Grantham-Allee 20, 53757 Sankt Augustin. Das aktuelle Programm findet ihr unter der URL: https://programm.froscon.org/2026/

Die diesjährigen Keynotes werden in englischer Sprache gehalten:

Neben diesen möchte ich eure Aufmerksamkeit eigen- und uneigennützig auf folgende Vorträge in chronologischer Reihenfolge richten:

Dies ist natürlich nur eine kleine Auswahl. Und neben den Vorträgen und Workshops warten auch noch die Auststeller darauf, mit euch über ihre vielfältigen und tollen Open-Source-Projekte zu sprechen.

Möglich wird diese Konferenz durch die Unterstützung ihrer Partner und durch viele private Spenden. Vielen Dank allen Unterstüzenden!

Ich freue mich schon sehr und kann es kaum noch erwarten. Welchen Vorträgen oder Workshops seht ihr entgegen? Was gefällt euch an der FrOSCon und zieht euch nach Sankt Augustien? Schreibt es mir in die Kommentare.

Schwachstellen- und Patchmanagement im Jahre 2026

4 Antworten

In diesem Artikel thematisiere ich, wie sich die Anzahl der entdeckten Schwachstellen in den letzten Jahren entwickelt hat und ob wir noch von Zero-Day sprechen, oder eher von Zero-Hour oder Zero-Minute.

Ich werde darstellen, warum es in meinen Augen bis auf wenige Ausnahmen nicht mehr angemessen ist, nur noch einmal im Jahr oder quartalsweise zu patchen und unter Schmerzen eingeübte Prozesse heute nicht mehr zeitgemäß erscheinen.

Anschließend werde ich euch bitten, eure Erfahrungen anonym mit mir zu teilen. Ich erhoffe mir, so einen besseren Überblick über die Situation da draußen in den Rechenzentren, Serverräumen und IT-Betriebseinheiten zu gewinnen. Mehr dazu unten im Text.

Entwicklung der Bedrohungslage

Die Anzahl der pro Jahr gemeldeten Schwachstellen (CVE) steigt rasant, wie folgendes Diagramm in Abbildung 1 verdeutlicht.

Diagramm welches die Entwicklung der Schwachstellenanzahl pro Jahr für die Jahre 2003 bis 2025 darstellt. Erläuterungen dazu finden sich im Fließtext.
Abbildung 1: Grafische Darstellung der CVE-Metriken für die Jahre 2003 bis 2025 von: https://www.cve.org/About/Metrics

Während sich die Anzahl der CVE pro Jahr erstmalig im Zeitraum von 2016 bis 2017 von ca. 6.500 auf ca. 14.500 mehr als verdoppelt hat, kam es zuletzt in den Jahren 2021 bis 2024 zu einer Verdopplung. Diesmal hat sich die Anzahl jedoch von ca. 20.000 auf knapp über 40.000 gesteigert. Und diese Zahl steigt weiter. So wurden für das erste Quartal 2026 bereits 15.176 CVE gezählt.

Wenn sich dieser Trend fortsetzt, werden wir das Jahr 2026 mit deutlich mehr als 60.000 registrierten CVE abschließen. Das wären 5.000 CVE/Monat oder 164 CVE/Tag.

Gleichzeitig sinkt die mittlere Zeit von der Veröffentlichung eines CVE bis zu einem Exploit, wie Abbildung 2 zeigt.

Abbildung 2: Die mittlere Zeit zwischen der Veröffentlichung einer Schwachstelle und des Exploits sinkt stetig (schwarze Linie). Quelle: https://zerodayclock.com/ (letzter Abruf: 2026-06-28)

Lag die mittlere Zeit zwischen der Veröffentlichung eines CVE und des Exploits 2023 noch bei über 4 Monaten, ist diese auf 21,5 Tage im Jahr 2025 gesunken. Für 2026 wird diese sogar mit nur noch 3 Stunden angegeben.

Noch bedrohlicher wirkt die Lage, wenn man sich ansieht, für wie viele CVE noch am gleichen Tag oder sogar vor deren Veröffentlichung ein Exploit bekannt wird (siehe Abbildung 3). Man spricht hier auch von Zero-Day-Exploits.

Abbildung 3: Rate der Zero-Day-Exploits, gemessen in Prozent an der Anzahl CVE pro Jahr (rote Linie). Quelle: https://zerodayclock.com/ (letzter Abruf: 2026-06-28)

Im Jahr 2024 gab es für 47,9% der CVE einen Zero-Day-Exploit. Im Jahr 2025 war das bereits für mehr als die Hälfte der Fall, nämlich 53,6 %. Das Jahr 2026 ist noch in vollem Gange. Die Rate der Zero-Day-Exploits liegt mit bisher 76,9% nochmals deutlich höher.

Es wird für die Paketbetreuenden, Upstream-Entwickelnden und Software-Herstellenden Menschen immer herausfordernder, einen Patch bereitzustellen, bevor ein Exploit existiert und aktiv gegen verwundbare Systeme eingesetzt wird.

Klassische Ansätze funktionieren nicht mehr

Aus meiner beruflichen Tätigkeit als Red Hat TAM und als Sysadministator bei verschiedenen Unternehmen ist mir bekannt, dass unterschiedliche Unternehmen und Organisationen sehr verschieden mit Schwachstellen und deren Behandlung umgehen.

Allen ist gemein, dass sie für ihre Anwendungen Wartungsfenster vereinbaren, in denen z.B. Sicherheitsaktualisierungen installiert werden, um vorhandene Schwachstellen zu schließen. Einige haben einen Patchday pro Jahr, manche patchen einmal im Quartal und wieder andere monatlich. Einzelne Unternehmen können dies sogar noch schneller.

Die einen haben regelmäßig wiederkehrende Wartungsfenster, die anderen müssen diese bei Bedarf anmelden. Einige haben schlanke Prozesse, einige nutzen Change-Management nach ITIL.

Um die Integrität, Verfügbarkeit und Vertraulichkeit der eigenen Informationssysteme und deren umgebener Infrastruktur zu schützen, sind zwei Grundsätze seit vielen Jahren allgemein bekannt:

  1. Installiere verfügbare Sicherheitsaktualisierungen so schnell wie möglich.
  2. Nutze und implementiere Verteidigung in der Tiefe.

Die beiden Grundsätze stehen nicht in einer Entweder-Oder-Beziehung. Sie sollten beide berücksichtigt werden.

In meinen Augen ist es längst nicht mehr zeitgemäß, Sicherheitsaktualisierungen jährlich oder quartalsweise zu installieren. Eine kleine Ausnahme mögen hier Systeme bilden, deren Nutzerkreis stark eingeschränkt ist und auf die ausschließlich über wenige sehr gut gesicherte Kanäle zugegriffen werden kann.

Um es deutlich zu sagen: „Für wochen- oder tagelange Change-Management-Prozesse bleibt keine Zeit. Wer weiterhin so arbeitet, riskiert die Informationssicherheit seiner Umgebung.“

Wer alle seine Systeme einmal im Monat wartet und neustartet, bewegt sich in meiner Wahrnehmung aktuell im Mittelfeld dessen, was man im Feld findet. Doch auch hierauf darf sich niemand ausruhen. Existiert zu einem CVE ein Exploit und ein Patch, erscheint es fahrlässig, bis zu einem Monat mit dessen Installation zu warten.

Leider fehlt etlichen Unternehmen bzw. Organisationen noch immer die Fähigkeit schnell festzustellen, ob ihre IT-Dienste korrekt ausgeführt werden. Patch-Management-Zyklen sehen hier meist vor, dass zuerst einige Systeme aktualisiert werden, dann wartet man 1-2 Wochen, ob jemand meckert und dann aktualisiert man die restlichen Systeme. Das ist nicht mehr zeitgemäß.

Aus der eingangs beschriebenen Bedrohungslage folgend muss das neue Ziel lauten, jedes individuelle System an jedem Tag aktualisieren und neustarten zu können. Die Funktion von IT-Diensten ist durch automatisierte Mechanismen wie z.B. Monitoring oder automatisierte Tests zu verifizieren, um schnell mit der nächsten Stage fortfahren zu können. Wer dieses Ziel noch nicht erreicht hat, sollte sich schnellstens auf den Weg machen. Selbst wenn die 100% unerreichbar scheinen, ist jedes System, das man schnell absichern kann, ein deutlich geringeres Risiko für die eigene Informationssicherheit.

Wo Sicherheitsaktualisierungen nicht zeitnah eingespielt werden können, lässt sich das Risiko durch Verteidigung in der Tiefe minimieren. Kommunikationsverbindungen von und zu betrachteten Systemen sind zu überwachen und ggf. zu limitieren. Doch auch diese Maßnahmen müssen schnell verfügbar und umsetzbar sein. Wer erst zwei Wochen diskutieren muss, ob man den Zugriff auf einen Dienst einschränken könne, müsse, sollte, handelt nicht angemessen.

Zusammenfassend sehe ich unklare Verantwortlichkeiten, langwierige Abstimmungsprozesse und manuelle Tätigkeiten als Gift und Risiko für die Informationssicherheit. Klare Strukturen, geklärte Verantwortlichkeiten und Automation sind kein nice-to-have, sondern ein MUSS.

Wie geht ihr damit um?

Nun möchte ich von euch wissen: „Patcht ihr schon oder prozessiert ihr noch?“

Ich bin sehr daran interessiert zu erfahren, wie es in den Umgebungen meiner Lesenden und derer Bekannten zugeht. Daher freue ich mich sehr, wenn ihr (gern anonym) euer Patch-Management-Konzept, die Branche eures Unternehmens und die ungefähre Größe eurer Umgebung mit der Gemeinschaft bzw. mir teilt.

  • Ihr habt euer Patch-Management im eigenen (Firmen-)Blog beschrieben? Teilt bitte den Link in den Kommentaren.
  • Sendet mir gerne eine E-Mail an patchmanagement@my-it-brain.de.
  • Beschreibt euer Patch-Management in den Kommentaren unter diesem Beitrag.

Evtl. werde ich eure Beispiele anonymisiert unter ausschließlicher Nennung der Branche (falls bekannt) in Vorträgen, Diskussion und weiteren Arbeiten zu diesem Thema verwenden. Bitte schreibt ausdrücklich dazu, wenn ihr dies nicht wünscht.

Ich freue mich auf eure Beiträge, Zusendungen und wenn ihr diesen Artikel in euren Netzwerken teilt.

Kernel Live Patching für Red Hat Enterprise Linux (RHEL)

Schreibe eine Antwort

Dieser Artikel richtet sich an jene, die sich für das Thema Kernel Live Patching (KLP) interessieren.

Im ersten Teil des Artikels stelle ich dar, wann KLP in meinen Augen keine gute Lösung darstellt und man auf den Einsatz nach Möglichkeit verzichten sollte. Wissend, dass es manchmal nicht anders geht, beschreibe ich im zweiten Teil am Beispiel von RHEL 9, wie KLP eingerichtet und genutzt werden kann.

Transparenzhinweis: Ich arbeite als Technical Account Manager (TAM) für die Firma Red Hat, welche die Distribution Red Hat Enterprise Linux (RHEL) herausgibt. Dieser Artikel spiegelt meine persönliche Meinung wider, welche mit der meines Arbeitgebers übereinstimmen kann, dies jedoch nicht in jedem Fall muss.

Der Userspace wird in diesem Artikel ausgeklammert, um den Umfang nicht zu sprengen. Ich werde diesen in einem folgenden Artikel aufgreifen.

Warum bzw. wann man Kernel Live Patching nicht nutzen sollte

Folgende Gründe sollten nicht zur Nutzung von KLP führen, sondern auf andere Weise adressiert werden:

  • Angst vor dem Serverneustart
  • Eine Softwarearchitektur, die Serverneustarts nicht vorsieht/zulässt
  • Ungeklärte Abhängigkeiten in vernetzten Systemen
  • Der Glaube, mit KLP nie wieder neustarten zu müssen

Angst ist in der IT ein ganz schlechter Ratgeber. Hier sollte unbedingt die Ursache und nicht das Symptom behandelt werden. Denn Serverneustarts können auch noch aus folgenden Gründen passieren bzw. notwendig werden:

  • Der Server verliert vorübergehend die Stromversorgung
  • Eine Kernel Panic bringt das System zum Absturz
  • Ein nicht mehr reagierendes System muss durch einen Reset neugestartet werden
  • Umzug der Hardware an einen neuen Standort

Dies sind nur vier Gründe, die mir sofort in den Sinn kommen. Wenn wir länger darüber nachdenken, fallen uns bestimmt noch viele weitere ein (ergänzt diese gern in den Kommentaren). Wichtig ist zu verstehen, dass Serverneustarts aus verschiedenen Gründen passieren und per se nicht schlimm sind.

Wenn die Softwarearchitektur keine Neustarts einzelner Komponenten zulässt, hat man ein ganz anderes Problem, welches dringend adressiert werden sollte. Soetwas wie 100%-tige Verfügbarkeit gibt es nicht. Hier ist in meinen Augen zu klären, ob es wirklich an der Anwendung oder eher an nicht verhandelten Wartungsfenstern liegt. KLP ist hier keine Lösung, da die Häufigkeit von Neustarts nur reduziert bzw. das Problem in die Zukunft verschoben wird.

Viele Sysadmins sind faul und das ist gut so. Motiviert es diese Personengruppe doch, manuelle Tätigkeiten zu automatisieren und sich die Arbeit zu erleichtern. Diese Faulheit darf allerdings nicht dazu führen, dass man sich vor der Analyse komplexer und vernetzter Systeme drückt. Abhängigkeiten können analysiert und in den meisten Fällen aufgelöst werden. Sind sie bekannt, kann man sie im Patchprozess berücksichtigen und den Vorgang inkl. Neustarts automatisieren. Auch in diesem Fall verzögert KLP das Unvermeidliche nur.

Kernel Live Patching kümmert sich, wie der Name schon sagt, nur um den Kernel. Was ist mit dem Userspace? Auch hier gibt es sicherheitskritische Bibliotheken und Anwendungen, wie z.B. openssl, gnutls oder die glibc, welche bei erkannten Schwachstellen zeitnah abgesichert werden müssen, um die Sicherheit des Systems nicht zu gefährden.

Neustarts sind per se nicht schlecht. Wer seine Server regelmäßig neustartet, gewinnt Vertrauen, dass diese auch wieder hochfahren und ihre Dienste korrekt erbringen. Schlummernde Probleme werden schneller erkannt und türmen sich nicht zu einem Störfall auf, der nur darauf wartet, im ungünstigsten Moment zu passieren. Und im Optimalfall sind die Dienste so entworfen worden, dass der Ausfall/Neustart eines einzelnen Servers nicht automatisch zu einer Nichtverfügbarkeit des Dienstes führt.

Ich möchte mein Plädoyer für Serverneustarts an dieser Stelle beenden und mich zwei Szenarios zuwenden, in denen KLP die Schmerzen des IT-Betriebs lindern kann.

Wann Kernel Live Patching Sinn macht

Für besonders geschäftskritische IT-Dienste existieren häufig Service-Level-Agreements (SLA), die eine sehr hohe Verfügbarkeit garantieren. Verstöße gegen diese SLA werden von den Stakeholdern meist nicht toleriert und sind in manchen Fällen mit Vertragsstrafen belegt. Zwar gilt auch hier, dass das Problem eher in der Softwarearchitektur liegt, doch hilft dies den Sysadmins nicht, die mit dem Betrieb beauftragt sind. Sie müssen irgendwie damit umgehen, bis eine bessere Lösung gefunden wird. Hier kann KLP eine Notlösung sein, um Sicherheitsrisiken im Betrieb zu reduzieren und SLA-Verstöße zu vermeiden.

Angelehnt an die SLA spielt die Zeit, die ein Server für einen Neustart benötigt, eine Rolle. Während die meisten VMs in Sekunden oder 1-2 Minuten neustarten, dauert dieser Vorgang bei Hardwareservern manchmal deutlich länger. Im Feld werden hier vereinzelt Zeiten zwischen 10-20 Minuten beobachtet (pro Server). Müssen mehrere Server für einen IT-Dienst sequentiell neugestartet werden, summieren sich die Zeiten schnell auf und machen größere Wartungsfenster erforderlich. KLP kann helfen, die Anzahl der langen Wartungsfenster zu reduzieren.

Es gibt Systeme, für deren Start ein manueller Eingriff durch Sysadmins notwendig ist. Dies kann z.B. die Eingabe eines BIOS-, Grub-, LUKS- oder UEFI-Passworts sein. Dies ist aufwändig und lästig, lässt sich aber leider nicht in allen Fällen wegautomatisieren. Auch hier erscheint es legitim, die Anzahl der manuellen Eingriffe durch den Einsatz von KLP zu minimieren.

Kernel Live Patching für RHEL 9 konfigurieren

Um mich für die Konfiguration vorzubereiten, habe ich folgende drei Quellen studiert:

Die wichtigsten Erkenntnisse daraus sind für mich:

  • Nicht jeder RHEL-Kernel erhält Live-Patches
  • An jedem 1. März, Juni, September und Dezember (jedes Quartal) wird für jedes unterstützte RHEL-Release ein Kernel festgelegt, welcher Live-Patches erhält
  • Für jeden dieser Kernel verspricht Red Hat bis zu einem Jahr lang Updates für CVEs, die nach Red Hats Ermessen als critical oder important kategorisiert wurden (siehe Severity Ratings)

Dass Red Hat für ausgewählte Kernel-Releases ein Jahr lang Live-Patches bereitstellt, lässt nicht den Schluss zu, nur noch einmal pro Jahr neustarten zu müssen. Denn:

  • CVEs der Kategorien moderate und low werden gar nicht adressiert
  • Man erhält keinerlei Bugfixes und keinerlei Produktverbesserungen (Red Hat Enhancement Advisories (RHEA))

Die Planung eines Neustarts wird jedoch ggf. vereinfacht.

Konfiguration von Kernel Live Patching für ein Labor-System

Ich habe ein Labor-System mit RHEL 9 auserkoren, welches als Hypervisor für einige Libvirt/KVM-VMs genutzt wird.

Dieses läuft aktuell mit dem Kernel 5.14.0-687.15.1.el9_8.x86_64, welcher laut Kernel Live Patch life cycles kein Kernel ist, für den KLP angeboten wird. Es ist also zuerst der kernel-5.14.0-687.10.1 zu installieren. Anschließend folge ich der Dokumentation, um den Live-Patch-Stream für diesen Kernel zu aktivieren (siehe folgender Codeblock).

~]$ sudo dnf search kernel-5.14.0-687.10.1.el9_8
Updating Subscription Management repositories.
Last metadata expiration check: 0:04:34 ago on Tue 23 Jun 2026 11:31:09 AM CEST.
================ Summary Matched: kernel-5.14.0-687.10.1.el9_8 ================
kpatch-patch-5_14_0-687_10_1.x86_64 : Initial empty kpatch-patch for
                                    : kernel-5.14.0-687.10.1.el9_8.x86_64
~]$ sudo dnf install kpatch-patch-5_14_0-687_10_1.x86_64

Wie im obigen Codeblock zu sehen, handelt es sich dabei um den initialen und leeren kpatch-patch. Das System hat also noch keinen Fix erhalten, sondern ist lediglich darauf vorbereitet.

Im jetzigen Zustand würde DNF das System bei einem Update jedoch auf die letzte verfügbare Kernelversion aktualisieren, welche keine Live-Patches erhält. Da dies von mir nicht gewünscht ist, aktiviere ich einen Filter, der zukünftig nur noch KLP-fähige Kernel anzeigt. Der folgende Codeblock zeigt den Zustand vor der Aktivierung des Filters, die Aktivierung selbst und den Zustand danach.

~]$ sudo dnf kpatch status
Updating Subscription Management repositories.
Last metadata expiration check: 0:04:36 ago on Tue 23 Jun 2026 11:43:44 AM CEST.
Kpatch update setting: auto-update
Kpatch filter setting: no-filter
Dependencies resolved.
Nothing to do.
Complete!

~]$ sudo dnf kpatch auto-filter
Updating Subscription Management repositories.
Kpatch filter setting: auto-filter

~]$ sudo dnf kpatch status
Please note, kpatch filter is enabled, only kpatch supported kernels are shown.
Kpatch update setting: auto-update
Kpatch filter setting: auto-filter
Dependencies resolved.
Nothing to do.
Complete!

Zum Abschluss ein Neustart und mein System läuft mit dem richtigen Kernel 5.14.0-687.10.1.el9_8.x86_64.

Aufräumarbeiten

Aktuell sind auf meinem System noch Kernel-Pakete installiert, die für KLP nicht vorgesehen sind, aber bei einem dnf update aktualisiert werden würden:

~]# dnf list --installed kernel*
Updating Subscription Management repositories.
Please note, kpatch filter is enabled, only kpatch supported kernels are shown.
Installed Packages
kernel.x86_64              5.14.0-611.55.1.el9_7 @rhel-9-for-x86_64-baseos-rpms
kernel.x86_64              5.14.0-687.10.1.el9_8 @rhel-9-for-x86_64-baseos-rpms
kernel.x86_64              5.14.0-687.15.1.el9_8 @rhel-9-for-x86_64-baseos-rpms
kernel-core.x86_64         5.14.0-611.55.1.el9_7 @rhel-9-for-x86_64-baseos-rpms
kernel-core.x86_64         5.14.0-687.10.1.el9_8 @rhel-9-for-x86_64-baseos-rpms
kernel-core.x86_64         5.14.0-687.15.1.el9_8 @rhel-9-for-x86_64-baseos-rpms
kernel-devel.x86_64        5.14.0-611.38.1.el9_7 @rhel-9-for-x86_64-appstream-rpms
kernel-devel.x86_64        5.14.0-611.55.1.el9_7 @rhel-9-for-x86_64-appstream-rpms
kernel-devel.x86_64        5.14.0-687.15.1.el9_8 @rhel-9-for-x86_64-appstream-rpms
kernel-headers.x86_64      5.14.0-687.15.1.el9_8 @rhel-9-for-x86_64-appstream-rpms
kernel-modules.x86_64      5.14.0-611.55.1.el9_7 @rhel-9-for-x86_64-baseos-rpms
kernel-modules.x86_64      5.14.0-687.10.1.el9_8 @rhel-9-for-x86_64-baseos-rpms
kernel-modules.x86_64      5.14.0-687.15.1.el9_8 @rhel-9-for-x86_64-baseos-rpms
kernel-modules-core.x86_64 5.14.0-611.55.1.el9_7 @rhel-9-for-x86_64-baseos-rpms
kernel-modules-core.x86_64 5.14.0-687.10.1.el9_8 @rhel-9-for-x86_64-baseos-rpms
kernel-modules-core.x86_64 5.14.0-687.15.1.el9_8 @rhel-9-for-x86_64-baseos-rpms
kernel-tools.x86_64        5.14.0-687.15.1.el9_8 @rhel-9-for-x86_64-baseos-rpms
kernel-tools-libs.x86_64   5.14.0-687.15.1.el9_8 @rhel-9-for-x86_64-baseos-rpms

Um aufzuräumen, habe ich alle überflüssigen Pakte entfernt, bis nur noch der KLP-fähige Kernel vorhanden ist:

~]# dnf list --installed kernel*
Updating Subscription Management repositories.
Please note, kpatch filter is enabled, only kpatch supported kernels are shown.
Installed Packages
kernel.x86_64                5.14.0-687.10.1.el9_8   @rhel-9-for-x86_64-baseos-rpms
kernel-core.x86_64           5.14.0-687.10.1.el9_8   @rhel-9-for-x86_64-baseos-rpms
kernel-modules.x86_64        5.14.0-687.10.1.el9_8   @rhel-9-for-x86_64-baseos-rpms
kernel-modules-core.x86_64   5.14.0-687.10.1.el9_8   @rhel-9-for-x86_64-baseos-rpms

Verhalten bei zukünftigen Updates

Durch den konfigurierten kpatch-Filter werden bei zukünftigen Updates nur Kernel aufgeführt, die KLP-fähig sind. Wird ein KLP veröffentlicht, erscheint dieser als kpatch-patch in der Ausgabe von dnf up`. Der folgende (gekürzte) Codeblock zeigt dies beispielhaft.

~]# dnf up
Updating Subscription Management repositories.
Please note, kpatch filter is enabled, only kpatch supported kernels are shown.
Dependencies resolved.
===================================================================================
 Package       Arch   Version               Repository                        Size
===================================================================================
Upgrading:
…
kpatch-patch-5_14_0-687_10_1 x86_64 1-1.el9_8 rhel-9-for-x86_64-baseos-rpms   22 k
…

Mit dem Befehl aus dem nächsten Codeblock kann kontrolliert werden, welche KLP aktuell installiert sind und welche CVEs sie adressieren.

~]# kpatch list
Loaded patch modules:
kpatch_5_14_0_687_10_1_1_1 [enabled]
	CVE-2026-43037

Installed patch modules:
kpatch_5_14_0_687_10_1_1_1 (5.14.0-687.10.1.el9_8.x86_64)

Obige Ausgabe bestätigt, dass ein KLP aktiv ist, der die kritische Schwachstelle CVE-2026-43037 schließt.

Fazit

KLP funktioniert und ist einfach einzurichten. Es ist nicht in jedem Fall die richtige Lösung und löst nicht alle Probleme, kann jedoch in manchen Fällen die Schmerzen im IT-Betrieb lindern.

Der Userspace wurde ausgeklammert, um den Umfang dieses Artikels nicht zu sprengen. Dies hebe ich mir für einen folgenden Artikel auf.

Oh Schreck – FrOSCon 2026

Schreibe eine Antwort

Den Lesenden dieses Blogs ist die FrOSCon sicherlich ein Begriff. Allen Neuzugängen sei kurz erklärt, das es sich dabei um die Free and Open Source Conference handelt, welche jedes Jahr im August an der Hochschule Bonn-Rhein-Sieg mit Hilfe des FrOSCon e.V. ausgerichtet wird.

Für viele meiner Bekannten und Freunde aus der FLOSS-Gemeinschaft ist es soetwas wie ein Familientreffen. Neben dem Wiedersehen vieler vertrauter Gesichter lockt auch ein Vortragsprogramm, welches stets mit interessanten Vorträgen zu unterschiedlichen Themen gefüllt ist. Dieses Jahr gab es 190 Einreichungen aus denen 77 Vorträge und 12 Workshops ausgewählt wurden. Ich freue mich schon darauf das Programm zu durchstöbern, welches voraussichtlich im Juli veröffentlicht wird.

Zumindest für mich war der Schreck groß, als die FrOSCon am 21. Mai ihre finanziellen Sorgen auf Mastodon teilte.

Screenshot des FrOSCon-Hilferufs mit dem Text: "Liebe FOSS-Community, die angespannte Lage in der IT-Wirtschaft führt dazu, dass viele unserer Partner dieses Jahr keinen Stand buchen. In Folge fehlt uns Budget für die Konferenz, u.a. für Veranstaltungstechnik, Messewände, Vortragsstreaming, Kinder- und Jugendprogramm, Helfer:innen-Verpflegung, Transportkosten, Versicherungen Wir suchen insbesondere Konferenzpartner und auch noch einen Kaffeepartner"
Bildschirmfoto des Hilferufs vom 12. Mai 2026 auf Mastodon

In der Folge haben viele FLOSS-Freunde bereits bei ihren Arbeitgeber:innen um Unterstützung gebeten und auch selbst gespendet. Meine Erleichterung war entsprechend groß, als bereits zwei Wochen später die gute Nachricht geteilt wurde: „Die Konferenz findet statt!“

dekorativ
Bildschirmfoto der Meldung vom 27. Mai, dass die Konferenz stattfindet

Das Spendenziel ist allerding noch nicht erreicht. Daher bitte ich alle, die diese Veranstlatung kennen, schätzen, gerne besuchen oder ein bisschen Geld für gemeinnützige Projekte erübrigen können, über einen dieser Wege zu spenden.

Darüber hinaus könnt ihr die Konferenz auch unterstützen, indem ihr ein Businessticket kauft.

Ich möchte an dieser Stelle dem Veranstaltungsteam für dessen Ausdauer, Einsatz und Zeit danken, damit diese Konferenz jedes Jahr stattfinden kann. Ich danke auch den diesjährigen Partnern der FrOSCon, welche die Konferenz auch in einer wirtschaftlich angespannten Zeit unterstützen.

Ich freue mich schon heute auf das Wiedersehen im August.

2. Erfahrungsbericht zum Reise-Router GL.iNet GL-A1300 mit OpenWrt und Travelmate

6 Antworten

Ein Wohnmobil, drei Reisende, vier Tage und fünf internetfähige Geräte (von denen wir wissen). Diese bilden den Rahmen für den zweiten Erfahrungsbericht zu meinem Reise-Router GL.iNet GL-A1300 mit OpenWrt und Travelmate.

Nach unserem Kurzurlaub habe ich meine Frau gefragt, ob sie den kleinen Reise-Router nützlich fand. Die Antwort war ein klares Ja. Es hat ihr gefallen, dass wir den kleinen Router nur mit einem USB-Anschluss versorgen und mit einem Uplink verbinden mussten und alle unsere internetfähigen Geräte waren ohne weitere Konfiguration wieder online. Das freut mich sehr, denn genau dies war der erhoffte Effekt.

Mir ist aufgefallen, dass ich das LuCI-Webinterface nicht mit den Webbrowsern meines Android-Smartphones aufrufen kann, mit denen meines Android-Tablets aber schon. Ich nutze auf beiden Firefox und Firefox Klar. Falls jemand eine Erklärung, für dieses Mysterium hat, freue ich mich über einen Kommentar.

AdBlock Fast klemmte zu Beginn. Ein apk update gefolgt von einem apk upgrade auf der CLI löste das Problem jedoch schnell in Luft auf.

An Plätzen, an denen kein Uplink-WLAN verfügbar war, habe ich den mobilen Hostspot meines Smartphones als Uplink benutzt. Auch dies hat gut funktioniert. Da sich das Smartphone meist in meiner Hosentasche befindet, habe ich mich einige Male damit aus der Reichtweite des Reise-Routers entfernt. Dramatisch war auch dies nicht, wurde jedoch umgehend durch humanoide Überwachungssysteme angezeigt. ;-)

Natürlich hat GL.iNet mit dem Mudi 7 (GL-E5800) auch für dieses Luxusproblem eine Lösung im Angebot. Allerdings sind mir die ca. 425 Euro für diesen Luxus etwas zu viel. Kennt ihr Alternativen, die über ähnliche Funktionen verfügen? Also klein, kompakt und fähig eine SIM-Karte zu tragen? Dann teilt diese doch bitte in den Kommentaren.

Der Reise-Router hat sich während einer Dienstreise und einer viertägigen Urlaubsreise bewährt und wird uns bzw. mich auch zukünftig auf diesen Reisen begleiten.

Vorstellung von 2,5 großartigen Open-Source-Projekten

Schreibe eine Antwort

Getreu dem Motto „Nutze Gutes und schreibe darüber“ stelle ich im heutigen Beitrag die Open-Source-Projekte lab-toolbox, kcli und kcli-toolbox vor.

Lab-toolbox

Die lab-toolbox ist ein Projekt von meinem TAM-Kollegen Chris Huang. Es handelt sich dabei um ein Python-Skript, welches die Erstellung von virtuellen Maschinen (VM) mit Red Hat Enterprise Linux (RHEL) unter KVM/QUEMU vereinfacht und beschleunigt.

Hinter der Idee zu diesem Projekt steckt dieser Anwendungsfall:

Als Plattform-TAMs müssen wir regelmäßig Dinge unter verschiedenen RHEL-Versionen testen. Häufig muss hierzu eine frische VM auf unserem Laptop herhalten, die nach dem Test auch direkt wieder entsorgt werden kann. Dies kann nun bspw. mit dem folgenden Kommando erledigt werden:

./create_vm.py --rhel 10 --hostname rhel10-1 --memory 4096 --vcpus 2

Mit diesem einen Befehl werden folgende Aufgaben ausgeführt:

  1. Es wird das aktuelle RHEL 10 Image auf der lokalen Festplatte genutzt, um eine RHEL 10 VM mit 4 GB RAM und 2 vCPU zu erstellen
  2. Das Skript fragt nach einem Passwort für den Konsolen-Login oder bietet an, sich ausschließlich per SSH einzuloggen
  3. Es generiert automatisch die Konfiguration für cloud-init, um:
    • den aktuellen Benutzer innerhalb der neuen VM zu erstellen
    • den SSH-Public-Key des Benutzers hinzuzufügen (automatisch oder per Option)

Ist die VM erstellt, können wir uns direkt mit unserem Benutzer und dessen SSH-Schlüssel einloggen.

Es gibt im Internet viele Wrapper-Skripte, welche die Einrichtung von lokalen VMs vereinfachen sollen. Mir gefällt an diesem besonders, dass es einen meiner häufigsten Anwendungsfälle auf den Punkt bedient. Dazu gibt es ein ausführliches README.md mit einer ausführlichen Dokumentation und einigen Beispielen.

Danke Chris, dass du dieses tolle Projekt mit uns teilst.

Kcli

Wenn es ein bischen mehr sein darf und z.B. folgende Funktionen gewünscht sind:

  • Deplyoment von Cloud-Images bei verschiedenen Providern (z.B. libvirt, KubeVirt, oVirt, OpenStack, VMware vSphere, AWS, Azure, GCP, IBM cloud and Hcloud) mit einem einzigen Werkzeug
  • Profile, um VMs mit der gleichen Hardware-Charakteristik zu starten
  • Komplette Labor-Umgebungen in YAML deklarieren und ausrollen
  • Große Auswahl an Cloud-Images verschiedener Linux-Distributionen
  • Einfache Verteilung und Integration von SSH-Schlüsseln
  • Automatische Registrierung von RHEL-VMs

Dann ist das Projekt kcli von meinem Kollegen Karim Boumedhel und vielen weiteren Beitragenden vielleicht etwas für euch. Wenn ihr jetzt neugierig geworden seid, werft für weitere Informationen einen Blick in die Dokumentation.

Als TAM und Sysadmin möchte ich auch komplexe Systeme testen, welche häufig aus mehreren VMs bestehen. Da mein Laptop hier schnell an seine Grenzen stößt, möchte ich diese Laborumgebungen auch bei anderen Anbietern bereitstellen können. Hierfür scheint mir dieses Projekt gut geeignet zu sein.

Kcli-toolbox

Dies ist der 0,5-Anteil der Vorstellungen in diesem Artikel. Damit ist nicht gemeint, dass es erst zur Hälfte fertig ist. Es ist vielmehr kein richtiges Projekt, sondern lediglich ein Containerfile und ein Custom-Toolbox-Build.

Toolbx ist ein Werkzeug für Linux, welches ein CLI für Softwareentwicklung und Troubleshooting bereitstellt, ohne dass ihr dafür alle notwendigen Werkzeuge auf eurem Host-System installieren müsst. Eine Toolbox basiert auf einem OCI-Container-Image. Es gibt sie in verschiedenen Geschmacksrichtungen. Bitte schaut für weitere Informationen in die Dokumentation.

Bei kcli-toolbox handelt es sich um ein Toolbox-Container-Image, bei dem kcli schon vorinstalliert ist. Das Image wird jeden Dienstag um 03:42 Uhr Ortszeit neu gebaut, um es auf einem aktuellen Stand zu halten.

Mir enthält der Abschnitt „Container Install“ der kcli-Dokumentation zu viele Optionen und aliases, die ich mir nicht merken möchte. Die Builds für EPEL-9 schlagen seit einiger Zeit fehl, so dass ich unter RHEL 9 nicht die letzte Version als RPM nutzen kann. Daher kam mir die Idee zu kcli-toolbox. Ich habe hiermit die aktuellste Version für Fedora 44 und kann diese so natürlich nutzen, als wäre sie als RPM-Paket installiert.

Probiert es doch gerne selbst einmal aus. Hinweise dazu findet ihr in der README.md.

Proof of Concept: Abfrage der nicht mehr unterstützten AppStreams über die Red Hat Lifecycle API

Schreibe eine Antwort

Im Folgenden möchte ich euch einen Proof of Concept (PoC) vorstellen, der aus einem Gespräch mit einem meiner Kunden entstanden ist.

AppStreams != AppStream

Es geht hier nicht um den offenen Standard AppStream, sondern um die in RHEL 8 und RHEL 9 genutzten AppStreams. Letztere sind ein inzwischen abgekündigtes Konzept zur Bereitstellung verschiedener Paketversionen mit einem definierten Unterstützungszeitraum innerhalb eines Major-Release. Für weitere Informationen hierzu siehe den englischsprachigen Artikel: Red Hat Enterprise Linux Application Streams Life Cycle.

Das Risiko

  • Pakete aus AppStreams werden auf Servern installiert.
  • Die Unterstützung dieser AppStreams endet und niemand merkt es.
  • Es wird Software in der Infrastruktur betrieben, die nie wieder ein Update erhält.

User Story

Im IT-Betrieb möchten wir die Lebenszyklusinformationen der AppStreams über eine API abfragen, deren Unterstützungszeitraum abgelaufen ist. Diese Liste möchten wir mit den auf unseren Servern installierten AppStreams abgleichen, um die Installationen zu identifizieren, die aktualisiert oder migriert werden müssen.

Lösungsansatz

Die gewünschten Informationen können über die Red Hat Lightspeed for RHEL Planning API abgerufen werden.

Wer seine Systeme an der Hybrid Cloud Console registriert hat, kann mit den abgelaufenen AppStreams gleichzeitig eine Liste der Systeme abrufen, auf denen diese installiert sind. Wer seine Systeme dort nicht registriert hat, kann die abgelaufenen AppStreams abfragen und die Informationen mit eigenen Mitteln weiterverarbeiten, um einen Abgleich durchzuführen.

Zur Demonstration habe ich einen Proof of Concept erstellt:

Die Repos beinhalten eine README.md mit der Dokumentation des Bash- und Python-Skripts sowie Links zu weiterführenden Informationen.

Falls euch dieses Beispiel gefällt, gebt ihm doch gerne einen Stern im jeweiligen Repository oder hinterlasst hier einen Kommentar.

Was gibt es dazu sonst noch wissenswertes?

Die in RHEL Lightspeed enthaltene Roadmap/Lifecycle-Anwendung verhält sich für einige User unerwartet. Als installiert werden AppStreams angezeigt, die auf einem System aktiviert sind. Dies ist auch der Fall, wenn ein Module Stream lediglich aktiviert ist, aber kein RPM-Paket aus diesem Stream tatsächlich installiert wurde. Dies kann zu einer Fehlinterpretation führen.

Red Hat liegt ein Feature Request vor, um dieses Verhalten zu ändern und nur AppStreams aufzuführen, deren RPM-Pakete tatsächlich installiert wurden. Mir liegen keine Informationen vor, ob und wann Red Hat dies umsetzen wird.

Des Weiteren liegt Red Hat die Anfrage vor, die Lightspeed Planning App als on-premises App im Satellite bereitzustellen. Auch hier kann ich leider nicht vorhersagen, ob und wann dies umgesetzt wird.

Falls ihr euch dafür interessiert, nehmt bitte Kontakt zum Red Hatter eures Vertrauens auf.