Den Node am Laufen halten

Der Node aktualisiert sich selbst und prüft seinen eigenen Zustand. Dein Admin hält Ubuntu und seinen Kernel aktuell und kann den Zeitpunkt wählen, zu dem Incus und cloudflared aktualisiert werden.

Mit doctor prüfen

sudo detachbox-node-host doctor

doctor prüft den Node durchgängig und ändert nichts. Jede Prüfung hat 20 Sekunden Zeit und gibt ihre Zeile aus, sobald sie fertig ist:

dass detachbox den Token des Nodes noch annimmt, node-host und seine Version und die letzte Antwort des Servers;
die Verbindungen des Tunnels zu Cloudflare und den Rückweg durch ihn, zu node-host und zum Terminal-Gateway;
ausgehendes HTTPS und TLS zu api.detachbox.com;
Incus, dass es zurückgehalten ist und ob neuere Builds von Incus oder cloudflared warten;
das jetzt geladene ZFS-Modul und das, welches der nächste Kernel laden wird, Deduplizierung, den Zustand des Pools und wie voll er ist;
deine privaten Netze gegen die Firewall der Terminals;
das Basis-Image und wann sein letzter Build begann.

Jedes ✗ kommt mit seiner Lösung. Ein Teil, der hängt, etwa Incus oder ZFS, zeigt auf seiner ✗-Zeile … within 20 s, und die späteren Prüfungen dieses Teils zeigen not checked: … did not answer above, statt zu warten. Ein … markiert, was die Prüfung nicht scheitern lässt: was sich noch nicht wissen lässt, etwa die erste Antwort des Servers in den Minuten nach einem Neustart von node-host, oder ein Update, das wartet. Die Zeile für Updates lautet ✓ Updates Incus <version>, cloudflared <version>: the newest builds apt knows of oder … Updates not yet: …; <build> waits: sudo detachbox-node-host upgrade installs it (node-host does on a day no terminal runs).

sudo detachbox-node-host doctor --report schickt das Ergebnis an detachbox, sodass dein Ansprechpartner bei detachbox sieht, was du siehst.

Was sich selbst aktualisiert

node-host aktualisiert sich innerhalb von Minuten nach jedem detachbox-Release. Er installiert nur, was der Release-Schlüssel von detachbox signiert hat, und stellt das vorige Release wieder her, wenn das neue nicht hochkommt.
Das Basis-Image deiner Terminals wird alle 6 Stunden mit den Updates von Ubuntu und den neuesten Versionen von Claude Code, Codex und OpenCode neu gebaut. Es geht erst nach einem Smoke-Test live; ein fehlgeschlagener Build lässt das letzte gute an seinem Platz. Laufende Terminals behalten das Image, mit dem sie gestartet sind, und ein neues oder neu gestartetes Terminal bekommt das aktuelle.

Incus und cloudflared

Beide bleiben in apt zurückgehalten, und dieser Hold wird nie aufgehoben: Dein eigenes apt upgrade lässt sie in Ruhe. Ein Neustart von cloudflared trennt einmal jede Verbindung durch den Tunnel des Nodes (Terminal-Tabs, Previews, Uploads), ein Neustart von Incus die Verbindungen offener Terminal-Tabs. In beiden Fällen verbinden sie sich innerhalb von Sekunden von selbst neu, und die Terminals laufen weiter, mit ihren tmux-Sitzungen, Agenten und allen Prozessen darin. Ein Terminal, das in diesen Sekunden gestartet oder gestoppt wird, scheitert einmal und klappt beim nächsten Versuch, und ein Build des Basis-Images, der gerade läuft, scheitert und wird innerhalb von 6 Stunden neu gebaut. Darum werden beide nur in einem Moment aktualisiert, den du wählst, oder an einem Tag, an dem kein Terminal läuft.

sudo detachbox-node-host upgrade --check      # fragt die Repositories der beiden Hersteller; nichts ändert sich
sudo detachbox-node-host upgrade              # sagt, was neuer ist und was mit den Terminals passiert, fragt [y/N]
sudo detachbox-node-host upgrade --confirm    # aktualisiert ohne Rückfrage

