Den Support-Lebenszyklus eines Betriebssystems prüfen, bevor Automatisierung darauf aufsetzt

Ziel

Bevor ein Agent Patching, Upgrades oder eine Compliance-Prüfung auf einem Host automatisiert, ist zu bestätigen, dass die Betriebssystemversion des Hosts noch innerhalb des Support-Zeitraums des Herstellers liegt. Ist das nicht der Fall, muss der Host deutlich markiert werden.

Voraussetzungen

Betriebssystem und Version müssen sich ermitteln lassen (siehe den Begleitartikel zur Erkennung des Betriebssystems aus einem Skript). Ausserdem ist Netzwerkzugriff auf die vom Hersteller veröffentlichte Lifecycle-Seite oder eine lokal zwischengespeicherte Kopie der relevanten Daten nötig.

Schritte

1. Zuerst Betriebssystemfamilie und genaue Version bzw. genauen Release ermitteln (Distributionsname, Hauptversion und, bei Produkten mit Point-Release-Zählung, auch die Nebenversion).
2. Als primäre Quelle die Lifecycle-Angaben des Herstellers selbst heranziehen, nicht die eines Drittanbieters:
   • RHEL: Die Seite von Red Hat zur Richtlinie für Paketaktualisierungen und Errata-Support beschreibt die Phasen jedes Major Release und deren Dauer.
   • Ubuntu: Die Seite zum Release-Zyklus von Ubuntu unterscheidet Standard-Releases (9 Monate) von LTS-Releases (5 Jahre Standard-Support, verlängerbar).
   • Debian: Die Seite zu den Stable-Releases nennt, welcher Release aktuell ist, und verzeichnet den Zeitpunkt, ab dem ein Release keine Updates mehr erhält. Das separate Projekt Debian LTS verlängert den Sicherheitssupport für einige Architekturen weiter.
   • Windows / Windows Server: Die Website der Microsoft Lifecycle Policy nennt feste und moderne Lifecycle-Daten pro Produkt und Servicing-Kanal.
   • AIX: Die Support-Seiten von IBM veröffentlichen die Support-Lifecycle-Daten der AIX Technology Levels (TL).
   • FreeBSD: Die Seite Security Information listet auf, welche Branches derzeit Sicherheitspatches erhalten.
   • macOS: Apple veröffentlicht keinen festen End-of-Life-Plan. In der Praxis liefert Apple üblicherweise Sicherheitsupdates für den aktuellen und die beiden vorherigen Releases, wobei die beiden älteren oft nur einen Teil der Korrekturen erhalten. Nachverfolgt wird dies nicht in einem offiziellen Kalender, sondern von Drittanbieter-Aggregatoren wie endoflife.date.
3. Die Version des Hosts mit den gefundenen Daten vergleichen. "Nicht feststellbar, kein veröffentlichtes Datum gefunden" gilt dabei als "zur Prüfung markieren", nicht als "Support wird angenommen".
4. Datum der Prüfung, konsultierte Quelle und resultierenden Status (unterstützt / EOL naht / EOL überschritten) zusammen mit dem Inventareintrag des Hosts festhalten.
5. Bei einem Host nach dem End-of-Life verhindern, dass automatisierte Patch- und Compliance-Workflows für diesen Host einen einwandfreien Zustand melden. Stattdessen ist er als Befund auszuweisen, der eine Entscheidung erfordert (Upgrade, Ersatz oder dokumentierte Risikoakzeptanz).

Erwartetes Ergebnis

Für jeden Host im Geltungsbereich liegt ein dokumentierter, datierter Lifecycle-Status mit benannter Quelle vor. Hosts nach dem End-of-Life sind sichtbar markiert und nicht stillschweigend in Zusammenfassungen wie "alles gepatcht" enthalten.

Grenzen und Prüfbasis

Lifecycle-Seiten der Hersteller ändern sich. Ein zwischengespeichertes Datum sollte daher regelmässig neu verifiziert und nicht als dauerhaft gültig behandelt werden. Weil Apple keine EOL-Richtlinie veröffentlicht, ist der macOS-Status zwangsläufig eine Schlussfolgerung und keine dokumentierte Tatsache; in Berichten ist er entsprechend zu kennzeichnen. Diese Methodik klärt nicht, ob ein EOL-Host derzeit ausgenutzt wird, sondern nur, dass er keine Korrekturen mehr erhalten wird. Das ist eine eigene, vorgelagerte Frage, die eine Automatisierung nicht überspringen sollte.