Daniel Allaire
0dd57ba995
CE CACHE EST UN MAILLON DONT DEPEND SA PROPRE RECONSTRUCTION. Toute la flotte y prend ses paquets. S il pointe vers un amont mort, apt echoue sur les quinze machines, donc le socle echoue, donc le deploiement n atteint jamais la couche qui poserait le bon amont. LE CORRECTIF SE RETROUVE DANS LA COUCHE QUE LA PANNE EMPECHE D ATTEINDRE, et il faut une main pour en sortir. C est arrive le 2026-08-31 : l amont pointait sur le cache de patient 0, eteint la veille pour liberer de la RAM. apt rendait « 503 Connection timeout » EN CITANT L ADRESSE DU CACHE LOCAL, jamais celle de l amont manquant — la panne accusait le maillon visible. DEUX FILETS, SYMETRIQUES. serveur_artefacts sonde l amont AVANT d ecrire, et refuse s il est muet : mieux vaut un cache qui garde sa configuration precedente qu un cache qu on vient de rendre inutilisable pour toute la flotte. client_artefacts sonde la source AVANT de detourner apt vers elle. Ce fichier ECRASE le plancher d amorcage pose par le socle — le poser sur un cache mort prive la machine du cache du SITE, qui lui fonctionnait. En refusant, le plancher reste : la flotte est degradee mais debout, et REPARABLE PAR UN DEPLOIEMENT. `ignore_errors` ET NON `failed_when: false` — la difference est toute la garde. failed_when: false REECRIT le verdict : la tache n est plus jamais failed, donc `is not failed` est toujours vrai, donc l assertion ne peut pas tirer. Ecrite ainsi, ma premiere version a declare « joignable » un amont mesure MUET la seconde d avant. Une garde qui ne peut pas echouer ne garde rien. Deux controles verifies sur la machine : amont eteint -> refuse ; amont reel -> pose. 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 |
||
|---|---|---|
| .. | ||
| defaults | ||
| meta | ||
| tasks | ||
| README.md | ||
client_artefacts
Intégration cliente : l'hôte prend ses paquets à la source de l'écosystème
(serveur_artefacts) plutôt que chez Debian.
Principe
Une ligne dans /etc/apt/apt.conf.d/. C'est tout ce que ce rôle fait, et c'est
délibérément tout ce qu'il fait.
Acquire::http::Proxy "http://<hôte-source>.<domaine>:3142";
Elle suit l'existence du service — elle ne se déclare pas
client_artefacts_actif est dérivé de l'inventaire : un groupe serveur_artefacts
sans hôte, c'est un écosystème qui prend ses paquets à l'amont, et c'est un choix valide.
Le rôle ne pose alors rien — et retire la direction posée auparavant, sans quoi les
hôtes resteraient braqués sur une machine disparue et n'installeraient plus rien. Une
intégration qui ne sait pas se retirer est un piège différé.
C'est la même leçon que pour le SSO, les bases et les dépendances causales : le moteur ne doit pas supposer l'écosystème complet.
Un cache ne sert jamais la machine qui le construit
client_artefacts est déployé dans la couche agents, en dernier — quand sa cible est
debout. Conséquence à connaître : lors d'une construction from-zero, les premières
machines prennent encore leurs paquets à l'amont, puisque le cache n'existe pas encore.
Il sert dès le deuxième passage, et à chaque reconstruction — c'est-à-dire exactement le scénario pour lequel il existe.
Seul le HTTP passe par le cache
Les dépôts Debian sont servis en HTTP et leur intégrité vient de leurs signatures. Les
dépôts tiers en HTTPS continuent d'aller en direct : client_artefacts_https existe mais
reste à false tant que le cache ne sait pas les remapper.