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

instancier : emet setops_supernet, derive du seed

Browse source 
Keycloak ne demarrait pas : pg_hba n'autorisait que 10.11.0.0/16 pour un tenant
en 10.27.0.0/16. La valeur etait figee dans group_vars, sous un commentaire
« AJUSTER au sous-reseau reel » que personne n'a suivi.

Postfix portait la meme valeur perimee et aurait echoue plus tard sur le
courriel. Technolibre aussi (10.12.0.0/16 pour un tenant en 10.21.0.0/16).
Quatre fichiers, une seule faute, repetee parce que recopiee.

`setops_supernet` se derive comme le VMID et l'adresse ; les quatre fichiers le
consomment. Chezlepro -> 10.27.0.0/16, Technolibre -> 10.21.0.0/16, sans saisie.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Daniel Allaire 2026-08-07 10:33:25 -04:00
parent 41413c7f04
commit 7cb358dab6
2 changed files with 49 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

40
CHANGELOG.md
View file

@ -2,6 +2,46 @@
## 2026-08-06 — le chemin nord-sud devient dérivable
### Le supernet du tenant devient un intrant dérivé
Keycloak ne démarrait pas :
```
FATAL: aucune entrée dans pg_hba.conf pour l'hôte « 10.27.17.11 »,
utilisateur « keycloak », base « keycloak », chiffrement SSL
```
PostgreSQL n'autorisait que `10.11.0.0/16` — l'ancien monde — pour un tenant en
`10.27.0.0/16`. La valeur était figée dans `group_vars`, sous un commentaire
*« AJUSTER au sous-réseau réel de déploiement »* que personne n'avait suivi. Un commentaire
qui demande une action est une action qui n'aura pas lieu.
**Postfix portait la même valeur périmée**, et aurait échoué de la même façon plus tard, sur
le courriel. **Technolibre aussi** : `10.12.0.0/16` pour un tenant en `10.21.0.0/16`. Quatre
fichiers, une seule faute, répétée parce que recopiée.
`instancier` émet désormais `setops_supernet`, dérivé du seed comme le VMID et l'adresse.
Les quatre fichiers le consomment, et la valeur suit le tenant sans être saisie :
```
Chezlepro 10.27.0.0/16
Technolibre 10.21.0.0/16
```
### La chaîne d'identité est debout
```
keycloak active issuer = http://keycloak.chezlepro.internal:8080/realms/…
slapd active namingContexts: dc=chezlepro,dc=internal
```
`idm-01` : dix playbooks, aucun échec, fédération LDAP configurée. Et les quatre premiers se
sont rejoués à **zéro changement** — tout ce qui a été corrigé aujourd'hui converge.
Quatre VM sur quatorze sont entièrement déployées : l'autorité de certification, le DNS
autoritatif, l'identité (annuaire + SSO) et les bases (PostgreSQL + Redis).
### Trois défauts que seul un vrai déploiement pouvait montrer
`idm-01` — première VM d'une autre zone de sécurité (`t17iden`) — a prouvé le **routage

9
scripts/instancier.py
View file

@ -41,6 +41,7 @@ from inventory_rules import (
integrations_de,
integrations_universelles,
liens_acceptes,
supernet_de,
)
RACINE = Path(__file__).resolve().parents[1]
@ -192,6 +193,14 @@ def generer() -> dict:
_, seq = fonction_seq(nom)
d = deriver_nomenclature(str(srv.get("fonction", "")), seq, nomenclature) or {}
hostvars = {
# Supernet du tenant, DERIVE du seed comme tout le reste. Il repond a la
# question « quels clients mon service doit-il accepter ? », posee par
# PostgreSQL (pg_hba), Postfix (reseaux de confiance) et tout service qui
# filtre par reseau. Le figer a la main dans group_vars, c'etait garantir
# qu'il devienne faux : les deux valeurs trouvees le 2026-08-07 dataient de
# l'ancien monde (10.11.0.0/16 pour un tenant en 10.27.0.0/16), avec un
# commentaire « AJUSTER » jamais suivi. PostgreSQL refusait Keycloak.
"setops_supernet": supernet_de(int(index_tenant)) if index_tenant is not None else None,
"ansible_host": d.get("adresse_ip"),
"ansible_user": "ansible",
"proxmox_cidr": d.get("cidr"),