Nach 145 Tagen ununterbrochener Uptime war es Zeit für einen jener Befehle, die sich ein wenig folgenreicher anfühlen, wenn die betreffende Maschine still und zuverlässig einen guten Teil des eigenen digitalen Lebens am Laufen hält:

reboot

Bis dahin hatte der Server laut btop ungefähr 51 TiB empfangen und 5 TiB gesendet.

Er hatte Webseiten ausgeliefert, Dateien gespeichert, Metriken gesammelt, Kameras aufgezeichnet, Fernsehen empfangen, Hausautomation betrieben, DNS-Anfragen aufgelöst, Datenbanken gehostet, Software gebaut, Wetterdaten verarbeitet, IoT-Geräte koordiniert und Dutzende weitere kleine Aufgaben erledigt, die man leicht vergisst – bis die Maschine einmal nicht verfügbar ist.

Und ich hatte sie gerade von Debian 12 Bookworm auf Debian 13 Trixie aktualisiert.

Ein großes Betriebssystem-Upgrade ist vermutlich einer der fragilsten Zustände, in die man einen solchen Server absichtlich versetzen kann. Für eine gewisse Zeit besteht das System aus einem alten laufenden Kernel, frisch ausgetauschten Userspace-Bibliotheken, Prozessen, die noch alte Binaries im Speicher halten, gestoppten Diensten, bereits aktualisierten Diensten, vorübergehend deaktivierten Drittanbieter-Repositories und einem neuen Kernel, der auf seinen ersten Start wartet.

Ein paar Stunden später war trotzdem alles wieder da.

Und nicht nur das.

Die Maschine lief mit deutlich geringerer Last, ungefähr halbiertem Speicherverbrauch und mehr als 10 GB weniger Altlasten aus Paketen und sonstigem Ballast.

Das Interessante daran ist nicht, dass Debian sich aktualisieren lässt.

Interessant ist vielmehr, was das darüber aussagt, einen ernsthaft genutzten Heimserver auf ganz normalem Linux direkt auf der Hardware zu betreiben – ohne Proxmox unter alles zu schieben und ohne reflexartig jeden Daemon in Docker zu verpacken.

---

Der Server, der still zur Infrastruktur wurde

Das hier ist kein dediziertes NAS und auch kein alter Laptop, auf dem Pi-hole läuft.

Es ist mein zentraler lokaler Linux-Server und faktisch das Rückgrat meiner Infrastruktur.

Unter anderem laufen darauf:

• lokale PHP-Anwendungen und Entwicklungsumgebungen
• MariaDB und Valkey
• Samba und allgemeine NAS-Aufgaben wie TimeMachine-Backups
• CoreDNS
• MQTT
• openHAB und Hausautomation
• TVHeadend mit einer DVB-Karte von Digital Devices
• WeeWX und die Verarbeitung der Wetterstationsdaten
• Prometheus-Monitoring für die übrige Infrastruktur
• Grafana
• UniFi Network Server
• Frigate NVR mit Videoanalyse
• lokale und externe Backups
• geplante Jobs, Synchronisationen und Automatisierungsskripte
• diverse Entwicklungswerkzeuge
• eine Reihe von Docker-Containern dort, wo Container tatsächlich sinnvoll sind
• interne Software wie Mainframe und PentaPaper

Das ist ein komplexer Workload.

Das bedeutet nicht, dass dafür zwingend eine komplexe Architektur nötig wäre.

Dieser Unterschied ist entscheidend.

Erstaunlich viele Homelab-Diskussionen beginnen mit der Annahme, dass jeder neue Dienst zu einem weiteren Docker-Container, einer weiteren VM, einem weiteren LXC-Container oder einer weiteren Schicht unterhalb eines Hypervisors werden müsse.

Ich nutze all diese Technologien dort, wo sie sinnvoll sind.

Ich halte sie nur nicht für Selbstzwecke.

Manchmal sieht die sauberste Architektur für einen Dienst tatsächlich so aus:

systemd
   ↓
service

und nicht so:

hypervisor
   ↓
virtual machine
   ↓
container runtime
   ↓
container
   ↓
service

Modernes Linux ist außerordentlich gut darin, viele unterschiedliche Workloads gleichzeitig zu betreiben. Genau darin sind Unix-artige Systeme über Jahrzehnte immer besser geworden.

