Daniel Allaire
9f36f08db0
Some checks are pending
verifier / verifier (push) Waiting to run
Demande de l'exploitant : « il faut vraiment faire une distinction entre l'underlay et les tenants. Definis bien la frontiere entre les deux mondes. L'underlay et son tenant doivent avoir chacun sa voute. » LA DOCTRINE (docs/frontiere-physique-virtuel.md) : qui possede quoi, ou ca vit, qui l'administre. Et la regle qui la rend operante — UN TENANT NE DETIENT JAMAIS UN SECRET DU MONDE PHYSIQUE. Aujourd'hui chaque tenant porte le jeton d'API du cluster ; patient 0 a du le recopier pour exister. C'est la faute des neuf copies, appliquee aux secrets : une valeur qui vit a N endroits diverge, et on ne peut plus en revoquer une sans les autres. L'INSTRUMENT (`make underlay-plan`) confronte le fichier au reel : l'API du cluster pour les adresses REELLEMENT portees, une sonde TCP pour ce qui repond. N'ecrit rien. CE QU'IL A TROUVE, des le premier passage : management 10.0.0.0/24, stockage 10.0.1.0/24, ceph 10.0.2-3.0/24 -> PERSONNE transit 10.0.4.0/24, vxlan 10.0.5.0/24 -> occupes (3 noeuds) portes par les noeuds et declares NULLE PART : 192.168.11.x (la vraie gestion), 10.11.5-7.x, 192.168.50.x, 10.1.110.254 La frontiere avait deja migre vers 10.17.0.1 ; les hyperviseurs, non. Le fichier decrivait le monde d'avant — et c'est pour cela que la regle d'admin de patient 0 atterrissait sur `wan`, ou elle n'aurait jamais laisse passer personne. DEUX PRECAUTIONS ECRITES DANS L'INSTRUMENT, apprises en l'ecrivant : - l'AUTORITE DEPEND DU ROLE. L'API de Proxmox connait ses hyperviseurs, et eux seuls. Declarer un commutateur « porte par personne » parce que le cluster l'ignore, c'est accuser le monde de ce que l'instrument ne voit pas. - « pas joignable d'ici » n'est pas « absent ». Les reseaux de CHEMIN (transit, VXLAN, stockage) ne sont jamais joignables de l'exterieur, par construction (D-78). Le premier jet les declarait morts. Le devis a donc corrige DEUX FOIS sa propre facon de mesurer avant de rendre un verdict. RESTE, dans l'ordre : ecrire dans underlay.yml ce qui EST ; separer les voutes ; et alors seulement appliquer la frontiere. make verifier 41/41. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| audit | ||
| img | ||
| modeles_vm | ||
| architecture-set-ops.md | ||
| authentification.md | ||
| autorisation.md | ||
| bindings-conception.md | ||
| carte-set-ops.md | ||
| catalogue-services.md | ||
| config-proxmox.md | ||
| couches-deploiement.yml | ||
| courriel-conception.md | ||
| decisions-architecture.md | ||
| dependances-groupes.yml | ||
| devis-services.md | ||
| dimensionnement-ressources.md | ||
| dns-interne.md | ||
| ecosysteme-chezlepro.md | ||
| flux-conception.md | ||
| frontiere-opnsense.md | ||
| frontiere-physique-virtuel.md | ||
| hebergeur-exploitation.md | ||
| identite-sso.md | ||
| implanter-un-tenant-sur-un-site.md | ||
| integrations-vm.md | ||
| intrants-base-gui-conception.md | ||
| intrants-communs.md | ||
| meta-classe.md | ||
| migration-tenant.md | ||
| MISE-A-JOUR-CODEX-CLAUDE.md | ||
| multi-instances.md | ||
| nomenclature-vm.md | ||
| plan-et-generation.md | ||
| positionnement.md | ||
| pouvoirs-set-ops.md | ||
| preparer-un-site-hebergeur.md | ||
| procedure-template-debian13-proxmox.md | ||
| registre-flux.md | ||
| runbooks-exploitation.md | ||
| sdn-evpn.md | ||
| theme-forgejo-hors-flotte.md | ||
| vm-lifecycle.md | ||