Mises à jour et diagnostic

Garder sh0 à jour, revenir en arrière quand une version se comporte mal, et contrôler l’hôte avant d’accuser l’app.

Mettre sh0 à jour

Lancez la mise à jour sur le serveur. Elle cherche la dernière version finale sur GitHub, télécharge l’archive de votre architecture, la vérifie avec les sommes de contrôle publiées et remplace le binaire. La version remplacée est gardée pour un retour arrière.

sudo sh0 update

* sh0 self-update
  Current version: v1.10.3-rc9

  Checking for updates...
  [+] Already running the latest version (v1.10.3-rc9).

Dans un terminal interactif, sh0 demande avant de redémarrer le service. Avec --yes, il redémarre sans demander. Lancé depuis cron, un tube ou un script sans --yes, il ne redémarre jamais, et le dit d’abord.

Canaux

Par défaut, la mise à jour suit le canal stable : uniquement les versions finales. --channel beta installe à la place la pré-version la plus récente. --force installe la version du canal même si elle n’est pas plus récente : c’est ainsi qu’on revient à une version antérieure.

Revenir en arrière

--rollback remet en place la version que la dernière mise à jour a remplacée. Utilisez-le quand une version se comporte mal juste après une mise à jour.

Ce qui continue de tourner

Vos applications sont des conteneurs Docker : redémarrer sh0 ne les arrête pas. Le proxy inverse placé devant elles reste aussi en service, tant que l’unité de service garde KillMode=process, que pose l’installateur (voir Installation).

Contrôler l’hôte avec sh0 doctor

Lancez sh0 doctor sur le serveur quand quelque chose semble anormal, avant une mise à jour, ou juste après l’installation. Il ne demande aucune connexion et ne modifie rien.

sudo sh0 doctor

sh0 doctor préflight d'hôte
  données : /var/lib/sh0

   OK  docker                     démon joignable -- version 29.8.1, API 1.56, linux/amd64, 2 conteneurs (2 en marche)
   OK  port 80                    tenu par `caddy` -- c'est notre propre pile
   OK  port 443                   tenu par `caddy` -- c'est notre propre pile
   OK  port 9000                  tenu par `sh0` -- c'est notre propre pile
   OK  disque                     /var/lib/docker : 20.5 % occupés, 119.2 Gio libres sur 149.9 Gio
   OK  certificats                1 actif(s) (1 par Caddy, 0 téléversé(s), 35 interne(s) hors seuil), le plus proche expire dans 88 j (demo.sh0.dev)
   OK  panneau (domaine)          demo.sh0.dev servi en HTTPS, certificat valable jusqu'au 2026-12-29
  WARN panneau (exposition)       HTTPS en service, mais le port 9000 répond encore en clair sur 5.78.182.107
   OK  horloge                    synchronisée, décalage mesuré 0 s
   OK  Applications sans projet   toutes les applications sont rattachées à un projet

  des avertissements, rien de bloquant  (code de sortie 0)

Chaque ligne est un contrôle : Docker, les ports dont sh0 a besoin (80, 443 et le port du panneau), l’espace disque libre, les certificats proches de l’expiration, le domaine du panneau et le fait qu’il réponde encore en HTTP clair, l’horloge, et les apps restées hors de tout projet. Une ligne WARN signale quelque chose à corriger ; elle ne bloque pas.

Codes de sortie

• 0 : rien ne bloque (des avertissements peuvent rester).
• 1 : au moins un défaut bloquant.
• 2 : un contrôle n’a pas pu s’exécuter. Un contrôle qui n’a pas tourné n’est jamais présenté comme réussi.

Ajoutez --json pour une sortie lisible par une machine, par exemple dans un script de supervision.

Contrôles de la base

Deux sous-commandes en lecture seule inspectent la base de sh0 à la recherche de restes d’anciennes versions :

• sh0 doctor backup-rows compte les enregistrements de restauration qu’une migration antérieure n’a pas pu atteindre.
• sh0 doctor bind-mounts liste les montages de l’hôte que les règles de montage actuelles refuseraient.