From a694cb1487b5f305fd1f02cddfcb68ff72243888 Mon Sep 17 00:00:00 2001 From: Daniel Allaire Date: Wed, 12 Aug 2026 17:08:19 -0400 Subject: [PATCH] frontiere : un tenant perime injectait ses vieilles adresses dans le pare-feu partage MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Apres le renumerotage de Chezlepro, la frontiere portait encore 17 adresses 10.21.x — l'ancienne plage de Technolibre. Et frontiere-plan repondait « la frontiere dit deja ce que le devis dit ». Les deux etaient vrais. Deux natures d'objets, deux sources : SETOPS_TENANT_ (reseau) <- LA FORMULE -> recalcule seul, 10.11 SETOPS__SERVEUR_* (hotes) <- le hosts.yml du tenant -> reste a 10.21 Le devis lisait fidelement une entree perimee et l'annoncait conforme. Le controle n'etait pas faux — son INTRANT l'etait. Ce que ca revele : la frontiere est PARTAGEE entre tous les tenants, mais P03 ne verifie la fraicheur de l'inventaire que pour l'instance ACTIVE. Un tenant qu'on ne regarde pas — parce qu'il n'a aucune VM, precisement — continue d'imposer ses adresses au pare-feu de tout le monde. Corrige en regenerant l'inventaire de Technolibre puis en reappliquant. Verifie non pas sur le devis mais sur la CONFIGURATION REELLE du boitier, telechargee et relue : il ne reste que 10.0 (underlay), 10.11 et 10.17. Reste : P03 devrait boucler sur les instances decouvertes, pas seulement l'active. Co-Authored-By: Claude Opus 5 --- CHANGELOG.md | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index a1a909e..88b1c81 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,35 @@ # CHANGELOG — Set-OPS +## 2026-08-12 — Un tenant périmé injecte ses vieilles adresses dans le pare-feu partagé + +Après le renumérotage de Chezlepro, la frontière portait encore **17 adresses `10.21.x`** +— l'ancienne plage de **Technolibre**. Et `frontiere-plan` répondait *« la frontière dit +déjà ce que le devis dit »*. + +Les deux étaient vrais. La frontière construit deux natures d'objets : + +| Objet | Source | Comportement | +|---|---|---| +| `SETOPS_TENANT_` (réseau) | **la formule** (`sous_reseau_de`) | s'est recalculé seul → `10.11` | +| `SETOPS__SERVEUR_*` (hôtes) | **le `hosts.yml` du tenant** | est resté à `10.21` | + +Le devis lisait donc *fidèlement* une entrée périmée, et l'annonçait conforme. **Le +contrôle n'était pas faux — son intrant l'était.** + +### Ce que ça révèle + +La frontière est **partagée entre tous les tenants**, mais `P03` ne vérifie la fraîcheur +de l'inventaire que pour l'instance **active**. Un tenant qu'on ne regarde pas — parce +qu'il n'a aucune VM, précisément — continue d'imposer ses adresses au pare-feu de tout le +monde, sans qu'aucune preuve ne s'en aperçoive. + +Corrigé en régénérant l'inventaire de Technolibre puis en réappliquant. Vérifié non pas +sur le devis mais sur la **configuration réelle du boîtier**, téléchargée et relue : il ne +reste que `10.0` (underlay), `10.11` et `10.17`. Zéro `10.21`, zéro `10.27`. + +> **Ce qui manque encore** : rien ne prouve que *chaque* tenant fédéré a un inventaire à +> jour. P03 devrait boucler sur les instances découvertes, pas seulement sur l'active. + ## 2026-08-12 — P03 peut enfin échouer, et elle échoue `instancier.py comparer` affichait l'écart puis renvoyait **toujours `0`**. La preuve P03