← KADAI English
KADAI · Stand 3. Oktober 2026 · gezeigt an der Seed-Maschine, gilt für jede Maschine

Was wann wo gezogen und gestartet wird

Drei Zeitabschnitte im Leben einer KADAI-Maschine: der einmalige Erstboot (die Zeremonie), jeder spätere Boot (die Regel), und der laufende Betrieb bis zum Herunterfahren. Farben zeigen die Richtung: ziehen, schieben, starten, Mensch.

ziehen - vom Repo-Host / Nextcloud auf die Maschine schieben - von der Maschine zum Repo-Host starten / auslösen - innerhalb der Maschine Mensch - Eingabe oder Handgriff

1 · Erstboot - einmalig, die Zeremonie

Das Seed-Image ist generisch. Erst die Zeremonie macht daraus Ihre Maschine: Sie erzeugt ihre eigenen Schlüssel, im Sicherheitschip, wo sie einen hat, holt das Kernel-Repo, entsperrt mit Ihrer Passphrase die Master-Identität und trägt sich selbst in die Empfängerliste ein. Auf einem laufenden Ubuntu macht dasselbe der Assistent aus dem Startpaket (start/); er trägt auch den Deploy-Key selbst ein, über ein Token, das nur die Master-Identität öffnet. Schritt 4 entfällt dann.

