SSD Nodes Learn 🎉 VPS ab $5.50/Monat
Anleitungen Matt ConnorVon Matt Connor

Ubuntu LTS oder Interim-Release auf dem Server?

Ubuntu Interim-Releases erhalten neun Monate Updates, LTS-Versionen fünf Jahre. Erfahren Sie, welche Supportdauer und welcher Upgradeaufwand für Ihren Server zählt.

Ubuntu LTS oder Interim-Releases: die kurze Antwort

Die Entscheidung zwischen einem Ubuntu LTS und einem Interim-Release auf einem Server hängt von einer Zahl ab: Wie lange erhält dieses Release Sicherheitsupdates? Ein LTS erhält fünf Jahre lang standardmäßige Security-Wartung. Ein Interim-Release erhält neun Monate lang Updates. Danach werden die Updates eingestellt, und Sie müssen ein Upgrade durchführen oder das System neu aufsetzen. Verwenden Sie ein LTS für alles, worauf andere angewiesen sind. Verwenden Sie ein Interim-Release nur dort, wo Sie das System neu aufsetzen können, ohne jemanden fragen zu müssen.

LTS steht für Long Term Support. Canonical veröffentlicht alle zwei Jahre im April eines geraden Jahres ein LTS und dazwischen alle sechs Monate ein Interim-Release. 26.04 LTS wurde am 23. April 2026 veröffentlicht. Die standardmäßige Security-Wartung läuft bis 2031. 26.10 soll am 15. Oktober 2026 erscheinen. Es ist ein Interim-Release, daher endet der Support im Juli 2027.

Wie lange die einzelnen Ubuntu-Releases unterstützt werden

ChartSupport length and release upgrades needed over five years
The data behind this chart
[
  {
    "label": "LTS, standard support",
    "support_months": 60,
    "upgrades_over_5_years": 1
  },
  {
    "label": "LTS with Ubuntu Pro",
    "support_months": 120,
    "upgrades_over_5_years": 0
  },
  {
    "label": "Interim release",
    "support_months": 9,
    "upgrades_over_5_years": 10
  }
]

Das sind die von Canonical veröffentlichten Richtwerte aus August 2026 und keine Messwerte von einem Testsystem. Ein LTS-Release erhält 60 Monate reguläre Sicherheitswartung. Das entspricht 1 geplantem Release-Upgrade innerhalb von fünf Jahren. Ein Interim-Release erhält 9 Monate Unterstützung. Wenn Sie in diesen fünf Jahren beim Interim-Track bleiben, sind 10 Release-Upgrades erforderlich, weil Sie kein Release überspringen können und fünf Jahre zehn Releases umfassen.

Ein Ubuntu-Pro-Abonnement erhöht den Wert für LTS auf 120 Monate beziehungsweise zehn Jahre. Außerdem wird die Abdeckung von der main-Komponente auf das gesamte Archiv erweitert. Im August 2026 ist Pro für die private Nutzung auf bis zu fünf Rechnern kostenlos. Das deckt die meisten kleinen VPS-Flotten ab. Für ein Interim-Release gibt es keine vergleichbare Option. Die Unterstützung ist auf neun Monate begrenzt, und kein Abonnement verlängert sie.

Was neun Monate auf einem echten Server kosten

Nehmen wir 26.10 als Beispiel. Diese Version wird am 15. Oktober 2026 veröffentlicht. Ihre Sicherheitswartung endet im Juli 2027. Das entspricht demselben Muster von neun Monaten, das bei 25.10 im Juli 2026 endete. Auf dem Kalender sieht das nach einem Wartungsfenster alle drei Quartale aus. Diese Betrachtung ist falsch. Sie führt zu einer zu niedrigen Einschätzung der Kosten.

Die Fristenkette im Beispiel

Installieren Sie 26.10 im Oktober 2026 und warten Sie bis zum letzten sicheren Zeitpunkt. Sie aktualisieren im Juni 2027 auf 27.04, kurz bevor 26.10 ausläuft. 27.04 wurde jedoch bereits im April 2027 veröffentlicht. Die neunmonatige Wartung dieser Version endet im Januar 2028. Ihre zweite Frist kommt also sieben Monate nach der ersten, nicht nach neun Monaten.

