Daniel Allaire
53c5f41a1a
Some checks are pending
verifier / verifier (push) Waiting to run
Les six machines du SITE — racine de l AC, forge, cache, resolveur, depot de sauvegarde, runner — ne recevaient que serveur_debian. Ni auditd, ni fail2ban, ni apparmor, ni sysctl, ni pare-feu. Le commentaire au-dessus de GROUPE_SOCLE affirmait pourtant le contraire, ce qui rendait l ecart invisible. Le pare-feu du site n avait aucune des trois pieces qui le rendent applicable : - aucune regle generee (resoudre_flux lit un hosts.yml ; le site a un inventaire dynamique) -> commande nftables-site, branchee sur make flux - le chemin du jeu de regles sortait du depot (inventory_dir vaut scripts/ pour un inventaire dynamique) -> host_var explicite - aucun nftables_admin_ssh : l exploitant administre PAR REBOND, la connexion arrive avec l adresse de la patte de frontiere DANS LA ZONE VISEE. Le generateur refuse desormais de produire des regles sans cet intrant. Defaut attrape en LISANT le jeu de regles avant de l appliquer : la regle DNS de site-dns-01 omettait 10.17.0.0/16. _supernets_voisins retire l instance montee — juste chez un tenant, faux du cote du site, ou ca retire le locataire qu on pilote. L appliquer aurait prive de DNS les quinze machines reconstruites la veille. MaxStartups du depot passe en host_var : dans le meta du role, il ne portait que dans son play, et le passage de serveur_durci le remettait au defaut sans rien dire. Un reglage qui depend de l ordre des plays revient en arriere. Verifie depuis un locataire a travers le nouveau pare-feu : cache, forge, depot (2 snapshots) et resolveur repondent ; l AC du site refuse, et c est correct. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019f91zs9SDdwSzL2CVei6on |
||
|---|---|---|
| .. | ||
| defaults | ||
| meta | ||
| tasks | ||
| README.md | ||
serveur_backup_site
Le marqueur du dépôt de sauvegarde du site. Il dit que ce dépôt est celui où les écosystèmes du site déposent leur état, et déclare le flux qui le permet. Il n'installe rien.
Le quatrième service prêté
| ce que le site prête | pendant la jeunesse du tenant |
|---|---|
| les paquets | serveur_cache_site |
| le génome | serveur_forge_site |
| les noms | serveur_resolveur_site |
| l'état | ce rôle |
Ce qu'il a corrigé
Mesuré le 2026-09-01, en préparant un rasage de Chezlepro : toutes ses sauvegardes
vivaient sur backup-01, une VM de sa propre flotte. Raser l'écosystème aurait détruit
les données et leur seul filet dans le même geste.
La doctrine affirmait pourtant que client_backup_cible « pointe déjà hors de
l'écosystème ». C'était vrai pour patient 0, qui sauvegarde chez eregion — faux pour
Chezlepro. Un document qui décrit une propriété que le réel n'a pas est exactement ce que
ce dépôt traque.
Pourquoi une zone à lui seul
site-sauvegarde (VLAN 35) n'existe que pour lui. Il détient l'état de chaque tenant :
clés d'autorité, annuaires, bases, courriel. C'est la machine dont la compromission coûte
le plus cher du site — davantage que la forge, dont le contenu est du code, et davantage
que l'AC, qui forge des noms sans détenir de données.
Le mettre avec le génome aurait partagé un domaine de diffusion entre ce que les tenants viennent chercher et ce qu'ils déposent. Deux natures opposées : l'une est faite pour être lue par tous, l'autre pour n'être lue par personne.
Ce qui rend la mutualisation acceptable
Le site reçoit des octets chiffrés par restic avant de partir. Il héberge l'état de ses locataires sans pouvoir le lire — c'est ce qui distingue ce service de la voûte, qui ne se mutualise à aucun âge.
Ce que ce rôle ne fait pas
Il n'installe rien. Il vérifie deux choses : que la racine des dépôts existe, et qu'il reste de la place devant les locataires. Un dépôt qui se remplit n'échoue pas à l'ouverture — il échoue au milieu d'un instantané, chez le locataire, et la panne se lit comme une erreur réseau.