2026-06-24 20:17:46 -04:00
|
|
|
---
|
|
|
|
|
- name: Appliquer le groupe serveur_debian
|
|
|
|
|
hosts: serveur_debian
|
|
|
|
|
become: true
|
empreintes muettes, courses de premier demarrage, collision de noms
Quatre meta/empreinte.yml declaraient leurs valeurs A LA RACINE, sans la cle
`setops_empreinte:` : collabora, nextcloud, web_dorsal, web_frontal. Le lecteur
les voyait vides et rendait {0,0,0} — en silence. collab-01 s'est retrouvee avec
1 coeur / 1 Go pour porter Nextcloud ET Collabora, et a cesse de repondre en SSH
faute de memoire. Corrigee : 4c/5632Mo. Une garde refuse desormais cette forme.
Un fichier qui existe mais ne dit rien est pire qu'un fichier absent : le repli
aurait donne des valeurs sensees.
Deux courses de premier demarrage :
- le clone rend la main avant que son .conf existe -> attente active sur l'API ;
- le verrou dpkg frappait hors de `common_packages` -> `lock_timeout` pose en
module_defaults sur les 30 playbooks de groupe, une declaration au lieu de 30.
Au passage, j'ai failli livrer pire que le defaut : une URL coupee avec `>-`
inserait une ESPACE en son milieu. Le lint passait, la requete non.
Enfin : `proxmox_kvm` identifie une VM par son NOM. Une VM heritee homonyme lui
a fait rapporter `ok` sans rien cloner — un deploiement peut donc PARAITRE
reussi alors qu'aucune VM n'existe. Touche D-37 directement.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-07 16:22:38 -04:00
|
|
|
# Le verrou dpkg est tenu par les maj automatiques de Debian, par vagues, plusieurs
|
|
|
|
|
# minutes apres le premier demarrage. Pose ICI plutot que dans chaque role : toute
|
|
|
|
|
# tache apt du play en herite, y compris celles des roles inclus.
|
|
|
|
|
module_defaults:
|
|
|
|
|
ansible.builtin.apt:
|
|
|
|
|
lock_timeout: 300
|
|
|
|
|
|
2026-06-24 20:17:46 -04:00
|
|
|
gather_facts: true
|
|
|
|
|
|
|
|
|
|
pre_tasks:
|
|
|
|
|
- name: Vérifier que la cible est Debian
|
|
|
|
|
ansible.builtin.assert:
|
|
|
|
|
that:
|
|
|
|
|
- ansible_facts.distribution == "Debian"
|
|
|
|
|
fail_msg: "Ce playbook est prévu pour Debian."
|
|
|
|
|
|
dns : client_unbound universel, et un resolveur d'amorcage
Une VM ne peut pas s'installer sans resoudre des noms. PowerDNS repond
UNIQUEMENT pour la zone souveraine et ne recurse pour personne : il manquait un
resolveur recursif. `client_unbound` est l'outil ecrit pour ca — il rejoint
`client_journal` et `client_metrique` parmi les integrations universelles.
`infra-dns-01` est exempte (PowerDNS occupe son port 53), et
`serveur_powerdns_listen_addresses` passe de 0.0.0.0 a l'adresse de l'hote pour
laisser 127.0.0.1:53 libre. Mais l'appartenance au groupe est AUSSI ce qui ouvre
le port 53 a la frontiere : en exemptant la machine, je lui retirais le droit de
resoudre. `serveur_powerdns` declare donc son propre flux sortant — il ne
recurse pour personne, mais doit resoudre pour lui-meme.
Nouvel intrant `dns_amorcage`, derive jusqu'a `make creer-vm`. Cloud-init
l'ecrit bien mais sans effet : `dns-nameservers` exige `resolvconf`, absent du
gabarit, et installer resolvconf demande apt, qui demande la resolution.
`serveur_debian` pose donc le resolveur en pre_tasks, avant le premier apt, avec
une garde qui respecte la bascule ulterieure de client_unbound.
Defaut corrige en chemin : `_intrants_communs()` lisait `instance/` en dur ; le
chemin derive maintenant de l'inventaire recu, et un test le prouve.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-06 21:41:58 -04:00
|
|
|
# Résolveur d'AMORÇAGE, posé avant `common_packages` — donc avant le premier `apt`.
|
|
|
|
|
# Sans lui, le déploiement échoue avant d'avoir commencé : le gabarit doré transporte
|
|
|
|
|
# un `/etc/resolv.conf` figé, et le `dns-nameservers` écrit par cloud-init reste sans
|
|
|
|
|
# effet faute de `resolvconf` (qu'on ne peut pas installer sans résolution — la boucle
|
|
|
|
|
# se referme). Mesuré le 2026-08-06 sur deux VM neuves.
|
|
|
|
|
#
|
2026-08-24 16:59:34 -04:00
|
|
|
# PASSAGE DE RELAIS : `client_resolveur` reprend ce fichier plus tard pour le basculer
|
dns : client_unbound universel, et un resolveur d'amorcage
Une VM ne peut pas s'installer sans resoudre des noms. PowerDNS repond
UNIQUEMENT pour la zone souveraine et ne recurse pour personne : il manquait un
resolveur recursif. `client_unbound` est l'outil ecrit pour ca — il rejoint
`client_journal` et `client_metrique` parmi les integrations universelles.
`infra-dns-01` est exempte (PowerDNS occupe son port 53), et
`serveur_powerdns_listen_addresses` passe de 0.0.0.0 a l'adresse de l'hote pour
laisser 127.0.0.1:53 libre. Mais l'appartenance au groupe est AUSSI ce qui ouvre
le port 53 a la frontiere : en exemptant la machine, je lui retirais le droit de
resoudre. `serveur_powerdns` declare donc son propre flux sortant — il ne
recurse pour personne, mais doit resoudre pour lui-meme.
Nouvel intrant `dns_amorcage`, derive jusqu'a `make creer-vm`. Cloud-init
l'ecrit bien mais sans effet : `dns-nameservers` exige `resolvconf`, absent du
gabarit, et installer resolvconf demande apt, qui demande la resolution.
`serveur_debian` pose donc le resolveur en pre_tasks, avant le premier apt, avec
une garde qui respecte la bascule ulterieure de client_unbound.
Defaut corrige en chemin : `_intrants_communs()` lisait `instance/` en dur ; le
chemin derive maintenant de l'inventaire recu, et un test le prouve.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-06 21:41:58 -04:00
|
|
|
# vers `127.0.0.1`. La garde ci-dessous le respecte — sans elle, chaque déploiement
|
|
|
|
|
# défairait la bascule, et deux rôles se disputeraient le même fichier sans fin.
|
socle : la source d'artefacts d'amorcage — nourrir la premiere machine
LA PREMIERE MACHINE D'UN ECOSYSTEME N'A NI RESOLVEUR NI CACHE, ET C'EST ELLE QUI
DOIT LES CONSTRUIRE. Mesure sur ops-01, premiere machine de la reconstruction de
Chezlepro : le socle restait bloque sur son premier apt update.
sortie Internet TCP 443 OK
DNS UDP 53 -> 9.9.9.9 MUET
Le DNS sortant est ferme PAR CONCEPTION — un tenant resout chez lui. Or apt vise
deb.debian.org par son NOM, et le cache de l'ecosysteme n'existe pas encore.
UN MANDATAIRE HTTP RESOUT CE QUE LE CLIENT NE PEUT PAS RESOUDRE : apt lui envoie
l'URL absolue et c'est lui qui traduit. La machine n'a besoin d'aucun DNS, seulement
d'une ADRESSE. Symetrique exacte de , meme place dans le socle.
AUCUN FLUX A OUVRIR : accepte deja le 3142 depuis
, qui resout les SUPERNETS des tenants — donc toute machine, pas
seulement leur cache. Verifie depuis ops-01 : HTTP 200 en 0,158 s.
C'EST DE LA FILIATION, PAS UNE RUSTINE. L'emprunt est declare (l'intrant nomme
l'amont) et il s'efface : ecrit 00-setops-artefacts, qui trie
APRES, donc gagne des que l'ecosysteme a sa source. Le plancher reste dessous,
comme /etc/hosts reste sous le DNS. Le retirer le jour venu est une emancipation —
un geste, pas un effet.
DIAGNOSTIC CORRIGE EN CHEMIN : j'avais lu "BLOQUE" vers le resolveur, le cache et
la PKI du tenant comme un pare-feu. C'etait une ABSENCE — ops-01 est la seule VM de
Chezlepro qui existe. Un port muet ressemble a un refus.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019f91zs9SDdwSzL2CVei6on
2026-08-28 15:05:11 -04:00
|
|
|
# SOURCE D'ARTEFACTS D'AMORÇAGE, posée avant le premier `apt` — symétrique exacte du
|
|
|
|
|
# résolveur d'amorçage ci-dessous, et pour la même raison de fond : LA PREMIÈRE
|
|
|
|
|
# MACHINE D'UN ÉCOSYSTÈME N'A NI RÉSOLVEUR NI CACHE, ET C'EST ELLE QUI DOIT LES
|
|
|
|
|
# CONSTRUIRE.
|
|
|
|
|
#
|
|
|
|
|
# Mesuré le 2026-08-28 sur `ops-01`, première machine de la reconstruction de
|
|
|
|
|
# Chezlepro. Le socle restait bloqué sur son premier `apt update`, sans message qui
|
|
|
|
|
# parle de réseau :
|
|
|
|
|
#
|
|
|
|
|
# sortie Internet TCP 443 OK
|
|
|
|
|
# DNS UDP 53 -> 9.9.9.9 MUET
|
|
|
|
|
#
|
|
|
|
|
# Le DNS sortant est fermé PAR CONCEPTION — un tenant résout chez lui, son DNS ne
|
|
|
|
|
# traverse jamais la frontière. Or apt vise `deb.debian.org` PAR SON NOM, et le cache
|
|
|
|
|
# de l'écosystème n'existe pas encore.
|
|
|
|
|
#
|
|
|
|
|
# UN MANDATAIRE HTTP RÉSOUT CE QUE LE CLIENT NE PEUT PAS RÉSOUDRE : apt lui envoie
|
|
|
|
|
# l'URL absolue, et c'est LUI qui traduit le nom. La machine n'a donc besoin d'aucun
|
|
|
|
|
# DNS pour installer ses paquets — seulement d'une ADRESSE.
|
|
|
|
|
#
|
|
|
|
|
# C'EST DE LA FILIATION, PAS UNE RUSTINE (docs/filiation-emancipation.md). L'hébergeur
|
|
|
|
|
# nourrit la première machine de son locataire le temps que celui-ci monte son propre
|
|
|
|
|
# cache. L'emprunt est DÉCLARÉ — l'intrant nomme l'amont — et il s'efface de lui-même :
|
|
|
|
|
# `client_artefacts` écrit `00-setops-artefacts`, qui trie APRÈS ce fichier-ci, donc
|
|
|
|
|
# gagne dès que l'écosystème a sa propre source. Le plancher reste dessous, comme
|
|
|
|
|
# `/etc/hosts` reste sous le DNS.
|
|
|
|
|
#
|
|
|
|
|
# Aucun flux à ouvrir : `serveur_cache_site` accepte déjà le 3142 depuis
|
|
|
|
|
# `voisins_site`, qui résout les SUPERNETS des tenants — donc toute machine, pas
|
|
|
|
|
# seulement leur cache. Vérifié depuis `ops-01` : HTTP 200 en 0,158 s.
|
|
|
|
|
- name: Poser la source d'artefacts d'amorçage (avant tout apt)
|
|
|
|
|
ansible.builtin.copy:
|
|
|
|
|
dest: /etc/apt/apt.conf.d/00-setops-amorcage-artefacts
|
|
|
|
|
owner: root
|
|
|
|
|
group: root
|
|
|
|
|
mode: "0644"
|
|
|
|
|
content: |
|
|
|
|
|
// GÉNÉRÉ par Set-OPS (socle) — source d'artefacts d'AMORÇAGE, intrant
|
|
|
|
|
// `artefacts_amorcage`. Remplacé par `client_artefacts` (00-setops-artefacts,
|
|
|
|
|
// qui trie après) dès que l'écosystème a sa propre source.
|
|
|
|
|
//
|
|
|
|
|
// UNE ADRESSE, JAMAIS UN NOM : au moment où ce fichier sert, la machine n'a pas
|
|
|
|
|
// encore de résolveur, et le DNS sortant d'un tenant est fermé par conception.
|
|
|
|
|
Acquire::http::Proxy "http://{{ artefacts_amorcage }}";
|
|
|
|
|
// `DIRECT` est obligatoire : apt fait HÉRITER la valeur HTTPS de la valeur HTTP
|
|
|
|
|
// quand elle n'est pas définie, et enverrait les dépôts tiers en HTTPS dans un
|
|
|
|
|
// cache qui refuse les tunnels (mesuré le 2026-08-23).
|
|
|
|
|
Acquire::https::Proxy "DIRECT";
|
|
|
|
|
when:
|
|
|
|
|
- artefacts_amorcage is defined
|
|
|
|
|
- artefacts_amorcage | string | length > 0
|
|
|
|
|
|
dns : client_unbound universel, et un resolveur d'amorcage
Une VM ne peut pas s'installer sans resoudre des noms. PowerDNS repond
UNIQUEMENT pour la zone souveraine et ne recurse pour personne : il manquait un
resolveur recursif. `client_unbound` est l'outil ecrit pour ca — il rejoint
`client_journal` et `client_metrique` parmi les integrations universelles.
`infra-dns-01` est exempte (PowerDNS occupe son port 53), et
`serveur_powerdns_listen_addresses` passe de 0.0.0.0 a l'adresse de l'hote pour
laisser 127.0.0.1:53 libre. Mais l'appartenance au groupe est AUSSI ce qui ouvre
le port 53 a la frontiere : en exemptant la machine, je lui retirais le droit de
resoudre. `serveur_powerdns` declare donc son propre flux sortant — il ne
recurse pour personne, mais doit resoudre pour lui-meme.
Nouvel intrant `dns_amorcage`, derive jusqu'a `make creer-vm`. Cloud-init
l'ecrit bien mais sans effet : `dns-nameservers` exige `resolvconf`, absent du
gabarit, et installer resolvconf demande apt, qui demande la resolution.
`serveur_debian` pose donc le resolveur en pre_tasks, avant le premier apt, avec
une garde qui respecte la bascule ulterieure de client_unbound.
Defaut corrige en chemin : `_intrants_communs()` lisait `instance/` en dur ; le
chemin derive maintenant de l'inventaire recu, et un test le prouve.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-06 21:41:58 -04:00
|
|
|
- name: Lire le résolveur en place
|
|
|
|
|
ansible.builtin.slurp:
|
|
|
|
|
src: /etc/resolv.conf
|
|
|
|
|
register: serveur_debian_resolv_actuel
|
|
|
|
|
failed_when: false
|
|
|
|
|
changed_when: false
|
|
|
|
|
|
|
|
|
|
- name: Poser le résolveur d'amorçage (avant tout apt)
|
|
|
|
|
ansible.builtin.copy:
|
|
|
|
|
dest: /etc/resolv.conf
|
|
|
|
|
owner: root
|
|
|
|
|
group: root
|
|
|
|
|
mode: "0644"
|
|
|
|
|
content: |
|
|
|
|
|
# Géré par Set-OPS — résolveur d'amorçage (intrant `dns_amorcage`).
|
2026-08-24 16:59:34 -04:00
|
|
|
# Remplacé par `client_resolveur` lorsqu'il bascule vers le résolveur local.
|
dns : client_unbound universel, et un resolveur d'amorcage
Une VM ne peut pas s'installer sans resoudre des noms. PowerDNS repond
UNIQUEMENT pour la zone souveraine et ne recurse pour personne : il manquait un
resolveur recursif. `client_unbound` est l'outil ecrit pour ca — il rejoint
`client_journal` et `client_metrique` parmi les integrations universelles.
`infra-dns-01` est exempte (PowerDNS occupe son port 53), et
`serveur_powerdns_listen_addresses` passe de 0.0.0.0 a l'adresse de l'hote pour
laisser 127.0.0.1:53 libre. Mais l'appartenance au groupe est AUSSI ce qui ouvre
le port 53 a la frontiere : en exemptant la machine, je lui retirais le droit de
resoudre. `serveur_powerdns` declare donc son propre flux sortant — il ne
recurse pour personne, mais doit resoudre pour lui-meme.
Nouvel intrant `dns_amorcage`, derive jusqu'a `make creer-vm`. Cloud-init
l'ecrit bien mais sans effet : `dns-nameservers` exige `resolvconf`, absent du
gabarit, et installer resolvconf demande apt, qui demande la resolution.
`serveur_debian` pose donc le resolveur en pre_tasks, avant le premier apt, avec
une garde qui respecte la bascule ulterieure de client_unbound.
Defaut corrige en chemin : `_intrants_communs()` lisait `instance/` en dur ; le
chemin derive maintenant de l'inventaire recu, et un test le prouve.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-06 21:41:58 -04:00
|
|
|
{% for serveur in dns_amorcage.split(',') if serveur | trim %}
|
|
|
|
|
nameserver {{ serveur | trim }}
|
|
|
|
|
{% endfor %}
|
2026-08-25 13:57:48 -04:00
|
|
|
# L'AMORÇAGE NE DOIT PAS DÉFAIRE CE QUI EST DÉJÀ EN PLACE (2026-08-25).
|
|
|
|
|
#
|
|
|
|
|
# La garde ne protégeait que l'hôte du résolveur lui-même (`127.0.0.1`). Partout
|
|
|
|
|
# ailleurs, le socle réécrivait `/etc/resolv.conf` avec `dns_amorcage` — donc
|
|
|
|
|
# **défaisait la bascule** de `client_resolveur` à chaque passage.
|
|
|
|
|
#
|
|
|
|
|
# Ça ne s'était jamais vu chez un tenant : `dns_amorcage` y vaut l'adresse du
|
|
|
|
|
# résolveur du tenant, si bien que réécrire remettait la même valeur. La
|
|
|
|
|
# coïncidence masquait le défaut.
|
|
|
|
|
#
|
|
|
|
|
# Sur le site, les deux ont divergé quelques heures — l'amorçage pointait encore sur
|
|
|
|
|
# la frontière alors que `client_resolveur` avait basculé les machines sur
|
|
|
|
|
# `site-dns-01`. Chaque déploiement du socle les ramenait en arrière, en silence, et
|
|
|
|
|
# ça ne s'est vu qu'en retirant la règle de pare-feu vers la frontière : les cinq
|
|
|
|
|
# machines ont alors perdu la résolution d'un coup.
|
|
|
|
|
#
|
|
|
|
|
# On ne pose donc l'amorçage que si rien de sensé n'est déjà là : ni la loopback, ni
|
|
|
|
|
# un résolveur déclaré de cet écosystème.
|
|
|
|
|
vars:
|
|
|
|
|
serveur_debian_resolv_texte: >-
|
|
|
|
|
{{ serveur_debian_resolv_actuel.content | default('') | b64decode | string }}
|
|
|
|
|
serveur_debian_resolveurs_declares: >-
|
|
|
|
|
{{ (groups['serveur_resolveur'] | default([]))
|
|
|
|
|
| map('extract', hostvars, 'ansible_host') | select | list }}
|
dns : client_unbound universel, et un resolveur d'amorcage
Une VM ne peut pas s'installer sans resoudre des noms. PowerDNS repond
UNIQUEMENT pour la zone souveraine et ne recurse pour personne : il manquait un
resolveur recursif. `client_unbound` est l'outil ecrit pour ca — il rejoint
`client_journal` et `client_metrique` parmi les integrations universelles.
`infra-dns-01` est exempte (PowerDNS occupe son port 53), et
`serveur_powerdns_listen_addresses` passe de 0.0.0.0 a l'adresse de l'hote pour
laisser 127.0.0.1:53 libre. Mais l'appartenance au groupe est AUSSI ce qui ouvre
le port 53 a la frontiere : en exemptant la machine, je lui retirais le droit de
resoudre. `serveur_powerdns` declare donc son propre flux sortant — il ne
recurse pour personne, mais doit resoudre pour lui-meme.
Nouvel intrant `dns_amorcage`, derive jusqu'a `make creer-vm`. Cloud-init
l'ecrit bien mais sans effet : `dns-nameservers` exige `resolvconf`, absent du
gabarit, et installer resolvconf demande apt, qui demande la resolution.
`serveur_debian` pose donc le resolveur en pre_tasks, avant le premier apt, avec
une garde qui respecte la bascule ulterieure de client_unbound.
Defaut corrige en chemin : `_intrants_communs()` lisait `instance/` en dur ; le
chemin derive maintenant de l'inventaire recu, et un test le prouve.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-06 21:41:58 -04:00
|
|
|
when:
|
|
|
|
|
- dns_amorcage is defined
|
|
|
|
|
- dns_amorcage | string | length > 0
|
2026-08-25 13:57:48 -04:00
|
|
|
- "'127.0.0.1' not in serveur_debian_resolv_texte"
|
|
|
|
|
- serveur_debian_resolveurs_declares
|
|
|
|
|
| select('in', serveur_debian_resolv_texte) | list | length == 0
|
dns : client_unbound universel, et un resolveur d'amorcage
Une VM ne peut pas s'installer sans resoudre des noms. PowerDNS repond
UNIQUEMENT pour la zone souveraine et ne recurse pour personne : il manquait un
resolveur recursif. `client_unbound` est l'outil ecrit pour ca — il rejoint
`client_journal` et `client_metrique` parmi les integrations universelles.
`infra-dns-01` est exempte (PowerDNS occupe son port 53), et
`serveur_powerdns_listen_addresses` passe de 0.0.0.0 a l'adresse de l'hote pour
laisser 127.0.0.1:53 libre. Mais l'appartenance au groupe est AUSSI ce qui ouvre
le port 53 a la frontiere : en exemptant la machine, je lui retirais le droit de
resoudre. `serveur_powerdns` declare donc son propre flux sortant — il ne
recurse pour personne, mais doit resoudre pour lui-meme.
Nouvel intrant `dns_amorcage`, derive jusqu'a `make creer-vm`. Cloud-init
l'ecrit bien mais sans effet : `dns-nameservers` exige `resolvconf`, absent du
gabarit, et installer resolvconf demande apt, qui demande la resolution.
`serveur_debian` pose donc le resolveur en pre_tasks, avant le premier apt, avec
une garde qui respecte la bascule ulterieure de client_unbound.
Defaut corrige en chemin : `_intrants_communs()` lisait `instance/` en dur ; le
chemin derive maintenant de l'inventaire recu, et un test le prouve.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-06 21:41:58 -04:00
|
|
|
|
2026-06-24 20:17:46 -04:00
|
|
|
roles:
|
site : quatre zones d'autorite, et l'ordre inscrit dans les integrations
Le site n'est plus un /24 plat. Une zone par nature d'autorite — pilotage, autorite,
genome, service — chacune son VLAN et sa patte sur la frontiere. L'inversion corrigee,
mesuree : les cinq VM du site n'avaient AUCUN filtrage est-ouest, contre policy_in=DROP
sur une machine de tenant. La plus autoritaire etait la moins protegee.
Filtrage nord-sud par choix de l'exploitant : un seul point de police, un seul devis.
90 -> 117 regles. Chaque flux `flotte` produit une regle par zone SOURCE, destination
nommee — ce qui etait gratuit devient police.
L'ORDRE FAIT PARTIE DE L'INTEGRATION. client_pki tournait en parallele sur tous les hotes ;
sur celui qui porte l'autorite il recharge step-ca, et les quatre autres echouaient dans
cette fenetre sur `TLS handshake timeout` — un message qui accuse le reseau. Chaque
integration declare desormais sa dependance dans meta/integration.yml, les playbooks en
sont le miroir genere, et P44 refuse l'ecart (4 controles negatifs). `serveur: ~` est une
reponse valable : client_metrique pose un exportateur qu'on vient LIRE.
Autres defauts du meme soir :
- le plancher /etc/hosts venait APRES le premier apt, qui vise le cache par son NOM :
boucle fermee des que les adresses changent. Il ne s'installe pas, il rend installable.
- dns_amorcage ecrit en dur a eu tort deux fois ; il se derive de serveur_resolveur.
- l'ACL du resolveur derivait d'un seul sous-reseau : trois zones refusees sur quatre.
ET UNE ERREUR A MOI : j'ai diagnostique un trou noir de MTU et declare 1450. Faux — pas de
VXLAN sur ce chemin, tout est a 1500 de bout en bout. Ma mesure etait reelle, mon
interpretation non : je venais de debrancher la carte a chaud, et chaque `ip link set mtu`
reconfigurait l'interface. C'est la reconfiguration qui debloquait, pas la valeur.
44 preuves vertes, ansible-lint profil production.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-25 17:31:07 -04:00
|
|
|
# LE PLANCHER AVANT LE PREMIER `apt` (2026-08-25).
|
|
|
|
|
#
|
|
|
|
|
# `hosts_statiques` venait APRÈS `common_packages`, qui commence par un `apt update`.
|
|
|
|
|
# Or apt vise le cache PAR SON NOM — `site-cache-01.<domaine>` — ce qui est voulu :
|
|
|
|
|
# une configuration agnostique de l'adressage.
|
|
|
|
|
#
|
|
|
|
|
# Le jour où les adresses changent, la boucle se referme : apt échoue faute de
|
|
|
|
|
# résoudre, donc le socle n'atteint jamais `hosts_statiques`, donc le plancher reste
|
|
|
|
|
# périmé, donc apt échoue. Mesuré le 2026-08-25 après le découpage du site en zones :
|
|
|
|
|
# cinq machines bloquées, `/etc/hosts` vide de toute entrée du site.
|
|
|
|
|
#
|
|
|
|
|
# Le résolveur d'amorçage est déjà une `pre_task` pour exactement cette raison. Le
|
|
|
|
|
# plancher est de la même nature : il ne s'installe pas, **il rend installable**.
|
2026-06-30 18:05:42 -04:00
|
|
|
- hosts_statiques
|
site : quatre zones d'autorite, et l'ordre inscrit dans les integrations
Le site n'est plus un /24 plat. Une zone par nature d'autorite — pilotage, autorite,
genome, service — chacune son VLAN et sa patte sur la frontiere. L'inversion corrigee,
mesuree : les cinq VM du site n'avaient AUCUN filtrage est-ouest, contre policy_in=DROP
sur une machine de tenant. La plus autoritaire etait la moins protegee.
Filtrage nord-sud par choix de l'exploitant : un seul point de police, un seul devis.
90 -> 117 regles. Chaque flux `flotte` produit une regle par zone SOURCE, destination
nommee — ce qui etait gratuit devient police.
L'ORDRE FAIT PARTIE DE L'INTEGRATION. client_pki tournait en parallele sur tous les hotes ;
sur celui qui porte l'autorite il recharge step-ca, et les quatre autres echouaient dans
cette fenetre sur `TLS handshake timeout` — un message qui accuse le reseau. Chaque
integration declare desormais sa dependance dans meta/integration.yml, les playbooks en
sont le miroir genere, et P44 refuse l'ecart (4 controles negatifs). `serveur: ~` est une
reponse valable : client_metrique pose un exportateur qu'on vient LIRE.
Autres defauts du meme soir :
- le plancher /etc/hosts venait APRES le premier apt, qui vise le cache par son NOM :
boucle fermee des que les adresses changent. Il ne s'installe pas, il rend installable.
- dns_amorcage ecrit en dur a eu tort deux fois ; il se derive de serveur_resolveur.
- l'ACL du resolveur derivait d'un seul sous-reseau : trois zones refusees sur quatre.
ET UNE ERREUR A MOI : j'ai diagnostique un trou noir de MTU et declare 1450. Faux — pas de
VXLAN sur ce chemin, tout est a 1500 de bout en bout. Ma mesure etait reelle, mon
interpretation non : je venais de debrancher la carte a chaud, et chaque `ip link set mtu`
reconfigurait l'interface. C'est la reconfiguration qui debloquait, pas la valeur.
44 preuves vertes, ansible-lint profil production.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-25 17:31:07 -04:00
|
|
|
- common_packages
|
2026-06-24 20:17:46 -04:00
|
|
|
- qemu_guest_agent
|
|
|
|
|
- cloud_init
|
|
|
|
|
- sudo_ansible
|
|
|
|
|
- chrony
|
|
|
|
|
- ssh_baseline
|
|
|
|
|
- systemd_ssh_auto
|
|
|
|
|
- motd
|