Chaque role proprietaire (AC, bases, annuaire, Nextcloud, rspamd/DKIM,
courriel, forge, web) remet son etat au moment ou il le creerait neuf,
depuis le dernier instantane anterieur a la naissance de la machine.
La sauvegarde refuse de deposer tant qu'un etat d'avant attend.
Outil de noeud setops-restaurer ; cibles sauvegarder-maintenant,
restauration-etat, restauration-renoncer ; test_restauration.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
CORRECTION DE COMPTE D ABORD. J avais annonce cinq groupes sans sonde. La
mesure en donne VINGT-SEPT : j avais compte ceux que j avais en tete, pas
ceux que le depot contient. Il en reste vingt-deux.
LES CINQ, PAR ORDRE DE DEGAT SILENCIEUX.
autorite (step_ca) — la plus urgente : nos certificats vivent 24 h, une AC
muette ne casse rien aujourd hui et casse TOUT demain, d un coup, sur les
21 machines. Elle surveille aussi l expiration de la RACINE, que personne
ne regarde parce qu elle vit des annees (relevee a 3642 jours).
base (postgresql) — une VRAIE requete, pas pg_isready : celui-ci dit que
le port repond, pas que la base sert. Plus le compte des connexions : a
saturation, chaque application tombe sans que la base ait l air morte.
annuaire (openldap) — elle COMPTE les entrees. Un annuaire vide repond
success a tout : le mensonge des sauvegardes vides, vert et sans contenu.
zones (powerdns) — un autoritatif sans zone repond NXDOMAIN a tout, ce qui
se lit comme « ce nom n existe pas ».
edge (nginx) — elle valide la configuration SUR DISQUE : nginx sert la
derniere valide, et une configuration cassee ne se voit qu au prochain
demarrage, souvent des mois plus tard.
Les cinq eprouvees vertes sur le sain puis rouges PAR PARAMETRE, sans
toucher a un service.
Etat : 20 sondes sur 19 roles, 23 services distincts, 70 instances, 67 au
vert. Les trois autres sont connues : deux sauvegardes sans donnee a
emporter, et Loki en delai de stabilisation apres redeploiement.
make prouver : CONFORME, 64 OK, 0 echec, 0 saute.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
Le deploiement de Chezlepro depuis son propre runner a franchi le socle et le
durcissement sur les quinze machines, et s est arrete sur une seule :
infra-pki-01 : Echec temporaire dans la resolution du nom
url: https://packages.smallstep.com/keys/apt/repo-signing-key.gpg
UN TENANT N A PAS DE DNS SORTANT, ET C EST VOULU. Il resout chez lui, sa requete ne
traverse jamais la frontiere. apt s en sort par le mandataire du cache, qui resout a
sa place ; get_url n a pas de mandataire. Mesure sur la machine : DNS bloque, 443
sortant OK par adresse, apt via le cache OK.
Les cinq reprises du role ne pouvaient rien : elles etaient ecrites pour un serveur
INTERMITTENT (2026-08-23), pas pour une resolution fermee. Une reprise ne repare que
ce qui est passager.
UNE DETTE NOMMEE, APPELEE. client_artefacts le disait : les depots tiers en HTTPS
vont en direct, la seconde voie est propre et RESTE A FAIRE. Elle a ete appelee le
jour ou un ecosysteme s est reconstruit derriere une frontiere qui fait son travail.
La cle est versionnee, avec son empreinte et sa procedure de rafraichissement. Meme
idiome que les collections et les roues : le depot porte, la cible n ouvre rien.
C est ce qui rend une lignee reproductible SANS INTERNET.
Cout ecrit : une rotation amont n est plus recuperee toute seule, mais elle ne passe
pas inapercue — apt refuse alors le depot, bruyamment.
TROUVE EN LA RECUPERANT : l URL publique REDIRIGE vers pkgs.infra.smallstep.com.
Sans suivre les redirections on obtient un fichier VIDE, et curl -f sans -L sort en
succes. La procedure le dit, parce que ce piege ne se voit qu au deploiement suivant.
Le correctif du pare-feu a tenu : plus une seule suspension, quinze machines a
ok=66 et 0 unreachable.
make verifier : vert. make prouver : CONFORME, 55 OK, 0 echec, 0 saute.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019f91zs9SDdwSzL2CVei6on
Quatre machines, zero echec, la forge repond (service actif, ecoute 3000, HTTP 200).
forge-01 121 taches, infra-pki-01 109, infra-edge-01 92, infra-dns-01 84.
1. UN TIERS INTERMITTENT ARRETAIT TOUT. `packages.smallstep.com` repond une fois sur deux ;
`get_url` abandonne a 10 s sans reprise. Mesure AVANT d'accuser le reseau : DNS
resolvait, la poignee TLS aboutissait, 138 Ko depuis deb.debian.org passaient en 0,09 s,
et le chemin acceptait 1450 octets en refusant 1500 — l'attendu exact en overlay. Le
reseau n'y etait pour rien. Reprises posees sur les trois telechargements du chemin
critique (serveur_step_ca, client_pki, serveur_forgejo). Une dizaine d'autres restent
sans reprise : liste dans le CHANGELOG.
2. UN `register` A ECRASE UN CHEMIN DE FICHIER. En posant la reprise, j'ai enregistre dans
`client_pki_cle`, nom que le role utilisait deja pour la cle privee. L'ecart s'est vu 70
taches plus loin : `step ca certificate` recevait un dict serialise a la place du
fichier et refusait « too many positional arguments ». Un register ecrit dans l'espace
de noms de TOUT le role.
3. LE SSO SE DECLARAIT AU LIEU DE SE DERIVER. `serveur_forgejo_oidc_actif: true` en dur
faisait cabler une source OAuth2 vers un Keycloak inexistant. Derive desormais de
l'inventaire. Quatrieme manifestation en deux jours de la meme hypothese — le moteur
supposait l'ecosysteme COMPLET — apres les intrants (P32), les bases (P35) et les
dependances causales.
AUCUN de ces defauts n'etait visible sur Chezlepro, qui porte tout et tournait deja. Ils ne
pouvaient apparaitre qu'au premier ecosysteme DIFFERENT.
make verifier 41 OK, 0 echec, 0 saute ; make test inchange.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Arbitrage de l'exploitant : garder aussi les cles de signature. Zero get_url
sans garde dans le depot, contre neuf ce matin.
Avant : 6 serveurs tiers x 14 hotes recontactes a chaque deploiement. Apres :
zero. Un deploiement de flotte ne depend plus d'aucun serveur etranger pour ce
que la machine possede deja.
Consequence assumee et ecrite dans chaque role : une rotation de cle amont
n'est plus recuperee seule. Elle ne passe pas inapercue pour autant — apt
refuse le depot, bruyamment — et le remede tient en une ligne. C'est un defaut
SONORE, pas silencieux ; toute la journee a consiste a transformer les seconds
en premiers.
Verifie sur backup-01 : changed=0, trois taches sautees. Reste a eprouver sur
un hote neuf, ou la garde doit laisser passer le telechargement.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le rôle ajoute bien le dépôt Smallstep et installe step-cli/step-ca —
il n'était PAS cassé. Mais en --check, le dépôt/binaire ne sont pas
réellement présents → apt « No package step-cli » puis « step ca init »
échouaient (faux). Ajout de when: not ansible_check_mode sur l'install
et l'initialisation de l'AC (le service l'avait déjà).
Dry-run step_ca : failed=0 (prouvé avec vault_* de test). Config dépôt
vérifiée (clé officielle, stable/debian suite debs) — vrai déploiement
non exécuté (nécessite la voûte + action GUI).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
« Vérifier » échouait faussement sur un hôte frais : les tâches
« démarrer service » et les handlers restart/reload/validate touchent
un paquet que --check n'installe pas vraiment → service/fichier absent
→ faux fatal, qui bloquait le déploiement (le dry-run doit passer pour
débloquer « Déployer »).
Ajout de « when: not ansible_check_mode » sur ces tâches + handlers des
13 rôles serveur_* (29 gardes). Sautées en dry-run, inchangées en réel.
Validé : powerdns dry-run failed=0 ; ansible-lint 0 échec ; 19 playbooks
syntax-OK.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
