TuxCare ELS: Alte Linux-Versionen kontrolliert weiterbetreiben

Was TuxCare ELS ergänzt

Endet die reguläre Wartung einer Linux-Distribution, erhält ein Server nicht zwangsläufig weiterhin Sicherheitsupdates über die bisherigen Paketquellen. Das ist besonders problematisch, wenn eine Fachanwendung noch an die alte Umgebung gebunden ist. Erweiterter Support kann Zeit für eine kontrollierte Umstellung schaffen, ohne das Ende der regulären Wartung rückgängig zu machen.

TuxCare Endless Lifecycle Support for OS stellt für unterstützte ältere Distributionen Sicherheitsupdates und ausgewählte Fehlerkorrekturen bereit. Laut Hersteller umfasst das Angebot den Kernel und eine distributionsabhängige Auswahl wichtiger Pakete. Es installiert keine neue Linux-Hauptversion: Der Server bleibt auf seiner bisherigen Distributionsversion und erhält für abgedeckte Komponenten zusätzliche Wartung.

Für den Betrieb kann das eine wichtige Übergangslösung sein: Statt eine inkompatible Anwendung sofort umstellen zu müssen, lässt sich die Migration vorbereiten, während verfügbare Sicherheitskorrekturen für abgedeckte Pakete eingespielt werden. Voraussetzung ist allerdings, dass die tatsächlich benötigten Pakete, die Architektur und das gewählte Angebot zusammenpassen.

Die Paketabdeckung ist nicht mit der Sicherheit des gesamten Servers gleichzusetzen. Eine selbst installierte Anwendung, eine Erweiterung oder ein Dienst aus einer anderen Paketquelle kann außerhalb des OS-Angebots liegen. Auch Konfigurationsfehler und unnötig erreichbare Dienste verschwinden nicht durch ein Abonnement; sie müssen weiterhin geprüft und abgesichert werden.

Auch bei abgedeckten Paketen ist der Schweregrad relevant: TuxCare sieht Sicherheitskorrekturen für hohe und kritische Risiken ab CVSS 7 vor. Bei mittleren Risiken von CVSS 4,0 bis 6,9 kommen Patches laut Anbieter in Betracht, wenn keine Mitigation verfügbar ist und genügend Kundennachfrage besteht. TuxCare behält sich zudem vor, statt einer direkten Codekorrektur eine Mitigation anzubieten. Ein abgedecktes Paket bedeutet daher nicht, dass jede darin bekannte Schwachstelle behoben wird.

Entscheidend ist deshalb nicht nur, ob die Distribution auf einer Supportliste steht. Für Linux Security zählt, welche Komponenten auf dem konkreten Server eingesetzt werden, ob passende Korrekturen bereitstehen und ob diese tatsächlich installiert sind. ELS ergänzt den Patchprozess, ersetzt aber weder die Bestandsaufnahme noch einen Migrationsplan.

Abdeckung und Serverinventar prüfen

Vor der Auswahl von TuxCare ELS steht ein Serverinventar. Erfasse Distribution und genaue Version, Architektur und laufenden Kernel. Dokumentiere außerdem die eingerichteten Paketquellen und die öffentlich oder aus anderen Netzen erreichbaren Dienste. So lässt sich die Herstellerliste mit dem tatsächlichen System vergleichen, statt nur den Namen der Distribution abzuhaken.

Bei einem älteren Webserver gehören beispielsweise Webserver-Paket, Kryptobibliotheken, PHP-Laufzeit und benötigte PHP-Erweiterungen in die Bestandsaufnahme. Halte jeweils fest, woher das Paket stammt und welche Fassung installiert ist. Eine Erweiterung aus einem Fremd-Repository kann andere Wartungsbedingungen haben als ein Paket aus der ursprünglichen Distribution.

Gleiche diese Komponenten einzeln mit der aktuellen Paketliste für die betreffende Distribution ab. Prüfe auch die Architektur und die Bedingungen des vorgesehenen Angebots. Eine unterstützte Distribution bedeutet nicht, dass jedes dort installierte Paket oder jede Version einer Laufzeit automatisch von ELS for OS abgedeckt wird. Selbst bei abgedeckten Paketen hängt die Behandlung einzelner Schwachstellen unter anderem vom Schweregrad ab.

