forge du site : le marqueur manquant — le genome n etait ouvert a personne
MEME PATRON QUE serveur_artefacts + serveur_cache_site : un installateur, un
marqueur. Le site rend DEUX services a ses locataires pendant leur jeunesse, les
PAQUETS et le GENOME. Le premier etait declare, le second ne l etait pas — alors
que D-81 fait de cette forge l autorite dont tout ecosysteme se reproduit.
Mesure sur ops-01, premiere machine de la reconstruction de Chezlepro :
cache du SITE 10.0.33.21:3142 : OK
forge du SITE 10.0.33.11:443 : BLOQUE
Le plan du tenant declarait pourtant lire son genome a cette adresse. UNE
DEPENDANCE DECLAREE CHEZ LE CONSOMMATEUR, SANS FLUX CHEZ LE FOURNISSEUR — et rien
ne le signalait : la garde de matrice de resoudre_flux ne verifie que les paires
role->role, jamais un pair symbolique comme voisins_site.
POURQUOI UN ROLE A PART : ajouter cet ingress a serveur_forgejo aurait ouvert LA
FORGE DE CHAQUE TENANT a ses voisins. La responsabilite appartient a une machine
precise, pas au logiciel qu elle fait tourner.
Il verifie que la forge ECOUTE vraiment : sans ca il attribuerait l autorite du
genome a un port muet, et l ecosysteme venu s y reproduire attendrait sans savoir
pourquoi — ce qui est exactement arrive, quinze minutes durant.
TROIS GARDES ONT TRAVAILLE : le catalogue a refuse un role qu il ne nomme pas, la
carte a corrige ses deux chiffres, et P49 a exige la regeneration du registre.
P33 a impose partage: true — le marqueur emprunte l ecoute de serveur_forgejo.
Frontiere : 4 objets crees, 0 retire. Verifie depuis ops-01 : 443 OK.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019f91zs9SDdwSzL2CVei6on
2026-08-28 16:15:42 -04:00
|
|
|
---
|
|
|
|
|
# Flux réseau de la FORGE DU GÉNOME DU SITE. Voir docs/flux-conception.md.
|
|
|
|
|
#
|
|
|
|
|
# UN SEUL FLUX, et c'est tout son sens : servir le génome aux écosystèmes que ce site
|
|
|
|
|
# héberge. `serveur_forgejo` porte le reste (servir sa propre flotte, ses miroirs).
|
|
|
|
|
#
|
|
|
|
|
# EXACTEMENT LE SYMÉTRIQUE DE `serveur_cache_site`. Le site rend deux services à ses
|
|
|
|
|
# locataires pendant leur jeunesse : les paquets et le génome. Le premier était déclaré,
|
|
|
|
|
# le second ne l'était pas — et pourtant D-81 fait de cette forge l'AUTORITÉ dont tout
|
|
|
|
|
# écosystème se reproduit.
|
|
|
|
|
#
|
|
|
|
|
# CE QUE ÇA A COÛTÉ (2026-08-28) : `ops-01`, première machine de la reconstruction de
|
|
|
|
|
# Chezlepro, atteignait le cache du site et restait bloquée sur le clonage du génome.
|
|
|
|
|
#
|
|
|
|
|
# cache du SITE 10.0.33.21:3142 : OK
|
|
|
|
|
# forge du SITE 10.0.33.11:443 : BLOQUÉ
|
|
|
|
|
#
|
|
|
|
|
# Le plan du tenant déclarait pourtant lire son génome à cette adresse. **Une dépendance
|
|
|
|
|
# déclarée chez le consommateur, sans flux correspondant chez le fournisseur** — et rien
|
|
|
|
|
# ne le signalait, parce que la garde de matrice ne vérifie que les paires rôle→rôle.
|
|
|
|
|
#
|
|
|
|
|
# `voisins_site` désigne les autres tenants que CE SITE héberge. Ni `flotte` (mon
|
|
|
|
|
# écosystème), ni `externe` — qui aurait publié la forge du génome à l'Internet.
|
|
|
|
|
#
|
|
|
|
|
# LA RÈGLE APPARTIENT AU SITE : c'est son runner qui prépare le terrain, pas un tenant
|
|
|
|
|
# qui ouvrirait une porte chez un autre.
|
|
|
|
|
flux:
|
|
|
|
|
- sens: ingress
|
|
|
|
|
port: 443
|
|
|
|
|
protocole: tcp
|
|
|
|
|
pair: voisins_site
|
|
|
|
|
chiffrement: tls-requis
|
|
|
|
|
raison: >-
|
|
|
|
|
Servir le génome aux écosystèmes de ce site : c'est de cette forge qu'ils clonent
|
|
|
|
|
leur moteur, leurs modèles et la carte de la fabric (D-81). Sans ce flux, un
|
|
|
|
|
écosystème neuf ne peut pas se reproduire.
|
|
|
|
|
# CE RÔLE N'OUVRE AUCUNE ÉCOUTE — il emprunte celle de `serveur_forgejo`, sur le même
|
|
|
|
|
# hôte. Sans ce mot, P33 y voit deux rôles qui se disputent le 443, et elle a raison
|
|
|
|
|
# de le demander : seul le registre distingue « j'ouvre » de « j'autorise une source
|
|
|
|
|
# de plus sur l'écoute d'un autre ».
|
|
|
|
|
partage: true
|
2026-10-11 19:59:07 -04:00
|
|
|
|
|
|
|
|
# LA LECTURE DE SON DEPOT PAR LE RUNNER D'UN LOCATAIRE (2026-10-11,
|
|
|
|
|
# `docs/depots-prives-conception.md`). Les depots des locataires deviennent prives : chacun
|
|
|
|
|
# se lit avec une cle de deploiement en lecture seule, et une cle de deploiement ne passe
|
|
|
|
|
# que par SSH. `runners_locataires` : les seuls runners, lus dans les faces publiees — pas
|
|
|
|
|
# les supernets. L'utilisateur `git` de ce `sshd` est contraint par la forge : la cle n'y
|
|
|
|
|
# ouvre aucune session, seulement le depot qui l'a enregistree.
|
|
|
|
|
- sens: ingress
|
|
|
|
|
port: 22
|
|
|
|
|
protocole: tcp
|
|
|
|
|
pair: runners_locataires
|
|
|
|
|
chiffrement: ssh
|
|
|
|
|
raison: >-
|
|
|
|
|
Chaque runner de locataire lit son propre depot du genome, prive, avec sa cle de
|
|
|
|
|
deploiement en lecture seule. Il ne lit ni le depot d'un autre locataire, ni celui
|
|
|
|
|
du site.
|
|
|
|
|
# CE ROLE N'OUVRE AUCUNE ECOUTE — il emprunte le `sshd` du socle, comme
|
|
|
|
|
# `serveur_ops_tenant` (voir P33).
|
|
|
|
|
partage: true
|