ThysTips_dn42/infra-dn42
1
0
Fork 0
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity Actions

feat(openbao) : les coffres des nœuds sont démontés, les trois ouvertures refermées #33

Merged
thystips merged 1 commit from feat/openbao-node-teardown into main 2026-08-11 19:29:19 +02:00
Conversation 0 Commits 1 Files changed 18 +608 -248
thystips commented 2026-08-11 02:33:28 +02:00
Owner
Copy link

Le coffre ne tourne plus que dans les conteneurs. Les quatre coffres des nœuds sont arrêtés et nettoyés, les rôles openbao* ont quitté leur play, et les trois ouvertures que la matrice nommait avec leur échéance sont refermées — la ligne 18, le 8200 de la 19a, et la ligne de transit vers les coffres de nos autres nœuds. Le 5000 de la 19a reste : c'est le looking glass.

Tout est déjà déployé sur les 12 machines. changed=0 au second passage.

Le défaut trouvé en démontant, et c'est le vrai sujet

Retirer un collecteur textfile de la liste ne retirait RIEN de la machine. La minuterie restait activée, le script restait en place, et surtout l'ancien .prom continuait d'être servi.

C'est le .prom qui est le piège, pas la minuterie : un fichier textfile n'a pas d'horodatage, donc node_exporter sert ce qu'il y trouve comme une mesure de maintenant, indéfiniment. Le démontage aurait laissé les quatre nœuds publier dn42_openbao_sealed 0 sur un coffre qui n'existe plus. Une métrique absente se voit (absent()) ; une métrique figée, non.

textfile.yml a donc gagné son retrait — symétrique de celui qui existait déjà pour les fichiers Alloy, et pour la même raison écrite au même endroit. Il balaie l'union des collecteurs du rôle, nœuds et conteneurs confondus : un collecteur qui déménage doit partir de celui qu'il a quitté, ce qui est exactement le cas d'openbao-metrics.

Le nom du .prom n'était dérivable de rien — cert-metrics → certificates.prom, service-metrics → services.prom — il se déclare maintenant, à côté du script plutôt qu'à l'intérieur.

Un geste, pas une convergence

openbao-teardown.yml, lancé à la main, un nœud à la fois. Le play des nœuds n'ayant plus aucun rôle openbao*, une machine reconstruite n'aura jamais de coffre : il n'y a rien à faire converger, seulement quatre machines à nettoyer.

vars_files sur les defaults des trois rôles, et non include_role: tasks_from qui était le geste évident : les trois dépendent d'openbao_binary par leur meta, et une inclusion de rôle exécute ses dépendances. Le démontage aurait commencé par réinstaller le binaire qu'il vient retirer.

⚠ L'ORDRE — c'est la seule partie non évidente :
1 --tags monitoring retire le collecteur du nœud
2 openbao-teardown arrête et nettoie
3 --tags nftables referme

Inverser 1 et 2 fait crier une panne inventée : le collecteur survit à l'arrêt du coffre, publie dn42_openbao_up 0, et Dn42OpenbaoDown part en critical sur un service qu'on vient de retirer volontairement.

Ce qui survit, et ce qui ne survit pas

Gardés : /var/lib/openbao/raft, /var/backups/openbao, les comptes openbao et baoagent. Détruire des données est une décision qu'on ne prend pas le jour même — la posture que le dépôt tient déjà pour NetBox, dont le sync ne supprime jamais. Les comptes parce que supprimer un UID réattribuable à des fichiers restants, et il en reste justement, se passe mal en silence.

Retiré, et c'est un écart assumé au plan : /var/lib/openbao/tls. Ce n'est pas de la donnée, c'est un identifiant — la clé privée d'un listener qui n'écoute plus, que plus aucun agent ne renouvelle. Un certificat valide sans propriétaire se retire.

Mesuré

  • changed=0 au second passage sur les 12 machines.
  • Nœuds : aucune unité *bao*, ni binaire, ni /etc/openbao, ni /var/lib/openbao/tls, ni openbao.prom. Le raft et les instantanés sont intacts sur les quatre.
  • Le diff nftables est purement soustractif et ne touche aucune ligne 5000 — vérifié par comparaison du rendu, pas supposé.
  • Le tier sert toujours en TLS depuis les quatre nœuds, chacun répondu par son propre X-Ingress-Node.
  • Les 4 coffres en conteneur : descellés, un seul leader, agent listener-cert actif, instantanés présents.
  • ocsp_stapling off : "disable_ocsp_stapling":true lu dans la configuration chargée via l'API d'administration. L'option n'a donc pas été ignorée en silence — mais son effet ne se verra qu'à la prochaine émission, l'avertissement n'apparaissant qu'à ce moment-là et pas périodiquement (vérifié : zéro occurrence sur 24 h avant comme après).

