Linux joue souvent le rôle de plan de contrôle, passerelle ou proxy sortant pour OpenClaw, tandis que le Mac qui exécute réellement les builds peut être sur MacCloud. Nous supposons une distribution avec systemd (Ubuntu LTS, Debian, images cloud). Objectif : droits clairs, redémarrages propres, dépannage simple.

1. Pourquoi un utilisateur et des répertoires dédiés

N’exécutez pas les processus métier en root. Créez un utilisateur système et un répertoire de travail pour OpenClaw (par ex. /var/lib/openclaw), placez configuration et secrets sous ce compte et verrouillez les fichiers sensibles en 600. Sauvegardes, migrations et passations restent lisibles.

2. Écrire une unité systemd fiable

Utilisez Type=simple ou le type recommandé en amont, définissez WorkingDirectory et EnvironmentFile. Activez Restart=on-failure avec un RestartSec raisonnable pour éviter les boucles qui saturent le CPU. Pour plusieurs instances, utilisez des unités modèle ou des noms distincts—pas de fichier PID partagé.

En bref : voir les raisons d’arrêt dans journalctl -u s’aligne mieux sur les tickets qu’un simple echo dans un script.

3. Réseau et pare-feu

Par défaut : refuser l’entrant, ouvrir au besoin. Client sortant uniquement : aucun port entrant n’est nécessaire. Avec les Mac sur MacCloud, privilégiez une IP de sortie fixe ou un réseau privé pour simplifier les listes blanches côté cloud. Si vous ouvrez des ports, documentez-les avec leur durée de validité.

4. Journaux et rotation

Envoyez la sortie standard vers journald ou vers des fichiers gérés par logrotate. Ajoutez des champs tels que run_id et step pour corréler avec les logs de build sur le Mac. Un disque plein fait tomber toute l’orchestration—prévoyez des plafonds.

5. Travailler avec des builders Mac

Linux orchestre et gère les callbacks ; le Mac prend les tâches Xcode / GUI. Placez les étapes longues là où vous maîtrisez mieux la durée de location et la facturation. Sur des instances Mac facturées au jour ou à la semaine, évitez de lancer des jobs longs non interruptibles à la limite de renouvellement.

6. Liste de contrôle

  • Le service tourne-t-il en non-root avec des droits minimaux ?
  • systemctl status montre-t-il les dernières lignes utiles en cas d’échec ?
  • Pare-feu et groupes de sécurité cloud sont-ils vérifiés des deux côtés ?
  • La croissance des logs a-t-elle des alertes de seuil ?

Pour le débogage desktop, voir le guide WSL2 ; pour la CI, l’intégration GitHub Actions.