#1740 - t_9e5952c4 — Le service d'état passe sur le LXC 132, avec sa sauvegarde relue - foXaCe/studio

hermes-bot commented

2026-10-15 16:49:02 +02:00

Collaborator

Carte t_9e5952c4. L'hôte du LXC 130 est éteint : le service d'état qui vivait dessus ne répond plus, et tout ce qui l'appelle tombe. Il renaît sur le LXC 132, qui reste allumé, avec sa sauvegarde quotidienne relue.

Ce qui change

_infra/etat-studio.service : unité du 132 — 192.168.1.86:8799 (ETAT_ADRESSE), User=studio, Restart=always, code dans /opt/etat-studio, base /var/lib/etat-studio/etat.sqlite. Le plafond du jour (ETAT_PLAFOND) vit à côté de la base, sous studio : le 132 ne monte pas /studio (NFS) et l'opérateur doit pouvoir relever son chiffre sans root.
_infra/installer-etat-service.sh : vérifie d'abord qu'il peut écrire dans sa destination, ne pose rien à moitié, et dit la ligne root à lancer par le Proxmox. La base n'est jamais créée, copiée ni renommée.
_infra/etat-132-pousser.sh : pose la source sur le 132 dans le home de studio (le 132 n'a pas de copie git du dépôt) et sonde les sommes des deux côtés.
_infra/etat-sauvegarde.py + etat-sauvegarde.timer (03:40) : copie cohérente par l'API de sauvegarde de SQLite (la ligne de commande sqlite3 n'existe pas sur le 132 : mesuré), refermée à plat, relue (integrity_check, mêmes tables, au moins autant de lignes qu'au départ) et gardée 7 fois. Base absente = refus en 1, sans rien écrire ; copie qui ne se relit pas = renommée .verification-ratee.
_infra/etat-service.py : adresse par défaut du 132.
Doc : _infra/LISEZMOI.md, _tableau/LXC-132.md, OUTILS.md, LECONS.md (deux leçons datées).

Champ d'API qui change (le front en dépend)

GET /sante du service d'état porte désormais {"ok", "demarrage", "bail", "base", "journal"} : base (le chemin de la base) et journal (wal, absente, inconnu : <raison>) s'ajoutent. Additif — etat_client.sante() et ses appelants ne lisent que ok, demarrage, bail. Un contrôle ne crée rien : /sante lit la base en lecture seule.

Preuves (mesurées le 2026-10-15)

python3 _infra/test_etat_132.py : 17 OK, ÉCARTS : aucun (unité, minuteur, installateur, base neuve, adresse impossible, /sante sur base absente et sur base illisible).
python3 _infra/test_etat_sauvegarde.py : 23 OK, ÉCARTS : aucun ; 100 % du fichier (couverture mesurée).
python3 _tableau/lancer-tests.py --tout : 191 bancs verts, cliquet de couverture passé (ENSEMBLE 99 %).
cargo test --release --locked dans _tableau/rust : rc 0 (tous les test result: ok) ; cargo build --release --locked sans erreur ni nouvel avertissement.
Sur le 132, service essayé à la main sur 192.168.1.86:8799 (base jetable dans /var/tmp, python3 3.11.2) : GET /sante → {"ok": true, "base": "/var/tmp/etat-essai/etat.sqlite", "journal": "wal"} ; POST /sorties/poser → 200, puis relu par GET /sorties et GET /sorties/detail ; GET /sante/GET /sorties depuis le PC ; puis arrêté par son PID (port 8799 libre ensuite, bac à sable supprimé).
Sauvegarde réelle de la base du 132 : 45 056 octets, journal wal, 5 tables, 13 lignes → copie relue (integrity ok, mêmes tables, 12 sorties, 1 bascule). /var/lib/etat-studio ne contient ensuite que la base et la copie.

Rouge préexistant, pas de cette branche

test_garde_couches.py, test_garde_doublons.py et test_garde_plafond.py sont rouges à cause de _tableau/ : doublon _iso (pilote.py/releves.py), doublon lire_fichier (conso_claude.py/rust/banc-memoire-unite.py), collecte.py à 840 lignes pour une dérogation à 800. Mesuré dans un worktree détaché sur origin/main (7861f657) sans mes fichiers : les trois échouent à l'identique.

Ce qui reste à faire, et qui n'est pas de moi

La pose en root : l'atelier n'a pas de root sur le 132 (/opt appartient à root — touch refusé à studio ; root@192.168.1.60 refuse publickey,password). La source est déjà en place sur le 132 ; il reste une commande, à lancer du Proxmox :
ssh root@192.168.1.60 'pct exec 132 -- sh /home/studio/etat-studio-src/_infra/installer-etat-service.sh'
Les appelants portent encore l'adresse de l'hôte du 130 : etat_client.py:98, _tableau/socle.py:445, _tableau/serveur_depenses.py:18, _tableau/collecte.py:40, et les défauts du service Rust. Tant qu'ils ne sont pas changés, personne n'atteint le service, même debout sur le 132. Le collecteur (192.168.1.142:8798, onglet Processus) est dans le même cas.

Carte t_9e5952c4. L'hôte du LXC 130 est éteint : le service d'état qui vivait dessus ne répond plus, et tout ce qui l'appelle tombe. Il renaît sur le LXC 132, qui reste allumé, avec sa sauvegarde quotidienne relue. ## Ce qui change - `_infra/etat-studio.service` : unité du 132 — `192.168.1.86:8799` (`ETAT_ADRESSE`), `User=studio`, `Restart=always`, code dans `/opt/etat-studio`, base `/var/lib/etat-studio/etat.sqlite`. Le plafond du jour (`ETAT_PLAFOND`) vit à côté de la base, sous `studio` : le 132 ne monte pas `/studio` (NFS) et l'opérateur doit pouvoir relever son chiffre sans root. - `_infra/installer-etat-service.sh` : vérifie d'abord qu'il peut écrire dans sa destination, ne pose rien à moitié, et dit la ligne root à lancer par le Proxmox. La base n'est jamais créée, copiée ni renommée. - `_infra/etat-132-pousser.sh` : pose la source sur le 132 dans le home de `studio` (le 132 n'a pas de copie git du dépôt) et sonde les sommes des deux côtés. - `_infra/etat-sauvegarde.py` + `etat-sauvegarde.timer` (03:40) : copie **cohérente** par l'API de sauvegarde de SQLite (la ligne de commande `sqlite3` n'existe pas sur le 132 : mesuré), refermée à plat, **relue** (`integrity_check`, mêmes tables, au moins autant de lignes qu'au départ) et gardée 7 fois. Base absente = refus en 1, sans rien écrire ; copie qui ne se relit pas = renommée `.verification-ratee`. - `_infra/etat-service.py` : adresse par défaut du 132. - Doc : `_infra/LISEZMOI.md`, `_tableau/LXC-132.md`, `OUTILS.md`, `LECONS.md` (deux leçons datées). ## Champ d'API qui change (le front en dépend) `GET /sante` du service d'état porte désormais `{"ok", "demarrage", "bail", "base", "journal"}` : `base` (le chemin de la base) et `journal` (`wal`, `absente`, `inconnu : <raison>`) s'ajoutent. Additif — `etat_client.sante()` et ses appelants ne lisent que `ok`, `demarrage`, `bail`. Un contrôle ne crée rien : `/sante` lit la base en lecture seule. ## Preuves (mesurées le 2026-10-15) - `python3 _infra/test_etat_132.py` : **17 OK, ÉCARTS : aucun** (unité, minuteur, installateur, base neuve, adresse impossible, `/sante` sur base absente et sur base illisible). - `python3 _infra/test_etat_sauvegarde.py` : **23 OK, ÉCARTS : aucun** ; 100 % du fichier (couverture mesurée). - `python3 _tableau/lancer-tests.py --tout` : **191 bancs verts**, cliquet de couverture passé (ENSEMBLE 99 %). - `cargo test --release --locked` dans `_tableau/rust` : rc 0 (tous les `test result: ok`) ; `cargo build --release --locked` sans erreur ni nouvel avertissement. - Sur le 132, service essayé à la main sur `192.168.1.86:8799` (base jetable dans `/var/tmp`, python3 3.11.2) : `GET /sante` → `{"ok": true, "base": "/var/tmp/etat-essai/etat.sqlite", "journal": "wal"}` ; `POST /sorties/poser` → 200, puis relu par `GET /sorties` et `GET /sorties/detail` ; `GET /sante`/`GET /sorties` depuis le PC ; puis arrêté **par son PID** (port 8799 libre ensuite, bac à sable supprimé). - Sauvegarde réelle de la base du 132 : 45 056 octets, `journal wal`, 5 tables, 13 lignes → copie relue (integrity ok, mêmes tables, 12 sorties, 1 bascule). `/var/lib/etat-studio` ne contient ensuite que la base et la copie. ## Rouge préexistant, pas de cette branche `test_garde_couches.py`, `test_garde_doublons.py` et `test_garde_plafond.py` sont rouges à cause de `_tableau/` : doublon `_iso` (`pilote.py`/`releves.py`), doublon `lire_fichier` (`conso_claude.py`/`rust/banc-memoire-unite.py`), `collecte.py` à 840 lignes pour une dérogation à 800. Mesuré dans un worktree détaché sur `origin/main` (7861f657) **sans mes fichiers** : les trois échouent à l'identique. ## Ce qui reste à faire, et qui n'est pas de moi - **La pose en root** : l'atelier n'a pas de root sur le 132 (`/opt` appartient à root — `touch` refusé à `studio` ; `root@192.168.1.60` refuse `publickey,password`). La source est déjà en place sur le 132 ; il reste une commande, à lancer du Proxmox : `ssh root@192.168.1.60 'pct exec 132 -- sh /home/studio/etat-studio-src/_infra/installer-etat-service.sh'` - Les **appelants** portent encore l'adresse de l'hôte du 130 : `etat_client.py:98`, `_tableau/socle.py:445`, `_tableau/serveur_depenses.py:18`, `_tableau/collecte.py:40`, et les défauts du service Rust. Tant qu'ils ne sont pas changés, personne n'atteint le service, même debout sur le 132. Le collecteur (`192.168.1.142:8798`, onglet Processus) est dans le même cas.

hermes-bot added 1 commit

2026-10-15 16:49:02 +02:00

Le service d'état passe sur le LXC 132, avec sa sauvegarde relue

Tests du tableau (Rust + Svelte) / Front Svelte (_tableau/front) (push) Successful in 1m50s

Details

Tests du tableau (Rust + Svelte) / Front Svelte (_tableau/front) (pull_request) Successful in 1m34s

Details

Tests du tableau (Rust + Svelte) / Rust (_tableau/rust) (push) Successful in 7m32s

Details

Tests du tableau (Rust + Svelte) / Rust (_tableau/rust) (pull_request) Successful in 7m37s

Details

dc7246c9a2

L'hôte du LXC 130 est éteint (son adresse ne répond plus, mesuré le 2026-10-15) : le service
d'état qui vivait dessus ne répond plus, et tout ce qui l'appelle tombe. Le 132 est la machine
qui reste allumée. La base ne bouge pas de chemin : /var/lib/etat-studio/etat.sqlite, relevée
là en WAL et integrity ok le 2026-10-15.

- etat-studio.service : unité du 132 — 192.168.1.86:8799, User=studio, Restart=always, code
  dans /opt/etat-studio ; le plafond du jour vit à côté de la base, sous studio, pour que
  l'opérateur le relève sans root (le 132 ne monte pas /studio).
- installer-etat-service.sh : vérifie d'abord qu'il peut écrire dans sa destination (/opt est à
  root sur le 132, mesuré), ne pose rien à moitié, et dit la ligne root à lancer par le Proxmox.
  La base n'est jamais touchée.
- etat-132-pousser.sh : pose la source dans le home de studio et sonde les sommes des deux côtés.
- etat-sauvegarde.py + minuteur 03:40 : copie par l'API de sauvegarde de SQLite (la ligne de
  commande sqlite3 n'existe pas sur le 132), refermée à plat, RELUE (integrity_check, mêmes
  tables, autant de lignes) avant d'être gardée 7 fois ; base absente = refus, copie non
  relisible = renommée .verification-ratee.
- etat-service.py : adresse par défaut du 132 ; GET /sante dit la base et son mode de journal.
- Bancs _infra/test_etat_132.py et _infra/test_etat_sauvegarde.py ; docs LISEZMOI, LXC-132,
  OUTILS et LECONS.

Mesuré sur le 132 : service essayé sur 192.168.1.86:8799 (répond /sante, écrit une sortie, relu
depuis le PC), arrêté par son PID ensuite ; sauvegarde réelle faite et relue. La pose en root
reste à faire : l'atelier n'a pas de root sur le 132.