Besonders leicht übersehen werden selbst kompilierte Programme und separat installierte Laufzeitumgebungen. Auch ein Container-Image bringt eigene Komponenten mit: Die Wartung des Host-Betriebssystems belegt nicht, dass die Pakete im Image aktualisiert sind. Für solche Bestandteile brauchst du einen gesonderten Nachweis und einen eigenen Updateprozess.

ELS for OS und ELS für Anwendungen sind getrennte Angebote. Ob eine alte PHP-Version über ein zusätzliches Angebot gewartet werden kann, hängt unter anderem von Version, Paketformat, Architektur und Bezugsweg ab. Eine weitere mögliche Umgebung für ältere PHP-Anwendungen beschreibt der Artikel zu CloudLinux Alt-PHP und seinen Sicherheitsaspekten; daraus folgt keine Abdeckung durch ein TuxCare-OS-Abonnement.

Supportfristen richtig einordnen

Ein Supportende ist nur zusammen mit der jeweiligen Wartungsphase aussagekräftig. Das Ende der regulären Wartung bedeutet nicht immer, dass sämtliche kostenpflichtigen oder ergänzenden Angebote gleichzeitig enden. Für eine Entscheidung solltest du deshalb sowohl den Zeitraum als auch die abgedeckten Pakete, Architekturen und Vertragsbedingungen notieren.

Die aktuell abrufbare TuxCare-Dokumentation nennt für unterstützte Betriebssysteme eine zugesagte ELS-Laufzeit von 25 Jahren ab dem jeweils angegebenen ursprünglichen Supportende. Als Beispiele führt sie für CentOS 7 den 30. Juni 2049 und für Ubuntu 18.04 den 31. Mai 2048 auf. Das sind Angaben des Anbieters zum Supportzeitraum, keine Zusage für jede installierte Anwendung.

Bei Ubuntu 18.04 unterscheidet Canonical mehrere Phasen: Die Standardwartung endete im Mai 2023; Ubuntu Pro wird bis Mai 2028 genannt. Die aktuelle Übersicht weist für zusätzliche Legacy-Abdeckung Mai 2033 aus. Diese Angebote sind nicht allein anhand ihrer Enddaten vergleichbar, weil Paketumfang, Architektur und Vertragsbedingungen für den konkreten Server zählen.

Vergleiche etwa bei einem Ubuntu-Webserver, ob die benötigten Pakete tatsächlich in der jeweils gewählten Wartung enthalten sind und wie sich die Updates in den bestehenden Betriebsprozess einfügen. Ein längerer Zeitraum hilft wenig, wenn eine kritische Laufzeit oder Erweiterung außerhalb des vereinbarten Umfangs liegt.

Die genannten Fristen beruhen auf dynamischen Herstellerseiten im recherchierten Quellenstand vom 4. November 2026. Ob alle aktuellen Angaben bereits an diesem Stichtag galten, lässt sich nicht durchgängig rückwirkend verifizieren. Prüfe Fristen und Paketlisten deshalb vor Veröffentlichung beziehungsweise Vertragsabschluss erneut und halte den jeweiligen Abrufstand fest. Auch eine lange Supportzusage ist keine Garantie für einen insgesamt sicheren Server.

CentOS-7-Server praktisch aufnehmen

Angenommen, ein CentOS-7-Webserver muss eine ältere Fachanwendung vorübergehend weiter ausführen. Bevor du TuxCare ELS auswählst, erfasst du den tatsächlichen Systemzustand und die Abhängigkeiten der Anwendung. Entscheidend ist nicht nur, ob CentOS 7 unterstützt wird, sondern ob die benötigten Komponenten für die vorhandene Architektur abgedeckt sind.

Die folgenden Befehle kannst du auf dem Server in einer Shell ausführen. Sie lesen die Distributionskennung, die Maschinenarchitektur und die Version des laufenden Kernels aus; sie verändern weder Pakete noch Paketquellen. Notiere die Ausgaben im Serverinventar und gleiche sie mit der aktuellen CentOS-7-Anleitung ab.

cat /etc/os-release
uname -m
uname -r

Ergänze das Serverinventar um konfigurierte Paketquellen, installierte Paketfassungen und öffentlich erreichbare Dienste. Bei einem Webserver gehören dazu insbesondere Webserver-Paket, Kryptobibliotheken, PHP-Laufzeit und Erweiterungen. Halte auch fest, welche Komponenten aus Fremdquellen stammen oder selbst kompiliert wurden; sie dürfen nicht ungeprüft als Teil der OS-Abdeckung gelten.

