Status
Mit der 2026 veröffentlichten Ubuntu LTS-Version sehen wir weitgehend eine Evolution statt einer Revolution. Mehrheitlich kleinere Versionsaktualisierungen, ein aktueller Kernel in Version 7 und viele kleine Änderungen «unter der Haube».
Eine Übersicht der verfügbaren Software-Versionen für die am häufigsten verwendeten Dienste findest du in unserer Dokumentation.
Welche Schritte sind zur Implementierung einer neuen Ubuntu Version nötig?
Hast du dich schon einmal gefragt, welche Aufwände nötig sind, um eine neue Ubuntu LTS-Version in unserem Ökosystem zu implementieren? Es ist ein wenig komplizierter, als das neue Image auf einen USB-Stick zu laden! Wir nehmen euch mit auf unsere Implementationsreise.
Ein erster Blick
Am 23. April 2026 wurde Ubuntu Resolute veröffentlicht. Eine erste Beta-Version erschien einen Monat vor der finalen Veröffentlichung.
Kurz nach der Veröffentlichung der ersten Beta-Version haben wir das erste Mal einen Blick auf Ubuntu Resolute geworfen. Nachdem klar war, welche Ruby-Version in der neuen Ubuntu-Version verwendet wird, konnten wir die weiteren Aufwände für unsere Self-Service Tools wie nine-manage-vhosts, nine-manage-databases und FTPAdmin2, sowie einige weitere Tools, die nicht direkt von Kunden verwendet werden (aber wichtig für unsere Automation sind), planen.
Nach unserem ersten Blick auf die Beta-Version haben wir die Backlog-Issues erstellt, die uns für die Umsetzung als notwendig erschienen.
Schritt für Schritt
Die erste zu lösende Herausforderung lag im Bereich des Paketmanagers und der Paketquellen. Nachdem in Version 3.1 von apt einige Optionen entfernt wurden, mussten wir unsere Automation um Paketquellen und unsere eigenen Mirror (wir erstellen eine lokale Kopie der Canonical Paketquellen für alle Ubuntu-Versionen) anpassen.
Nachdem diese Anpassung vorgenommen worden war, war die Erstellung eines «Packagebuilder»-Images für die neue Ubuntu-Version nötig. Dieses Container-Image wird verwendet, um in automatisierten Pipelines Debian-Pakete für Tools wie nine-manage-vhosts und nine-manage-databases, aber auch Prometheus Exporters zu erstellen.
Prometheus wird bei Nine für die Überwachung von Systemen eingesetzt. Exporter sind die Quelle für Metriken, auf denen die Alarmierung aufbaut. Nine baut mehr als 20 Exporter-Pakete, die keinem einheitlichen Prozess folgen und Anpassungen im Build-Prozess benötigen.
Um diese Pakete in einer «echten» Systemumgebung zu testen (statt in einer Container-Umgebung, in der wesentliche Elemente wie z.B. systemd fehlen), haben wir ausserdem ein VirtualBox VM-Image von Ubuntu Resolute erstellt, in dem unsere selbst gebauten Pakete getestet werden.
Nachdem wir unsere Automations- und Überwachungs-Tools erfolgreich kompilieren und testen konnten, konnten wir mit der Automation und Verifikation unserer Managed Services fortfahren.
Mit Ubuntu Resolute haben viele Services aktualisierte systemd-Konfigurationen und überarbeitete AppArmor-Profile erhalten. Zwar verbessert dies die Sicherheit, es machte allerdings auch Anpassungen und Tests nötig, bspw. in unserer Automation für Apache und MariaDB.
Eine der Änderungen an systemd resultierte darin, dass das /tmp-Verzeichnis bzw. Partition nicht länger auf der lokalen Festplatte angelegt wurde. Stattdessen nutzt /tmp eine tmpfs-Partition, die den Arbeitsspeicher verwendet.
Arbeitsspeicher ist eine wertvolle und knappe Ressource und viele Applikationen und Dienste verwenden /tmp für die Ablage von nur kurzzeitig nötigen Daten, die unter Umständen recht viel Speicherplatz beanspruchen können. Eine tmpfs-Partition erfüllt die Anforderungen im Server-Betrieb nicht. Daher haben wir für /tmp weiterhin ein traditionelles Dateisystem im Einsatz.
Die meisten dieser Anpassungen sind unabhängig vom System-Typ (virtuelle Maschine oder Hardware-Server). Für die Bereitstellung von Hardware-Servern mit Ubuntu Resolute mussten aber ebenfalls Anpassungen an unserem Provisionierungssystem vorgenommen werden.
Eine kleine Revolution
In den vergangenen Jahren haben die Firmen hinter Elasticsearch und Redis versucht, ihre Open Source-Dienste weiter zu kommerzialisieren. Hierzu wurde die Lizenz geändert und der Quellcode nicht länger unter einer Open Source-Lizenz veröffentlicht. Zwar sind beide Unternehmen in der Zwischenzeit wieder zu einer Open Source-Lizenz zurückgekehrt. Verlorenes Vertrauen ist allerdings schwer wieder zurückzuerlangen und die Open Source-Welt hat zwischenzeitlich auf die Lizenzanpassungen reagiert.
In unserem Service-Angebot wurde Elasticsearch durch OpenSearch ersetzt.
Nachdem die Lizenzanpassung für Redis bekannt gegeben worden war, dachten wir zunächst, dass wir bereits gut aufgestellt sind: Bereits im Jahr 2023 hatten wir KeyDB implementiert. Was zunächst wie eine vielversprechende Lösung aussah (bspw. vollständig kompatibel zu Redis, die Möglichkeit einer Multi-Primary Replikation), hat sich jedoch als Sackgasse erwiesen. Das KeyDB-Projekt ist inzwischen verwaist und erhält keine Aktualisierungen mehr.
Im Jahr 2024, im Anschluss an die Ankündigung der Lizenzänderung, wurde ein Redis-Fork veröffentlicht, der durch viele bekannte Namen Unterstützung erfährt: hinter Valkey stehen Unternehmen wie AWS, Google Cloud, Percona, Oracle und mehr. Die breite Unterstützung von Branchengrössen hat dazu beigetragen, dass Valkey schnell Fahrt aufnehmen und sich als Alternative zu Redis etablieren konnte.
Mit Ubuntu Resolute wurde Valkey in Version 9 in das Ubuntu «Main»-Repository aufgenommen. Im Main-Repository werden Pakete bereitgestellt, die von Canonical während des gesamten Zyklus einer Ubuntu-Version unterstützt werden.
Da Valkey in Version 9 vollständig kompatibel mit Redis in Version 7.2.4 ist und Redis weiterhin nur im «Universe»-Repository bereitgestellt wird (ein von der «Community» verwaltetes Repository), fiel uns die Entscheidung, zu Valkey zu wechseln, leicht: vollständig kompatibel zur letzten Redis-Version, die wir anbieten (7.0 in Ubuntu Noble), aber aktiv unterstützt in allen Ubuntu Lifecycle-Phasen.
Zusammenfassung der Entwicklung
Die nötigen Entwicklungsschritte vermitteln nicht nur einen groben Überblick über einige technische Herausforderungen, sondern geben auch einen Einblick in die Arbeitsweise der Nine-Entwickler sowie in die verwendeten Tools und Prozesse.
Viele der Backlog-Issues sind iterative Arbeitsschritte, die aufeinander aufbauen. Neben der technischen Entwicklung und der Qualitätssicherung ist es unerlässlich, sicherzustellen, dass keine ungewollten Effekte auf älteren Ubuntu-Versionen auftreten, da alle Ubuntu-Versionen mittels derselben Code-Basis automatisiert werden.
Nach 76 Merge-Requests in 20 Backlog-Issues wurden am 29. Juni 2026 die ersten Ubuntu-Resolute-Systeme an unsere Kunden ausgeliefert.