Aktualisieren Sie im Dezember 2027 erneut auf 27.10. Diese Version wurde im Oktober 2027 veröffentlicht und endet im Juli 2028. Ab diesem Zeitpunkt ist das Muster festgelegt. Sie verwenden immer eine Version hinter der aktuellen. Deshalb fällt ungefähr alle sechs Monate eine Frist an. Neun Monate ist die Wartungsdauer einer einzelnen Version. Der Abstand zwischen Ihren Wartungsfenstern beträgt nicht neun Monate.

Ein Release-Upgrade ersetzt das Betriebssystem direkt auf dem vorhandenen System. do-release-upgrade schreibt die apt-Quellen neu, deaktiviert Repositories von Drittanbietern, ändert die Version fast jedes installierten Pakets, fragt bei bearbeiteten Konfigurationsdateien nach und startet das System am Ende neu. Deshalb ist es ein geplantes Wartungsfenster und kein Hintergrundprozess.

Führen Sie das Upgrade über ssh aus, schützt Sie das Werkzeug vor einem Abbruch Ihrer eigenen Verbindung. Es startet eine eigene screen-Sitzung und öffnet einen zweiten sshd. Zuvor weist es darauf hin:

To make recovery in case of failure easier, an additional sshd will
be started on port '1022'. If anything goes wrong with the running ssh
you can still connect to the additional one.

Lassen Sie diese Einstellung unverändert. Wenn Ihre Firewall oder die separate Netzwerk-Firewall Ihres Providers Port 1022 blockiert, steht diese Ausweichverbindung nicht zur Verfügung. Ein Verbindungsabbruch hinterlässt dann einen teilweise aktualisierten Paketsatz. Wenn Sie selbst innerhalb von tmux oder screen arbeiten, erhalten Sie auf jedem System denselben Schutz.

Die Abfragen zu Konfigurationsdateien machen aus einem Upgrade von fünfzehn Minuten schnell eine Stunde:

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?

Wenn Sie Ihre Datei behalten, entgehen Ihnen Änderungen an den neuen Standardeinstellungen. Wenn Sie die Datei des Paketbetreuers übernehmen, ist Ihre Härtung entfernt, bis Sie sie wieder eintragen. Ohne Kenntnis der Änderungen in dieser Version ist keine der beiden Antworten sicher. Deshalb gehört das Lesen der Release Notes zum Wartungsfenster und ist keine optionale Vorbereitung.

Anschließend müssen Sie die Anzahl der Systeme berücksichtigen. Ein VPS im Interim-Zweig bedeutet in fünf Jahren zehn Upgrade-Fenster. Bei fünf VPS sind es fünfzig, sofern nicht jedes System verworfen und aus einem Image neu erstellt wird. Fünf Systeme im LTS-Zweig erfordern im selben Zeitraum fünf Upgrades. Den Monat für jedes Upgrade können Sie selbst festlegen.

Warum Sie eine Ubuntu-Version nicht überspringen können

Die Upgrade-Pfade sind festgelegt. Eine Zwischenversion wird auf die jeweils nächste Version aktualisiert. Eine LTS-Version wird direkt auf die nächste LTS-Version aktualisiert oder auf die nächste Zwischenversion, wenn Sie dies anfordern. Kein Upgrade überspringt zwei Schritte. Der Weg von 26.10 zu 28.04 LTS führt über 27.04 und 27.10 oder erfordert eine Neuinstallation des Systems.

Der Mechanismus ist wichtig, weil er zeigt, dass diese Regel nicht umgangen werden kann. do-release-upgrade ruft eine Meta-Release-Datei von changelogs.ubuntu.com ab und lädt anschließend ein Upgrade-Tool herunter, das für genau einen Übergang entwickelt wurde. Canonical erstellt und testet jeweils nur einen Übergang. Für einen Versionssprung, der eine Version überspringt, gibt es daher weder ein passendes Tool noch entsprechende Tests. Das Upgrade-Programm verweigert den Sprung nicht aus Vorsicht. Es kann dafür schlicht nichts anbieten.

Welche Version angeboten wird, ergibt sich aus einer Konfigurationszeile:

grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c