DNS verbraucht praktisch nichts. MQTT wartet die meiste Zeit. Webanwendungen erzeugen Last in Schüben. MariaDB hält sinnvolle Daten im Cache und ruht zwischen Abfragen. openHAB reagiert auf Ereignisse. TVHeadend verschiebt einen großen Teil seines Lebens schlicht Datenströme. Prometheus sammelt periodisch Metriken. WeeWX wacht auf, verarbeitet Messwerte und legt sich wieder schlafen.

Selbst etwas vergleichsweise Substanzielles wie Frigate bedeutet nicht automatisch, dass der Rest der Maschine plötzlich einen eigenen Cluster braucht.

Die meisten Workloads erreichen ihre Spitzenlast nicht gleichzeitig.

Und genau dadurch wird Konsolidierung so effizient.

---

Bare Metal bedeutet nicht automatisch Snowflake-Server

Es gibt noch eine zweite Annahme, der ich zunehmend widerspreche: dass direkt unter Linux installierte Software zwangsläufig in endloser manueller Konfiguration, vergessenen Dateien unter /etc, mysteriösen Paketkonflikten und einem Server endet, den nach drei Jahren niemand mehr anzufassen wagt.

Das kann so enden.

Es muss aber nicht.

Dieser Server wird mit Ansible verwaltet. Seine wesentliche Konfiguration liegt als Infrastructure as Code vor. Dienste werden überwacht. Daten werden gesichert. Der Großteil der Software stammt entweder direkt aus Debian oder aus einer kleinen Zahl bewusst ausgewählter Upstream-Repositories.

Das Betriebsmodell ähnelt damit eher professioneller Infrastruktur als einer Sammlung von Shell-Befehlen, die irgendwann aus Foren kopiert wurden.

Das verändert das Risikomodell erheblich.

Wenn eine Maschine ausfällt, lautet die entscheidende Frage nicht:

Kann ich irgendwie genau diese Installation reparieren?

Sondern:

Verstehe ich ihren Zustand gut genug, um ihn reproduzieren zu können?

Das sind zwei vollkommen unterschiedliche Situationen.

Derselben Philosophie folgt auch meine Backup-Strategie. Ich habe bereits separat darüber geschrieben, warum ich RAID1 auf einer Maschine wie dieser nicht blind als Ersatz für Backups betrachte. Spiegelung schützt vor einer bestimmten Form von Hardwareausfall. Wenn ich versehentlich eine Datei lösche und genau diese Löschung sofort auf die zweite Platte gespiegelt wird, hilft mir das überhaupt nicht.

Für manche Datenbestände passt deshalb eine periodische Synchronisation auf zusätzliche Laufwerke – von denen einige den Großteil der Zeit sogar abgeschaltet bleiben können – wesentlich besser zu den Fehlerbildern, gegen die ich mich tatsächlich schützen möchte.

Das Prinzip ist im gesamten System dasselbe:

Die Architektur sollte sich am Problem orientieren – nicht an der gerade modischen Lösung.

---

Ein großes Upgrade ist der Moment, in dem sich die Architektur beweisen muss

Normalbetrieb beweist überraschend wenig.

Ein Dienst, der seit zwei Jahren läuft, kann auch einfach deshalb weiterlaufen, weil ihn in dieser Zeit niemand gestört hat.

Ein großes Distributions-Upgrade ist etwas anderes.

Hier bewegen sich die Abhängigkeiten direkt unter einem.

Während der Migration von Debian 12 auf Debian 13 sah der konzeptionelle Zustand der Maschine zeitweise ungefähr so aus:

old running kernel
+
partially upgraded userspace
+
old processes with old libraries mapped
+
new libraries on disk
+
some stopped services
+
some already upgraded services
+
third-party repositories temporarily disabled
+
new kernel modules being built
+
new kernel waiting for first boot

Genau in diesem Moment wird Konfigurationsschuld sichtbar.

Alte Signaturschlüssel funktionieren nicht mehr.

Kernelmodule lassen sich nicht mehr kompilieren.

Dienste hängen von Java-Versionen ab, an die man längst nicht mehr gedacht hat.

Python-Umgebungen verweisen auf Interpreter, die nicht mehr existieren.

Upstream-Konfigurationsdateien haben sich verändert.

Ansible beginnt plötzlich vor Mustern zu warnen, die vor einigen Jahren noch vollkommen normal waren.