⚠ Une alerte a tiré pour de bon

Dn42OpenbaoNoSingleLeader (critical) a été firing du 10/08 23:08 au 11/08 01:58, et le démontage l'a éteinte. Deux clusters existaient réellement le temps de la bascule, et sum(dn42_openbao_leader) sans by les additionnait : elle a dit la vérité littérale pour un état voulu et transitoire.

Le déclencheur a été le relais de métriques, qui a rendu le second cluster visible un jour après sa création — le symptôme est arrivé loin de sa cause. La leçon est gardée en commentaire : une agrégation sans by suppose un seul ensemble, et faire cohabiter deux instances d'un même service la fait mentir.

À côté, Dn42NodeMetricsMissing est firing sur instance="openbao" et "ingress" : c'est un artefact du renommage des instances (PR #32), la fenêtre de 6 h se souvenant des anciens noms. Elle s'éteint seule.

Côté ATNET/k8s-flux — f85bd6e poussé

Les 9 règles du groupe dn42-openbao s'évaluaient déjà juste : pas une expression ne compare instance à un nom, ce qui est exactement ce qui a permis à la bascule de se faire sans toucher ce fichier — et exactement ce qui rendait la dérive invisible. Ce sont les descriptions qui envoyaient chercher la panne sur la mauvaise machine. Toutes les commandes citées passent en incus exec <nœud>:<service> -- ….

Aucune expression, aucun seuil, aucun for: ni severity: n'est touché.

Ce qui reste

Un geste sur ca1 : les quatre secret_id de l'AppRole dn42-node-cert qui appartenaient aux nœuds restent valides là-bas jusqu'à leur TTL — supprimer un fichier ne révoque rien. Ils sont distinguables par leur métadonnée ; la commande est dans roles/openbao/README.md. Hors de ce playbook délibérément : il tourne avec les identifiants des nœuds, et mélanger les deux coffres dans un même play a déjà coûté un 403.

Sans rapport avec cette PR, et déjà noté : la moitié « nœud » du rôle ingress (ingress_on_node, teardown.yml) est morte depuis la PR #25 et attend le même geste.