Prompt=lts bietet nur die nächste LTS-Version an. Prompt=normal bietet die nächste Version an, unabhängig davon, ob sie eine LTS-Version ist. Prompt=never bietet keine Version an. Damit verhindern Sie, dass ein hilfsbereiter Kollege ein nicht geplantes Upgrade startet. Bei einer Version, die keine LTS-Version ist, verhält sich lts genau wie normal, weil die nächste Version nach 26.10 unter beiden Einstellungen 27.04 ist. Die Prüfung gibt Checking for a new Ubuntu release und anschließend entweder eine New release ... available.-Zeile oder No new release found. aus.

Eine weitere Zeitplanregel führt häufig zu Missverständnissen. Ein Upgrade von einer LTS-Version auf die nächste LTS-Version wird nicht am Tag der Veröffentlichung der neuen LTS-Version angeboten. Es wird mit dem ersten Point-Release freigeschaltet. Für 26.04.1 ist der 27 August 2026 vorgesehen. Ein 24.04-System mit Prompt=lts, das im Sommer 2026 mit No new release found. antwortete, war nicht fehlerhaft. Es folgte der vorgesehenen Richtlinie. Sobald der Pfad freigeschaltet ist, ist das Upgrade von 24.04 auf 26.04 LTS der Durchlauf, den Sie planen und testen sollten.

Wann die Wahl einer Zwischenversion sinnvoll ist

In vier Fällen bietet sie echte Vorteile:

  • Sie benötigen auf diesem System jetzt einen Kernel oder eine Userspace-Version, die im LTS-Archiv nicht enthalten ist.
  • Das System ist ein Build-Host, ein CI-Runner oder ein Testsystem, das Sie aus einem Image neu erstellen. Ein Upgrade bedeutet dann eine neue Instanz statt eines Wartungsfensters.
  • Eine Hardware- oder Hypervisor-Funktion wurde erst nach dem Einfrieren der LTS-Version eingeführt, und es gibt keinen Backport.
  • Sie prüfen, welche Inhalte die nächste LTS-Version enthalten wird. 28.04 wird aus 26.10, 27.04 und 27.10 zusammengestellt. Eine inkompatible Änderung auf einem Ersatz-VPS zu finden, kostet weniger, als sie auf dem wichtigen System zu entdecken.

Die meisten Benutzer, die zu einer Zwischenversion greifen, benötigen nur ein neueres Paket und keine neuere Distribution. Dafür gibt es zwei kostengünstigere Lösungen. Der Hardware-Enablement-Stack bringt Kernel aus späteren Versionen in eine LTS-Version. Bei 24.04 ist das sudo apt install linux-generic-hwe-24.04. Der Stack wird mit jedem Point Release aktualisiert, beginnend mit dem zweiten. Für eine einzelne Anwendung aktualisieren ein Container-Image oder das Repository des Anbieters nur eine Komponente statt des gesamten Betriebssystems.

Wenn eine Interim-Version die falsche Wahl ist

  • Alles mit zahlenden Benutzern oder einer Rufbereitschaft. Sie akzeptieren damit zweimal pro Jahr ein obligatorisches Upgrade, um Paketversionen zu erhalten, die Sie möglicherweise nie verwenden.
  • Jeder Server, auf dem unattended-upgrades Ihre Sicherheitsupdates übernimmt. Diese Automatisierung ist nur so zuverlässig wie die Security-Paketquelle, aus der sie ihre Pakete bezieht.
  • Eine Serverflotte, die Sie manuell aktualisieren, weil die tatsächlichen Kosten aus einem Wartungsfenster multipliziert mit der Anzahl der Server bestehen.
  • Alles, was Sie installieren und anschließend ein Jahr lang nicht mehr prüfen. Eine vergessene Interim-Version ist neun Monate später ein ungepatchter, aus dem Internet erreichbarer Server.

Dieser letzte Fehler bleibt unbemerkt. Genau das macht ihn gefährlich. Wenn eine Version das Ende ihrer Lebensdauer erreicht, werden ihre Pakete nach old-releases.ubuntu.com verschoben. Dadurch schlägt sudo apt update mit 404-Fehlern bei archive.ubuntu.com fehl. Die auf dem Datenträger gespeicherten Paketlisten veralten. unattended-upgrades läuft weiterhin nach seinem Zeitplan und schreibt weiterhin Zeilen wie diese in /var/log/unattended-upgrades/unattended-upgrades.log:

No packages found that can be upgraded unattended and no pending auto-removals

Diese Zeile sieht auf einem vollständig gepatchten Server genauso aus wie auf einem Server, dessen Version vor vier Monaten das Ende ihrer Lebensdauer erreicht hat. Wenn niemand die apt-Fehler liest oder das Ende der Lebensdauer überwacht, gibt es auf dem System keinen Hinweis darauf, welcher der beiden Fälle vorliegt.

Die Art von Änderung, die zuerst im Interim-Track landet

Im März 2026 schlug ein Canonical-Engineer im Ubuntu Discourse vor, den signierten GRUB-Bootloader zu reduzieren, der in 26.10 für Secure Boot ausgeliefert wird. Der Vorschlag entfernt die Dateisystemtreiber für btrfs, hfsplus, xfs und zfs, die JPEG- und PNG-Bildparser, Apple-Partitionstabellen, /boot auf LVM, Software-RAID außer RAID 1 sowie ein LUKS-verschlüsseltes /boot. Als Grund wird genannt, dass Parser in einem Bootloader wiederholt Sicherheitsfehler verursachen und dass die Logik für Speicher und Verschlüsselung in die initramfs gehört, das kleine anfängliche RAM-Dateisystem, das der Kernel vor dem eigentlichen Root-Dateisystem einhängt. Im August 2026 handelt es sich dabei um einen diskutierten Vorschlag und nicht um eine ausgelieferte Änderung.

Für die meisten VPS-Instanzen würde sich dadurch nichts ändern, weil sie ohne Secure Boot von einem einfachen ext4-/boot auf einer GPT-Partitionstabelle booten. Prüfen Sie Ihre Konfiguration, statt dies anzunehmen. Wenn Ihr Root-Dateisystem ZFS ist oder /boot auf btrfs oder innerhalb von LUKS liegt, ist dies genau die Art von Änderung, die Sie zuerst im Interim-Track trifft. Im Diskussions-Thread wird betroffenen Benutzern daher empfohlen, bei einer LTS-Version zu bleiben. Dieser Rat fasst das gesamte Argument in einem Satz zusammen. In Interim-Versionen werden Änderungen ausprobiert. In einer LTS-Version kommen sie an, nachdem zwei Jahre mit Interim-Versionen gezeigt haben, was sie beschädigen.

Dasselbe Muster zeigt sich bei jeder Interim-Version in kleinerem Maßstab. Die Standardversionen der Datenbank, der Sprachlaufzeit und der init-Konfiguration werden aktualisiert. Dadurch können funktionierende Konfigurationsdateien unbrauchbar werden. Die Aktualisierung der Standardwerte ist der Zweck einer Interim-Version. Deshalb gehört es zum Preis, den Sie mit dieser Entscheidung akzeptiert haben, vor jedem dieser zehn Upgrades die Release Notes zu lesen.

Den passenden Track beim Erstellen des Servers auswählen

Wählen Sie den Track bereits bei der Installation aus. Eine spätere Änderung erfordert eine Neuinstallation oder eine Reihe von Upgrades. Auf einem neuen Server zeigen vier Befehle, wo Sie stehen:

lsb_release -a
grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c
pro security-status

lsb_release -a sollte den Release angeben, den Sie installieren wollten. Bei einem LTS endet die Beschreibungszeile mit LTS. Die Zeile Prompt sollte mit dem von Ihnen gewählten Track übereinstimmen, nicht mit dem Track, den das Image des Providers zufällig mitgebracht hat. do-release-upgrade -c sollte bei einem aktuellen LTS mit No new release found. antworten. Wird stattdessen ein Interim-Release angeboten, ist Prompt auf normal gesetzt. Dann sollte jemand prüfen, ob dies beabsichtigt war. pro security-status zeigt, wie viele installierte Pakete von welchem Update-Stream abgedeckt sind. Der Befehl weist außerdem ausdrücklich darauf hin, wenn der Rechner nicht mit einem Abonnement verknüpft ist.

