Neuer Linux-Client:
Erst das Sicherheitsnetz, dann die Einrichtung

Ein frisch installierter Rechner ist der verletzlichste Moment im Leben einer Maschine. Alles ist neu, nichts ist gesichert — und genau jetzt greift man tief ins System ein: Paketquellen, Bootloader, Shell-Konfiguration. Geht dabei etwas schief, steht die Neuinstallation an.

Ich habe diese Woche einen neuen Linux-Client aufgesetzt und dabei eine Reihenfolge eingehalten, die ich vorher anders gemacht hätte. Dieser Beitrag beschreibt sie — samt der drei Fallen, in die ich getreten bin.

Die Reihenfolge ist die eigentliche Erkenntnis

Der naheliegende Ablauf wäre: System installieren, Werkzeuge einrichten, produktiv werden, irgendwann Backups aufsetzen. Das ist genau falsch herum.

Richtig ist:

1. Rückwärtsgang zuerst. Snapshot-Netz einrichten, bevor irgendetwas anderes passiert — und den Rollback einmal wirklich ausprobieren.
2. Dann erst die Einrichtung. Schlüssel, Editor, Konfiguration, Shell-Aliase.
3. Zum Schluss die Mobilität. Fernzugriff, wenn das Gerät das Haus verlässt.

Der Grund ist simpel: Schritt 2 ist der riskante Teil. Er fasst Bootloader und Systemdateien an. Wer ihn ohne funktionierendes Sicherheitsnetz macht, hat bei einem Fehler nichts in der Hand. Und „funktionierend" heißt: erprobt, nicht bloß installiert.

Phase A: Das Snapshot-Netz — und die drei Fallen

Die Zutaten sind Standard: Btrfs als Dateisystem mit den Subvolumes @ und @home, Timeshift im Btrfs-Modus für die Snapshots, grub-btrfs, um aus dem Bootmenü heraus in einen Snapshot zu starten, und timeshift-autosnap-apt, das vor jedem Paket-Update automatisch einen Snapshot zieht.

Das Versprechen: Ein Update zerlegt das System, man startet neu, wählt im GRUB-Menü den Snapshot von vorhin, und alles ist wieder gut.

Bei mir hat genau das erst einmal nicht funktioniert — aus drei voneinander unabhängigen Gründen. Alle drei sind generischer Natur und dürften jeden treffen, der dieselbe Kombination fährt.

Falle 1: Die Snapshots waren gar nicht bootbar

Im GRUB-Menü erschienen die Snapshots, aber der Start brach ab. Ursache war eine Kette:

grub-btrfs erzeugt die Snapshot-Einträge, indem es die Mount-Optionen der Root-Zeile aus der fstab im Snapshot übernimmt. Dort stand — völlig üblich — defaults,subvol=@. Daraus wurde ein Kernel-Parameter rootflags=defaults,subvol=….

Und da liegt das Problem: Beim normalen Mounten filtert mount(8) das Schlüsselwort defaults vorher heraus. Der Kernel bekommt rootflags beim Root-Mount aber direkt, ohne diesen Filter — und lehnt es als ungültige Option ab. Der Boot scheitert, bevor irgendetwas Lesbares auf dem Schirm steht.

Lösung: defaults aus der Root-Zeile der fstab entfernen (subvol=@ allein genügt) und die Erkennungsfunktion in der GRUB-Snapshot-Konfiguration so anpassen, dass sie das Schlüsselwort auch aus bereits bestehenden Snapshots herausfiltert. Nur das eine zu tun reicht nicht: ohne den zweiten Teil bleiben alle älteren Snapshots unbootbar.

Falle 2: Das Bootmenü wurde nie aktualisiert

Neue Snapshots tauchten im GRUB-Menü nicht auf. Der zuständige Dienst lief, meldete keinen Fehler — und tat trotzdem nichts Sinnvolles.

Der Grund ist ein feiner, aber folgenschwerer Unterschied: Die systemd-Unit bindet ihre Konfigurationsdatei per EnvironmentFile= ein. Diese Datei ist aber als Shell-Skript geschrieben und enthält eine Verzweigung der Art „wenn das hier eine Fedora-Installation ist, nimm diese Pfade".

systemd wertet in einer EnvironmentFile keine Shell-Logik aus. Es liest stumpf SCHLÜSSEL=WERT-Zeilen. Die Bedingung wurde also ignoriert und die Zweige bedingungslos gesetzt — der Dienst suchte auf einem Debian-basierten System nach Fedora-Pfaden und schrieb ins Leere.

Lösung: Die Verzweigung auskommentieren und die für die eigene Distribution korrekten Pfade explizit setzen.

Falle 3: Die Automatik-Erkennung ist unzuverlässig