Und irgendwann erreicht man den Punkt, an dem es nur noch einen Weg gibt, herauszufinden, ob das neue System wirklich funktioniert:

Man muss es neu starten.

Das ist ein wesentlich aussagekräftigerer Test für Wartbarkeit als weitere 100 Tage Uptime.

---

Bookworm auf Trixie vorbereiten

Ich wollte APT nicht gleichzeitig die komplette Debian-Distributionstransition und ein halbes Dutzend externer Repositories auflösen lassen.

Das erste Ziel war deshalb, die Paketebene zu vereinfachen.

Ich ersetzte die alte Debian-Repository-Konfiguration durch eine moderne deb822-Quelle:

Types: deb
URIs: https://deb.debian.org/debian
Suites: trixie trixie-updates
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: https://security.debian.org/debian-security
Suites: trixie-security
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Außerdem wechselte ich von einem festen deutschen Debian-Mirror zu deb.debian.org.

An einem guten nationalen Mirror ist grundsätzlich nichts auszusetzen. Für Infrastruktur, die unabhängig davon funktionieren soll, wo ich sie irgendwann deploye, ist Debians CDN-gestützter Endpoint jedoch der angenehmere Standard.

Die Bookworm-Backports verschwanden. Alte Source-Paket-Einträge, die ich ohnehin nicht nutzte, ebenfalls. Drittanbieter-Repositories nahm ich für die eigentliche Migration vorübergehend aus dem Spiel.

Danach folgte der übliche gestaffelte Übergang:

apt upgrade --without-new-pkgs

anschließend die Installation des neuen Kernels und der Header und schließlich:

apt full-upgrade

Entscheidend war, den Reboot nicht unnötig früh zu erzwingen.

Solange der alte Kernel und die bestehende SSH-Sitzung noch liefen, hatte ich weiterhin eine ausgesprochen komfortable Recovery-Umgebung.

---

Das erste echte Hindernis: ZFS und DKMS

Der neue Debian-13-Kernel ließ sich zunächst nicht vollständig konfigurieren.

Nicht, weil mit dem Kernel etwas nicht gestimmt hätte, sondern weil DKMS versuchte, ein altes ZFS-Modul dagegen neu zu bauen – und dabei scheiterte.

Der Fehler pflanzte sich entsprechend nach oben fort:

zfs DKMS build fails
        ↓
kernel postinst fails
        ↓
linux-image remains unconfigured
        ↓
headers remain unconfigured
        ↓
kernel meta packages remain unconfigured

Genau deshalb bevorzuge ich es, Abhängigkeitsketten zu verstehen, statt einen APT-Fehler als undurchdringliche Wand aus rotem Text zu behandeln.

Der Kernel war in Ordnung.

ZFS war das Problem.

Ein Update des ZFS-Stacks auf die zu Trixie kompatible Version über apt install zfs-dkms zfsutils-linux und ein erneuter DKMS-Lauf lösten das Problem. Danach ließ sich der Kernel normal konfigurieren.

Keine Neuinstallation.

Keine Recovery-Umgebung.

Kein Mysterium.

---

NodeSource traf auf Debians strengere Kryptographie-Policy

Ein weiterer interessanter Fehler tauchte beim Wiedereinbinden von Node.js auf.

Debian 13 lehnte die bestehende Signatur des NodeSource-Repositories ab, weil der verwendete Signaturschlüssel noch eine alte SHA-1-Zertifizierungssignatur in seiner Kette enthielt.

APT erklärte das ziemlich eindeutig:

Policy rejected non-revocation signature
because SHA1 is not considered secure

Auch hier tat das System exakt das, was es tun sollte.

Die Lösung bestand nicht darin, APTs Sicherheitsrichtlinien aufzuweichen. Stattdessen ersetzte ich den veralteten NodeSource-Key samt Repository-Definition durch die aktuelle Variante.

Bei der Gelegenheit installierte ich direkt Node.js 24 zusammen mit Yarn 4, statt aus historischen Gründen eine alte Entwicklungsumgebung mitzuschleppen.

Das ist einer der wiederkehrenden Vorteile großer Upgrades:

Sie schaffen einen natürlichen Zeitpunkt, um zu hinterfragen, ob alte Infrastruktur überhaupt noch durch die nächste Migration getragen werden sollte.

Manchmal besteht die richtige Migrationsstrategie schlicht aus Löschen.

---

Auch Java wurde einfacher