Le coffre ne tourne plus que dans les conteneurs. Les quatre coffres des nœuds sont arrêtés et nettoyés, les rôles `openbao*` ont quitté leur play, et **les trois ouvertures que la matrice nommait avec leur échéance sont refermées** — la ligne 18, le `8200` de la 19a, et la ligne de transit vers les coffres de nos autres nœuds. Le `5000` de la 19a reste : c'est le looking glass. **Tout est déjà déployé sur les 12 machines.** `changed=0` au second passage. ## Le défaut trouvé en démontant, et c'est le vrai sujet **Retirer un collecteur textfile de la liste ne retirait RIEN de la machine.** La minuterie restait activée, le script restait en place, et surtout l'ancien `.prom` continuait d'être servi. C'est le `.prom` qui est le piège, pas la minuterie : **un fichier textfile n'a pas d'horodatage**, donc node_exporter sert ce qu'il y trouve comme une mesure de *maintenant*, indéfiniment. Le démontage aurait laissé les quatre nœuds publier `dn42_openbao_sealed 0` sur un coffre qui n'existe plus. Une métrique absente se voit (`absent()`) ; une métrique figée, non. `textfile.yml` a donc gagné son retrait — symétrique de celui qui existait déjà pour les fichiers Alloy, et pour la même raison écrite au même endroit. Il balaie **l'union** des collecteurs du rôle, nœuds et conteneurs confondus : un collecteur qui *déménage* doit partir de celui qu'il a quitté, ce qui est exactement le cas d'`openbao-metrics`. Le nom du `.prom` n'était dérivable de rien — `cert-metrics` → `certificates.prom`, `service-metrics` → `services.prom` — il se **déclare** maintenant, à côté du script plutôt qu'à l'intérieur. ## Un geste, pas une convergence `openbao-teardown.yml`, lancé à la main, un nœud à la fois. Le play des nœuds n'ayant plus aucun rôle `openbao*`, une machine reconstruite n'aura jamais de coffre : il n'y a rien à faire converger, seulement quatre machines à nettoyer. `vars_files` sur les defaults des trois rôles, et non `include_role: tasks_from` qui était le geste évident : les trois dépendent d'`openbao_binary` par leur `meta`, et une inclusion de rôle exécute ses dépendances. Le démontage aurait commencé par réinstaller le binaire qu'il vient retirer. **⚠ L'ORDRE** — c'est la seule partie non évidente : | | | |---|---| | 1 | `--tags monitoring` retire le collecteur du nœud | | 2 | `openbao-teardown` arrête et nettoie | | 3 | `--tags nftables` referme | Inverser 1 et 2 fait crier une panne inventée : le collecteur survit à l'arrêt du coffre, publie `dn42_openbao_up 0`, et `Dn42OpenbaoDown` part en *critical* sur un service qu'on vient de retirer volontairement. ## Ce qui survit, et ce qui ne survit pas **Gardés** : `/var/lib/openbao/raft`, `/var/backups/openbao`, les comptes `openbao` et `baoagent`. Détruire des données est une décision qu'on ne prend pas le jour même — la posture que le dépôt tient déjà pour NetBox, dont le sync ne supprime jamais. Les comptes parce que supprimer un UID réattribuable à des fichiers restants, et il en reste justement, se passe mal en silence. **Retiré, et c'est un écart assumé au plan** : `/var/lib/openbao/tls`. Ce n'est pas de la donnée, c'est un **identifiant** — la clé privée d'un listener qui n'écoute plus, que plus aucun agent ne renouvelle. Un certificat valide sans propriétaire se retire. ## Mesuré - `changed=0` au second passage sur les **12 machines**. - Nœuds : **aucune** unité `*bao*`, ni binaire, ni `/etc/openbao`, ni `/var/lib/openbao/tls`, ni `openbao.prom`. Le raft et les instantanés sont intacts sur les quatre. - **Le diff nftables est purement soustractif** et ne touche aucune ligne `5000` — vérifié par comparaison du rendu, pas supposé. - Le tier sert toujours en TLS depuis les quatre nœuds, chacun répondu par son propre `X-Ingress-Node`. - Les 4 coffres en conteneur : descellés, **un seul leader**, agent `listener-cert` actif, instantanés présents. - `ocsp_stapling off` : `"disable_ocsp_stapling":true` **lu dans la configuration chargée** via l'API d'administration. L'option n'a donc pas été ignorée en silence — mais son effet ne se verra qu'à la prochaine émission, l'avertissement n'apparaissant qu'à ce moment-là et pas périodiquement (vérifié : zéro occurrence sur 24 h avant comme après). ## ⚠ Une alerte a tiré pour de bon `Dn42OpenbaoNoSingleLeader` (*critical*) a été `firing` **du 10/08 23:08 au 11/08 01:58**, et le démontage l'a éteinte. Deux clusters existaient réellement le temps de la bascule, et `sum(dn42_openbao_leader)` sans `by` les additionnait : elle a dit la vérité littérale pour un état voulu et transitoire. Le déclencheur a été le **relais de métriques**, qui a rendu le second cluster visible un jour après sa création — le symptôme est arrivé loin de sa cause. La leçon est gardée en commentaire : une agrégation sans `by` suppose un seul ensemble, et faire cohabiter deux instances d'un même service la fait mentir. À côté, `Dn42NodeMetricsMissing` est `firing` sur `instance="openbao"` et `"ingress"` : c'est un **artefact du renommage** des instances (PR #32), la fenêtre de 6 h se souvenant des anciens noms. Elle s'éteint seule. ## Côté `ATNET/k8s-flux` — `f85bd6e` poussé Les 9 règles du groupe `dn42-openbao` **s'évaluaient déjà juste** : pas une expression ne compare `instance` à un nom, ce qui est exactement ce qui a permis à la bascule de se faire sans toucher ce fichier — et exactement ce qui rendait la dérive invisible. Ce sont les **descriptions** qui envoyaient chercher la panne sur la mauvaise machine. Toutes les commandes citées passent en `incus exec <nœud>:<service> -- …`. Aucune expression, aucun seuil, aucun `for:` ni `severity:` n'est touché. ## Ce qui reste **Un geste sur `ca1`** : les quatre `secret_id` de l'AppRole `dn42-node-cert` qui appartenaient aux nœuds restent valides là-bas jusqu'à leur TTL — supprimer un fichier ne révoque rien. Ils sont distinguables par leur métadonnée ; la commande est dans `roles/openbao/README.md`. Hors de ce playbook délibérément : il tourne avec les identifiants des nœuds, et mélanger les deux coffres dans un même play a déjà coûté un 403. **Sans rapport avec cette PR, et déjà noté** : la moitié « nœud » du rôle `ingress` (`ingress_on_node`, `teardown.yml`) est morte depuis la PR #25 et attend le même geste.
Le coffre ne tourne plus que dans les conteneurs. Les quatre coffres des nœuds
sont arrêtés et nettoyés, les rôles `openbao*` ont quitté leur play, et les
trois ouvertures que la matrice nommait avec leur échéance sont refermées :
la ligne 18, le `8200` de la 19a, et la ligne de transit vers les coffres de
nos autres nœuds. Le `5000` de la 19a reste — c'est le looking glass.