Für CentOS 7 nennt TuxCare einen gültigen Lizenzschlüssel, Root-Zugriff und HTTPS-Verbindungen als Voraussetzungen. Die Anleitung unterscheidet außerdem nach Architektur: Für aarch64 und i686 beschreibt sie Userspace-Abdeckung, Kernel-Live-Patching dagegen nur für x86_64. Diese Einschränkung betrifft die CentOS-7-Anleitung und lässt sich nicht pauschal auf andere Distributionen übertragen.

Prüfe für die konkrete Fachanwendung anschließend jedes benötigte Paket gegen die aktuelle Liste und kläre verbleibende Lücken mit dem jeweiligen Anbieter. Auch ein unterstützter laufender Kernel beweist für sich genommen weder die Abdeckung der Anwendung noch, dass alle verfügbaren Updates installiert und aktiv sind.

Repository einrichten und Updates ausrollen

Plane die Einrichtung als kontrollierte Prüfkette: Zuerst müssen Lizenz, Architektur und benötigte Pakete passen. Danach klärst du, ob der Server die für seine Distribution erforderlichen Ziele über HTTPS erreichen darf. Verwende für Registrierung und Repository-Einrichtung die aktuelle distributionsspezifische Originalanleitung, da sich Voraussetzungen und Zieladressen ändern können.

Bei CentOS 7 beschreibt TuxCare die Registrierung des Systems, das Hinzufügen der Paketquelle und eines PGP-Schlüssels. Die Quelle ermöglicht anschließend den Bezug passender Pakete; sie installiert aber nicht automatisch alle verfügbaren Updates. Kontrolliere nach der Einrichtung, ob das Repository erwartungsgemäß eingebunden ist und der Paketmanager passende Updates anbietet.

Ein Proxy oder restriktive ausgehende Firewallregeln müssen in die Planung einbezogen werden. Für mehrere Systeme kann ein lokaler Mirror nach Abstimmung mit TuxCare infrage kommen. Übernimm Zieladressen nicht blind aus einer allgemeinen FAQ: Gleiche sie vor der Freigabe mit der aktuellen Anleitung für die gewählte Distribution und dem vorgesehenen Betriebsweg ab.

Erprobe verfügbare Updates zunächst auf einer möglichst vergleichbaren Testumgebung mit der Fachanwendung. Prüfe dabei deren Start, wichtige Geschäftsabläufe und Schnittstellen. Danach erfolgen betriebliche Freigabe und Installation auf dem Produktivsystem; dokumentiere Paketfassungen, Zeitpunkt und Ergebnis, statt allein die erfolgreiche Repository-Aktivierung als Abschluss zu verbuchen.

Wird ein erwartetes Update noch nicht angeboten, prüfe auch den Rolloutstatus. Für mehrere Plattformen verteilt TuxCare Updates gestaffelt; nach Veröffentlichung im stabilen Repository kann dies bis zu 14 zusätzliche Tage dauern. Bei Bedarf beschreibt der Anbieter einen Bypass: Verwende ihn nur nach der aktuellen Anleitung für die jeweilige Distribution und das konkrete Release sowie nach betrieblicher Freigabe. Aus der Rolloutdauer folgt keine garantierte Gesamtfrist für einen Patch.

Halte außerdem einen Rückfallweg und ein geeignetes Wartungsfenster bereit. Lizenzschlüssel gehören nicht in veröffentlichte Beispielbefehle, Tickets oder ungeschützte Protokolle. Für die konkrete Registrierung solltest du die aktuelle Herstelleranleitung verwenden und Zugangsdaten nur über die dafür vorgesehenen Verfahren bereitstellen.

Wartungsalternativen im Vergleich

Die Wahl zwischen TuxCare ELS und einer erweiterten Herstellerwartung hängt vom tatsächlichen Paketbestand und den Vertragsbedingungen ab. Die Tabelle nennt Beispiele für die Vorauswahl, keine allgemeine Zusage für jede Architektur oder jedes Paket. Recherchebezug ist der 4. November 2026; die dynamischen Herstellerangaben und Paketlisten müssen vor Veröffentlichung erneut geprüft werden.

Bei Ubuntu 18.04 endete die Standardwartung im Mai 2023. Canonical nennt für Ubuntu Pro Unterstützung bis Mai 2028 und in seiner aktuellen Übersicht für zusätzliche Legacy-Abdeckung Mai 2033. TuxCare nennt für Ubuntu 18.04 derzeit den 31. Mai 2048 als ELS-Enddatum. Diese Daten beschreiben unterschiedliche Angebote; aus einem späteren Enddatum folgt nicht automatisch die passende Paketabdeckung.

