Linux spielt oft die Rolle von OpenClaws Steuerungsebene, Gateway oder ausgehendem Proxy, während der Mac, der wirklich baut, auf MacCloud laufen kann. Wir setzen eine Distribution mit systemd voraus (z. B. Ubuntu LTS, Debian oder Cloud-Images). Ziel: klare Rechte, saubere Neustarts, einfaches Troubleshooting.

1. Warum eigener Benutzer und Verzeichnisse wichtig sind

Führen Sie Geschäftsprozesse nicht als root aus. Legen Sie einen dedizierten Systembenutzer und Arbeitsordner für OpenClaw an (z. B. /var/lib/openclaw), halten Sie Konfiguration und Geheimnisse dort und setzen Sie sensible Dateien auf 600. Backups, Migrationen und Übergaben bleiben nachvollziehbar.

2. Stabile systemd-Unit schreiben

Nutzen Sie Type=simple oder den vom Upstream empfohlenen Typ, setzen Sie WorkingDirectory und EnvironmentFile explizit. Aktivieren Sie Restart=on-failure mit sinnvollem RestartSec, damit Crash-Schleifen die CPU nicht leerfeuern. Mehrere Instanzen über Template-Units oder getrennte Dienstnamen trennen—keine gemeinsame PID-Datei.

Kurz: Start-/Stoppgründe in journalctl -u zu sehen passt besser zu Ticketsystemen als lose echos in Skripten.

3. Netzwerk und Firewall

Standard: eingehend verweigern, nur bei Bedarf öffnen. Als reiner ausgehender Client können Sie ohne eingehende Ports auskommen. Zur Kommunikation mit Macs auf MacCloud bevorzugen Sie feste Ausgangs-IP oder privates Netz, damit Whitelists in der Cloud einfacher werden. Bei Lochern Ports und Gültigkeit im Änderungsprotokoll festhalten.

4. Logs und Rotation

Leiten Sie stdout/stderr an journald oder in von logrotate verwaltete Dateien. Felder wie run_id und step helfen beim Abgleich mit Build-Logs auf dem Mac. Volle Platten legen die gesamte Orchestrierung lahm—Obergrenzen nicht vergessen.

5. Zusammenarbeit mit Mac-Buildern

Linux übernimmt Orchestrierung und Callbacks, Mac Xcode/GUI-lastige Schritte. Legen Sie lange Schritte dorthin, wo Sie Laufzeit und Abrechnung besser kontrollieren. Bei tages- oder wochenweise abgerechneten Mac-Instanzen keine nicht unterbrechbaren Langjobs knapp vor Verlängerungsgrenzen starten.

6. Selbstcheckliste

  • Läuft der Dienst als nicht-root mit minimalen Verzeichnisrechten?
  • Liefert systemctl status bei Fehlern die letzten nützlichen Logzeilen?
  • Wurden Firewall und Cloud-Security-Gruppen beidseitig geprüft?
  • Gibt es Schwellenalarme für Logwachstum?

Für Desktop-Debugging siehe den WSL2-Leitfaden; für CI GitHub Actions-Integration.