2026 · Inter-régions
Mac mini M4 : matrice Mosh vs SSH

Ce texte se découpe volontairement du récit fan-out rsync multi-nœuds, qui répond à la question « comment les binaires atterrissent de façon homogène sur les workers ». Ici, on répond à « comment des ingénieurs restent branchés assez longtemps » pour trier des tests flaky, suivre des journaux de build et coordonner un correctif sans blocage au milieu d’une commande. Si vous concevez des arbres d’artefacts et des chemins de promotion, commencez par la matrice 2026 cluster Mac mini M4 (rsync & verrous). Si vous éclatez des passerelles multi-AZ et avez besoin de digests webhook, voyez les notes OpenClaw multi-AZ sur clustervps. L’index complet est sur la page d’accueil du blog.

SSH demeure le plan de contrôle par défaut : git+ssh, scp, rsync --rsh=ssh et la plupart des runners CI. Mosh est un upgrade ciblé pour les longues sessions interactives lorsque le RTT grimpe et que le jitter rend un volet tmux visqueux. Aucun des deux protocoles ne sérialise les écritures vers un même arbre DerivedData partagé : cela relève toujours du système de fichiers et de l’orchestration.

Règle 2026 pour les équipes inter-régions : batch et automatisation restent sur SSH avec timeouts explicites ; pair debugging, release captain et astreinte shell évaluent Mosh dès que la sortie UDP est validée par la sécurité. La matrice ci-dessous parle d’expérience opérateur, pas de débit de synchronisation d’artefacts — gardez ces budgets sur la piste rsync décrite dans l’article dédié.

Liste ports / pare-feu (checklist)

Recopiez les lignes dans les groupes de sécurité, les listes de sortie d’entreprise et le champ « notes » de la politique pare-feu du nœud. Après chaque changement, retestez depuis trois chemins réels — Wi‑Fi bureau, partage 4G, VPN split-tunnel — car une approbation papier reflète rarement le retour UDP sous NAT symétrique.

Contrôles d’acceptation avant de déclarer le cluster « prêt Mosh » : (1) lancer mosh user@host depuis chaque classe de réseau ; (2) couper/rallumer le Wi‑Fi en tapant — l’echo local doit rester utilisable ; (3) si vous resserrez la fenêtre UDP, reflétez les mêmes bornes dans les scripts de lancement côté client pour que le support réponde toujours la même chose.

Stratégie combinée verrous de build / flock

Mosh améliore le rendu des caractères et leur survie sous perte de paquets ; il ne sérialise pas les écrivains concurrents sur un même répertoire d’artefacts canonique. Traitez le parallélisme en compilation large, promotion étroite : chaque branche a son worktree isolé, et seule l’étape de promotion — copie vers l’arbre validé, écriture du manifeste, notifications — passe sous un flock exclusif.

• Emplacement des fichiers de verrou : SSD local ou volume métadonnées basse latence. Tenir des verrous sur SSHFS ou NFS lointain amplifie la fausse contention et masque les vrais blocages.
• Largeur de section critique : n’entourez que la promotion, pas toute une compile Xcode ou SwiftPM. Un verrou trop large transforme la ferme M4 en machine single-thread.
• Humain vs robot : quand un ingénieur lance des scripts depuis Mosh, ceux-ci doivent appeler le même point d’entrée « promote » que la CI pour éviter le contournement « juste un hotfix rapide ».
• Acceptation parallèle : ouvrez deux shells interactifs et faites la course sur le script de promotion ; l’un doit sortir vite avec un code documenté (par ex. 17 pour « verrou occupé ») tandis que l’observabilité classe l’événement en mis en file, pas en gel.

Une barrière minimale que GitHub Actions et les humains peuvent partager — gardez-la à côté du guide rsync interne, mais exécutez-la depuis le transport shell de votre choix :

flock -n /var/tmp/m4-promote.lock bash -c '
  ./scripts/promote_artifacts.sh
' || { echo "verrou promote occupé"; exit 17; }

Prolongez la checklist avec des signaux infra : alertez lorsque le temps d’attente du verrou dépasse un budget percentile, et corrélez les pics avec des sessions Mosh simultanées pour distinguer « deux humains se sont croisés » d’« orage CI ». Pour cadrer capacité et budget avant de figer les changements réseau, alignez finance et plateforme sur la même grille tarifaire publique (voir encart en bas de page).

FAQ

Mosh peut-il remplacer flock ou l’exclusion mutuelle CI ? Non. Mosh est transport et rendu pour terminaux interactifs. La possibilité pour deux jobs d’écrire le même répertoire relève du layout, du parallélisme orchestrateur et des verrous explicites sur la promotion.

Le TCP 22 est ouvert — pourquoi Mosh échoue-t-il ? Parce que Mosh a aussi besoin d’un plan de données UDP et d’un mosh-server fonctionnel sur l’hôte. SSH amorce la session ; il ne remplace pas la plage UDP du tableau. Validez le retour de trafic et tout middlebox qui « aide » l’UDP.

Faut-il migrer l’automatisation vers Mosh ? En général non. Le travail non interactif s’audit mieux en SSH avec codes de sortie déterministes et timeouts. Réservez Mosh aux humains qui fixent un compilateur depuis un réseau d’hôtel médiocre.

tmux rend-il Mosh superflu ? tmux protège l’état serveur si SSH tombe ; Mosh lisse en plus la frappe côté client. Beaucoup empilent les deux : Mosh jusqu’au bord datacenter, tmux sur le nœud pour relais entre opérateurs.