Vergleiche deshalb den Wartungsumfang für jedes benötigte Paket und die tatsächlich eingesetzte Architektur. Bei Ubuntu sind insbesondere Main- und Universe-Komponenten sowie die Bedingungen für Pro und einen möglichen Legacy-Zusatz relevant. Halte außerdem fest, wie sich verfügbare CVE-Fixes nachweisen lassen und ob die vorhandenen Freigabe- und Updateprozesse zum Angebot passen.

Das Migrationsziel bleibt in beiden Beispielen eine Planungsentscheidung, keine Eigenschaft des Wartungsvertrags. Ist die Fachanwendung auf einer unterstützten Plattform noch nicht lauffähig, kann eine passende Wartungsalternative Zeit für Tests schaffen. Deckt keines der Angebote eine kritische Abhängigkeit ab, muss diese Lücke gesondert behandelt werden, bevor der Weiterbetrieb verantwortbar ist.

CVE-Meldungen und Backports prüfen

Meldet ein Scanner nach einem Update weiterhin eine Schwachstelle, prüfe zuerst die genaue Distribution und Version sowie Name, Architektur und installierte Fassung des betroffenen Pakets. Ermittle außerdem, aus welcher Paketquelle es stammt. Ein Befund für ein Distributionspaket lässt sich nicht ohne Weiteres auf eine selbst kompilierte Anwendung oder ein Paket aus einem Fremd-Repository übertragen.

Der Grund für scheinbare Widersprüche kann ein Backport sein: Dabei wird eine Sicherheitskorrektur in einen älteren Entwicklungsstand übernommen, ohne dass dessen sichtbare Upstream-Versionsnummer der neuesten Veröffentlichung entspricht. Eine ältere Versionsnummer allein beweist daher weder, dass das Paket verwundbar ist, noch, dass die Scanner-Meldung falsch sein muss.

Gleiche die konkrete CVE und die installierte Paketfassung mit den Angaben für deine Distribution im TuxCare-CVE-Tracker ab. „In Testing“ bedeutet, dass ein Fix noch getestet wird; bei „In Rollout“ wird er über Rollout-Repositories verteilt. „Released“ bezeichnet dagegen die vollständige Freigabe für alle Nutzer. Auch dann musst du prüfen, ob die passende Fassung tatsächlich installiert wurde; „Not Vulnerable“ besagt, dass die TuxCare-Version nicht betroffen ist.

Fehlt ein erwartetes Update im Paketmanager, prüfe neben Paketquelle und Version den Rolloutstatus. Bei mehreren Plattformen kann die gestaffelte Verteilung nach Veröffentlichung im stabilen Repository bis zu 14 zusätzliche Tage beanspruchen. Ein möglicher Bypass gehört nur nach aktueller distributions- und releasebezogener Originalanleitung und betrieblicher Freigabe in den Prozess; daraus ergibt sich keine garantierte Gesamtpatchfrist.

Untersuche anschließend die Datenbasis und Auswertung des Scanners. TuxCare stellt für eine Reihe von ELS-Produkten OVAL-Daten bereit; ob dein Werkzeug die für das konkrete System passenden Daten verwendet und korrekt interpretiert, musst du selbst prüfen. Dokumentiere Paketfassung, CVE-Status und Scanzeitpunkt. Bleibt der Abgleich unklar, behandle den Befund weiter als offen und kläre ihn mit den zuständigen Fachstellen oder dem Anbieter.

Patchbetrieb und Neustarts planen

Ein eingerichtetes Repository ist der Anfang des Patchbetriebs, nicht sein Abschluss. Lege fest, wer regelmäßig nach verfügbaren Updates sieht, wer die Freigabe erteilt und wie ausgefallene Aktualisierungen erkannt werden. Vergleiche dabei die tatsächlich installierten Paketfassungen mit den verfügbaren Updates und halte Abweichungen für jedes System fest.

Erprobe Updates möglichst zunächst auf einem vergleichbaren Testsystem mit derselben Anwendung und relevanten Paketquellen. Prüfe dort insbesondere Start, Anmeldung und wichtige Schnittstellen der Fachanwendung. Erst nach der betrieblichen Freigabe rollst du die Pakete kontrolliert aus; das Ergebnis und etwaige Fehler gehören in den Installationsnachweis.