grub-btrfs bringt eine Betriebsart mit, die Timeshift-Snapshots automatisch finden soll. Klingt bequem, ist aber fragil: Der Dienst wartet nach dem Dateisystem-Ereignis eine Sekunde und sucht dann in der Prozessliste nach dem laufenden Timeshift, um daraus den Pfad abzuleiten.

Das funktioniert bei Snapshots, die man von Hand über die grafische Oberfläche anlegt — die dauern lang genug. Bei allen automatischen Snapshots (beim Booten, täglich, vor Paket-Updates) ist Timeshift nach einer Sekunde längst fertig und aus der Prozessliste verschwunden. Die Suche liefert nichts, der Pfad wird falsch, das Menü bleibt alt.

Bitter daran: Es sind genau die automatischen Snapshots, auf die man sich verlässt.

Lösung: Auf die Automatik verzichten. Stattdessen die oberste Btrfs-Ebene fest einhängen und dem Dienst den Snapshot-Pfad direkt mitgeben. Damit dabei keine Startreihenfolge-Probleme entstehen, gehört in die Unit zusätzlich eine Abhängigkeit auf diesen Mountpunkt.

Und dann: den Rollback wirklich testen

Das ist der Schritt, den man am liebsten überspringt. Nicht tun. Datei anlegen, Snapshot ziehen, Datei löschen, Snapshot zurückspielen, nachsehen ob die Datei wieder da ist.

Dabei lernt man auch eine Design-Entscheidung kennen, die man bewusst treffen sollte: Gehört @home mit in die Snapshots? Ist es drin, holt ein Rollback auch persönliche Dateien zurück — man verliert also alles, was seit dem Snapshot entstanden ist. Ist es draußen, bleiben eigene Dateien unangetastet, aber ein Rollback ist dann eben nur ein System-Rollback. Beides ist vertretbar; man muss nur wissen, was man gewählt hat, bevor man es im Ernstfall herausfindet.

Ein letzter Fallstrick am Rande: Der GRUB-Konfigurationsordner führt beim Neuerzeugen des Menüs jede ausführbare Datei darin aus. Wer dort eine Sicherungskopie ablegt und das Ausführbar-Bit stehen lässt, bekommt jeden Menüeintrag doppelt. Sicherungen gehören woanders hin.

Phase B: Der Client gliedert sich selbst ein

Jetzt erst wird eingerichtet — und zwar so, dass die Maschine sich den Zustand holt, statt dass man ihn ihr aufträgt.

Ein eigener Schlüssel pro Gerät

Der verlockende Weg ist, den vorhandenen Infrastruktur-Schlüssel auf das neue Gerät zu kopieren. Der richtige Weg ist, dass das Gerät sich lokal einen eigenen erzeugt und nur der öffentliche Teil einmal auf dem Git-Server hinterlegt wird.

Der Unterschied zeigt sich am Tag, an dem das Notebook im Zug liegen bleibt: Dann sperrt man genau einen Schlüssel, und der Rest der Infrastruktur bleibt unberührt. Beim kopierten Schlüssel tauscht man alles. Nebeneffekt: Kein privater Schlüssel wandert je über einen USB-Stick.

Dotfiles aus dem eigenen Git

Shell-Konfiguration, Aliase und Editor-Einstellungen liegen in einem Git-Repository auf einer selbst gehosteten Instanz — Gitea, Forgejo oder GitLab tun es gleichermaßen. Der neue Rechner klont es und verlinkt die Dateien in sein Home-Verzeichnis.

Der Gewinn ist nicht die einmalige Einrichtung, sondern der Alltag danach: Ein neuer Projekt-Alias wird einmal ins Repo geschrieben und ist nach einem pull auf allen Maschinen da. Kein Nachpflegen, kein Auseinanderdriften. Die Aliase selbst sind kleine Helfer, die eine SSH-Verbindung zum richtigen Server aufbauen, ins richtige Verzeichnis wechseln und die passende Terminal-Sitzung anhängen — aus drei Handgriffen wird ein Wort.

Wichtig dabei, und der Grund, warum das überhaupt sauber funktioniert: In diese Repositories gehören keine Geheimnisse. Keine Tokens, keine Passwörter, keine privaten Schlüssel — auch nicht in Kommentaren, auch nicht in der Dokumentation. Konfiguration ja, Zugangsdaten nein. Die gehören in einen Passwort-Speicher, auf den zur Laufzeit zugegriffen wird. Wer diese Trennung nicht von Anfang an zieht, zieht sie später unter Schmerzen.

Editor: native Paketinstallation, nicht die Sandbox