Notieren Sie anschließend das End-of-Life-Datum dort, wo Sie es zusammen mit den übrigen Build-Notizen für diesen Server wiederfinden. Das gehört zu den anderen Aufgaben in den ersten zehn Minuten auf einem neuen VPS. Ein Supportdatum, das nur im Gedächtnis einer Person existiert, läuft unbemerkt ab. Wenn Sie den halbjährlichen Wechsel vollständig vermeiden möchten, lohnt sich das FreeBSD-Release-Modell im Vergleich zu Linux vor der Entscheidung, eine gesamte Serverflotte auf eines der beiden Systeme festzulegen, eine Stunde Lektüre.

FAQ

Sollte ich ein Ubuntu-Interim-Release auf einem Produktionsserver einsetzen?

In fast allen Fällen: nein. Ein Interim-Release erhält neun Monate nach seiner Veröffentlichung keine Sicherheitsupdates mehr. Der Produktionseinsatz auf diesem Release-Zweig bedeutet daher dauerhaft ein verpflichtendes Upgrade-Fenster ungefähr zweimal pro Jahr. Eine sinnvolle Ausnahme sind Maschinen, die ohnehin aus einem Image neu erstellt werden, etwa CI-Runner und Build-Hosts. Dort ist ein Upgrade eine neue Instanz und kein Wartungsfenster. Wenn echte Benutzer vom Server abhängen, installieren Sie das LTS und verwenden Sie die eingesparten Wartungsfenster für andere Aufgaben.

Wie lange wird ein Ubuntu-Interim-Release unterstützt?

Neun Monate. 26.10 wird am 15. Oktober 2026 veröffentlicht. Seine Sicherheitswartung endet im Juli 2027. Das entspricht dem Zeitplan von 25.10, dessen Unterstützung im Juli 2026 endete. Jedes Interim-Release folgt diesem Muster: Veröffentlichung im April oder Oktober, Ende der Unterstützung neun Monate später. Ein LTS erhält fünf Jahre Standard-Sicherheitswartung. Mit Ubuntu Pro verlängert sie sich auf zehn Jahre. Seit August 2026 ist Ubuntu Pro für die private Nutzung auf bis zu fünf Maschinen kostenlos.

Kann ich Ubuntu-Releases beim Upgrade überspringen?

Nein. do-release-upgrade führt Upgrades schrittweise durch: Ein Interim-Release wird auf das nächste Release aktualisiert. Ein LTS kann direkt auf das nächste LTS aktualisiert werden. Für ein Upgrade von 26.10 auf 28.04 LTS müssen Sie das Upgrade zunächst auf 27.04 und anschließend auf 27.10 durchführen. Alternativ müssen Sie die Maschine neu installieren. Canonical entwickelt und testet jeden Übergang einzeln. Das Upgrade-Programm lädt ein Werkzeug für genau diesen Übergang herunter. Für einen Sprung über zwei Releases gibt es kein passendes Werkzeug. Ein solcher Sprung wird daher nie angeboten.

Was passiert, wenn mein Ubuntu-Release das Ende seiner Lebensdauer erreicht?

Die Pakete werden nach old-releases.ubuntu.com verschoben. Daher schlägt sudo apt update bei Zugriffen auf archive.ubuntu.com mit 404-Fehlern fehl. Für dieses Release werden überhaupt keine neuen Sicherheitsupdates mehr veröffentlicht. Auf der Maschine wird dies nicht angekündigt. Der Server läuft weiter und verarbeitet weiterhin Netzwerkverkehr, während jede neu veröffentlichte Schwachstelle darin offen bleibt. Die Wiederherstellung besteht aus einem unter Zeitdruck durchgeführten Release-Upgrade oder einer Neuinstallation. Überwachen Sie daher das Datum und nicht erst die Symptome.

Ist der LTS-Kernel für neue Hardware zu alt?

In der Regel nicht, denn ein LTS behält seinen ursprünglichen Kernel nicht fünf Jahre lang. Der Hardware Enablement Stack, HWE, bringt Kernel aus späteren Releases über Point Releases in das LTS. Eine Serverinstallation kann dies mit einem Paket wie linux-generic-hwe-24.04 aktivieren. Prüfen Sie mit uname -r, welchen Kernel Sie ausführen, bevor Sie den Kernel als Ursache annehmen. Wenn eine Userspace-Version fehlt und nicht eine Kernel-Funktion, ist ein Container oder ein Hersteller-Repository eine deutlich kleinere Änderung, als die gesamte Maschine auf den Interim-Release-Zweig umzustellen.