Plane für Änderungen außerdem ein Wartungsfenster. Auch nach einem erfolgreichen Paketupdate können laufende Prozesse noch alte Bibliotheken verwenden, bis sie neu gestartet werden. Anwendungen müssen gegebenenfalls ebenfalls neu starten; bei Kerneländerungen kann ein Systemneustart erforderlich sein. Prüfe nach dem Neustart sowohl die Dienstfunktion als auch den erwarteten Paket- und Betriebszustand.

KernelCare Live Patching ist ein ergänzendes Produkt und von regulären ELS-Paketupdates zu unterscheiden. Es kann unterstützte Kernelkorrekturen im laufenden Betrieb bereitstellen, ersetzt aber weder alle Updates noch jeden Dienst- oder Systemneustart. Prüfe Produkt, Distribution und Architektur: Für CentOS 7 dokumentiert TuxCare Kernel-Live-Patching nur für x86_64. Weitere Grundlagen erläutert der Beitrag zum KernelCare Patch Feed.

Die Ausgabe von uname -r zeigt den laufenden Kernel, aber nicht den vollständigen Updatezustand des Servers. Ein installiertes Kernelpaket kann beispielsweise erst nach einem Neustart aktiv werden; umgekehrt sagt die Ausgabe nichts darüber aus, ob Bibliotheken und Anwendungen aktualisiert und neu gestartet wurden.

Übergangslösung oder Migration wählen

Ob TuxCare ELS für einen konkreten Server genügt, entscheidet sich an dessen tatsächlichen Komponenten und Risiken. Stelle den benötigten Paketen die verfügbare Abdeckung gegenüber und erfasse offene Lücken bei Anwendungen, Laufzeitumgebungen und Fremdsoftware. ELS for OS deckt eine distributionsabhängige Auswahl ab; aus der Unterstützung des Betriebssystems folgt keine Wartung jeder darauf betriebenen Anwendung.

Prüfe auch verbleibende CVE-Lücken innerhalb abgedeckter Pakete. Mittlere Risiken werden laut TuxCare nur unter zusätzlichen Voraussetzungen für einen Patch berücksichtigt; zudem kann der Anbieter eine Mitigation statt einer direkten Codekorrektur vorsehen. Bewerte deshalb für die konkrete Schwachstelle, ob ein Fix oder eine Mitigation verfügbar ist und ob die verbleibenden Risiken für deinen Betrieb tragbar sind.

Eine Übergangslösung kann sinnvoll sein, wenn eine Fachanwendung vorerst an die alte Plattform gebunden ist und die verbleibenden Risiken beherrschbar sind. Vergleiche aber auch verfügbare Herstellerwartung: Bei Ubuntu 18.04 kommen je nach benötigtem Umfang Ubuntu Pro und gegebenenfalls der Legacy-Zusatz als Alternativen in Betracht. Prüfe Pakete, Architektur und Vertragsbedingungen statt nur das jeweilige Enddatum.

Für einen öffentlich erreichbaren Dienst mit ungepflegter Anwendung oder nicht abgedeckter Laufzeit kann ELS allein unzureichend sein. Begrenze deshalb Zugriffe auf tatsächlich benötigte Netze und Dienste, entferne unnötige Freigaben und kontrolliere administrative Zugänge. Diese Netzwerkbegrenzung verkleinert die Angriffsfläche, ersetzt aber fehlende Sicherheitsupdates nicht.

Halte den Weiterbetrieb zeitlich begrenzt und lege ein Migrationsziel mit Verantwortlichen und einem überprüfbaren Termin fest. Plane Anwendungstests auf der Zielplattform, die Datenübernahme und die Prüfung aller relevanten Schnittstellen. Ein Rückfallplan sollte festlegen, unter welchen Bedingungen du die Umstellung abbrichst und wie du zum bisherigen Betrieb zurückkehrst.

Überprüfe den Plan regelmäßig anhand neuer Paketlücken, geänderter Herstellerabhängigkeiten und des Betriebsaufwands. Wenn benötigte Komponenten nicht mehr wartbar sind oder sich notwendige Zugriffe nicht ausreichend begrenzen lassen, reicht eine bloße Verlängerung der Betriebssystemwartung möglicherweise nicht aus. Dann müssen Migration, Ersatz der Anwendung oder kontrollierte Stilllegung neu bewertet werden.