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

frontiere : un tenant perime injectait ses vieilles adresses dans le pare-feu partage

Browse source 
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_<T>      (reseau) <- LA FORMULE           -> recalcule seul, 10.11
  SETOPS_<T>_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 <noreply@anthropic.com>
This commit is contained in:
Daniel Allaire 2026-08-12 17:08:19 -04:00
parent db083df3f6
commit a694cb1487
1 changed files with 30 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

30
CHANGELOG.md
View file

@ -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_<T>` (réseau) | **la formule** (`sous_reseau_de`) | s'est recalculé seul → `10.11` |
| `SETOPS_<T>_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