Alliance-Boreale/Set-OPS-Public
2
0
Fork 0
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity

exportateur postgresql de chezlepro pose ; les voutes ne sont pas sur les forges

Browse source 
vault_pg_exportateur ajoute a la voute de Chezlepro (hors depot), role redeploye,
pg_up 1 : plus aucun critique. La voute a ete redeposee sur le runner. Deux
phrases qui disaient les voutes repliquees sur les forges sont corrigees.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Daniel Allaire 2026-09-28 12:41:14 -04:00
parent f5adffb0de
commit 0551c4b4de
3 changed files with 27 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

20
CHANGELOG.md
View file

@ -1,5 +1,25 @@
# CHANGELOG — Set-OPS
## 2026-09-28 (5) — L'exportateur PostgreSQL de Chezlepro, et où vivent vraiment les voûtes
**Le dernier critique de Chezlepro.** `obs-01!collecte` : Prometheus scrutait
`data-sql-01:9187`, où rien n'écoutait. `serveur_postgresql` ne pose l'exportateur que si
`vault_pg_exportateur` existe ; Technolibre l'avait, pas Chezlepro. Ajouté à sa voûte
selon la procédure (copie, lecture par un tube et comptage : 32 clés, chiffrement vers un
fichier neuf relu : 33 clés, les 32 d'origine identiques, puis remplacement). Rôle
redéployé : exportateur actif, `pg_up 1`. Chezlepro n'a plus aucun critique.
**Écart restant.** `vault.yml.example` promet « VIDE = … Prometheus ne dérive aucune
cible » ; le gabarit de Prometheus dérive pourtant la cible de tout hôte du groupe, secret
ou pas. Un écosystème sans exportateur verra donc sa collecte rouge — le signal est juste,
la promesse ne l'est pas.
**Où vivent les voûtes.** `sortir-les-cles-du-poste.md` et `exporter_cles.py` disaient les
voûtes chiffrées répliquées sur les forges. Elles sont gitignorées : chacune vit sur le
poste et sur le runner de son écosystème (copie chiffrée par `serveur_ops_tenant`). Le
runner de Chezlepro portait donc la voûte d'avant ce changement ; redéposée, empreintes
identiques. Les deux phrases sont corrigées.
## 2026-09-28 (4) — Une sonde posée sous condition n'est attendue que là où elle est posée
**Ce que la fraîcheur a fait voir.** Chez les deux locataires, `obs-01!journaux-frontiere`

4
docs/sortir-les-cles-du-poste.md
View file

@ -6,7 +6,9 @@
## Ce qui est en jeu
Le **code** de Set-OPS est répliqué **deux fois** : `eregion` et la forge du site. Les
**voûtes chiffrées** y sont aussi.
**voûtes chiffrées**, elles, n'y sont **pas** — elles sont gitignorées. Chacune vit sur
ce poste et sur le runner de son écosystème, qui en reçoit une copie chiffrée par
`serveur_ops_tenant`. *(Corrigé le 2026-09-28 : cette page les disait sur les forges.)*
> **Ce chiffre était trois, et il a baissé sans que rien ne le signale.** Un coffre répliqué deux fois reste
> solide — mais c'est la **redondance du génome** qui a diminué, pas le chiffrement, et

6
scripts/exporter_cles.py
View file

@ -3,8 +3,10 @@
CE QUE CE SCRIPT PROTEGE, ET POURQUOI C'EST LE PLUS URGENT (mesure du 2026-09-05).
Le CODE de Set-OPS est replique deux fois : `eregion` et la forge du site. Les
voutes chiffrees y sont aussi — le coffre est solide.
Le CODE de Set-OPS est replique deux fois : `eregion` et la forge du site. Les VOUTES,
elles, n'y sont PAS : elles sont gitignorees. Chaque voute chiffree vit sur ce poste et
sur le runner de son ecosysteme, qui en recoit une copie par `serveur_ops_tenant`
(corrige le 2026-09-28 : cette ligne disait qu'elles etaient sur les forges).
Les CLES qui ouvrent ce coffre, elles, vivent dans six fichiers de `~/.config`, 357
octets au total, sans aucune copie ailleurs. S'y ajoutent les cles SSH par lesquelles on