Den Node installieren

Ein Befehl als root macht aus einem frischen Ubuntu-Server deinen Node. Gib ihm den Token von deinem Ansprechpartner bei detachbox und die leere Disk für den Pool:

curl -fsSL https://api.detachbox.com/api/v1/node-host/install \
  | sudo bash -s -- <token> --disk /dev/sdb

Das dauert 30 bis 60 Minuten; die meiste Zeit kostet der Build von OpenZFS und des ersten Basis-Images. Am Ende steht „The node … is live“, und die Terminals deines Kontos öffnen sich unter https://my.detachbox.com.

Melden sich auf dem Server auch andere Leute an, lass den Token weg: Eine Befehlszeile sieht jeder lokale Benutzer, solange die Installation läuft. Ohne Token fragt der Befehl in deinem Terminal mit detachbox enrollment token: danach und zeigt deine Eingabe nicht an.

curl -fsSL https://api.detachbox.com/api/v1/node-host/install \
  | sudo bash -s -- --disk /dev/sdb

Was der Befehl annimmt

Ein neuer Lauf ohne --private-network behält die Netze, die der frühere Lauf bekommen hat. Sobald der Node registriert ist, änderst du sie mit private-networks, nicht mit dem Installationsbefehl.

Erst kommen die Prüfungen

Der Befehl beginnt mit einer Tabelle von Prüfungen: das System, root, systemd, das Root-Dateisystem, andere Container oder Tunnel auf dem Server, CPU und RAM, die Disk, die privaten Netze, die Uhr, Secure Boot und die Kernel-Header, wenn ZFS gebaut werden muss, DNS, jedes ausgehende Ziel, TLS und der Token. Jede Zeile zeigt ✓ oder ✗, und unter jedem ✗ steht die Lösung. Auf dem Server ändert sich nichts, bis jede Zeile ✓ zeigt.

Um die Tabelle schon vor dem Tag der Installation zu sehen, setz --check hinter den Token:

curl -fsSL https://api.detachbox.com/api/v1/node-host/install \
  | sudo bash -s -- <token> --check --disk /dev/sdb

Der Befehl führt dann nur die Prüfungen aus und endet mit Nothing on this machine changed and the token is not spent: the same command without --check installs the node. Der heruntergeladene und geprüfte node-host bleibt für diesen nächsten Lauf auf dem Server, wie nach jedem Lauf.

Die acht Schritte

1. Pakete: das neueste Incus aus dem Stable-Repository von Zabbly (7.6 oder neuer) und das neueste cloudflared von Cloudflare, aus ihren eigenen apt-Repositories, mit ihren Signaturschlüsseln fest im Installer. Die Installation hält beide zurück (apt-mark hold): Ein Neustart von einem der beiden kappt die offenen Verbindungen zum Node für ein paar Sekunden, also werden sie nur in einem Moment aktualisiert, den du wählst, oder an einem Tag, an dem kein Terminal läuft.
2. OpenZFS 2.4.4 und das Limit für den ZFS-Cache. Der Installer baut OpenZFS aus dem offiziellen Release, mit festgelegtem SHA-256 und einer Signatur, die er mit dem Release-Schlüssel von OpenZFS prüft, zu Paketen mit einem DKMS-Modul, sodass jeder Kernel mit Headern es bekommt. Er tauscht Ubuntus Modul ohne Neustart gegen das neue.
3. Der ZFS-Pool boxes auf deiner Disk.
4. Incus: sein Storage, zwei Bridges (eine für die Terminals, eine für den Edge des Nodes), ihre Firewall-Regeln, die Projekte und die API von Incus selbst, nur auf der Bridge des Edge.
5. Das erste Basis-Image: Ubuntu mit Docker, Claude Code, Codex und OpenCode, 10 bis 20 Minuten. Der Node baut es alle 6 Stunden neu.
6. Registrierung bei api.detachbox.com: Der Node bekommt seinen Namen, seine Schlüssel, seinen Cloudflare-Tunnel und seine eigene Domain unter detachbox.dev; node-host bekommt seine Konfiguration und seine Units.
7. cloudflared und node-host starten.
8. Die Inbetriebnahme durch den Server: detachbox erreicht node-host über den Tunnel, startet den Edge (das Terminal-Gateway und den Preview-Proxy), führt einen Smoke-Test aus und richtet das Compute deines Kontos ein. Der Befehl gibt jede Stufe aus, sobald der Server sie erreicht.

Jeder Schritt zeigt den Teil, an dem er gerade ist, etwa Configure, Compile und Packaging des OpenZFS-Builds. Während ein langer Teil läuft, kommt alle 30 Sekunden eine Zeile.

Ein neuer Lauf macht dort weiter, wo der alte stehen blieb

Stoppt irgendetwas die Installation, etwa ein blockierter Host, eine abgerissene Verbindung oder ein Neustart, führ denselben Befehl noch einmal aus. Er macht bei dem Schritt weiter, der abgebrochen ist, und was schon fertig ist, macht er nicht noch einmal. Der heruntergeladene und geprüfte node-host bleibt auf dem Server, nur für root lesbar, bis die Installation ihn an seinen Platz legt. Ein Token lädt node-host dreimal herunter, danach einmal alle 30 Minuten; der Befehl sagt, wie lange du warten musst.

• Bricht die Remote-Shell ab, aus der du ihn gestartet hast, stoppt die Installation, wo sie gerade ist. Ohne Terminal gestartet, aus einem Skript oder einem Tool mit Zeitlimit, läuft sie weiter. Bei einer wackligen Verbindung führ sie in tmux aus.
• Ctrl-C oder sudo kill <pid> aus einer anderen Sitzung stoppt einen Lauf innerhalb von Sekunden, samt allem, was sein Schritt gestartet hat.
• Immer nur ein Lauf. Startest du den Befehl, während ein Lauf arbeitet, ändert er nichts: Er sagt, seit wann dieser Lauf arbeitet, unter welchem Prozess und wie du ihn verfolgst.
• Ein neuer Lauf nutzt dieselbe Disk. Um auf einer anderen Disk neu anzufangen, deinstallier zuerst.

Wenn ein Schritt scheitert

Der Befehl gibt aus, was gescheitert ist, warum, und den Befehl oder die Änderung, die es behebt, mit den letzten 30 Zeilen des fehlgeschlagenen Befehls. Der Fehler geht mit deinem Token an detachbox, also sieht ihn auch dein Ansprechpartner bei detachbox. Behebe ihn und führ denselben Befehl noch einmal aus. Fehlerbehebung am Node deckt die üblichen Fälle ab.

Das Log

/var/lib/detachbox-node/install/install.log enthält jeden Lauf vollständig: die Zeile, die seinen Beginn und sein Release nennt, jede Zeile jedes ausgeführten Befehls und wie er endete. Hast du die Sitzung verloren, sagt das Log, wie der Lauf ausging. Um einen Lauf aus einer anderen Sitzung zu verfolgen:

sudo tail -f /var/lib/detachbox-node/install/install.log

Was auf dem Server läuft

Was wo landet