openHAB hatte im Laufe der Zeit ein kleines JVM-Museum angesammelt:

Zulu 11
Zulu 17
Zulu 21
OpenJDK 11
OpenJDK 17
...

Das meiste davon war Geschichte, keine Architektur.

Debian 13 liefert eine vollkommen geeignete OpenJDK-21-Umgebung mit, also verwendet openHAB nun einfach:

JAVA_HOME=/usr/lib/jvm/java-21-openjdk-amd64

Das alte Azul-Repository konnte verschwinden.

Die überflüssigen Laufzeitumgebungen ebenfalls.

openHAB startete unter Debians nativem OpenJDK 21 vollkommen unspektakulär wieder.

Und genau das ist für mich die größere Verbesserung als der Austausch einer Java-Distribution gegen eine andere:

ein externes Repository weniger, eine herstellerspezifische Abhängigkeit weniger, eine kleinere Wartungsfläche.

---

Python 3.13 legte alte pipx-Umgebungen offen

Debian 13 brachte außerdem Python 3.13 als System-Python mit.

Meine pipx-Umgebungen waren naturgemäß noch mit dem vorherigen Interpreter erstellt worden. Entsprechend funktionierten Tools wie Ansible zunächst nicht mehr.

Auch hier war konzeptionell nichts Schwieriges zu lösen:

pipx reinstall-all --python python3.13

und die isolierten Umgebungen wurden sauber neu aufgebaut.

Das ist einer jener Punkte, an denen modernes Python-Packaging deutlich angenehmer ist als die frühere Gewohnheit, beliebige Pakete mit sudo pip install direkt in das System-Python zu werfen.

Die Debian-Python-Installation bleibt Debians Verantwortung.

CLI-Anwendungen leben in ihren pipx-Umgebungen.

Die Grenze ist klar.

---

Ansible bei der Gelegenheit gleich mit modernisiert

Nachdem Ansible selbst wieder lief, legte das Betriebssystem-Upgrade noch einige Deprecations offen.

Keine davon war besonders dramatisch.

Die Repository-Verwaltung wechselte vom alten:

apt_repository:

hin zu:

ansible.builtin.deb822_repository:

was sehr gut zu Debians modernem .sources-Format passt.

MariaDB-spezifische Automatisierungen können inzwischen die MariaDB-Collection verwenden, statt auf Dauer alte MySQL-orientierte Modulnamen mitzuschleppen.

Nach den nötigen Anpassungen lief ein vollständiger realer Ansible-Durchlauf mit folgendem Ergebnis durch:

ok=346
changed=41
unreachable=0
failed=0
skipped=35
rescued=0
ignored=0

Dieses Ergebnis war für mich fast genauso wichtig wie funktionierende Anwendungen.

Der Server war nicht nur betriebsbereit.

Sein gewünschter Zustand konvergierte weiterhin sauber.

---

Das Rätsel um den DVB-Treiber endete erfreulich

TVHeadend war eine jener Komponenten, bei denen ich mit mehr Aufwand gerechnet hatte.

Im Server steckt eine DVB-Karte von Digital Devices. Vor Jahren hatte ich dafür den externen dddvb-Treiber manuell installiert:

make
make install
depmod

Später wanderte derselbe Ablauf in Ansible.

Eine DKMS-Integration gab es nicht.

Trotzdem hatte die Karte Kernel-Updates über Jahre hinweg problemlos überstanden.

Nach dem Start von Debian 13 funktionierte TVHeadend sofort.

Das geladene Modul lag hier:

/lib/modules/6.12.107+deb13-amd64/kernel/drivers/media/pci/ddbridge/ddbridge.ko.xz

Der Pfad verriet, was geschehen war.

Das war längst nicht mehr mein manuell gebauter externer Treiber.

Der Linux-Kernel unterstützt die Hardware inzwischen über seinen eigenen In-Tree-ddbridge-Treiber gut genug, sodass das System bei irgendeinem Kernelwechsel schlicht auf die native Implementierung zurückgefallen war.

Ich hatte es nie bemerkt, weil nichts aufgehört hatte zu funktionieren.

Das ist vermutlich meine liebste Form von Infrastrukturmigration.

Keine Ankündigung.

Kein Rewrite.

Eine Abhängigkeit wird schlicht überflüssig.