Eine kleine, aber praktische Erkenntnis: Wenn der Editor per Remote-Verbindung auf Servern arbeiten soll, ist die native Paket-Variante aus dem offiziellen Repository die richtige Wahl — nicht die Sandbox-Variante aus einem Flatpak-Store. Deren Isolation macht Remote-SSH, integriertes Terminal und Terminal-Multiplexer zur Geduldsprobe. Sind versehentlich beide installiert, konkurrieren zwei gleichnamige Befehle miteinander.

Phase C: Tailscale für die Mobilität

Zum Schluss der Fernzugriff. Ein Mesh-VPN wie Tailscale (oder das quelloffene Headscale als eigener Koordinationsserver) verbindet die Geräte direkt miteinander, statt allen Verkehr durch einen zentralen Einwahlpunkt zu zwingen.

Zwei Dinge, die ich vorher nicht wusste:

Erstens genügt es nicht, das Gerät ins Netz aufzunehmen, wenn man auch die anderen Geräte im Heimnetz erreichen will — also solche, auf denen das VPN selbst nicht läuft. Dafür muss irgendwo im Netz ein Gerät die lokalen Subnetze anbieten, und der Client muss diese Routen annehmen. Unter Linux ist das kein Schalter in der Weboberfläche, sondern eine Option beim Verbinden. Ob sie aktiv ist, lässt sich am Client abfragen.

Zweitens beweist ein Test im eigenen WLAN gar nichts: Die Pakete nehmen dann ohnehin den direkten Weg, das VPN ist gar nicht beteiligt. Der einzige aussagekräftige Test ist der von draußen — WLAN aus, Mobilfunk an, und dann prüfen, ob die internen Dienste antworten.

Angenehm im Alltag: Das Ganze läuft im Hintergrund, ohne Verbinden-Knopf, und nur der Verkehr zu den eigenen Zielen geht durch den Tunnel. Normales Surfen bleibt direkt.

Wo KI dabei hilft — und wo nicht

Ich habe die Einrichtung mit einem Kommandozeilen-Agenten begleitet, der im Terminal arbeitet, Dateien liest und Befehle ausführt. Der ehrliche Befund nach dieser Woche:

Wo es wirklich trägt: beim Diagnostizieren. Die drei Fallen oben haben eines gemeinsam — das Symptom liegt weit vom Verursacher entfernt. Ein nicht bootender Snapshot sagt nichts über ein Schlüsselwort in der fstab. Ein Dienst, der ohne Fehlermeldung nichts tut, sagt nichts darüber, dass systemd keine Shell-Logik auswertet. Solche Ketten systematisch rückwärts zu verfolgen, Konfiguration gegen den tatsächlichen Systemzustand zu prüfen und die Ursache zu benennen statt am Symptom zu drehen — das ist die Stärke.

Wo man aufpassen muss: bei fertigen Rezepten. Ein im Voraus geschriebenes Einrichtungsskript bildet den Wissensstand vor dem ersten Kontakt mit der echten Maschine ab. Mein eigenes Referenzskript verwendete genau die Automatik aus Falle 3 — es hätte den Fehler brav reproduziert. Erst der Abgleich zwischen Skript und laufendem System hat das aufgedeckt.

Daraus folgt die eigentliche Arbeitsteilung: Das Skript ist der Ausgangspunkt, nicht das Ergebnis. Was am System gelernt wird, muss zurück ins Skript — sonst läuft der nächste Rechner in dieselben drei Fallen.

Kurzfassung als Checkliste

1. Snapshot-Netz zuerst. Vor jeder anderen Einrichtung.
2. Rollback erproben. Installiert ist nicht funktionierend.
3. Bewusst entscheiden, ob das Home-Verzeichnis Teil der Snapshots ist.
4. Automatik-Erkennung meiden, Pfade explizit setzen.
5. Eigener Schlüssel pro Gerät, nie einen geteilten kopieren.
6. Konfiguration nach Git, Geheimnisse in den Passwort-Speicher. Getrennt halten.
7. Fernzugriff von draußen testen, nicht aus dem eigenen WLAN.
8. Gelerntes zurück ins Skript schreiben.

Punkt 1 und 2 kosten zusammen eine halbe Stunde. Sie sind die beste halbe Stunde, die man in einen neuen Rechner steckt.

Nachtrag zur Haltbarkeit: Zwei der drei Korrekturen liegen in Dateien, die von Paketen verwaltet werden. Ein Update der betreffenden Pakete kann sie überschreiben. Nach solchen Updates lohnt ein kurzer Blick — und ein Boot-Test in einen Snapshot.

KI-Tools für Ihr Unternehmen?

Ob lokale Spracherkennung, automatisierte Workflows oder datenschutzkonforme KI-Infrastruktur — WOLFSOFT begleitet Ihr Team bei der Umsetzung. Komplett ohne Cloud-Zwang.