upgrade listet, was neuer ist, wie viele Terminals laufen und was die Neustarts mit ihnen machen, und fragt dann. Ohne ein Terminal, in dem es fragen kann, lehnt es ab und nennt --confirm. Sobald die Pakete installiert werden, läuft das Upgrade bis zum Ende durch, egal was mit deiner Sitzung passiert; sudo tail -f /var/lib/detachbox-node/install/install.log verfolgt es. Es endet mit doctor und ✓ Upgraded: …, auf unserem Test-Node nach etwa einer Minute.

node-host versucht dasselbe Upgrade einmal am Tag, das erste Mal 15 Minuten, nachdem er gestartet ist, und nur, wenn außer dem Edge nichts läuft: kein Terminal, kein Build des Basis-Images. Läuft ein Terminal, schreibt er in sein Log, dass das Upgrade wartet, und versucht es einen Tag später wieder. Ein Node, auf dem immer irgendein Terminal läuft, aktualisiert sich nie von selbst: doctor zeigt das Update so lange, bis du upgrade ausführst.

Kernel-Updates

Ubuntu und seinen Kernel aktualisierst du selbst. Installier jeden neuen Kernel mit seinen linux-headers, dann baut DKMS das ZFS 2.4.4 des Nodes von selbst dafür; auf unserem Test-Node dauerte das etwa 4 Minuten. doctor zeigt danach eine Zeile ZFS for <kernel> für den laufenden Kernel und eine für den neuesten installierten Kernel, den der nächste Boot lädt. Beide müssen ✓ zeigen, bevor du neu startest; nach einem Neustart in den neuen Kernel kommt der Node von selbst zurück.

Bootet jemals ein Kernel ohne das ZFS des Nodes, schaltet node-host die Deduplizierung ab, bevor ein Terminal ein Byte schreibt, und meldet das in doctor und an detachbox. Beim ersten Hochfahren mit einem reparierten Modul schaltet er die Deduplizierung wieder ein.

Neustarts

Ein Neustart stoppt laufende Prozesse und tmux-Sitzungen. node-host und der Tunnel starten mit dem Server, und deine Terminals kommen von selbst zurück, mit ihren Dateien, apt-Paketen und Docker-Images; Docker-Container mit einer restart:-Regel starten wieder. Jeder Agent kehrt von selbst in seine letzte Unterhaltung zurück und wartet auf seinen Entwickler. Ein Agent, der nicht zurück ist, startet mit Terminal in dieser Unterhaltung neu starten wieder dort.

Wenn der Node offline geht

Eine Minute, nachdem der Node nicht mehr antwortet, zeigt das Dashboard Node offline seit 14:02 in der oberen Leiste und auf der Compute-Seite, und ein offenes Terminal sagt, dass es sich von selbst neu verbindet, sobald der Node zurück ist. Die Dateien bleiben auf dem Server. Nach 10 Minuten Stille bekommt das Konto, dem der Node gehört, eine E-Mail, die die Uhrzeit nennt und auf sudo detachbox-node-host doctor verweist, und eine weitere, sobald der Node wieder antwortet. Ein Neustart oder ein Update von node-host dauert nie so lange.

Mehr Kerne oder Speicher

Gib sie dem Server und sag dann deinem Ansprechpartner bei detachbox Bescheid. node-host meldet Kerne, Speicher und Pool des Servers an detachbox, und dein Ansprechpartner setzt die neue Größe um; von selbst ändert sich nichts. Das laufende Compute übernimmt die neue Größe ohne Neustart, und Aktivität hält sie fest.

Wenn detachbox den Node abmeldet

Wird die Registrierung deines Nodes aufgehoben, sagt doctor das in einer Zeile, „✗ Account taken off“, mit dem, was zu tun ist: sudo detachbox-node-host uninstall --confirm, oder, wenn du damit nicht gerechnet hast, schick diese Zeile an deinen Ansprechpartner bei detachbox. Bis dahin bleibt node-host still, Tunnel und Edge bleiben, wie sie sind, und er fragt alle 15 Minuten bei detachbox nach, sodass ein irrtümlich abgelehnter Node innerhalb dieser Zeit zurück ist. Eine Ablehnung, die nicht im Wortlaut des detachbox-Servers kommt, etwa von einem Proxy, der eine eigene Anmeldung verlangt, heißt nicht, dass der Node abgemeldet ist: doctor sagt das in der Zeile Account. Lass den Node ohne Anmeldung durch diesen Proxy oder schick die Zeile an deinen Ansprechpartner bei detachbox.