Aller au contenu

Infrastructure

Sommaire

J’héberge chez moi l’essentiel de ce que j’utilise au quotidien. Ce n’est pas une vitrine : c’est ce qui tourne, avec les compromis que ça suppose. Cette page dit quoi, sur quoi, et ce que les pannes m’ont appris.

La forme générale
#

Schéma de l'infrastructure : l'hôte Proxmox et ses trois machines virtuelles réparties en VLAN, le NAS de sauvegarde, le proxy inverse en façade et le réseau maillé Headscale.

Un hôte Proxmox, trois machines virtuelles aux rôles séparés, un NAS Synology pour les sauvegardes, et un réseau maillé Headscale qui relie le tout sans exposer quoi que ce soit au passage. Des VLAN séparent les usages — Management pour l’hyperviseur, DMZ pour la façade, Serveur, Downloader, Storage pour le NAS — plus une zone Agents isolée, conservée sans machine active.

Ce qui tourne
#

Sur la VM docker :

ServiceRôle
Homepagetableau de bord d’accueil
Paperless-ngxgestion documentaire
Homeboxinventaire personnel
FreshRSSlecteur de flux
Kavitabibliothèque numérique
Actual Budgetbudget personnel
Dockhandgestion des piles Docker
Uptime Kumasupervision et alertes
Prometheus + Grafanamétriques et tableaux de bord
CrowdSec (interface web)consulte le LAPI hébergé sur frontend
n8nautomatisation de traitements personnels
ntfynotifications push auto-hébergées

Ce qui m’a mordu
#

Une alerte qui semblait partir, et qui ne partait jamais. Aucune alerte Proxmox n’arrivait, sans que rien ne le signale : le journal affichait notified via target 'mail-to-root' même quand le courriel ne partirait jamais, sendmail échouant en différé dans la file postfix. La cause réelle était ailleurs : le port 25 sortant bloqué, postfix incapable de joindre iCloud, découvert en testant tout autre chose. Ne jamais considérer un target sendmail comme fonctionnel sans l’avoir vérifié de bout en bout : un webhook échoue devant vous, un courriel échoue plus tard, ailleurs.
Détecter n’est pas alerter. Prometheus est resté arrêté 17 heures, puis deux jours, sans que rien ne remonte — alors que les sondes fonctionnaient parfaitement et qu’Uptime Kuma avait bien enregistré les bascules. Le premier incident a été traité en ajoutant une sonde, donc en corrigeant la détection, qui n’était pas le problème : la cause était resendInterval = 0, la valeur par défaut sur tous les moniteurs, qui ne notifie qu’une fois. Quand une alerte n’arrive pas, séparer trois étages avant de corriger : la sonde détecte-t-elle, la notification est-elle rattachée, l’envoi aboutit-il et se répète-t-il ?
Une politique de sécurité qui casse le site sans rien dire. Ce site-ci se chargeait et s’affichait normalement, tout en 200 côté serveur, sans rien dans les journaux. La cause : une CSP script-src 'self' héritée d’un fragment de configuration partagé, qui bloquait les scripts en ligne du thème, découverte par hasard dans la console du navigateur. Une fonctionnalité JavaScript bloquée par une CSP est invisible côté serveur — vérifier l’en-tête avec curl ne prouve rien, il faut ouvrir la console sur une vraie page. Autoriser chaque script par son hachage règle le problème du jour, mais les hachages changent à la mise à jour du thème : le contrôle qui les recalcule et signale une absence fait partie du correctif, pas d’un raffinement optionnel.

Ce que ça m’a appris
#

La partie la plus utile de cette infrastructure n’est pas ce qui tourne, mais ce qui signale quand ça s’arrête : une sonde qui détecte sans alerter, ou une alerte qui part sans jamais arriver, produit exactement le même silence qu’une panne inexistante.