`dn42_roles.openbao` reste VRAI sur les quatre nœuds : c'est lui qui place le
conteneur. Le drapeau ne dit plus « ce nœud fait tourner un coffre » mais « ce
nœud héberge le conteneur du coffre ».

## Le défaut trouvé en démontant, et c'est le vrai sujet du commit

**Retirer un collecteur textfile de la liste ne retirait RIEN de la machine.**
La minuterie restait activée, le script restait à sa place, et surtout l'ancien
`.prom` continuait d'être servi — un fichier textfile n'a pas d'horodatage, donc
node_exporter sert ce qu'il y trouve comme une mesure de MAINTENANT, pour
toujours. Le démontage aurait donc laissé les quatre nœuds publier
`dn42_openbao_sealed 0` sur un coffre qui n'existe plus. Une métrique absente se
voit ; celle-là, non.

`textfile.yml` a gagné son retrait, symétrique de celui qui existait déjà pour
les fichiers Alloy. Il balaie l'UNION des collecteurs du rôle, nœuds et
conteneurs confondus : un collecteur qui déménage doit partir de celui qu'il a
quitté, ce qui est exactement le cas d'`openbao-metrics`.

Le nom du `.prom` n'était dérivable de rien (`cert-metrics` →
`certificates.prom`, `service-metrics` → `services.prom`) : il se déclare
maintenant, à côté du script plutôt qu'à l'intérieur.

## Un geste, pas une convergence

`openbao-teardown.yml`, lancé à la main, un nœud à la fois. Le play des nœuds
n'ayant plus de rôle `openbao*`, une machine reconstruite n'aura jamais de
coffre : il n'y a rien à faire converger, seulement quatre machines à nettoyer.

⚠ L'ORDRE — la supervision d'abord, sinon le collecteur survit à l'arrêt du
coffre et `Dn42OpenbaoDown` part en *critical* sur un service retiré volontai-
rement.

**Ce qui survit** : le raft, les instantanés, les comptes. Détruire des données
est une décision qu'on ne prend pas le jour même — la posture que le dépôt tient
déjà pour NetBox.

**Ce qui ne survit pas, écart assumé** : `/var/lib/openbao/tls`. Ce n'est pas de
la donnée, c'est la clé privée d'un listener qui n'écoute plus et que plus aucun
agent ne renouvelle.

## Mesuré

- `changed=0` au second passage sur les 12 machines.
- Nœuds : aucune unité `*bao*`, ni binaire, ni `/etc/openbao`, ni `openbao.prom`.
  `/var/lib/openbao/raft` et `/var/backups/openbao` intacts sur les quatre.
- Le diff nftables est **purement soustractif** et ne touche aucune ligne `5000`.
- Le tier sert toujours en TLS depuis les quatre, chacun par son propre nœud.
- Les 4 coffres en conteneur : descellés, un seul leader, agent actif,
  instantanés présents.
- `ocsp_stapling off` : `"disable_ocsp_stapling":true` lu dans la configuration
  chargée par l'API d'administration — l'option n'a pas été ignorée en silence.
  Son effet, lui, ne se verra qu'à la prochaine émission.

⚠ **`Dn42OpenbaoNoSingleLeader` a tiré pour de bon**, le 10/08 de 23:08 à 01:58 :
deux clusters existaient réellement, et `sum()` sans `by` les additionnait. Le
démontage l'a éteinte. Gardé en commentaire dans `ATNET/k8s-flux`, où les neuf
règles ont suivi.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGwvXLVXJ2PrRFwJTB3Xp9
thystips deleted branch feat/openbao-node-teardown 2026-08-11 19:29:19 +02:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
ThysTips_dn42/infra-dn42!33
No description provided.