Sie Maschine (Seed-VM) Repo-Host · kadai-kernel Nextcloud kadai/seeds/*.qcow2 Image holen, VM anlegen VM bootet aus dem Seed 1 Login kadai / kadai kadai-setup startet (Konsole) 2 erzeugt lokal, aus Zufall: Sync-Schlüssel (ssh) + age-Schlüssel, im Chip oder als Datei 3 Deploy-Key eintragen(Paket: macht der Assistent) Deploy Keys (write) 4 me.md.age · Skripte git clone ~/kadai (Repo-Kopie) 5 Master-Passphrase master-key.age nur im RAM entsperren 6 Kernel entschlüsseln → me.md eigenen Schlüssel in .kadai-recipients; Kernel und Schlüsselbund-Passwort neu verschlüsseln 7 enroll-Commit Units installieren: Kernel-Sync, Autosave, stündlicher Push, Compile Linger an → ab jetzt gilt Abschnitt 2 8
Die Maschinen-Identität (Schritt 3) entsteht aus dem Nichts auf der Maschine; Ihre Person-Identität liegt vorher im Repo. Schritt 6–7 verheiraten beide: Danach ist die Maschine vollwertiger Empfänger und braucht die Passphrase nie wieder. Der einzige Schritt außerhalb der Maschine ist der Deploy-Key (4); auf dem Paketweg übernimmt ihn der Assistent.

2 · Jeder Boot - die Regel

Ab dem zweiten Boot läuft alles ohne Zeremonie. Die Reihenfolge ist erzwungen: Der Kernel ist entschlüsselt, bevor Plasma startet; der Desktop wird reconciled, bevor Sie den Sperrbildschirm entsperren.

Repo-Host System (root) Ihre Dienste (kadai) Plasma · Bildschirm Sie 1 UEFI → systemd-boot → Linux 2 NetworkManager: DHCP 3 SDDM: Autologin kadai systemd --user startet 4 kadai-kernel.service age -d → me.md (Klartext) me.md.age · Spec git pull (Merge), dann Push 5 Plasma-Sitzung startet Before= erzwingt Reihenfolge 6 „Willkommen, Jan - Kernel geladen" 7 kadai-compile.service Reconciler: Soll (Spec) vs. Ist Ist-Zustand per DBus lesen nur die Differenz anwenden 8 Sperrbildschirm (Autostart) 9 Ihr Desktop: Activities, Widgets Passwort
Schritt 4 läuft dank Linger schon beim Boot, nicht erst beim Login; die Ordnung Before=plasma-workspace.target garantiert, dass Plasma (5) erst nach dem entschlüsselten Kernel startet. Der Reconciler (7) ist idempotent: Stimmt der Desktop schon, tut er nichts. Sie sehen davon nur 8 und 9.

3 · Betrieb & Herunterfahren - was zurückfließt

Was Sie während der Sitzung ändern, fließt über genau einen Kanal zurück: das Repo mit Kernel, Schlüsselbund und Tresor. Alle zehn Minuten wird lokal gesichert, ohne Netz und ohne Schlüssel; hinaus geht es bei An- und Abmeldung und stündlich, über den Sync-Schlüssel, der keine Präsenz verlangt. Andere Maschinen bekommen es bei ihrem nächsten Boot oder ihrem nächsten stündlichen Push, der dann erst zieht.

Repo-Host Diese Maschine Nextcloud Andere Maschinen kadai-kernel-autosave.timer · alle 10 min me.md geändert? → an alle Empfänger verschlüsseln → commit, lokal auto-save-Commit Anmeldung, stündlich, Logout / Herunterfahren: kadai-kernel-push.timer, ExecStartPost, ExecStop → Push; abgelehnt → Merge je Datei → Push .kadai-storage.sh offload / restore / pin auf Zuruf; lokal bleibt ein Platzhalter; jede Bewegung protokolliert kadai-storage/… beim nächsten Boot: git pull → entschlüsseln → Begrüßung mit neuem Stand Bau-VM, künftige
Sichern und Pushen teilen sich dieselbe Prüfung (SHA-256 des Klartexts): Nur echte Änderungen erzeugen Commits - sonst würde die nicht-deterministische Verschlüsselung alle zehn Minuten Phantom-Commits produzieren. Wird ein Push abgelehnt, weil eine andere Maschine zuerst da war, führt git je Datei mit einem eigenen Treiber zusammen: den Kernel je Eintrag, den Schlüsselbund je Eintrag, den Tresor gar nicht, der fremde Stand wird daneben gelegt. Die git-Historie ist damit zugleich das Protokoll, welche Maschine wann etwas wusste.

Wo lebt was

Die Frage „reist das mit?" beantwortet sich am Ort: Nur was im Repo liegt, kommt auf jede Maschine.

OrtWasReist mit?
Ihr Kopfdie Master-Passphrase (Laborwert - hier nicht abgedruckt)ja - das ist ihr Zweck
Repo · kadai-kernel (eigener Forgejo-Server)me.md.age (Kernel, verschlüsselt an alle Maschinen), .kadai-recipients und .kadai-revoked, master-key.age, keyring.kdbx mit keyring.pass.age (Systemzugänge), vault.kdbx (Ihre Passwörter), desktop-spec.json, alle Skripte, bootstrap.shja - auf jede Maschine
Maschine, lokalage-Maschinenschlüssel und Sync-Schlüssel (im Sicherheitschip, sonst als Datei), entschlüsseltes me.md, Beobachtungslogs (Abgleich, Vorschläge), Autologin-/Sperr-Konfiguration, alles in Plasma, was die Spec nicht abdecktnein - bewusst nicht (Schlüssel) bzw. noch nicht (Logs, Konfiguration)
NextcloudSeed-Images unter kadai/seeds/; ausgelagerte Dateien unter kadai-storage/Seeds: für alle · Dateien: bei Bedarf zurückholbar
AbgeleitetActivities, Farben, Panel-Widgets - vom Reconciler aus der Spec erzeugtwird auf jeder Maschine neu hergestellt
Die Grenze zwischen „lokal" und „im Repo" ist die Aufgabe der nächsten Ausbaustufen: Autologin und Sperre in bootstrap.sh, mehr Desktop-Eigenschaften in die Spec, Anwendungen als deklarierte Paketliste, Beobachtungslogs als eigene synchronisierte Schicht. Der Nextcloud-Zugang ist seit Oktober 2026 umgezogen: aus einer lokalen Datei in den Schlüsselbund, der mitreist. Was Sie am System wollen, gehört ins Repo - was die Maschine ist, bleibt lokal.