2026 OpenClaw sur VPS Linux sans interface : de install.sh à la première réponse canal via gateway probe et channels probe

Sans bureau, le code de sortie de l’installateur n’indique pas la production. Ce guide fixe l’objectif sur la première réponse fiable, impose l’échelle officielle CLI puis gateway probe puis channels probe avant les modèles, et rappelle que ufw et les groupes de sécurité cloud sont une intersection, pas une addition.

Sans interface graphique sur Ubuntu ou Debian, l’équipe confond souvent le code de sortie de l’installateur avec une passerelle prête pour la production. Ce guide ancre l’objectif sur la première réponse de canal fiable et impose l’échelle officielle : Node et chemin CLI, openclaw status, gateway probe, sondes channels, puis seulement les modèles.

Consignez écoute, règles ufw et groupes de sécurité cloud dans le même ticket : la politique effective est l’intersection, pas l’écran le plus rassurant.

1. Faux positifs qui semblent verts

Douleur un : l’installateur pose des binaires pendant que Node reste sous la majeure supportée ou que PATH pointe encore vers un ancien préfixe. Vérifiez node -v et which openclaw juste après l’installation, puis openclaw status avant toute fusion JSON pour savoir quel utilisateur possède l’arbre de configuration.

Douleur deux : ouvrir l’inbound dans le cloud en oubliant DNS et TLS sortants. Dans les VPC à egress restreint, les timeouts ressemblent à du throttling modèle ; utilisez curl -v vers les endpoints du fournisseur de chat avant d’accuser les quotas.

Douleur trois : confondre LISTEN avec l’exposition publique. ss peut n’afficher que la loopback tandis que le groupe de sécurité bloque encore ou qu’ufw contredit la console.

1. Geler installateurs et éditeurs concurrents sur le même JSON.
2. Archiver les arbres de configuration avant la première fusion.
3. Imprimer l’ordre de l’échelle dans l’en-tête du ticket.

Si cloud-init réécrit le réseau à chaque boot, un jeu de règles iptables posé à la main peut disparaître entre deux sondes ; versionnez les modules cloud-init dans le même dépôt que la config passerelle.

Les scripts profile.d qui étendent PATH pour les shells interactifs rendent souvent verts les tests manuels alors que les unités systemd gardent un PATH minimal.

2. Matrice : quel runbook compagnon en premier ?

Le tableau oriente vers les articles SFTPMAC adaptés au lieu de mélanger des commandes Docker sur du bare metal.

3. Échelle en huit étapes depuis install.sh

Douleur quatre : sauter gateway probe et lancer gateway install --force. Cela multiplie processus et ports quand la cause était un pare-feu ou un chemin de jeton. Réservez le force install aux cas split-brain documentés après snapshots.

Douleur cinq : blâmer les modèles sans canal vert. Stabilisez gateway status, puis channels status --probe, inspectez les dossiers d’identifiants et les quotas fournisseur. Conservez codes de fermeture WebSocket et lignes HTTP.

Douleur six : mélanger conseils compose et bare metal. Compose utilise pont et fichiers env injectés ; le VPS nu utilise sshd, ufw et parfois linger utilisateur systemd.

node -v
which openclaw
curl -fsSL https://openclaw.ai/install.sh | bash
openclaw status
openclaw gateway probe
openclaw gateway status
openclaw doctor
openclaw channels status --probe

1. Geler les modifications humaines et CI concurrentes.
2. Exporter dumps d’environnement pour shell de login, shell d’automation et futur utilisateur de service.
3. Vérifier Node 22+ et réinstaller depuis des dépôts approuvés si besoin.
4. Exécuter l’installateur avec journaux rotatifs.
5. status puis gateway probe avant chirurgie JSON.
6. gateway status et doctor, puis status à nouveau.
7. Ajuster ufw et règles cloud dans une fenêtre horaire avec note de rollback.
8. Sonder les canaux puis message synthétique par fournisseur avec capture redactée.

Ajoutez aux logs JSON des champs probe_step, exit_code et duration_ms pour que la CI détecte des dérives sur plusieurs nuits sans comparaison manuelle de captures.

Conservez les en-têtes x-ratelimit-* des API de chat près des logs passerelle afin de distinguer un 429 fournisseur d’un proxy intermédiaire.

Les gestionnaires de webhooks doivent exposer des clés d’idempotence ; notez dans le ticket quelle clé rejette un doublon pour ne pas confondre redelivery et nouvelle action utilisateur.

Pour l’objet stocké, mesurez profondeur de file et bande passante en parallèle des sondes canal : TLS vers le chat n’implique pas des presigned PUT fiables vers votre compartiment.

Le préchargement HSTS sur nginx peut forcer https public alors que les healthchecks internes attendent encore http ; séparez noms d’hôte publics et internes dans la narration du ticket.

Vérifiez si ForceCommand ou Match User dans sshd_config rogne l’environnement pour l’automation Ansible, sinon sondes manuelles et tâches cron divergent.

4. Tableau prêt pour astreinte

Étiqueter le plan sur le ticket pour éviter de coller des fragments bare metal dans une stack compose. La matrice choisit quel article lire d’abord, pas quel fournisseur acheter.

Les opérateurs VPS possèdent le rythme du noyau, le durcissement OpenSSH, les miroirs et les montées de Node. Les opérateurs Docker possèdent digests et alignement des jetons.

5. Pare-feu, dual stack, webhooks

Séparez plan de gestion, RPC passerelle et webhooks de canaux : source, destination, protocole explicites. Règles temporairement larges avec fenêtre de temps puis retour au moindre privilège.

