CE QUE JE DISAIS ETAIT FAUX. « Il n y a rien sur origin » — le DEPOT y
est, et a jour, exactement notre HEAD. C est le WIKI qui etait vide. Je
l avais recopie d une session precedente sans le remesurer.
LA GARDE AVAIT RAISON DE REFUSER, ET TORT DE S ARRETER LA. wiki-publier
refuse un wiki vide parce que publier y inventerait un nom de branche.
Son message renvoyait a l interface Forgejo — injoignable depuis ce poste,
et ce n est pas une panne : la forge du site n accepte le 443 que des
machines qui declarent le flux.
Forgejo DECLARE pourtant la reponse : wiki_branch, dans son API. Interroge
depuis ops-01 — machine qui a le flux — il repond main. On ne devinait
pas : on ne demandait pas. WIKI_BRANCHE= ajoute a la recette, le refus
reste le defaut. Les deux cotes eprouves.
Resultat : 26 pages sur les deux forges, contenu identique au fichier pres.
LECON D INSTRUMENT. Trois sondes fausses avant la bonne : connect() direct
rend TimeoutError (politique, pas route manquante) ; un tunnel par la
frontiere ne repondait pas ; et git ls-remote fonctionnait tres bien, parce
que ~/.ssh/config passe par un ProxyJump que la sonde ignorait.
make prouver : CONFORME, 62 OK, 0 echec, 1 saute.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
cloud-init n est pas un logiciel d installation : c est une SOURCE DE
VERITE EXTERNE. Il se reveille a chaque demarrage et relit le lecteur
attache par l hyperviseur, qui peut redefinir comptes, cles SSH, mots de
passe et reseau. Sur une machine que le plan possede, c est un second
maitre — que le plan ne decrit pas, que make valider ne mesure pas, et
qui parle en premier.
Sa tache est finie a la premiere seconde : c est parce qu il a REUSSI a
poser l adresse et les cles qu Ansible a pu entrer.
TROIS MOITIES, ET ELLES SE DEFONT SEPAREMENT.
- le GABARIT le garde : sans lui un clone n a ni adresse ni nom ;
- le SOCLE ne l installe plus : le garder produisait un va-et-vient a
chaque deploiement, deux changed par passage, idempotence perdue ;
- le DURCISSEMENT le retire (roles/cloud_init_retrait, en dernier).
P63 garde les trois, plus le CONTENU du role : une coquille vide passerait
les trois premiers controles sans rien fermer. Quatre controles negatifs
rejoues.
CE QUI REND LE RETRAIT SUR EST MESURE, PAS SUPPOSE (obs-01, 2026-09-09) :
/etc/network/interfaces.d/50-cloud-init n appartient a aucun paquet — dpkg
-S ne le trouve pas — et le postrm ne le nomme jamais, meme en purge.
L adresse survit. Le role le verifie quand meme, avant et apres, et n
accuse que si le retrait l a emporte : une VM qui perd ce fichier ne se
plaint pas, elle repart sans adresse et plus personne ne peut entrer.
DEUX CHOIX DITS FRANCHEMENT. cloud-guest-utils reste (growpart : ni
service, ni port, ni source de donnees). Les ~29 paquets orphelins ne sont
pas retires par defaut : autoremove deciderait a partir des drapeaux dpkg,
et un durcissement ne doit pas pouvoir surprendre.
NON DEPLOYE : le code est ecrit, valide et prouve ; il n a pas ete
applique a la flotte. Essai a blanc sur obs-01 : cloud-init a retirer,
configuration reseau intacte.
make prouver : CONFORME, 62 OK, 0 echec, 1 saute (63 preuves).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
