Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Forme de l’agent form Décidé

Un daemon obligatoire, et trois bouches pour un seul cerveau : CLI, GUI locale (Tauri) et dashboard web parlent tous à l'agent, jamais à sa place. Mises à jour auto signées avec rollout progressif — et un heartbeat, parce que le silence est la pire panne d'un backup.

En clair — le gardien, l'interphone, l'écran du hall Le daemon est le gardien de l'immeuble : il habite sur place, détient les clés (credentials, privilèges), fait ses rondes aux heures prévues, et pointe auprès de la société de télésurveillance. La CLI est l'interphone pour lui parler ; la GUI locale, l'écran d'accueil dans le hall ; le dashboard web, la société de télésurveillance qui voit tous les immeubles. Aucun des trois ne fait de ronde lui-même : un seul cerveau, trois bouches.

Décision 1 — Un daemon + des clients IPC, un seul binaire

Le daemon est obligatoire — tout ce qui précède le suppose : planification rattrapable, polling de config, plages de throttling, requester VSS, heartbeat, et les privilèges de la table multi-plateforme.

  • Un seul binaire cairn (un artefact à signer par plateforme), sous-commandes : daemon, backup, restore, status, config, enroll…
  • IPC local — la CLI et la GUI parlent au daemon via socket Unix (vérification des credentials du pair : qui est root, qui est admin) / named pipe Windows (security descriptor). C'est le daemon qui détient les credentials serveur et exécute ; les clients IPC ne font que demander.
  • Mode one-shot (cairn backup --oneshot sous cron) conservé pour serveurs minimalistes et debug.

Décision 2 — La GUI locale : Tauri, client léger du daemon

  • Stack : Tauri — backend Rust (réutilise les crates du projet : types IPC, client du daemon), UI web sur la webview système (WebView2 / WKWebView / WebKitGTK) : binaires de quelques Mo là où Electron en pèse 200, systray et notifications natives, installeurs alignés sur la matrice de packaging.
  • L'argument décisif : un seul kit UI, deux surfaces. L'UI Tauri étant du web, la GUI locale et la Table d'orientation (le dashboard, section H) partagent design system et composants — TypeScript + Svelte (affinité assumée ; léger, ce qui colle à l'esprit Tauri. Décision finale avec le sujet « stack front » de la section H). On ne construit pas deux produits visuels.
  • Périmètre — statut & progression (systray), pause / throttle, navigateur de restauration (parcourir les snapshots, sélectionner, restaurer), assistant d'enrôlement au premier lancement, notifications natives, affichage lecture seule des hooks locaux.
  • Client léger strict — la GUI parle à l'IPC du daemon, point : zéro logique métier, zéro credential serveur. Même API que la CLI.
  • Faiblesse assumée — WebKitGTK sur desktop Linux est la moins bonne des trois webviews ; la CLI reste complète en repli. Sur NAS : pas de GUI locale, l'UI du paquet DSM/QTS ouvre le dashboard web.

Décision 3 — Mises à jour auto : canaux natifs d’abord, self-update sinon

Un produit de flotte ne survit pas aux mises à jour manuelles — le revendeur avec 500 NAS n’ira jamais cliquer 500 fois.

  • Canaux natifs des plateformes quand ils existent — le dépôt SPK/QPKG (le Centre de paquets vérifie les mises à jour tout seul — infrastructure qu'on a déjà), dépôts apt/rpm.
  • Self-update intégré pour Windows et le binaire Linux nu : télécharger → vérifier la signature → swap atomique → health-check au redémarrage → rollback automatique si la nouvelle version ne tient pas.
  • Règles transverses — jamais de mise à jour pendant un backup (différée) ; canaux stable/beta ; rollout progressif piloté serveur (10 % → 100 %, arrêt si ça casse) ; la politique de mise à jour est un champ de config à trois étages (le revendeur peut verrouiller « auto : on ») ; chaque agent rapporte sa version → le dashboard voit la flotte.
Le canal de mise à jour est LA surface d'attaque Fais le calcul : l'updater a le droit de remplacer un binaire qui tourne root/SYSTEM sur toutes les machines de tous les clients de tous les revendeurs. C'est la leçon SolarWinds. Règles absolues : la signature est vérifiée par l'agent lui-même avant le swap — pas juste du TLS : compromettre le serveur de mise à jour ne doit pas suffire ; la clé de signature vit hors ligne, jamais sur l'infra de release ; et le rollout progressif sert de pare-feu de dernier recours. Chaque nouvelle version porte un sceau que l'ancienne vérifie avant de lui céder la place.

Décision 4 — La supervision du daemon : le silence est l’ennemi

En clair — le veilleur qui pointe Un backup qui échoue fait du bruit — une erreur, une alerte. Un agent mort ne fait rien du tout : pas de backup, pas d'erreur, rien. C'est la pire panne d'un produit de sauvegarde, celle qu'on découvre le jour de la restauration. La parade du gardien de nuit : pointer. Ce n'est pas l'absence d'alarme qui rassure, c'est le pointage régulier — et c'est son absence qui alerte.
  • Superviseur local — systemd (Restart=always + watchdog), launchd (KeepAlive), recovery actions du Service Windows, init DSM/QTS : l'agent planté est relancé.
  • Heartbeat — l'agent pointe régulièrement auprès du serveur, indépendamment de tout backup planifié. Le dashboard alerte « agent silencieux depuis X » — la machine débranchée, le daemon tué, le NAS mort : tout se voit, même quand rien ne devait tourner.
  • Diagnostic — logs locaux rotatifs, cairn status pour l'état complet en local ; la télémétrie d'exploitation relève de la section K.