ufw et groupes cloud s’intersectent : allow plus deny donne deny. Les deux captures dans le même ticket.

Dual stack : valider AAAA et famille d’écoute ensemble pour éviter d’attribuer à l’appli les aléas Happy Eyeballs.

Indiquez si TLS se termine sur nginx ou sur la passerelle, car sondes et healthchecks diffèrent.

Synchronisez chrony ou systemd-timesyncd avant d’interpréter les erreurs TLS : quelques minutes de dérive rendent des certificats valides « invalides » et détournent l’équipe vers de faux problèmes de modèle.

Si journald grossit sans rotation, les inodes saturent alors que df -h semble confortable ; les écritures webhook échouent alors sans message limpide côté passerelle.

Surveillez le compteur conntrack face au plafond : des rafales WebSocket produisent les mêmes symptômes qu’une règle de groupe de sécurité mal alignée.

Testez explicitement le PMTU lorsque tunnels inter-régions ou routeurs anciens sont en chemin : les trous noirs ressemblent à des handshakes bloqués même si une petite sonde ICMP restait verte.

Les suffixes DNS de recherche peuvent fuiter des noms internes ; notez le FQDN réellement résolu dans le ticket pour que l’audit sache quel resolver a répondu.

6. Cinq drills reproductibles

Drill un : tarball du home et fragments avant édition JSON, checksum dans le ticket.

Drill deux : gateway probe avec l’identité qui possédera le service pour révéler les PATH non interactifs.

Drill trois : TLS sortant avec curl -v vers les endpoints du chat, noter la durée de handshake.

Drill quatre : toggles ufw par paires avec horodatage UTC et rollback en une ligne.

Drill cinq : rejouer le message de canal synthétique après chaque bump mineur, captures redactées, logs bruts stockés séparément.

Ensemble ils réduisent le temps pour savoir si la panne est le fournisseur de modèle ou votre périmètre.

Contrôlez ulimit -n pour l’utilisateur de service avant les tests de canaux parallèles ; des plafonds PAM bas déclenchent des « too many open files » qui imitent l’instabilité réseau.

Si cgroup v2 limite la mémoire, corrélez les OOM du noyau avec les redémarrages de passerelle pour ne pas attribuer à tort des latences webhook au fournisseur de chat.

Planifiez unattended-upgrades hors de votre première nuit d’acceptation et notez les reboots de noyau, car les binds de ports peuvent changer après redémarrage.

Forcez LANG et LC_ALL en UTF-8 dans les unités systemd, sinon les merges JSON laissent des mojibake qui embrouillent l’analyse post-incident.

Les jetons éphémères ne doivent pas rester lisibles par tout le monde sur un tmpfs de staging ; si vous les y posez, horodatez aussi leur suppression dans le ticket.

Évitez de combiner seccomp nginx et Node sans comparer les listes d’appels système, sinon doctor reste vert pendant que certains healthchecks échouent silencieusement.

7. Frontières avec split brain, Docker et dérive HOME

Lisez l’échelle officielle dans le guide gateway probe avant de toucher aux modèles. La dérive systemd HOME concerne les upgrades, pas la première mise en service.

Un fichier texte daté sur l’hôte listant commandes de sonde, codes de sortie et initiales évite une journée de fouille réseau lors des rebuilds.

Traduisez ce fichier en tâches idempotentes Ansible ou Terraform pour que les rebuilds héritent de l’échelle.

Discipline de preuve : première page de sortie de chaque sonde, chemin absolu Node pour systemd versus shell interactif, extraits de flow logs SYN/RST si disponibles.

ProxyJump peut rendre les checks locaux verts pendant que la SG prod reste fausse ; listez les fournisseurs IPv4-only.

Reprise sur snapshot froid, balayage sortant trimestriel après rotation de certificats, combiner gateway vert avec fetch synthétique vers stockage objet, corréler fenêtres fail2ban avec plages d’IP de runners CI.

Dans Ansible, become_user diffère du shell de login que vous testez en SSH ; ne mélangez pas ansible_user et become_user sans rejouer l’échelle.

Terraform ignore_changes sur des pare-feu peut masquer une dérive réelle : documentez chaque exception avec l’ID du ticket qui l’a justifiée.

Pour les post-mortems, gardez un canal dédié qui ne contient que la chronologie des commandes, sans fils de discussion parasites, afin que la direction suive la preuve.

Si vous épinglez Node depuis un dépôt tiers, citez la source (Nodesource, distro, asdf) pour éviter deux binaires OpenSSL différents dans le même PATH.

Les modules noyau réseau (BBR, fq) appartiennent au même changement que les ports passerelle, sinon les rollbacks restent à moitié kernel et à moitié userspace.

8. FAQ

Q Installateur ok, probe rouge ? R Listener, ufw, DNS/egress, règles cloud avant les modèles.

Q Service systemd immédiat ? R Passerelle au premier plan pour acceptation, puis daemon avec snapshots.

Q Clés API rotées ? R Rejouer toute l’échelle une fois ; hier vert n’implique pas demain identique.

9. Conclusion et espace d’arbitrage Remote Mac

L’acceptation ordonnée réduit le brûlage de week-end sur Linux headless tout en montrant quelle couche a échoué.

Le VPS self-hosté reste puissant mais exige une attention continue noyau, distribution et politique.

Faites tourner les secrets webhook comme des mots de passe de base avec double écriture et note de retour arrière. Codez couleur dev/stage/prod sur les tickets pour éviter les diffs pare-feu dans le mauvais VPC.

Si les passerelles always-on et les chemins alignés Apple priment sur chaque bouton du noyau, comparez les heures d’ingénierie aux offres SFTPMAC Remote Mac.