2026 OpenClaw exklusiver Fern-Mac-Knotenwechsel & DR-Migration: Gateway-Token, LaunchAgent-plist, Skills/Plugin-Daten — SSH-headless-Checkliste + Entscheidungsmatrix & FAQ
Runbook für den Wechsel des dedizierten OpenClaw-Fern-Macs: Geheimnisse rotieren, LaunchAgents sauber umschalten, Skills- und Plug-in-Artefakte migrieren — alles reproduzierbar per SSH ohne lokale GUI.
1. Einleitung: Warum „Knotenwechsel“ mehr ist als git pull
Ein exklusiver Fern-Mac ist oft eine Quelle für Gateway, Skills-Caches und Kanal-Tokens. Beim Hardware-Tausch, Regionenwechsel oder DR-Failover müssen vier Schichten konsistent bleiben: Netz/Listener, Geheimnisse, Persistenzpfade und Prozessüberwachung. Für operative Tiefe zu Logs und Health-Probes siehe auch OpenClaw Beobachtbarkeit & LaunchAgent-Logs auf Fern-Mac.
- Gateway-Token und OAuth-/Bot-Secrets getrennt inventarisieren
- LaunchAgent-plist mit absoluten Pfaden und Log-Pipes versionieren
- Skills- und Plug-in-Datenverzeichnisse (Caches, Indizes) gezielt kopieren oder bewusst leeren
- SSH-headless-Abnahme: Ports,
launchctl, Health-URL
2. Architektur-Snapshot vor dem Cutover
2.1 Inventar minimal halten
Dokumentieren Sie pro Umgebung: Gateway-Bind-Adresse, öffentliche Basis-URL, Reverse-Proxy-Label, OpenClaw-Home (Arbeitsverzeichnis), Node-/CLI-Version und den LaunchAgent-Dateinamen. Das reduziert Doppelstarts zwischen GUI und launchd.
- Prozess: eine „Source of Truth“ für den Startbefehl (plist
ProgramArguments) - Secrets: getrennte Klassen — Gateway-Bearer vs. Kanal-App-Keys (Slack/Telegram/…)
- Pfade: Skills unter Nutzer-
~/vs. projektbezogene.openclaw-Snippets explizit benennen
2.2 RTO/RPO in einem Satz
Legen Sie fest, ob der neue Knoten sofort leer starten darf (nur Secrets + frische Indizes) oder ob ein bytegenauer Datenpfad nötig ist (längere Kopierfenster, rsync mit Checksummen).
3. Gateway-Token & Geheimnisse: Rotations-Reihenfolge
Falsche Reihenfolgen erzeugen 401-Stürme und „Zombie“-Sessions. Pragmatischer Ablauf auf dem neuen Mac (oder vor DNS-Switch):
- Alten Gateway-Prozess stoppen (
launchctl bootoutoder äquivalent), Listener freigeben. - Neues Token in Secret-Store schreiben (Keychain-Entry, verschlüsselte Datei, CI-Secret — was Ihr Runbook vorsieht).
- plist-
EnvironmentVariablesoder Wrapper-Skript aktualisieren; keine Token in Git. - Kanal-Endpunkte (Webhook-URL, App-Level-Token) auf neue öffentliche URL zeigen lassen, danach DNS/TLS cutover.
- Mit
curl -vgegen Health- und WS-Upgrade-Pfad verifizieren.
Wenn Sie denselben physischen Mac-Kapazitätspool nur logisch aufteilen, hilft die TCO-Sicht aus iOS/macOS CI: exklusiver Mac vs. mehrere Knoten — dort geht es um Parallelität und SSH-Stabilität, die auch OpenClaw-Deployments treffen.
4. LaunchAgent-plist: reproduzierbare Headless-Konfiguration
Typische Stolpersteine: relative Pfade nach Homebrew-Upgrade, fehlende PATH, Keychain-Zugriff nur nach interaktivem Unlock. Für Automation:
- Absolute Pfade zu
node/openclawund Arbeitsverzeichnis (WorkingDirectory) - StandardOutPath / StandardErrorPath setzen — sonst sind SSH-Sitzungen blind
- ThrottleInterval / KeepAlive bewusst wählen, um Crash-Loops sichtbar zu machen
- Nach plist-Änderung immer
bootout→bootstrap(GUI-Domänegui/$(id -u)für angemeldeten SSH-Benutzer)
# Beispiel: Status und harter Neustart (Label anpassen)
launchctl print gui/$(id -u)/com.example.openclaw.gateway
launchctl bootout gui/$(id -u) ~/Library/LaunchAgents/com.example.openclaw.gateway.plist
launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/com.example.openclaw.gateway.plist
5. Skills- & Plug-in-Datenverzeichnisse
Unterscheiden Sie ersetzbare Caches (können nach Cutover neu aufgebaut werden) von zustandskritischen Speichern (Memory-DB, lokale Vektoren, freigegebene Exec-Statusdateien). Für große Artefakte: rsync -aH mit exclude-Liste für Temp-Dateien; für kleine Teams oft schneller: bewusst leer starten und nur Konfiguration + Secrets migrieren.
-
1. Skill-Definitionen
Versionierte Repos oder read-only-Spiegel; nach Migration
openclaw doctorbzw. Ihre interne Validierung laufen lassen. -
2. Plug-in-Runtime-Caches
Oft sicher verworfen — dokumentieren Sie den Rebuild-Zeitpuffer im DR-Playbook.
-
3. Gateway-seitige Metadaten
Wenn an Kanäle gebunden: nach Token-Rotation erneut pairen oder Webhooks neu registrieren.
6. SSH-headless-Umschaltcheckliste (paste-fähig)
Abhak-Reihenfolge für Operateure ohne Bildschirm am Zielhost:
| Schritt | Kommando / Artefakt | Erwartung |
|---|---|---|
| 1. Session stabil | ssh -o ServerAliveInterval=30 … |
Kein NAT-Timeout während rsync |
| 2. Listener frei | lsof -nP -iTCP:<port> -sTCP:LISTEN |
Kein alter Gateway-Prozess |
| 3. plist aktiv | launchctl print gui/$(id -u)/… |
state = running, last exit = 0 |
| 4. Health | curl -fsS http://127.0.0.1:<port>/… |
HTTP 200 / dokumentiertes JSON |
| 5. Kanal-Smoke | Testnachricht / Bot-Event | Roundtrip ohne 401/403 |
Hinweis: Passen Sie Health-Pfade an Ihre Gateway-Version an; das Muster (lokal → öffentlich → Kanal) bleibt gültig.
7. Entscheidungsmatrix: gleicher Host vs. neuer Host
Kurzentscheidung für DR und geplanten Hardwaretausch:
| Kriterium | Auf gleichem Host migrieren | Neuer exklusiver Fern-Mac |
|---|---|---|
| Öffentliche URL / TLS-Zertifikat | Bleibt gleich — geringeres Risiko für Webhooks | DNS + Zertifikat + Kanal-Callbacks planen |
| Persistente Indizes | In-place Upgrade, kurze Read-only-Fenster möglich | rsync oder bewusster Cold-Start |
| Secrets-Rotation | Optional minimal | Empfohlen: alles rotieren |
| Rollback | Time Machine / Snapshot des Arbeitsverzeichnisses | Alter Host parallelhalten bis soak OK |
8. FAQ
F1: Muss ich Skills-Verzeichnisse 1:1 kopieren?
A: Nur wenn dort nicht verlierbare Zustände liegen. Viele Teams kopieren nur Manifeste + Referenzen und lassen Caches neu wärmen — dokumentieren Sie die Dauer.
F2: Gateway startet, Kanäle bleiben stumm?
A: Token-Basis-URL noch auf alten Host, oder Webhook zeigt noch auf alte öffentliche IP. DNS-TTL und Proxy-Cache mit einplanen.
F3: Zwei LaunchAgents nach Update?
A: Altes Label bootout, plist archivieren, lsof prüfen — doppelte ProgramArguments in ~/Library/LaunchAgents durchsuchen.
F4: Darf der Cutover nur per SSH erfolgen?
A: Ja, wenn alle Schritte (Secrets schreiben, plist, Datenkopie, Health) im Runbook stehen und Logs greifbar sind — ohne GUI.
9. Warum Mac mini und macOS für dieses Muster passen
Ein Gateway- und Skills-Host profitiert von niedrigem Leerlaufstrom, langer Laufzeitstabilität und einem Betriebssystem, in dem launchd, OpenSSH und Homebrew-Pfade vorhersehbar dokumentierbar sind. Apple-Silicon-Mac mini liefert genug Einzelthread-Leistung für TLS und JSON-Streaming, während das Gehäuse leise bleibt — ideal für 24/7-Headless-Betrieb neben anderen Fern-Mac-Workloads.
macOS verbindet Gatekeeper, SIP und FileVault mit einem vollwertigen Unix-Terminalstack; das verkürzt Runbooks gegenüber heterogenem Linux+Windows-Mix, sobald Sie Xcode-nahe Tools oder Desktop-freie Automatisierung auf demselben exklusiven Host bündeln. Für Teams, die die obige Checkliste dauerhaft ausrollen wollen, ist der Mac mini M4 ein pragmatischer Einstieg: hohe Effizienz pro Watt, geringe thermische Varianz und klare Pfadsemantik für LaunchAgents.
Wenn Sie Hardware nicht selbst vorhalten möchten, lohnt sich der Vergleich gemieteter Fern-Mac-Pakete — über die CTA unten zur Startseite wechseln, Angebote prüfen und den Migrationspfad dort testen, wo der Knoten langfristig laufen soll.