Und wenn der In-Tree-Treiber des Kernels weiterhin alles erledigt, was ich brauche, besteht der richtige nächste Schritt nicht darin, ein ausgefeiltes DKMS-Setup für den alten externen Treiber zu erfinden.

Sondern darin, die alte Treiber-Automatisierung zu löschen.

---

Dann kam der Reboot

An diesem Punkt befand sich die Maschine genau in jenem Zustand, der Remote-Upgrades psychologisch interessant macht.

Das Paket-Upgrade war abgeschlossen.

Der neue Kernel war vorhanden.

ZFS hatte erfolgreich gebaut.

SSH funktionierte.

Gleichzeitig befanden sich verschiedene langlebige Prozesse nach dem Austausch großer Teile des Userspace naturgemäß in etwas seltsamen Übergangszuständen.

Samba war gestoppt.

openHAB war gestoppt.

Einige Dienste hatten noch alte Bibliotheken im Speicher.

Andere liefen bereits mit den neuen.

Es gab keinen guten Grund, dieses temporäre Zwischenuniversum noch lange zu debuggen.

Nach 145 Tagen war es schlicht Zeit für den Neustart.

Selbst das Herunterfahren lieferte noch einen kleinen Moment Spannung. Ein zweiter Reboot-Befehl antwortete kurzzeitig mit:

Failed to set wall message, ignoring: Transport endpoint is not connected
Call to Reboot failed: Transport endpoint is not connected

Die Maschine hatte zu diesem Zeitpunkt bereits Teile ihrer IPC-Umgebung abgebaut und wartete noch auf verbleibende Stop-Jobs.

Wenig später brach SSH ab.

Das war der tatsächliche Neustart.

Ein paar Minuten später antwortete die Maschine wieder.

Debian 13.

Neuer Kernel.

Und dann begann der angenehm langweilige Teil.

---

Alles funktionierte

Samba funktionierte.

TVHeadend erkannte den Tuner und empfing Fernsehen.

Die PHP-Anwendungen liefen.

MariaDB lief.

Valkey lief.

Docker startete mit seinen Containern wieder.

Frigate nahm die Videoanalyse erneut auf.

openHAB lief unter dem neuen OpenJDK.

Prometheus und Grafana kamen zurück.

WeeWX funktionierte.

MQTT funktionierte.

Node 24 und Yarn 4 funktionierten.

Meine eigenen lokalen Anwendungen funktionierten.

Ein einziger fehlgeschlagener Dienst blieb übrig: OpenIPMI.

Die Maschine besitzt überhaupt keine IPMI-Hardware.

Es stellte sich heraus, dass der Dienst nur indirekt installiert worden war, weil ein Prometheus-Collector-Paket von ipmitool abhängt.

Also deaktivierte ich den nutzlosen Dienst und machte weiter.

Das war im Wesentlichen alles.

---

Das Performance-Ergebnis hat mich überrascht

Vor dem Upgrade war das System im Laufe der Zeit spürbar beschäftigter geworden.

Ungefähr sechs Monate zuvor sah ein normaler Workload grob so aus:

Zustand	Load Average	RAM-Nutzung
Früherer Ausgangswert	2.0 / 2.4 / 2.5	11–12 GB
Direkt vor dem Upgrade	3.61 / 4.24 / 3.75	~14 GB
Debian 13, einige Stunden später	1.15 / 1.34 / 1.56	~6.6 GB

Auch die CPU-Auslastung pendelte sich unter normalem Workload bei ungefähr 12 Prozent ein.

Und die Maschine fühlt sich schlicht direkter an.

Terminal-Interaktionen reagieren unmittelbarer. Webanwendungen wirken etwas knackiger. Paketdownloads über Debians CDN sind schneller. Das gesamte System macht einen weniger belasteten Eindruck.

Daraus würde ich ausdrücklich nicht die Aussage ableiten:

Debian 13 benötigt nur halb so viel RAM wie Debian 12.

Das wäre schlechtes Benchmarking.

Ich hatte eine Maschine neu gestartet, die zuvor 145 Tage durchgelaufen war. Ich entfernte veraltete Laufzeitumgebungen. Prozesse starteten aus einem sauberen Zustand. Große Teile des Userspace wurden aktualisiert. Alte Pakete verschwanden. Java- und Node-Umgebungen änderten sich.

Diese Effekte lassen sich nicht sauber voneinander isolieren.

Das operative Ergebnis ist trotzdem real:

Derselbe praktische Workload läuft jetzt mit deutlich geringerer Last und erheblich weniger Speicherverbrauch als unmittelbar vor der Migration.

Auch mehrere Stunden später blieben die Werte niedrig.

Das ist reale Kapazität, die dem System wieder zur Verfügung steht.

---

56 TiB sind ziemlich viel „Homelab“

Eine Zahl aus der alten Uptime blieb besonders hängen.

btop meldete über diese 145 Tage ungefähr:

51 TiB received
 5 TiB transmitted

Natürlich ist das nicht ausschließlich Internet-Traffic. Ein Server wie dieser bewegt beträchtliche Mengen an lokalem Video, Monitoring-Daten, Backups, Medien und Anwendungstraffic.

Trotzdem illustriert die Zahl einen wichtigen Punkt.

Diese Maschine ist kein dekoratives Homelab-Dashboard.

Sie arbeitet tatsächlich.

Jeden Tag.

Sie zeichnet Kameras auf.

Sie verarbeitet Fernsehen.

Sie speichert Dateien.

Sie hostet Anwendungen, die ich benutze.

Sie koordiniert mein Smart Home.

Sie sammelt Wetterdaten.

Sie überwacht andere Maschinen.

Sie betreibt Datenbanken.

Sie baut Software.

Sie verschiebt Backups.

Sie ist Infrastruktur.

Und trotz all dessen liegt der Load Average nach dem Upgrade bei ungefähr 1,3 und der Speicherverbrauch bei rund 6,5 GB.

Moderne Computer sind absurd leistungsfähig, wenn man sie einfach lässt.

---

Man muss nicht alles dockerisieren

Ich mag Docker.

Frigate ist ein sehr gutes Beispiel für einen Workload, bei dem ein Container für mich absolut sinnvoll ist. Dasselbe gilt für mehrere andere Dienste auf diesem Server.

Aber Container lösen bestimmte Probleme.

Sie sind keine moralische Verpflichtung.

Wenn Debian für eine Anwendung bereits ein ausgereiftes Paket mitbringt und sich der Dienst natürlich in den Host integriert, kann eine direkte Installation die simplere Lösung sein.

Native Dienste erhalten:

• systemd-Lifecycle-Management
• normale Journal-Integration
• konventionelle Pfade im Dateisystem
• Sicherheitsupdates der Distribution
• direkten Hardwarezugriff, wo sinnvoll
• unkompliziertes Networking
• weniger Abstraktionsschichten

Container geben mir:

• Paketierungsisolation
• kontrollierte Dependency-Umgebungen
• komfortable Upstream-Distribution
• einfache Entfernung
• sinnvolle Grenzen für Anwendungen mit komplexen Runtime-Anforderungen

Ich nutze beides.

Das ist die Architektur.

Nicht „Bare Metal gegen Docker“.

Nicht „Proxmox gegen Debian“.

Man sollte die kleinste Abstraktion verwenden, die das jeweilige Problem sauber löst.

---

Komplexität des Workloads ist nicht dasselbe wie Komplexität der Architektur

Das ist vielleicht die zentrale Erkenntnis.

Der Server erledigt sehr viel.

Sein mentales Modell bleibt trotzdem recht einfach:

                    Local network
                         │
        ┌────────────────┼────────────────┐
        │                │                │
      DNS/MQTT       Applications      Automation
        │                │                │
        └────────────────┼────────────────┘
                         │
              ┌────────────────────┐
              │     Debian 13      │
              │                    │
              │ Native services    │
              │ Docker workloads   │
              │ Databases          │
              │ Storage            │
              │ Media / DVB        │
              │ Monitoring         │
              │ Dev tooling        │
              └────────────────────┘
                         │
                   Ansible IaC
                         │
                Backups / restore

Darunter liegt ein einziges universelles Betriebssystem.

Ich kann Prozesse normal untersuchen.

Ich kann Netzwerk-Sockets normal untersuchen.

Ich kann Logs normal lesen.

APT kennt die Pakete.

systemd kennt die Dienste.

Ansible kennt die Konfiguration.

Prometheus kennt die Performance.

Die Backups kennen den Zustand.

Diese Einfachheit ist wertvoll.

---

KI macht Wartung einfacher – Urteilsvermögen bleibt trotzdem entscheidend

Zwischen diesem Upgrade und vergleichbaren Wartungsarbeiten vor zehn Jahren gibt es noch einen wesentlichen Unterschied:

