|
Some checks are pending
verifier / verifier (push) Waiting to run
Le site a son temoin : site-mon-01 (VLAN 36) porte PostgreSQL, Icinga et un relais. Le depot lui rapporte, et son premier verdict fut un vrai defaut — site-mon-01 n avait jamais depose son propre etat. Les trois sont au vert. serveur_backup_verification_locale repasse a true sur le depot : le drapeau ne dit plus on renonce mais verifie ce que tu peux ouvrir . La liste des noeuds attendus derive de l inventaire ou tourne le role, donc du site seul. serveur_postfix gagne un mode relais : un site n heberge aucune boite, il expedie. Directement par sa frontiere — emprunter le MTA d un locataire ferait dependre l hebergeur d un ecosysteme qu il peut outvivre. LA PANNE DE FOND : le modele de routes OPNsense lit enabled ; on lui envoyait disabled=0, un champ ignore. enabled restait a son defaut, ETEINT. Chaque route creee par Set-OPS depuis l origine l etait desactivee — invisible, parce qu une route eteinte EXISTE dans le modele et compte posee . Le rechargement lance pour activer la nouvelle patte a fait reprendre au noyau sa table depuis le modele : 14 routes sur 15 disparues, 11 machines de Chezlepro injoignables le lendemain de sa reconstruction, et le devis toujours vert. Trois corrections empilees : la cause (enabled), la cecite (le plan lit la table du NOYAU et signale absent ou eteint), l inaction (la reconfiguration ne se declenchait que sur un changement du modele). Aussi : un role du site peut enfin en appeler un autre a travers la frontiere — le devis traitait tout pair nomme comme l exterieur . Et nftables_admin_ssh se DERIVE de la carte : recopie a la main, il retardait d une zone, et m a verrouille dehors de la machine que je venais de creer. Reste ouvert : le destinataire des alertes est encore root@localhost. 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.