Die Fehlersuche bei unbekannten Sonderfällen ist heute drastisch schneller.

Als ZFS-DKMS scheiterte, als NodeSource mit Debians strengerer Signatur-Policy kollidierte, als eine Ansible-Deprecation auftauchte oder wenn ich überprüfen wollte, was eine bestimmte Transition genau bedeutete, konnte ich das Problem sofort gemeinsam mit KI durchdenken – statt zwanzig Minuten lang die richtige Kombination an Suchbegriffen zusammenzusetzen und anschließend veraltete Forenbeiträge gegeneinander abzuwägen.

Das ersetzt nicht die Notwendigkeit, das eigene System zu verstehen.

Im Gegenteil.

KI ist hier besonders nützlich, wenn man bereits genug versteht, um eine Antwort einzuordnen, die Abhängigkeitskette nachzuvollziehen und beurteilen zu können, ob ein vorgeschlagener Befehl auf der eigenen Maschine tatsächlich sinnvoll ist.

Sie komprimiert den Recherchezyklus.

Sie ersetzt kein operatives Urteilsvermögen.

Für die Wartung komplexer persönlicher Infrastruktur ist das trotzdem ein erheblicher Fortschritt.

---

Große Upgrades sind ein Test für die Qualität der Architektur

Uptime ist befriedigend.

Aber Uptime allein kann auch Fragilität verbergen.

Eine Maschine, die seit 500 Tagen nicht neu gestartet wurde, kann außerordentlich stabil sein – oder schlicht 500 Tage angesammelte Annahmen enthalten, die seitdem niemand mehr überprüft hat.

Ein großes Betriebssystem-Upgrade zwingt diese Annahmen ans Licht.

Kann sich der Kernel ändern?

Können sich Abhängigkeiten ändern?

Können Dienste neu starten?

Lässt sich die Konfiguration weiterhin reproduzieren?

Versteht man Fehler, wenn sie auftreten?

Kann man eine veraltete Abhängigkeit ersetzen, statt sie auf ewig mitzuschleppen?

Kann man neu starten und mit gutem Grund davon ausgehen, dass das System wiederkommt?

Genau deshalb hatte ich nach dieser Migration mehr Vertrauen in die Architektur als zuvor.

Sie hat Veränderung überstanden.

---

Vier Stunden, die sich gelohnt haben

Vom Beginn der Migration von Debian 12 auf Debian 13 bis zu einer vollständig funktionierenden, bereinigten und wieder mit Ansible konvergierenden Maschine vergingen ungefähr vier Stunden.

Die wesentlichen Punkte waren:

• Modernisierung der Debian-Repository-Konfiguration
• eine ZFS-DKMS-Inkompatibilität
• Austausch eines veralteten NodeSource-Signaturschlüssels
• Neuaufbau der pipx-Umgebungen für Python 3.13
• Umstellung von openHAB auf Debians natives OpenJDK 21
• Bereinigung alter Java- und Python-Runtimes
• Anpassung einiger moderner Ansible-Konventionen

Es gab keine Katastrophe.

Keine Neuinstallation.

Keinen längeren Ausfall.

Kein Suchen nach vergessener Konfiguration auf einer undokumentierten Maschine.

Und keinen Gang in den Keller, um einen alten Monitor hervorzukramen, weil SSH nie wieder zurückkam.

Das Ergebnis ist ein saubererer Debian-13-Server mit weniger externen Abhängigkeiten, einer modernen Entwicklungsumgebung, geringerem Speicherbedarf auf der Festplatte, deutlich reduzierter Last und wesentlich niedrigerem RAM-Verbrauch.

Vor allem aber erledigt er weiterhin still und zuverlässig alles, was er vorher erledigt hat.

Genau das erwarte ich von Infrastruktur.

Kein architektonisches Spektakel.

Keine maximale Abstraktion.

Nicht die größtmögliche Ansammlung an Plattformen zwischen Hardware und Anwendung.

Sondern ein System, dessen Komplexität proportional zu den Problemen bleibt, die es tatsächlich löst.

Manchmal kann das immer noch eine einzige, sehr leistungsfähige Linux-Maschine sein.

Und manchmal ist das beste Zeichen dafür, dass man sie gut gebaut hat, dass selbst das gefürchtete große Upgrade am Ende angenehm langweilig ausfällt.