Infrastructure on Mook’s Lab Chronicles

Mon bastion Warpgate : des clés SSH au simple alias

Sat, 19 Sep 2026 16:06:02 +0200

Dans mon terminal, accéder à un serveur tient en une seule ligne :

1

ssh dmz-nextcloud-01

Pas d’adresse IP à chercher, pas de serveur de rebond à saisir, aucune clé personnelle à copier sur la cible. Pourtant, sous la surface, une chaîne complète s’active : OpenSSH, Traefik, mon bastion Warpgate, Authentik et un fichier de configuration alimenté par WarpgateSH.

Dans le billet consacré à WarpgateSH, j’expliquais comment un script lourd à maintenir avait donné naissance à un outil dédié. Il me restait à présenter l’autre pan du système : le bastion lui-même, la gestion des clés SSH et son intégration dans mon système d’information — à l’échelle d’un homelab.

Je vais remonter cette commande étape par étape, depuis mon terminal jusqu’au serveur. Pour en reproduire le principe, je partirais simplement d’une VM et d’une machine de test.

Les exemples s’appuient sur mon infrastructure et le code de WarpgateSH au 19 septembre 2026 ; la version de Warpgate vérifiée le 10 septembre était la 0.27.5. Les valeurs example.net, alice et srv-demo sont fictives et réservées aux démonstrations.

Un bastion, pour quoi faire ?

Un bastion sert de point de passage contrôlé vers les ressources à administrer. Au lieu d’autoriser chaque poste à joindre directement chaque serveur, je centralise les flux sur un service unique. Il contrôle les identités, applique les droits et conserve des journaux d’accès.

Warpgate remplit cette fonction chez moi. Je lui déclare les cibles (les serveurs autorisés) et les rôles (qui a le droit d’y accéder), tout en conservant mon client SSH habituel.

À la différence d’un rebond classique via ProxyJump, la connexion SSH directe depuis mon poste s’arrête au bastion. Warpgate ouvre ensuite sa propre session vers la machine cible avec ses propres identifiants. Je n’ai donc jamais besoin d’y transférer mon agent SSH local.

Vue logique : le réseau et le proxy de transport sont volontairement omis pour faire ressortir les deux authentifications.

Cette étanchéité constitue le point clé du montage : mon identité sur le bastion et le compte Linux de la cible sont deux entités totalement distinctes.

Clé privée, clé publique : qui garde quoi ?

Une paire de clés SSH repose sur deux éléments liés mathématiquement :

la clé privée, gardée secrète par le client qui prouve son identité ;
la clé publique, déposée sur le serveur qui vérifie cette identité.

Lors de la connexion, le client signe le défi d’authentification avec sa clé privée. Le serveur valide cette signature via la clé publique correspondante, sans que la clé privée ne transite sur le réseau.

Sur un serveur OpenSSH standard, les clés autorisées sont listées dans ~/.ssh/authorized_keys au niveau du compte utilisateur Linux (alice, root, etc.).

Pour illustrer la génération manuelle, je prends cette commande :

1

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_bastion -C "poste-perso"

Cette commande produit deux fichiers (décrits dans le manuel ssh-keygen) :

1
2


~/.ssh/id_ed25519_bastion ← Fichier privé local
~/.ssh/id_ed25519_bastion.pub ← Clé publique à déployer côté serveur

Chez moi, les clés passent par l’agent Bitwarden

Je ne définis pas de mot de passe directement sur le fichier de clé : je délègue sa protection au coffre fort de Bitwarden et son utilisation à son agent SSH. OpenSSH sollicite l’agent pour signer l’authentification sans lire de fichier privé sur mon disque. Le guide SSH Bitwarden détaille sa mise en œuvre.

Dans mon inventaire Ansible, la connexion pointe vers le socket de l’agent :

1

-o IdentityAgent=~/.bitwarden-ssh-agent.sock

Une précision importante : stocker une clé non chiffrée dans Bitwarden protège sa copie dans le coffre, mais ne sécurise pas le fichier initial resté sur le disque s’il n’a pas été supprimé.

Pour accéder au bastion via SSH, j’enregistre ma clé publique dans mon profil Warpgate. Mon agent Bitwarden produit la signature ; le bastion la vérifie avec ma clé publique. Une fois authentifié, Warpgate initie la connexion vers la cible finale en utilisant sa propre clé privée. J’autorise donc la clé publique du bastion dans le fichier authorized_keys du serveur, et non ma clé personnelle.

Ce flux par clé sert principalement aux comptes de service. Pour mes sessions d’administration courantes, je valide mon identité dans le navigateur via Authentik.

Ed25519, RSA, ECDSA : trois algorithmes distincts

Ces appellations désignent des algorithmes utilisés pour les signatures d’authentification SSH :

Type	Ce que j’en retiens
Ed25519	C’est mon choix pour les systèmes récents et le type de clé déployé par mon socle Ansible.
RSA	Je le réserverais aux besoins de rétrocompatibilité, avec des signatures SHA-2 comme l’expliquent les notes OpenSSH 8.8.
ECDSA	Variante basée sur des courbes elliptiques standardisées, disponible nativement dans OpenSSH.
`ed25519-sk` / `ecdsa-sk`	Déclinaisons exploitant une clé de sécurité matérielle (FIDO2/YubiKey).

Pour une nouvelle installation, j’écarte les algorithmes obsolètes comme DSA.

Et la clé du serveur ?

SSH contrôle également l’authenticité de l’hôte distant pour éviter les interceptions.

authorized_keys contrôle qui peut entrer ;
known_hosts enregistre les serveurs de confiance.

Le poste client valide l’empreinte du bastion, puis le bastion valide celle du serveur cible. À la première connexion, je recommande de comparer l’empreinte proposée avec celle relevée depuis la console de la VM. Pour afficher cette dernière sur la cible, j’utiliserais cette commande :

1

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Note d’usage : ne pas comparer cette empreinte revient à accepter aveuglément l’identité du serveur. C’est un point d’amélioration que je prévois d’automatiser entièrement dans mon lab.

Déploiement dans le homelab

Mon bastion tourne sur une VM Proxmox dédiée (dmz-bastion-01), provisionnée via Terraform (2 vCPU, 2 Gio de RAM, 30 Gio de stockage).

Ansible déploie Docker et configure l’environnement. Voici un extrait de mon fichier Docker Compose :

1
2
3
4
5
6
7
8
9


services:
 warpgate:
 container_name: warpgate
 restart: unless-stopped
 ports:
 - "2222:2222"
 - "8888:8888"
 volumes:
 - ./data:/data

Le port 2222 reçoit les connexions SSH et le port 8888 héberge l’interface d’administration HTTPS. Le dossier ./data conserve l’état persistant de l’application.

Traefik en frontal : un nom, deux parcours

Traefik écoute sur bastion.int.homeblack.fr et redirige les requêtes vers le bastion :

1
2
3
4
5
6
7
8


Portail HTTPS (SSO)
Navigateur → bastion.int.homeblack.fr:443
 → Traefik → Warpgate:8888 (HTTPS)

Session SSH
OpenSSH → bastion.int.homeblack.fr:2222
 → Traefik (Relais TCP) → Warpgate:2222
 → Serveur cible:22

Traefik achemine le trafic vers Warpgate ; Warpgate gère les accès aux cibles. Traefik ignore tout des machines finales et se contente de relayer les flux.

Reverse proxy HTTPS pour le portail

Le portail web passe par un reverse proxy standard. L’inventaire Ansible définit le routage :

1
2
3


- name: "bastion"
 host: "bastion.int.homeblack.fr"
 upstream_url: "https://10.60.0.17:8888"

Les liens d’approbation et le retour Authentik passent par le navigateur, via l’accès HTTPS du portail.

Relais TCP dédié pour le flux SSH

SSH ne traitant pas le protocole HTTP, Traefik utilise un routeur TCP. La configuration statique déclare d’abord le point d’entrée :

1
2
3


entryPoints:
 warpgate-ssh:
 address: ":2222"

La configuration dynamique (chargée via le provider file) définit ensuite le routage :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


tcp:
 routers:
 warpgate-ssh:
 entryPoints:
 - warpgate-ssh
 rule: "HostSNI(`*`)"
 service: warpgate-ssh

 services:
 warpgate-ssh:
 loadBalancer:
 proxyProtocol:
 version: 2
 servers:
 - address: "10.60.0.17:2222"

La règle HostSNI(`*`) accepte tous les flux TCP bruts sans interception TLS (détails dans la doc Traefik TCP). Le chiffrement SSH reste géré de bout en bout entre le client et Warpgate.

Conservation des IP sources avec PROXY Protocol

Lorsqu’un proxy transfère une connexion, le serveur final ne voit que l’IP du proxy.

L’activation du PROXY protocol v2 permet à Traefik de transmettre l’IP d’origine du client dans un en-tête ajouté au début du flux TCP. Côté Warpgate (ansible/inventory/group_vars/bastion.yml) :

1
2
3
4
5


warpgate_ssh_external_host: "bastion.int.homeblack.fr"
warpgate_ssh_external_port: 2222
warpgate_ssh_proxy_protocol: true
warpgate_ssh_allowed_sources:
 - "10.40.0.28/32" # IP de Traefik autorisée

Segmentation réseau

Dans mon architecture, Traefik réside sur le réseau TRUST et Warpgate sur le réseau DMZ. Le flux traverse le pare-feu inter-vlan. Pour une nouvelle installation, je privilégierais un reverse proxy dans le même segment réseau que le service, afin d’éviter ce passage entre zones.

J’intègre aussi le filtrage des accès directs depuis les postes à la mise en place du bastion, avec l’objectif de faire passer les sessions d’administration par Warpgate.

Comment les serveurs valident le bastion

Une fois authentifié sur Warpgate, ce dernier initie la connexion SSH vers le serveur cible. La cible doit donc connaître la clé publique du bastion.

Mon rôle Ansible ssh-keys déploie automatiquement la clé publique du bastion (warpgate-target) dans le fichier authorized_keys du compte système distant :

1
2
3
4
5
6


- name: Deploy authorized_keys
 ansible.posix.authorized_key:
 user: "{{ ssh_user }}"
 state: present
 key: "{{ item }}"
 loop: "{{ ssh_public_keys }}"

Côté Warpgate, les paramètres de la cible (IP, port, utilisateur Linux) sont injectés via Terraform.

Pour me connecter à Nextcloud, la commande sous-jacente générée équivaut à :

1

ssh -p 2222 -l 'gregory.narcin:dmz-nextcloud-01' bastion.int.homeblack.fr

Le paramètre -l transmet l’instruction : « Connecte l’utilisateur Warpgate gregory.narcin à la cible dmz-nextcloud-01 ». Après validation des droits, Warpgate ouvre la session SSH vers la VM avec son propre compte d’administration.

SSO avec Authentik et accès automatisés

J’utilise Authentik comme fournisseur d’identité via OIDC, OpenID Connect, pour l’authentification unique (SSO).

Pour une connexion humaine, l’option In-browser auth affiche une URL et un code de validation dans le terminal. J’ouvre le lien, compare le code affiché et approuve la demande après authentification auprès d’Authentik. OpenSSH attend cette validation via la méthode keyboard-interactive.

Pour raccorder Warpgate à Authentik, je configure une application cliente et son URL de redirection, par exemple https://bastion.example.net/@warpgate/api/sso/return. Je sélectionne ensuite In-browser auth dans la politique d’authentification SSH de mon compte, comme l’explique le guide SSO Warpgate.

Je gère la correspondance des rôles avec Ansible :

1
2
3


warpgate_oidc_roles_claim: "groups"
warpgate_oidc_role_mappings:
 warpgate-operators: "ops"

Les appartenances aux groupes Authentik sont ainsi converties en rôles d’accès dans Warpgate.

Pour mes automatisations Ansible et mes pipelines CI/CD, je garde des comptes de service avec des clés SSH dédiées, comme svc-ansible : je ne veux pas qu’un traitement attende une validation dans mon navigateur.

Déclaration des cibles avec Terraform

Je déclare mes cibles Warpgate avec Terraform pour éviter de les ajouter manuellement dans l’interface :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


resource "warpgate_target" "ssh" {
 for_each = local.ssh_targets
 name = each.key

 ssh_options {
 host = each.value.ip_address
 port = 22
 username = try(each.value.ssh_username, "root")
 allow_insecure_algos = false
 public_key_auth {}
 }
}

Mon parcours de création suit cet ordre : VM Terraform → Cible Warpgate Terraform → Socle Ansible → Synchronisation du client.

J’exclus le bastion lui-même de cette liste et conserve un accès d’urgence indépendant pour pouvoir intervenir si Warpgate tombe en panne.

Automatisation des alias avec WarpgateSH

WarpgateSH interroge l’API de Warpgate pour générer automatiquement la configuration SSH locale et les alias associés.

Après avoir installé la CLI (guide de démarrage), je configure un profil ; voici les commandes avec les valeurs de démonstration :

1
2
3
4
5
6


warpgatesh profile add lab https://bastion.example.net
warpgatesh profile default lab
warpgatesh profile ssh-auth lab in-browser
warpgatesh agent install
warpgatesh sync
warpgatesh ls

L’outil ajoute un appel d’inclusion dans ~/.ssh/config :

1

Include ~/.ssh/warpgatesh/config

Le fichier généré (~/.ssh/warpgatesh/config) contient les entrées de ce type :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# Profile lab

Host srv-demo srv-demo.lab
 HostName "bastion.example.net"
 Port 2222
 User "alice:srv-demo"
 UserKnownHostsFile ~/.ssh/warpgatesh/known_hosts/lab
 StrictHostKeyChecking yes
 PreferredAuthentications keyboard-interactive
 KbdInteractiveAuthentication yes
 PasswordAuthentication no
 PubkeyAuthentication no

Explication des directives :

Host : définit l’alias court et l’alias qualifié.
HostName : pointe vers le bastion.
User : passe le sélecteur utilisateur:cible.
PreferredAuthentications : impose l’authentification interactive pour déclencher la validation SSO par navigateur.

Je peux ensuite utiliser la commande raccourcie :

1

ssh srv-demo

Diagnostic et retours d’expérience

J’ai rencontré des incohérences entre mes alias SSH : certains forçaient le mode keyboard-interactive, tandis que d’autres autorisaient aussi les clés publiques.

Pour comprendre ce qu’OpenSSH utilise réellement, je consulte sa configuration effective avec ssh -G, sans ouvrir de connexion :

1

ssh -G srv-demo | awk '/^(hostname|port|user|preferredauthentications|pubkeyauthentication) /'

Je peux ainsi repérer les conflits avec d’éventuelles directives Host * globales.

Pour valider un montage similaire, je vérifierais quatre points :

L’accès aux cibles autorisées.
Le refus d’accès à une cible non attribuée.
Le compte Linux obtenu à l’arrivée, avec whoami.
La présence de la session dans les traces d’audit de Warpgate.

Bilan

Avec ce montage, je centralise mes accès SSH sans intervenir sur chaque serveur à l’arrivée ou au départ d’un utilisateur. Je garde mes accès automatisés séparés grâce aux comptes de service dédiés.

En contrepartie, mon bastion devient un composant critique de l’infrastructure. Je dois sauvegarder régulièrement sa clé privée d’administration et ses données d’audit, et en restreindre strictement les accès. C’est bien ce qui se passe en coulisses, et même un peu plus… mais si je raconte tout ici, ce billet va finir avec un sommaire en trois volumes.

Selon moi, le plus simple est d’avancer par étapes : je commencerais par valider le flux SSH sur une seule cible, puis j’intégrerais le SSO OIDC avant d’automatiser la gestion des cibles et des alias sur mon poste.

De Beszel à Zabbix : pourquoi j’ai refait toute ma supervision

Tue, 15 Sep 2026 22:21:47 +0200

Au départ, je voulais simplement savoir si mes machines allaient bien. Un peu de CPU, de mémoire, de stockage, quelques températures et une alerte quand quelque chose sortait des clous. Beszel répondait très bien à ce besoin.

Son interface était claire, l’installation rapide et, surtout, il était stable. Je pouvais l’ouvrir, prendre la température du homelab en quelques secondes et repartir faire autre chose. Pour un outil de supervision, cette discrétion est une vraie qualité.

Puis mon besoin a évolué en même temps que mon lab. Je ne voulais plus seulement savoir si une VM consommait trop de mémoire. Je voulais savoir si le service qui tournait dessus fonctionnait, si un conteneur avait redémarré, si une sauvegarde était récente, si un mail avait réellement effectué tout son trajet ou encore si les DNS répondaient correctement.

J’ai ajouté Pulse, essayé Checkmk (« bad idea :’) »), multiplié les tests et fini par arriver sur Zabbix. En quelques semaines, j’ai refait presque tout mon système de supervision.

Ce n’est pas l’histoire d’une succession de mauvais outils. C’est plutôt celle d’un besoin qui a grandi vite, porté par la curiosité, jusqu’au moment où maintenir plusieurs réponses partielles est devenu plus pénible que de reprendre le problème depuis le début.

Beszel faisait exactement ce que je lui demandais

J’ai beaucoup aimé Beszel pour sa simplicité et sa légèreté. Il remontait les métriques essentielles de mes machines et de mes conteneurs Docker sans transformer l’installation en projet à part entière. L’interface allait droit au but et je n’avais pas besoin de passer une soirée dans la documentation pour comprendre la mise en place ou l’exploitation.

Ce serait donc injuste de raconter que je l’ai abandonné parce qu’il était instable ou limité dans l’absolu. Il faisait bien son travail. Dans mon périmètre, il ne tenait plus ma cadence insatiable.

Une machine peut avoir 20 % de CPU, beaucoup de mémoire disponible et un disque presque vide tout en rendant un service parfaitement inutilisable. Le processus peut être arrêté. Le certificat peut avoir expiré. Le DNS peut répondre sans fournir la bonne donnée. Un serveur mail peut accepter une connexion SMTP sans être capable de livrer un message jusque dans la boîte de réception.

Je commençais donc à vouloir surveiller ce qui se passait dans les VM, pas seulement autour d’elles.

Pulse apportait de son côté une lecture pertinente de Proxmox et de son environnement. Là encore, le problème n’était pas la qualité des données. Le problème était que je venais d’ajouter un outil supplémentaire à installer, mettre à jour, sauvegarder et comprendre.

J’avais Beszel pour certaines ressources, Pulse pour une autre partie de l’infrastructure, Grafana pour mes dashboards et plusieurs sondes qui vivaient encore ailleurs. Chaque écran avait une raison d’exister. Leur addition commençait pourtant à raconter une histoire assez différente : pour comprendre un incident, il fallait déjà savoir quel outil ouvrir.

La friction qui a lancé la suite est venue de là. Je ne cherchais pas à collectionner les dashboards. Je voulais réduire le nombre de systèmes capables de décider qu’il y avait un problème.

Checkmk m’a montré ce qui me manquait

Je n’avais encore jamais vraiment utilisé Checkmk. C’était donc l’occasion de tester une solution plus large (et probablement sur-vendue), capable de découvrir une machine et de transformer automatiquement ce qu’elle expose en services supervisés.

La première impression a été plutôt bonne. L’agent et les modules fournis de base remontaient beaucoup de choses sans que j’aie à tout construire à la main. CPU, mémoire, disques, interfaces, services systemd, conteneurs Docker : je retrouvais enfin les ressources et les services dans la même plateforme.

C’est cette profondeur prête à l’emploi qui m’a convaincu : je pouvais partir d’une VM, descendre jusqu’à ses services et ajouter mes propres contrôles lorsque le standard ne suffisait plus.

J’ai ainsi intégré des sondes DNS, des contrôles Proxmox et plusieurs scénarios mail. Je ne voulais pas seulement vérifier que les ports 25 ou 993 étaient ouverts. Je voulais établir une session chiffrée, m’authentifier, envoyer un message identifié, le retrouver en IMAP, mesurer son délai et nettoyer la boîte après le test.

À ce moment-là, ma supervision commençait réellement à représenter le fonctionnement du homelab.

Elle a aussi commencé à faire du bruit. Les interfaces TAP éphémères de Proxmox disparaissaient, les jobs du runner provoquaient des pics de mémoire et certains seuils réagissaient à des variations sans conséquence. J’ai raconté séparément comment j’ai repris en main ces alertes Checkmk, car cette étape m’a appris une chose importante : collecter beaucoup d’informations ne suffit pas, il faut encore décider lesquelles méritent de m’interrompre.

Puis l’outil a commencé à me fatiguer

Plus je poussais Checkmk, plus son ergonomie me ralentissait. L’interface me donnait parfois l’impression d’avoir été dessinée par un maçon : tout était solide, mais il fallait connaître le plan du bâtiment pour retrouver la bonne porte.

La création de dashboards a été le point le plus visible. J’avais déjà Grafana, où je pouvais construire une vue exactement comme je l’imaginais. Dans Checkmk, obtenir une présentation sur mesure me demandait beaucoup plus d’efforts pour un résultat qui me convenait moins.

La performance a aussi pesé dans la balance. Sur ma VM équipée de quatre vCPU, l’expérience restait plus lourde que ce que j’attendais pour la taille de mon homelab. Les métriques étaient bien conservées, mais leur consultation et leur chargement me semblaient lents. Dans mon usage, les contrôles restaient essentiellement calés sur la cadence standard d’une minute, alors que j’avais déjà une collecte plus fine dans VictoriaMetrics pour alimenter Grafana.

Une partie de cette différence vient du découpage des éditions. Checkmk Community est bien entièrement open source, mais elle utilise le cœur Nagios. Le Checkmk Micro Core, plus efficace, ainsi que plusieurs fonctions avancées de graphes et de connexion aux bases de métriques externes appartiennent aux éditions commerciales.

Le SSO (Single Sign-On) a fini d’illustrer ce décalage. L’intégration SAML native est elle aussi commerciale. En Community, j’aurais dû ajouter une couche d’authentification Apache ou monter une intégration LDAP avec Authentik uniquement pour Checkmk.

Ce n’était pas impossible. C’était juste franchement pénible, en 2026, de réserver une simple connexion SSO aux versions payantes. Pour les ACL ou le RBAC, à la limite… mais la connexion ?

Je n’ai rien contre les logiciels payants. Je préfère même une proposition claire, gratuite ou payante, à une succession de limites qui apparaissent lorsque je commence à exploiter sérieusement l’outil. Avec Checkmk, j’avais choisi Community pour sa promesse open source, mais plusieurs améliorations qui répondaient précisément à mes frustrations me renvoyaient vers une autre édition.

J’ai donc profité de ce moment pour vérifier si un autre outil correspondait mieux à la direction prise par mon homelab.

Revenir à Zabbix, mais pas par nostalgie

Zabbix n’était pas une découverte totale. Je l’avais déjà utilisé auparavant pour du pro et je connaissais une partie de ses forces : une grosse communauté, beaucoup de modèles, une architecture éprouvée et une grande liberté pour construire des contrôles sur mesure.

Son Agent 2 a beaucoup compté dans mon choix. Il reprend les contrôles système classiques et ajoute une architecture de plugins pour des composants comme Docker, systemd, SMART ou différentes bases de données. Son empreinte restait raisonnable pour mes machines, surtout face à l’alternative qui consistait à multiplier les agents spécialisés.

Surtout, Zabbix me laissait plusieurs chemins pour une même donnée : agent actif, requête HTTP, SNMP, élément dépendant, découverte bas niveau, script externe ou UserParameter. Cette variété peut rendre la prise en main dense, mais elle correspond bien à ma manière de travailler. Si un contrôle n’existe pas, je peux le construire, le versionner et le rattacher au même hôte que le reste de sa supervision.

La plateforme reste open source sous licence AGPL. Je pouvais utiliser le SSO SAML, ajuster la rétention et créer mes modèles sans changer d’édition. Grafana gardait son rôle de cockpit : VictoriaMetrics alimentait les vues d’infrastructure, et Zabbix Agent 2 lui fournissait les métriques des conteneurs sans ajouter cAdvisor.

Sur le papier, le choix était séduisant. Il restait à prouver que Zabbix pouvait reprendre les contrôles qui rendaient Checkmk réellement utile chez moi.

Une migration en parallèle

J’ai fait fonctionner Zabbix et Checkmk en parallèle le temps de reprendre les contrôles indispensables : Proxmox, Docker, systemd, OPNsense, DNS et les boucles mail. Une fois la couverture et les notifications vérifiées, Zabbix est devenu la plateforme de référence le 13 août 2026 et les agents Checkmk ont été retirés progressivement. J’ai conservé une sauvegarde protégée de la VM Checkmk pour pouvoir revenir en arrière si nécessaire.

Ce que cette migration a réellement changé

Aujourd’hui, je n’attends pas d’un seul outil qu’il fasse tout.

Grafana reste mon premier écran lorsque je veux prendre la température du homelab. Ses dashboards sont directs, visuels et construits autour de mes questions. Zabbix collecte les états, découvre les services et décide quand une anomalie devient un problème. Argus récupère dans Zabbix les versions réellement déployées. Plus récemment, CairnOps est venu ajouter une couche d’hypervision en utilisant Zabbix comme source.

Je sais désormais où regarder une tendance, où chercher un événement et quel système porte la décision d’alerter. Ajouter un outil reste possible, mais seulement s’il possède un rôle qui n’existe pas déjà ailleurs.

Beszel m’a rappelé la valeur d’une supervision simple. Checkmk m’a montré l’intérêt de descendre jusqu’aux services et aux contrôles métier. Zabbix m’a finalement donné la souplesse nécessaire pour réunir ces besoins sans abandonner les outils spécialisés qui fonctionnaient déjà bien.

Dans les prochains articles, je ferai le tour de cette architecture actuelle : Grafana comme cockpit, Zabbix derrière les alertes, puis les outils qui gravitent autour, notamment Argus, Uptime Kuma, LogChef et PatchMon. CairnOps aura droit à son propre récit, parce que son arrivée commence déjà à changer ma manière de lire l’état global du homelab.

J’ai enfin activé Hyperscan sur mes deux OPNsense

Mon, 24 Aug 2026 15:20:00 +0200

Tout est parti d’un article publié sur le blog de Suricata : Faster Suricata startups with Hyperscan caching.

Le sujet était le cache MPM (Multi-Pattern Matching) introduit avec Suricata 8. Au lieu de recompiler toutes les bases de motifs Hyperscan à chaque démarrage ou rechargement des règles, Suricata peut les conserver sur disque et les réutiliser. L’article annonçait un temps de démarrage réduit jusqu’à 50 %.

En le lisant, je me suis surtout posé une question beaucoup plus basique : est-ce qu’Hyperscan tournait réellement sur mes firewalls ?

La réponse était non.

Suricata fonctionnait déjà sur mes deux OPNsense, les événements remontaient bien dans VictoriaLogs et mon cluster HA faisait son travail. Mais le moteur de recherche de motifs capable de profiter des instructions vectorielles du processeur n’était pas actif.

Le verrou ne se trouvait pas vraiment dans Suricata. Mes deux VM utilisaient encore le modèle de CPU générique kvm64, pratique pour la compatibilité, mais trop conservateur pour exposer les instructions que je voulais utiliser. Avant de jouer avec le cache, il fallait donc commencer par activer le moteur lui-même.

Donner le bon CPU virtuel à Suricata

J’ai passé fw-core-p1 et fw-core-p2 en x86-64-v3. FreeBSD voyait alors correctement AVX2, AES et FMA, et je pouvais enfin demander explicitement Hyperscan à Suricata :

1
2
3


cpu {
 type = "x86-64-v3"
}

1

opnsense_ids_mpm_algo: "hs"

Le hs sélectionne Hyperscan comme moteur MPM. C’est la partie de Suricata qui cherche plusieurs motifs à la fois dans le trafic et écarte rapidement les signatures qui ne peuvent pas correspondre. La documentation OPNsense le présente d’ailleurs comme le meilleur choix sur les plateformes compatibles.

Le changement posait tout de même une question importante : mes hôtes Proxmox mélangent des processeurs Intel et AMD. J’ai donc fait migrer une VM de test d’Intel vers AMD, puis de nouveau vers Intel, avant de considérer x86-64-v3 comme un socle suffisamment portable chez moi.

Je n’ai pas touché aux règles de placement HA. Les deux firewalls restent volontairement séparés sur deux hôtes différents.

Le test qui comptait vraiment

Voir mpm-algo = hs sur les deux nœuds était une bonne nouvelle, mais cela ne disait encore rien sur le comportement du cluster pendant une vraie bascule.

J’ai donc laissé p2 reprendre les neuf VIP CARP. Pendant qu’il était MASTER avec Hyperscan actif, la sortie Internet continuait de fonctionner. Je n’ai observé aucune perte de paquets pendant le failover, avec une latence maximale de 13 ms.

Après le test, la situation normale était revenue : p1 MASTER, p2 BACKUP et neuf VIP au bon endroit. Le moteur de détection avait changé sans perturber le cluster.

Seize heures plus tard

Le premier contrôle montrait déjà Suricata autour de 356 à 359 Mio de mémoire, contre environ 548 Mio auparavant. J’ai laissé tourner avant de regarder de nouveau les compteurs.

Mesure	Après environ 16 heures
CPU Suricata	0 à 0,1 % sur les deux nœuds
Mémoire sur P1	233 Mio, soit −57,5 % par rapport au repère de 548 Mio
Mémoire sur P2	356 Mio, stable depuis le premier contrôle
Capture sur P1	51 044 239 paquets, 4 669 drops, soit 0,0091 %
Capture sur P2	1 078 301 paquets, aucun drop
Événements TLS	22 056 événements centralisés dans VictoriaLogs

Les 4 669 drops de capture observés sur p1 n’avaient pas augmenté depuis plus de deux heures lors du dernier relevé. Aucun drop Suricata n’apparaissait dans les échantillons contrôlés et la qualité de capture restait supérieure à 99,99 %.

Surtout, l’enrichissement n’avait pas disparu au passage : 926 SNI, 370 empreintes JA4, 55 empreintes de certificats et 23 émetteurs distincts remontaient toujours dans VictoriaLogs.

Ce n’est pas un benchmark. p1 et p2 n’ont ni le même rôle ni le même volume de trafic, et je ne vais pas attribuer toute la baisse à une seule option. La tendance observée reste néanmoins assez nette : CPU négligeable, mémoire en baisse et aucune dégradation visible de la détection ou du failover.

La configuration est maintenant décrite dans Terraform et Ansible. Le plan Terraform ne montrait aucun drift, le second passage Ansible terminait avec changed=0, et les sept tests du rôle passaient avec le syntax-check et ansible-lint.

Assez ironiquement, un article consacré au cache m’aura d’abord fait découvrir que je n’utilisais même pas le moteur. Le cache pourra venir ensuite. Pour l’instant, Hyperscan tourne enfin sur mes deux firewalls — et c’était déjà le vrai chantier.

Je voulais juste mettre à jour mes OPNsense

Sat, 15 Aug 2026 20:00:00 +0200

J’étais parti pour une petite révision tranquille de mes deux OPNsense. Une sauvegarde, une mise à jour du premier firewall, quelques contrôles, puis la même chose sur le second.

Le premier venait de terminer. J’ai lancé la mise à jour du second, puis contrôlé l’état du cluster pendant qu’elle avançait.

Un cluster qui fonctionnait… presque

Mon réseau repose sur deux firewalls, fw-core-p1 et fw-core-p2, avec neuf adresses IP virtuelles CARP. En temps normal, p1 porte les neuf VIP et p2 attend sagement en secours.

Après la mise à jour du premier nœud, l’état était un peu plus créatif :

1
2


8 VIP : p1 BACKUP / p2 MASTER
VIP LAN : p1 MASTER / p2 MASTER

Le réseau fonctionnait encore. Les interfaces répondaient, pfsync synchronisait toujours les connexions et rien ne semblait cassé à la maison. Mais la VIP du LAN était portée par les deux firewalls en même temps.

C’était le genre de problème assez discret pour passer inaperçu, jusqu’au jour où il décide de ne plus l’être.

Je n’ai rien tenté au milieu de l’opération. p1 a repris les neuf VIP avant le redémarrage du second, puis j’ai simplement surveillé le trafic jusqu’à son retour. Quelques minutes plus tard, les deux nœuds étaient bien en OPNsense 26.7.2_2 sur FreeBSD 15.1 et tous les services répondaient.

La mise à jour était terminée. Restait à comprendre ce petit double-MASTER.

P2 discutait avec lui-même

Le CARP du LAN utilisait l’unicast. Chaque firewall devait envoyer ses annonces directement à l’adresse réelle de l’autre :

1
2


P1 devait cibler 10.0.0.3
P2 devait cibler 10.0.0.2

Dans la configuration réelle, les deux ciblaient 10.0.0.3.

Pour p1, c’était correct. Pour p2, beaucoup moins : il envoyait ses annonces CARP à sa propre adresse.

Le plus amusant, c’est que la synchronisation HA faisait exactement ce que je lui demandais. p1 copiait sa configuration vers p2, y compris ce pair unicast qui aurait justement dû être différent sur chaque machine. Corriger uniquement le second nœud n’aurait servi à rien : la synchronisation suivante aurait remis la mauvaise valeur.

Mes huit autres VIP fonctionnaient déjà avec le multicast CARP classique. J’ai donc vérifié que les annonces envoyées vers 224.0.0.18 traversaient bien le bridge Proxmox et arrivaient sur p2. C’était le cas.

J’ai supprimé le pair unicast du LAN et laissé CARP revenir à son fonctionnement normal :

1
2
3


P1 ─┐
 ├── 224.0.0.18
P2 ─┘

Cette fois, les deux firewalls pouvaient partager exactement la même configuration sans que l’un d’eux finisse par se parler à lui-même.

Le petit test qui évite les grandes suppositions

Une fois la correction appliquée, j’ai placé p1 en maintenance. p2 a repris les neuf VIP, le DNS a continué de répondre et mes routes applicatives sont restées accessibles. En quittant le mode maintenance, p1 est redevenu MASTER par préemption et p2 est retourné en BACKUP.

1
2
3
4


fw-core-p1 : MASTER 9/9
fw-core-p2 : BACKUP 9/9
demotion : 0
pfsync : synchronisé

Au final, la mise à jour vers la série OPNsense 26.7 s’est passée sans incident. Elle m’a surtout donné une bonne excuse pour regarder un peu plus loin que le voyant vert.

Je voulais faire une petite révision. J’ai retiré une adresse dans un champ, relancé un vrai failover et mon cluster est maintenant plus simple qu’avant.

C’est déjà pas mal pour une matinée de maintenance.

J’allais ajouter un nœud Ceph. Mes backups partaient en même temps

Fri, 14 Aug 2026 12:40:31 +0200

Toutes les deux heures, mon cluster Ceph avait un petit passage à vide. Les VM devenaient moins réactives, les latences grimpaient et BlueStore finissait parfois par signaler des opérations lentes.

Ma première question a été assez classique : est-ce que le scheduler mClock était mal adapté à mon petit cluster ? Un retour à WPQ pouvait-il arranger les choses ? Et si le problème venait simplement du fait que trois nœuds et trois OSD ne suffisaient plus, fallait-il ajouter un quatrième PVE ?

Cette dernière option ne m’enchantait pas. Un nœud supplémentaire aurait apporté de la capacité et réparti la charge, mais aussi un nouveau coût pour corriger un problème que je ne comprenais pas encore.

J’ai donc commencé par regarder ce qui se passait réellement au moment des ralentissements. Le coupable n’était pas caché dans un obscur réglage Ceph : mes trois sauvegardes Proxmox Backup Server partaient exactement en même temps.

Avec trois OSD, le plus lent donne le tempo

Mon cluster repose sur trois nœuds Proxmox et un OSD NVMe par nœud :

Nœud	OSD	SSD
`pve-forum`	`osd.0`	WD Black SN770 2 To
`pve-dell`	`osd.1`	Crucial P310 2 To
`pve-fuji`	`osd.2`	Crucial P3 Plus 2 To

Le pool des VM utilise une réplication par trois. Chaque écriture doit donc être confirmée par les trois OSD. Ce choix me donne la tolérance aux pannes que je veux, mais il transforme naturellement le disque le plus lent en limite commune.

Le cluster n’était pourtant ni plein ni déséquilibré. Au moment du diagnostic, il était occupé à environ 33 %, ses 129 groupes de placement étaient active+clean et aucun recovery n’avait eu lieu durant les trente jours observés. Le réseau Ceph en 2,5 Gb/s ne montrait pas non plus d’erreurs ni de pertes.

En revanche, les latences maximales des OSD racontaient une tout autre histoire :

OSD	Latence commit maximale sur 30 jours
`osd.0`	3,2 s
`osd.1`	567 ms
`osd.2`	9,5 s

Le Crucial P3 Plus de pve-fuji était le plus préoccupant sur la durée, tandis que l’alerte active pouvait très bien pointer ponctuellement vers le WD de pve-forum. Ce n’était pas un OSD isolé qui souffrait en permanence : les trois SSD grand public encaissaient mal certaines rafales de petites écritures synchrones.

WPQ était une piste séduisante, mais pas la bonne

Le cluster utilisait déjà mClock avec son profil balanced. J’ai envisagé de repasser à la Weighted Priority Queue (WPQ), l’ancien scheduler, parce que le changement est souvent cité lorsque l’on cherche à réduire des latences Ceph.

Le souci, c’est que mon cluster n’était pas en train de faire du recovery ou du backfill. Les profils mClock savent répartir les ressources entre les opérations clientes, la récupération et les travaux de fond. Ici, les écritures des VM et celles provoquées par leurs sauvegardes appartenaient toutes à la même famille : des opérations clientes.

Passer à high_client_ops n’aurait donc pas appris à Ceph à préférer une VM interactive à sa propre sauvegarde. Revenir à WPQ aurait surtout changé la façon d’ordonner une saturation que je continuais à provoquer moi-même.

La documentation mClock de Ceph recommande d’ailleurs de rester prudent avec les réglages de bas niveau. Avant d’ajuster le scheduler, il fallait d’abord vérifier ce que je lui demandais d’absorber.

Le graphique qui revenait toutes les deux heures

Mon job PBS global était configuré toutes les deux heures, sans limite de bande passante. À chaque déclenchement, les sauvegardes des VM hébergées sur les trois nœuds partaient en parallèle : lecture des disques Ceph, création des snapshots et envoi vers PBS.

La corrélation avec les lenteurs était difficile à ignorer. Sur les 48 heures examinées :

les 563 événements aio_submit retries étaient tous apparus dans les trente minutes suivant le départ d’un backup ;
800 des 1 138 avertissements BlueStore étaient concentrés dans cette même fenêtre ;
les files NVMe avaient atteint une profondeur de 47 sur pve-forum et de 20 sur pve-fuji pendant un incident.

Ceph ne manquait pas de capacité. Il recevait simplement, à intervalles réguliers, trois grosses tapes sur l’épaule au même moment 😂.

Un quatrième PVE aurait probablement réduit la charge moyenne de chaque OSD. Il aurait aussi augmenté la capacité brute et les performances agrégées. Mais il n’aurait pas rendu raisonnables trois sauvegardes illimitées lancées ensemble. J’aurais payé du matériel pour mieux encaisser une mauvaise planification.

Quarante minutes entre chaque sauvegarde

J’ai remplacé le job global par trois jobs liés chacun à un nœud. Ils restent exécutés toutes les deux heures, mais avec quarante minutes d’écart :

Nœud	Horaire
`pve-forum`	heures paires à `:00`
`pve-dell`	heures paires à `:40`
`pve-fuji`	heures impaires à `:20`

Dans la syntaxe du planificateur Proxmox, cela donne :

1
2
3


pve-forum */2:00
pve-dell */2:40
pve-fuji 1/2:20

J’ai ajouté la même limite à chaque job :

1

bwlimit: 102400

La valeur est exprimée en Kio/s, soit 100 Mio/s. Le but n’était pas de rendre les sauvegardes artificiellement lentes, mais de leur laisser assez de débit sans leur permettre de prendre tout ce que les OSD pouvaient fournir pendant une pointe.

Je n’ai modifié ni la destination PBS, ni le mode snapshot, ni les exclusions existantes. Ce petit périmètre était important : une seule hypothèse changeait à la fois, donc le résultat restait lisible.

Le PoC a calmé la pointe, pas effacé le problème

Après avoir vérifié qu’aucun backup n’était encore actif, j’ai lancé manuellement le nouveau job de pve-dell. La sauvegarde complète s’est terminée en 43 secondes, avec des transferts ramenés autour de 80 à 104 Mio/s.

Sur ce passage, les logs ont compté cinq retries AIO, contre 22 pendant la fenêtre globale précédente. La latence commit Ceph a culminé à 47 ms, puis les 129 groupes de placement sont restés active+clean.

Cette comparaison reste indicative. Le PoC était fortement dédupliqué et un seul passage ne remplace pas plusieurs jours de métriques. Il a toutefois validé deux points utiles : le plafond était réellement appliqué et l’étalement réduisait déjà la violence de la pointe.

Le cluster n’est pas devenu parfait pour autant. Ceph continue ponctuellement de remonter un HEALTH_WARN pour des opérations BlueStore lentes. Les trois OSD sont toujours des SSD grand public sans protection contre les coupures de courant, et le P3 Plus en QLC reste le maillon qui m’inspire le moins confiance sous charge soutenue. La documentation matérielle de Ceph rappelle justement que les SSD clients peuvent voir leurs performances s’effondrer une fois leur cache épuisé, là où les modèles entreprise apportent notamment la protection contre les pertes d’alimentation.

Au moment où j’écris ces lignes, je prévois donc encore de remplacer progressivement les deux SSD les plus irréguliers, en commençant par celui de pve-fuji. Mais ce sera une amélioration matérielle posée sur une charge déjà mieux organisée, pas un achat destiné à masquer le symptôme.

Ce que j’en retiens

Je suis parti d’une question sur WPQ et de l’idée, un peu coûteuse, d’ajouter un quatrième nœud. La première amélioration utile a finalement tenu dans trois horaires et une limite de débit.

Le plus intéressant n’est pas que 100 Mio/s soit une valeur magique — elle ne l’est pas. C’est d’avoir trouvé le rythme réel du problème avant de toucher au scheduler ou au matériel. Les ralentissements revenaient toutes les deux heures parce que mes backups revenaient toutes les deux heures. Une fois la corrélation posée noir sur blanc, la solution est devenue beaucoup moins mystérieuse.

Pour ceux qui se demandent déjà vers quoi je compte me tourner, je remplacerais progressivement les SSD concernés par des Samsung 990 PRO 2 To, référence MZ-V9P2T0BW. Cela reste du matériel grand public, pas l’équivalent d’un NVMe datacenter avec protection contre les coupures, mais c’est le compromis que je retiendrais aujourd’hui pour mon homelab.

Je vais maintenant laisser tourner cette configuration, comparer plusieurs fenêtres de sauvegarde et observer si les futurs SSD changent encore le profil des latences. Le quatrième PVE, lui, peut rester pour l’instant dans la boutique.

Le script que j’en avais marre de lancer : la naissance de WarpgateSH

Tue, 11 Aug 2026 11:57:53 +0200

Au travail, j’utilise Teleport. Les accès sont là quand j’en ai besoin, l’expérience est fluide et je n’ai pas à réfléchir au fichier SSH qui se cache derrière. À force de profiter de ce confort, une question a commencé à me trotter dans la tête : pourquoi est-ce que je n’avais pas quelque chose d’aussi naturel dans mon homelab ?

Chez moi, Warpgate faisait déjà très bien la partie importante du travail. Il filtrait les accès à mes serveurs, s’intégrait à Authentik pour le SSO (Single Sign-On) et me permettait de gérer précisément qui pouvait atteindre quoi. Je ne cherchais pas un énième jump host ni une énorme plateforme. Je voulais quelque chose de simple, avec juste assez de contrôle pour mon usage.

Le petit caillou dans la chaussure se trouvait sur mon Mac.

Le script qui fonctionnait… quand je pensais à le lancer

J’avais écrit un script capable d’interroger Warpgate et de générer les alias nécessaires dans ma configuration SSH. Une fois exécuté, le résultat était exactement celui que je voulais :

1

ssh dmz-nextcloud-01

La même cible fonctionnait aussi dans scp, rsync, Ansible et les autres outils qui savent parler à OpenSSH. Sur le papier, le problème était réglé.

Dans la vraie vie, il restait une étape assez importante : il fallait penser à lancer le script.

Quand une machine apparaissait dans Warpgate, elle n’apparaissait pas magiquement sur mon poste. Quand les accès évoluaient, mon fichier local ne suivait pas tout seul. J’avais automatisé la génération, mais pas le moment où elle devait se produire. C’était pas ouf.

C’est cette petite friction, répétée suffisamment souvent, qui a déclenché le projet. Je ne voulais plus d’une commande supplémentaire à retenir après chaque changement d’infrastructure. Je voulais que Warpgate reste la source de vérité et que mon Mac suive naturellement.

Teleport m’a donné l’idée, Warpgate lui a donné sa forme

Mon expérience de Teleport au travail m’a montré à quel point une CLI capable d’interagir directement avec le serveur pouvait rendre les accès beaucoup plus fluides. Je ne voulais pourtant pas reproduire Teleport fonctionnalité par fonctionnalité. Le contexte n’était pas le même et mon besoin était beaucoup plus modeste.

Pour mon homelab, j’avais choisi Warpgate plutôt que Teleport Community Edition. La première raison était simple : Warpgate est entièrement open source. Il s’intégrait également très bien avec mon Authentik existant, sans m’obliger à revoir toute mon architecture d’authentification.

Surtout, son périmètre correspondait à ce que je cherchais. Je voulais filtrer les connexions, gérer les autorisations avec suffisamment de granularité et ajouter une couche de contrôle devant les serveurs, tout en gardant quelque chose que je pouvais comprendre et exploiter tranquillement pendant mon temps libre.

Petit shout-out, donc, au projet Warpgate et à ses mainteneurs. WarpgateSH existe parce que leur outil m’a donné une base suffisamment agréable pour avoir envie de prolonger l’expérience jusque sur le poste utilisateur.

D’abord une idée, puis beaucoup de questions

Au début, j’imaginais presque un petit utilitaire : récupérer les cibles autorisées, écrire un fichier SSH et passer à autre chose. Évidemment, le projet a commencé à poser des questions dès que j’ai essayé de lui donner une forme sérieuse.

Est-ce que la CLI devait être le produit principal ou seulement un complément à une application macOS ? Fallait-il gérer plusieurs instances Warpgate ? Que faire si une synchronisation échouait ? Comment conserver des alias agréables sans écraser une entrée déjà présente dans mon fichier SSH ? Et comment éviter de concevoir quelque chose de tellement lié à mon homelab que personne d’autre ne pourrait l’utiliser ?

Je n’avais pas de calendrier à tenir. Le vrai défi était là : prendre le temps de réfléchir à l’architecture avant de transformer mon premier script en un second script, simplement plus joli.

Une décision s’est imposée assez vite. La CLI resterait l’interface principale, et l’application graphique viendrait l’accompagner. Même avec toutes les fenêtres du monde fermées, je devais toujours pouvoir taper :

1

ssh une-cible

OpenSSH continuerait donc d’établir les connexions. WarpgateSH se contenterait de maintenir les informations locales à jour en arrière-plan. Cette séparation correspondait bien à mon objectif : améliorer mon quotidien sans remplacer les outils qui fonctionnaient déjà.

Rust sur macOS, avec Linux dans un coin de la tête

Le choix de la technologie a été l’autre gros morceau de réflexion. J’ai une petite affinité avec Rust, et ce projet lui allait plutôt bien : une CLI, un agent qui tourne en arrière-plan, des fichiers à manipuler proprement et l’envie d’obtenir un binaire solide.

Rust me donnait aussi une base portable. Je voulais commencer sur macOS, parce que c’est mon poste quotidien et le meilleur endroit pour éprouver réellement l’outil. Mais j’affectionne également Linux et je ne voulais pas découvrir dans six mois que toute l’architecture dépendait d’un détail impossible à transposer.

Le cœur, la CLI et l’agent sont donc écrits en Rust. Pour le compagnon graphique, j’ai choisi Tauri avec React. Cela me permet de construire une application légère pour macOS sans fermer la porte à une version Linux plus tard.

Il y a eu des tâtonnements, bien sûr. Le nom provisoire warpctl était déjà utilisé ailleurs. wsh, que je trouvais pratique, entrait lui aussi en collision avec d’autres outils. Le projet a fini par devenir WarpgateSH, avec la commande warpgatesh. Un peu plus long à taper, mais beaucoup plus simple à retrouver sur GitHub — et nettement moins susceptible de marcher sur les plates-bandes du voisin.

Le moment où le prototype est devenu réel

Le vrai déclic n’est pas arrivé pendant une discussion d’architecture ni devant une suite de tests verte.

Il est arrivé lorsque j’ai créé un jeton personnel depuis l’interface de Warpgate, que je l’ai donné au prototype et que la liste de mes serveurs est apparue. Les 41 cibles associées à mon compte étaient là, récupérées directement depuis Warpgate, sans utiliser le compte administrateur et sans relancer mon ancien script.

À ce moment-là, l’idée avait enfin dépassé le stade du README.

J’ai pu lancer une connexion avec la CLI :

1

warpgatesh dmz-nextcloud-01

Puis avec OpenSSH, exactement comme avant :

1

ssh dmz-nextcloud-01

C’était le résultat que je cherchais depuis le début. Warpgate gérait les accès, l’agent synchronisait les changements et mes habitudes dans le terminal ne bougeaient pas d’un millimètre.

Le compagnon macOS a ajouté le dernier morceau visible. Je pouvais voir l’état de l’agent, rechercher une cible, lancer une connexion et observer les actualisations sans revenir au terminal. Voir la liste évoluer dans l’interface pendant que l’agent travaillait en arrière-plan a rendu le projet beaucoup plus concret. Ce n’était plus seulement un outil que je développais : c’était déjà quelque chose que je pouvais utiliser.

Le résultat, pour l’instant

WarpgateSH n’est pas encore une application grand public parfaitement emballée. La distribution macOS, la signature pour les autres utilisateurs et les derniers détails du compagnon demandent encore du travail. Linux viendra ensuite, après une vraie période d’utilisation quotidienne sur mon Mac.

Mais la promesse initiale est déjà tenue : je n’ai plus besoin de lancer manuellement mon script pour retrouver les accès Warpgate sur mon poste. Je peux utiliser la CLI quand j’en ai envie, rester avec OpenSSH quand je préfère, et consulter l’application lorsque j’ai besoin d’une vue plus visuelle.

Le plus amusant, c’est que tout est parti d’une tâche qui prenait seulement quelques secondes. Lancer un script n’était pas un drame. C’était simplement le genre de petite corvée qui finit par rappeler, à chaque répétition, qu’elle ne devrait probablement plus exister.

Le projet est public et disponible ici : github.com/M0okz/warpgatesh.

Si WarpgateSH peut éviter à d’autres utilisateurs de maintenir leurs alias SSH à la main, le petit agacement de départ aura finalement servi à quelque chose.

À l’occasion, j’essaierai de vous faire un petit billet sur mon « flow » complet : du déploiement d’une ressource dans mon homelab jusqu’à la première connexion au serveur.

Authentik, la porte d’entrée de mon homelab — et le ménage qui lui manquait

Fri, 31 Jul 2026 15:06:16 +0200

Je voulais gagner quelques millisecondes sur mes connexions. En ouvrant la VM d’Authentik, j’ai surtout trouvé un petit musée de son histoire : un conteneur Redis devenu inutile, deux fichiers d’environnement presque identiques et des images Docker accumulées.

Comme le service tournait bien, j’avais laissé cette sédimentation vivre tranquillement. Pas idéal pour celui qui garde la porte de presque tout mon homelab. Cette maintenance était donc l’occasion de faire le ménage, mais aussi de présenter enfin Authentik sur ce blog.

Bien plus qu’une jolie page de connexion

SSO signifie Single Sign-On, ou authentification unique. Le raccourci habituel consiste à dire : « un seul compte pour toutes mes applications ». C’est vrai, mais ce n’est pas le point le plus important.

Une application raccordée à Authentik ne reçoit pas mon mot de passe. Elle délègue l’authentification à un fournisseur d’identité — un Identity Provider ou IdP — puis fait confiance au jeton ou à l’assertion qu’il lui retourne. Je peux donc centraliser la double authentification, les groupes, les règles d’accès et le cycle de vie des comptes sans recopier la même logique dans chaque service.

Au 31 juillet 2026, mon instance contient 21 applications. La majorité utilise OpenID Connect (OIDC), notamment GitLab, Grafana, Warpgate, Technitium et PatchMon. Wazuh passe par SAML. Pour OpenVSCode, qui n’a pas le même raccordement natif, nginx demande directement à l’outpost Proxy d’Authentik si la requête peut continuer.

Cette souplesse est l’une des raisons pour lesquelles Authentik s’est imposé chez moi. Je privilégie OIDC lorsqu’il est disponible, SAML lorsque l’application l’impose et le provider Proxy pour les services qui ne savent rien faire de tout cela.

1
2
3
4
5


GitLab ─────────────── OIDC ──────┐
Grafana ────────────── OIDC ──────┤
Warpgate ───────────── OIDC ──────┤
Wazuh ──────────────── SAML ──────┼──> Authentik ──> identité, MFA, groupes
OpenVSCode ── nginx / forward auth ┘

Le confort est évident : une seule session ouvre plusieurs outils et je n’administre plus une collection de comptes locaux oubliés. Le revers l’est tout autant : Authentik est devenu une dépendance critique. Une panne n’arrête pas forcément les sessions déjà ouvertes, mais elle peut bloquer toute nouvelle connexion. Une compromission aurait, elle, un rayon d’action particulièrement généreux.

Je le traite donc comme une brique de sécurité, pas comme un tableau de bord de plus.

Pourquoi Authentik plutôt que Keycloak ?

J’ai longtemps hésité avec Keycloak. Il avait pour lui l’ancienneté, une documentation abondante et un écosystème déjà installé. Son dépôt public remonte à 2013, alors que le premier commit d’Authentik date de 2018.

Choisir Authentik revenait donc à miser sur le plus jeune. Son interface et ses flows me parlaient davantage, son proxy intégré convenait bien au mélange d’applications modernes et de vieux services de mon homelab, et je me sentais plus à l’aise avec un cœur Python/Django qu’avec une JVM.

Ce n’est pas un verdict contre Java : Keycloak fonctionne sur Quarkus et propose un build optimisé. Authentik n’est pas spécialement léger non plus avec son serveur, son worker, PostgreSQL et ses éventuels outposts. Mon choix était surtout pratique : lequel aurais-je envie de comprendre et de dépanner pendant plusieurs années ? Pour moi, la réponse était Authentik.

Un projet qui a mûri

Les premières versions que j’ai suivies demandaient davantage de prudence : migrations sensibles, interface mouvante et notes de version à lire religieusement. Depuis la création d’Authentik Security en 2022, le projet a changé d’échelle et adopté un modèle open core, avec les protocoles essentiels toujours disponibles dans l’édition open source.

Au 31 juillet 2026, le dépôt GitHub affichait 22 563 étoiles et une activité le jour même. La version 2026.5.6 datait du 22 juillet. Ces chiffres ne prouvent pas la qualité du logiciel, mais ils confirment un développement suivi. Après plusieurs années de mises à jour, c’est surtout cette continuité qui me rassure.

Redis était parti, mon Compose ne le savait pas

Authentik a déplacé ses tâches vers PostgreSQL en 2025.8, puis le cache, les sessions Proxy et les WebSockets en 2025.10. Redis pouvait disparaître. Mon ancien Compose continuait pourtant à lancer ce quatrième conteneur, presque inactif mais toujours présent dans les dépendances et les variables d’environnement.

L’architecture actuelle repose sur trois rôles : PostgreSQL conserve les données, le serveur traite les requêtes et le worker s’occupe des tâches asynchrones. Les notes de version 2025.10 préviennent toutefois que PostgreSQL reçoit environ 50 % de connexions supplémentaires. J’ai supprimé une dépendance, pas sa charge de travail.

Après le ménage, la liste des services est devenue très lisible :

1
2
3
4


$ docker compose -f /opt/authentik/docker-compose.yml config --services
postgresql
server
worker

J’en ai profité pour fusionner .env et authentik.env, retirer les variables Redis, ajouter le montage /data et porter la mémoire partagée du serveur et du worker à 512 Mio. Avant le déploiement Ansible, j’ai vérifié la sauvegarde Proxmox Backup Server et la lisibilité d’un dump PostgreSQL. Le second passage du playbook n’a produit aucun changement.

Les logs avaient aussi besoin d’une limite

La VM ne dispose que d’un disque de 20 Gio. Avant l’intervention, 13 Gio étaient occupés et le stack produisait environ 19 000 lignes de logs par jour sans aucune rotation.

J’ai conservé le pilote json-file. Vector consomme l’API de logs Docker et Wazuh lit les fichiers JSON ; changer de pilote aurait donc cassé silencieusement une partie de l’observabilité. En revanche, chaque conteneur possède maintenant une rotation bornée :

1
2
3
4
5


logging:
 driver: json-file
 options:
 max-size: "20m"
 max-file: "5"

Après inventaire des images actives et nettoyage des seules images inutilisées, l’occupation est passée de 13 Gio à 4,6 Gio : environ 8,4 Gio récupérés, sans toucher aux volumes.

Le vrai goulot n’était pas Docker

J’étais venu chercher quelques millisecondes dans le bridge Docker. Il n’en ajoutait que 0,1 à 0,2, tandis que la route publique répondait autour de 152 ms. Passer en mode host aurait surtout échangé de l’isolation contre un gain invisible.

La piste utile se trouvait un étage plus bas. La VM tournait sur pve-fuji, un nœud Intel déjà chargé, avec parfois 5 à 8 % de temps CPU volé. Je l’ai migrée à chaud vers pve-forum, un nœud AMD plus disponible. La latence a immédiatement chuté… puis la VM a perdu le réseau avant de se figer. À cet instant, mon petit benchmark venait de se transformer en exercice de reprise.

Après retour sur pve-fuji et redémarrage forcé, PostgreSQL et les trois conteneurs sont repartis sans perte. La bonne méthode était une migration à froid : arrêt propre par Proxmox HA, déplacement de la VM éteinte, puis redémarrage sur pve-forum. L’interruption a duré environ 2 min 40.

Étape	Route publique moyenne observée
état initial sur `pve-fuji`	151,6 ms
Compose modernisé, retour sur `pve-fuji`	105,8 ms
migration à froid vers `pve-forum`	68,9 ms

Ces mesures appartiennent à mon environnement, pas à un benchmark universel d’Authentik. Elles montrent surtout que le placement de la VM pesait bien plus que le réseau Docker — rien de très surprenant dans mon homelab bricolé de toutes pièces :D

Une première porte ouverte

Ce billet n’avait pas vocation à devenir un guide d’Authentik. Mon blog vient de démarrer et je n’avais encore jamais présenté le service qui protège pourtant 21 de mes applications. Cette maintenance était simplement la bonne occasion de lui ouvrir la porte.

Je reviendrai dans un autre article sur mon organisation autour d’Authentik : les flows, les groupes, la double authentification, le raccordement des applications et les cas où j’utilise le proxy plutôt qu’OIDC ou SAML. Pour cette fois, je voulais simplement raconter comment un conteneur Redis devenu inutile m’a donné le prétexte de présenter le gardien de mon homelab.

12 Mo de SQLite, 28 Go d’écritures par jour : le piège des Query Logs de Technitium

Thu, 30 Jul 2026 11:00:00 +0200

Ma VM DNS écrivait près de 28 Go par jour sur Ceph. Avec un tel chiffre, je m’attendais à trouver un volume anormal de requêtes, un service bavard ou un buffer Vector qui débordait.

La réalité tenait dans une base SQLite de 12 Mo.

trust-dns-01 résout environ deux à trois requêtes par seconde. Ce n’est ni une attaque ni une charge impressionnante. Pourtant, le stockage travaillait suffisamment pour que la VM passe bien plus de temps à attendre ses entrées-sorties qu’à calculer.

Le DNS n’était pas débordé

Le 30 juillet 2026, j’ai repris les métriques sur les dernières 24 heures et l’état réel de la machine :

Mesure	Valeur observée
trafic DNS	environ 2,5 requêtes/s
CPU actif, hors attente I/O	6,3 % en moyenne
attente I/O (iowait)	29,1 % en moyenne
données écrites sur le disque	27,89 Go en 24 h
occupation du disque	8,8 Go sur 20 Go

La nuance entre CPU actif et iowait est importante. Un graphique calculé simplement comme 100 - idle donne l’impression que le processeur est occupé à 35 %. En réalité, sur cette VM limitée à un vCPU, près de 29 points correspondent au temps passé à attendre le stockage.

Le serveur DNS lui-même ne manque donc pas de puissance. Il attend surtout Ceph.

Une petite base qui réécrit sans arrêt

Technitium possède une application nommée Query Logs (Sqlite). Elle permet de retrouver précisément quel client a demandé quel domaine, à quelle heure et avec quelle réponse.

Sur mon instance, sa configuration contient notamment :

1
2
3
4
5
6
7
8


{
 "enableLogging": true,
 "maxLogDays": 7,
 "maxLogRecords": 10000,
 "enableVacuum": false,
 "useInMemoryDb": false,
 "sqliteDbPath": "querylogs.db"
}

La base fait environ 12 Mo et conserve autour de 10 000 entrées. Pendant une vérification, elle contenait 12 102 lignes couvrant un peu plus de 80 minutes, soit environ 2,5 requêtes par seconde.

Ce léger dépassement est normal : le plafond n’est pas appliqué à chaque insertion. Le nettoyage se déclenche toutes les quinze minutes. Entre deux passages, la table continue de grossir.

Dit comme cela, rien d’inquiétant. Le détail qui change tout se trouve dans les réglages effectifs de SQLite :

1
2


journal_mode = delete
synchronous = 2

La valeur 2 correspond au mode FULL. Avec le journal DELETE, SQLite crée un journal de rollback pour la transaction, synchronise les données, puis supprime le journal une fois le commit terminé. Ces choix privilégient la durabilité, comme l’explique la documentation officielle de SQLite sur les modes de journalisation et la synchronisation.

Ici, chaque nouvelle requête ajoute une ligne et met à jour treize index en plus de la clé primaire. L’application consomme les requêtes disponibles sans attendre de remplir un gros lot ; à faible trafic, elle peut donc committer très peu de lignes à la fois. Lorsque la limite est dépassée, les anciennes lignes sont aussi supprimées. La base reste petite, mais elle tourne en permanence : insertions, index, suppressions, journal, synchronisations.

Sur un disque local, cette activité passerait probablement inaperçue. Sur un stockage distribué comme Ceph, une succession de petites écritures synchrones coûte beaucoup plus cher que sa taille apparente. Le fichier querylogs.db-journal, présent et ouvert pendant le diagnostic, était le petit témoin de cette mécanique.

Deux mesures supplémentaires renforcent le diagnostic : le compteur du processus Technitium indiquait environ 15,5 Go écrits en 23 heures et, sur un échantillon de quinze secondes, 32 nouvelles requêtes ont accompagné 2,97 Mo d’écritures processus.

Je garde tout de même une réserve : Technitium écrit aussi ses statistiques et ses journaux, tandis que la métrique des 27,89 Go couvre toute la VM. Query Logs est la cause principale la mieux étayée, mais la preuve définitive viendra de la comparaison sur 24 heures après sa désactivation. Sans cet avant/après, lui attribuer chaque octet serait aller un peu vite.

L’espace disque racontait une autre histoire

L’amplification d’écriture n’explique pas à elle seule les 8,8 Go déjà occupés. Les plus gros consommateurs évitables étaient ailleurs :

Données	Taille observée
sauvegardes Technitium	3,7 Gio
statistiques DNS	568 Mio
journaux systemd	623 Mio

Le script de sauvegarde actuel supprime les archives âgées de plus de 30 jours. Cela laisse tout de même 36 fichiers, car une sauvegarde quotidienne pèse désormais entre 100 et 123 Mo et quelques sauvegardes manuelles s’ajoutent au lot.

Ce sont donc deux problèmes distincts :

Query Logs use le stockage avec beaucoup de petites écritures ;
les sauvegardes, statistiques et journaux consomment réellement l’espace disponible.

Supprimer la base SQLite ne libérerait qu’une douzaine de mégaoctets. Pour faire maigrir la VM, il faut aussi agir sur les rétentions.

Garder les requêtes, sans garder SQLite

Ma première idée était de désactiver complètement les journaux détaillés et de conserver seulement les statistiques agrégées dans Grafana. C’était efficace, mais je perdais une fonction à laquelle je tiens : pouvoir rechercher les requêtes DNS dans VictoriaLogs.

Le compromis que je prépare est donc le suivant :

1
2
3
4
5


Technitium Log Exporter
 ↓ HTTP local
 Vector
 ↓ NDJSON compressé
 VictoriaLogs

L’application officielle Log Exporter de Technitium peut expédier les requêtes par HTTP ou Syslog sans les écrire dans un fichier local. Vector recevra les lots en mémoire, extraira les champs utiles — client, nom demandé, type, code de réponse et temps de traitement — puis les enverra vers VictoriaLogs.

Vector n’est pas seulement là pour faire joli au milieu du schéma. Le sink HTTP utilisé par Technitium produit des lots JSON enveloppés par Serilog, alors que l’endpoint /insert/jsonline de VictoriaLogs attend un objet JSON par ligne. Il faut donc convertir et normaliser les événements.

Je préfère un buffer mémoire borné pour ce flux. Cela évite de recréer une nouvelle source d’écritures locales, au prix d’un compromis assumé : une panne ou un redémarrage peut faire perdre quelques requêtes. Pour mon homelab, la visibilité opérationnelle compte davantage qu’une conservation forensique parfaitement exhaustive.

Ces données restent sensibles. Une suite de requêtes DNS raconte rapidement les habitudes d’un réseau. Les noms demandés et les adresses clientes resteront des champs recherchables, mais pas des champs de stream à forte cardinalité, et leur accès devra être plus restreint que celui des journaux système ordinaires.

La suite, avec un vrai avant/après

Au moment où j’écris ces lignes, aucune modification de production n’a encore été appliquée. Le déploiement suivra volontairement plusieurs étapes :

activer Log Exporter et le flux Vector tout en gardant temporairement SQLite ;
comparer les événements pendant 30 à 60 minutes ;
mesurer pendant 24 à 72 heures le volume ingéré, la RAM et les écritures Ceph ;
désactiver Query Logs SQLite seulement après cette validation.

Je conserverai ensuite la base quelques jours comme possibilité de retour arrière. Si les écritures chutent comme prévu, j’aurai enfin le chiffre qui manque à ce diagnostic : le gain réel, pas seulement le coupable le plus crédible.

Je pensais devoir redimensionner un serveur DNS. En réalité, il fallait surtout l’empêcher de tenir son journal intime sur Ceph.

Trop d’alertes, plus aucune confiance : comment j’ai repris en main Checkmk

Wed, 29 Jul 2026 16:00:00 +0200

Une interface réseau disparaît à la fin d’un job. La mémoire du runner grimpe pendant un build. Une sonde mail dépasse son délai une seule fois. Un disque rappelle toutes les quelques minutes qu’il est toujours plein.

Pris séparément, chacun de ces événements mérite d’être observé. Transformés avec la même urgence en notifications, ils finissent surtout par m’apprendre à ne plus les regarder.

C’est le piège classique de la supervision : au début, on veut tout voir. Puis on ajoute des contrôles, des machines et des seuils jusqu’au moment où le système fonctionne techniquement, mais où le signal utile se retrouve noyé dans le bruit.

J’ai donc repris mes règles Checkmk une par une. Mon objectif n’était pas d’obtenir un joli écran entièrement vert. Je voulais qu’une notification signifie de nouveau : « il faut regarder maintenant ».

Le bruit n’a pas une cause unique

La mauvaise solution aurait été de relever tous les seuils ou de désactiver les services pénibles. C’est tentant, rapide et particulièrement efficace pour fabriquer une fausse tranquillité.

À la place, j’ai classé chaque alerte dans l’une de ces familles :

Situation	Exemple dans mon homelab	Réponse
état attendu	interface TAP supprimée avec une VM éphémère	ignorer précisément ce service
incident transitoire	pic de mémoire pendant un job CI	demander une seconde confirmation
problème réel mais répétitif	disque toujours en alerte	conserver l’état, espacer les notifications
seuil mal adapté	résolution DNS correcte mais un peu variable	recalibrer avec une mesure cohérente

Cette distinction paraît évidente après coup. Dans la pratique, elle oblige à répondre à une question parfois inconfortable : qu’est-ce qui justifie réellement de m’interrompre ?

Les interfaces TAP : du bruit parfaitement normal

Mes nœuds Proxmox créent des interfaces TAP pour connecter les interfaces réseau virtuelles des VM. Leur nom suit une forme comme :

1

tap<vmid>i<nic>

Ces interfaces vivent aussi longtemps que la VM ou la charge CI correspondante. Lorsqu’une machine temporaire s’arrête, son interface disparaît. Checkmk peut alors interpréter cette disparition comme un changement d’état à signaler.

Le problème ne venait donc pas d’une panne réseau. Le cycle de vie normal d’une ressource éphémère était traité comme celui d’un port physique.

J’ai commencé par faire découvrir les interfaces Proxmox avec leur description Linux stable plutôt qu’avec un numéro générique du type Interface 12. Cela évite qu’un bridge, un VLAN ou une nouvelle interface récupère le service d’un ancien périphérique.

J’ai ensuite ajouté une règle très ciblée :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


{
 "ruleset": "ignored_services",
 "description": "Homeblack - ignore ephemeral Proxmox TAP interfaces",
 "value": True,
 "conditions": {
 "host_name": {
 "match_on": ["pve-dell", "pve-forum", "pve-fuji"],
 "operator": "one_of",
 },
 "service_description": {
 "match_on": [r"Interface tap[0-9]+i[0-9]+$"],
 "operator": "one_of",
 },
 },
}

Je n’ignore pas « les interfaces de Proxmox ». Je retire uniquement les services qui correspondent au motif des TAP éphémères. Les interfaces physiques, les bridges, les VLANs et les interfaces des machines invitées restent surveillés.

C’est une nuance importante : une bonne exception décrit un comportement attendu, pas une catégorie suffisamment large pour faire disparaître le problème.

Un pic n’est pas encore une panne

Le runner GitLab présente un autre cas. Pendant un build, sa consommation mémoire peut monter brutalement pendant un cycle de contrôle, puis revenir à la normale.

Ce pic reste intéressant. S’il dure, je veux le savoir. S’il ne concerne qu’une mesure isolée, je ne veux pas être interrompu.

Checkmk distingue justement les états soft et hard. Un premier échec peut rester transitoire ; il ne devient un problème confirmé qu’après le nombre de tentatives défini.

Pour le service Memory de trust-runner-01, j’ai choisi deux contrôles consécutifs :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


{
 "ruleset": "extra_service_conf:max_check_attempts",
 "description": "Homeblack - retry transient runner memory pressure",
 "value": 2,
 "conditions": {
 "host_name": {
 "match_on": ["trust-runner-01"],
 "operator": "one_of",
 },
 "service_description": {
 "match_on": [r"Memory$"],
 "operator": "one_of",
 },
 },
}

Un pic d’un cycle reste visible dans l’historique, mais ne déclenche pas de notification immédiate. Si la pression persiste au contrôle suivant, l’état devient hard et l’alerte suit son chemin normal. Avec la fréquence actuelle des contrôles, cela représente environ une minute de confirmation.

Les pics courts restent visibles dans le graphe sans transformer automatiquement chaque mesure isolée en notification.

J’ai appliqué le même raisonnement aux contrôles SMTP entrant et IMAP de ma plateforme mail. Un timeout isolé mérite une nouvelle tentative ; deux échecs consécutifs commencent à ressembler à un incident.

En revanche, je n’ai pas ajouté un délai arbitraire de plusieurs heures au test de livraison de bout en bout. Cette sonde possède déjà sa propre notion du temps : avertissement après 120 secondes et état critique après 300 secondes. Ajouter quatre heures de silence par-dessus revenait à rendre le contrôle presque inutile.

Espacer une notification sans effacer le problème

Les disques posent une question différente. Un filesystem plein, une erreur SMART ou une latence d’entrée-sortie ne disparaissent pas parce que j’ai déjà reçu l’alerte.

Mais recevoir continuellement le même message ne rend pas la réparation plus rapide.

J’ai conservé les services SMART, Filesystem et Disk IO visibles dans Checkmk avec leurs états normaux. C’est uniquement la fréquence de leurs notifications sortantes qui est limitée :

1
2


DISK_NOTIFICATION_COOLDOWN_SECONDS = 24 * 60 * 60
DISK_SERVICE_PREFIXES = ("SMART ", "Filesystem ", "Disk IO ")

Le mécanisme garde une réservation par couple hôte/service. Une première notification de problème passe, puis les répétitions sont bloquées pendant 24 heures glissantes. Si le problème reste actif, Checkmk envoie un rappel quotidien.

Les retours à l’état normal restent présents dans l’historique Checkmk, mais ne génèrent pas de nouvelle notification pour ces trois familles de services. Je préfère ouvrir l’interface et retrouver toute la chronologie plutôt que d’être interrompu à chaque oscillation autour d’un seuil disque.

Il y a un détail auquel je tenais : si l’envoi de la notification échoue, la réservation est libérée. Le système pourra donc retenter plus tard au lieu de considérer comme livré un message qui n’est jamais arrivé.

Enfin, cette limitation ne concerne ni les hôtes, ni les autres services. Une machine inaccessible ou un contrôle métier en échec ne profite pas discrètement du même silence.

Un seuil doit représenter un risque

La supervision DNS de Technitium m’a fourni un bon exemple de seuil techniquement valide, mais opérationnellement trop sensible.

Je contrôle deux choses depuis le serveur Checkmk :

une résolution DNS autoritative en UDP, avec vérification de la réponse ;
l’ouverture du transport DNS sur le port TCP 53.

Au départ, les deux contrôles avertissaient au-dessus de 500 millisecondes. J’ai conservé ce seuil pour l’ouverture TCP, mais porté l’avertissement UDP à une seconde. L’état critique reste fixé à 1,5 seconde et le timeout à trois secondes.

Pourquoi séparer les deux ? Une connexion TCP sur le réseau interne doit rester très rapide. Une requête DNS complète traverse davantage d’étapes et peut subir une variation ponctuelle sans que le service soit dégradé.

Le 29 juillet 2026, ma vérification en lecture seule remontait :

Service	État observé	Temps de réponse
résolution DNS Technitium en UDP	OK	65 ms
transport DNS Technitium en TCP	OK	7 ms

Ce sont des mesures prises à un instant donné, pas une promesse de performance. Elles confirment surtout que les contrôles interrogent réellement le service et exposent leur métrique après la modification.

La mesure UDP reste très en dessous du seuil d’avertissement fixé à une seconde ; le seuil critique apparaît à 1,5 seconde.

Ce que je refuse de faire taire

Réduire le bruit n’a d’intérêt que si les vrais problèmes restent bruyants.

Les avertissements critiques NVMe et les erreurs d’intégrité continuent donc d’alerter dès leur première occurrence. Les filesystems restent surveillés avec leurs seuils normaux. Lorsque le disque du runner manque réellement de place, la réponse attendue est un nettoyage ou une augmentation du volume, pas un seuil plus généreux.

Même logique pour les TAP : j’ignore les interfaces éphémères, mais pas les uplinks. Pour la mémoire du runner, j’ajoute une confirmation, mais je ne supprime pas le contrôle. Pour le DNS, je détends seulement le seuil UDP ; le contrôle TCP conserve sa valeur plus stricte.

Je me sers désormais de cette règle simple :

Si l’alerte représente un problème mesuré, je la garde. Si elle décrit un comportement attendu, je corrige son modèle.

Des règles versionnées plutôt que des clics oubliés

Tous ces réglages sont décrits dans le dépôt d’infrastructure et appliqués par un helper qui utilise l’API REST de Checkmk. Cela me permet de relire une exception, de comprendre pourquoi elle existe et de la tester comme le reste du code.

Pour appliquer les règles de calibration :

1

python3 ansible/scripts/checkmk-rest-api.py calibrate-rules

Je rejoue ensuite la commande sans activation :

1

python3 ansible/scripts/checkmk-rest-api.py calibrate-rules --no-activate

La seconde exécution doit annoncer toutes les règles gérées comme inchangées. Pour les modifications de découverte, notamment les interfaces Proxmox, je relance aussi explicitement la découverte des services concernés :

1
2
3
4


python3 ansible/scripts/checkmk-rest-api.py discover \
 --host pve-dell \
 --host pve-forum \
 --host pve-fuji

Les tests automatisés vérifient également la portée des règles : motif exact des TAP, deux tentatives pour la mémoire du runner et intervalle de 1 440 minutes pour les problèmes disque persistants.

Enfin, je contrôle l’état effectif avec Livestatus, directement sur le serveur Checkmk. Lors de la dernière vérification, le service Memory du runner était bien configuré avec deux tentatives maximales. Les deux boucles mail et les contrôles DNS étaient en état OK.

Cette dernière étape est indispensable. Une configuration correcte dans Git ne prouve pas encore que Checkmk l’a activée ni qu’elle s’applique au bon service.

Ce que je retiens

Je pensais au départ qu’une bonne supervision devait tout remonter le plus vite possible. Je la vois maintenant comme un système de décisions : que faut-il conserver dans l’historique, que faut-il confirmer et qu’est-ce qui mérite réellement une interruption ?

Les quatre leviers ne sont pas interchangeables :

ignorer précisément une ressource éphémère ;
confirmer un état transitoire avec une nouvelle tentative ;
espacer le rappel d’un problème déjà connu ;
adapter un seuil à la mesure réellement effectuée.

Je garde volontairement le canal de réception en dehors de cet article. Je raconterai prochainement comment j’achemine ces alertes, où je les reçois et comment je décide lesquelles ont réellement le droit de m’interrompre.

Depuis cette reprise, l’écran vert m’intéresse moins. Ce qui compte, c’est que la prochaine notification inhabituelle récupère immédiatement mon attention — et qu’elle la mérite.

Le pipeline qui publie ce blog sans toucher à la prod

Sat, 25 Apr 2026 23:00:00 +0200

Au début, publier ce blog tenait dans une commande rsync lancée depuis mon Mac. Ce n’était pas compliqué. C’était même suffisamment simple pour que je repousse l’opération, puis que j’oublie quel article était réellement en ligne.

Le dépôt avançait, le serveur attendait et la production finissait parfois avec un temps de retard sur ce que j’avais sous les yeux.

J’ai donc écrit un premier pipeline GitLab CI/CD avec deux étapes : construire le site, puis copier public/ sur dmz-hugo-01. Quarante lignes de YAML, une clé SSH et, pensais-je, une petite soirée tranquille.

Le pipeline a fonctionné. Après plusieurs petites leçons.

Warpgate avait un deux-points de trop pour rsync

Le serveur Hugo n’est pas directement accessible depuis le runner. Le déploiement passe par Warpgate, qui encode la cible SSH dans le nom d’utilisateur :

1

compte:serveur-cible

C’est parfaitement compréhensible pour OpenSSH. rsync, lui, voit le premier : et pense avoir trouvé la séparation entre un hôte et un chemin distant.

Ma première destination ressemblait à ceci :

1

compte:dmz-hugo-01@warpgate:/var/www/blog.homeblack.fr/

Le résultat était surtout une erreur difficile à relier au véritable problème. La solution a été de sortir le nom d’utilisateur de la destination et de le passer explicitement à SSH avec -l :

1
2
3


rsync -rlptDz --delete-delay \
 -e "ssh -i /tmp/hugo_deploy_key -p ${WARPGATE_PORT} -l ${DEPLOY_USER}" \
 public/ "${WARPGATE_HOST}:${DEPLOY_PATH}/"

La destination redevient un banal hôte:chemin, tandis que SSH reçoit toujours l’identité Warpgate complète.

J’utilisais initialement mon propre compte pour cette connexion. Le pipeline possède maintenant un compte dédié, gitlab-ci-hugo, limité à cette cible. C’est plus lisible dans les journaux et le déploiement ne dépend plus de mon identité personnelle.

La clé SSH n’était pas le problème que je croyais

Ensuite est arrivé le classique :

1

Load key "/tmp/hugo_deploy_key": error in libcrypto

J’ai d’abord accusé le format de la clé. L’historique du dépôt raconte une histoire moins élégante : variable GitLab de type fichier, retours chariot, essais de copie, différences entre Alpine et Debian… J’ai corrigé plusieurs symptômes avant de stabiliser le chemin complet.

Le job de déploiement utilise désormais Debian Bookworm et transporte la clé sous forme encodée en base64. Elle est décodée dans un fichier temporaire avec des permissions strictes :

1
2


printf '%s' "$SSH_DEPLOY_KEY" | base64 -d > /tmp/hugo_deploy_key
chmod 600 /tmp/hugo_deploy_key

Ce n’est pas un mécanisme de chiffrement : la confidentialité dépend toujours de la variable CI stockée dans GitLab. Le base64 évite simplement qu’un copier-coller ou un retour à la ligne transforme la clé avant qu’OpenSSH puisse la lire.

Deux étapes ne suffisaient plus

Le premier pipeline savait construire et déployer. Il ne savait pas dire qu’un article avait une description trop longue, une couverture absente ou un lien local cassé. Il pouvait donc automatiser très efficacement la publication d’une erreur.

Le pipeline actuel possède trois étapes :

1
2
3
4


stages:
 - validate
 - build
 - deploy

La validation exécute les tests du dépôt et le validateur de contenu :

1
2
3
4
5
6


validate-content:
 stage: validate
 image: python:3.14-alpine
 script:
 - python3 -m unittest discover -s scripts -p "test_*.py"
 - python3 scripts/validate_content.py

Ce contrôle vérifie notamment le front matter, les titres SEO, les descriptions, les couvertures, les liens locaux et quelques motifs sensibles. Il impose aussi le format éditorial choisi pour chaque article : carnet de maintenance, retour d’expérience ou projet.

Le build utilise ensuite une version précise de Hugo, active --panicOnWarning et conserve public/ comme artefact pendant deux heures. Le job de déploiement récupère cet artefact : il ne reconstruit pas discrètement un site différent de celui qui vient d’être validé.

Une branche construit, seule main déploie

Le changement le plus important n’est pas une commande. C’est la frontière entre vérifier et publier.

Une branche ou une merge request lance la validation et le build. Cela suffit pour savoir que l’article est publiable, mais aucun fichier n’est envoyé au serveur. Le job deploy possède sa propre règle : il ne s’exécute que sur la branche principale.

1
2
3
4
5


deploy:
 interruptible: false
 resource_group: production
 rules:
 - if: "$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH"

resource_group empêche deux déploiements de production de se marcher dessus. Le job n’est pas interruptible afin qu’un nouveau commit ne coupe pas un rsync déjà engagé. À l’inverse, les validations et builds ordinaires peuvent être annulés lorsqu’un commit plus récent les rend inutiles.

Les règles globales évitent également de créer deux pipelines identiques lorsqu’une branche possède déjà une merge request ouverte. Ce sont de petits garde-fous, mais ils ont fait passer la CI d’un script distant à un véritable chemin de publication.

Le dernier contrôle se fait sur le vrai site

Le transfert conserve les permissions utiles, retarde les suppressions avec --delete-delay et active StrictHostKeyChecking contre le fichier known_hosts préparé par le job.

Une fois rsync terminé, le pipeline interroge directement l’URL de production :

1
2


curl --fail --silent --show-error --retry 5 --retry-delay 2 \
 "https://blog.homeblack.fr/" > /dev/null

Ce test ne prouve pas que chaque paragraphe est magnifique. Il confirme au moins que le chemin GitLab → artefact Hugo → Warpgate → Nginx aboutit encore à un site qui répond.

Ce que cela a changé quand j’écris

Aujourd’hui, je ne « déploie » plus le blog depuis mon poste. Je pousse une branche, la CI contrôle le contenu et construit le site. Quand la modification rejoint main, le même pipeline publie l’artefact validé puis vérifie la page réelle.

Le système reste volontairement simple. rsync écrit directement dans le répertoire servi par Nginx : je n’ai ni répertoire de releases ni bascule atomique vers une version précédente. Si un article doit être retiré, le rollback passe encore par Git et un nouveau pipeline.

Pour un blog personnel, ce compromis me convient. Le point important n’était pas d’empiler les outils, mais d’enlever une commande manuelle tout en gardant une limite nette : tester partout, déployer seulement après la fusion.

Je pensais automatiser un rsync. J’ai surtout fini par définir ce que « prêt à publier » voulait dire.

J’ai doublé mon firewall pour pouvoir en éteindre un

Tue, 31 Mar 2026 00:00:00 +0000

Mon premier OPNsense fonctionnait très bien. C’était justement le problème.

Tout le cœur du réseau reposait sur fw-core-p1 : le LAN, huit VLANs, l’accès Internet et les routes entre mes différentes zones. Tant que la VM tournait, je n’avais aucune raison d’y penser. Dès qu’une mise à jour demandait un redémarrage, la question revenait : qu’est-ce qui reste accessible si ce firewall s’arrête ?

Pas grand-chose.

Je ne cherchais pas à transformer mon homelab en infrastructure bancaire. Je voulais simplement pouvoir maintenir un firewall sans couper volontairement tout ce qui passait derrière lui. C’est comme ça que fw-core-p2 est arrivé.

Une seconde VM ne fait pas encore un cluster

Le plus facile aurait été de cloner fw-core-p1, de démarrer la copie et d’appeler ça de la haute disponibilité. Deux firewalls mal coordonnés savent surtout produire deux fois plus de problèmes.

J’ai donc commencé par leur donner la même forme. Les deux VM vivent sur deux nœuds Proxmox différents et possèdent exactement le même ordre d’interfaces : le WAN, le LAN, les huit VLANs du homelab, puis une dernière interface réservée à la synchronisation.

1
2
3
4
5
6


pve-forum pve-fuji
fw-core-p1 fw-core-p2
 MASTER ─── VLAN 999 SYNC ─── BACKUP
 │ pfsync │
 │ XML-RPC │
 └────── 9 VIP CARP partagées ──┘

Cette symétrie n’est pas seulement jolie dans Terraform. pfsync associe les états aux interfaces : si leur ordre ou leur nom diffère entre les deux machines, la réplication ne raconte plus la même histoire des deux côtés.

CARP, pfsync et XML-RPC ne font pas le même travail

J’avais tendance à ranger tout cela dans la boîte « HA ». En pratique, trois mécanismes distincts coopèrent.

CARP (Common Address Redundancy Protocol) détermine quel firewall porte les adresses IP virtuelles. Les machines du réseau utilisent ces VIP comme passerelles et n’ont pas besoin de savoir si p1 ou p2 répond derrière.

pfsync réplique la table d’états. Quand p2 reprend le trafic, il connaît déjà les connexions suivies par p1 au lieu de repartir avec une feuille blanche.

XML-RPC synchronise la configuration depuis le primaire : règles, alias, NAT et objets partagés. Le second nœud reste ainsi un vrai pair, pas une vieille copie que j’espère encore correcte six mois plus tard.

La documentation HA d’OPNsense recommande justement une interface dédiée à pfsync. J’ai appliqué ce principe avec le VLAN 999, utilisé également pour la synchronisation de configuration.

Dans Terraform, ce choix tient dans quelques lignes :

1
2
3
4
5
6


# vtnet10 -> SYNC (pfsync + xmlrpc HA)
network_device {
 bridge = var.fw_core_lan_bridge
 vlan_id = var.fw_core_sync_vlan
 model = "virtio"
}

Ce petit vtnet10 est pourtant l’une des pièces les plus importantes du montage. Le trafic utilisateur et les échanges qui permettent au cluster de rester cohérent ne se disputent pas la même interface logique.

Le moment où neuf VIP ont changé de côté

Une interface verte dans OPNsense ne prouve pas grand-chose. Le cluster est devenu réel le jour où j’ai placé fw-core-p1 en maintenance et regardé fw-core-p2 reprendre les neuf VIP.

1
2
3


fw-core-p1 : BACKUP
fw-core-p2 : MASTER
VIP CARP : 9/9 sur p2

Le DNS continuait de répondre et mes routes applicatives restaient accessibles. En quittant le mode maintenance, p1 a repris son rôle par préemption et p2 est retourné attendre en secours.

C’est un test très simple, mais il change complètement la confiance que j’accorde au montage. Avant lui, j’avais deux VM configurées pour faire du CARP. Après lui, j’avais un cluster que je pouvais réellement utiliser pendant une intervention.

La haute disponibilité synchronise aussi les erreurs

Le piège le plus intéressant est arrivé plus tard. Une VIP utilisait un pair CARP unicast propre à p1. XML-RPC a parfaitement synchronisé cette valeur vers p2, qui s’est alors mis à envoyer ses annonces… à sa propre adresse.

La synchronisation n’était pas cassée. Elle exécutait fidèlement une configuration qui n’aurait pas dû être identique sur les deux nœuds.

J’ai raconté cette petite surprise dans ma révision du cluster OPNsense. Elle m’a rappelé qu’un cluster ne rend pas une configuration correcte par magie. Il propage aussi très efficacement les mauvaises idées.

Le retour au multicast CARP a supprimé cette exception locale et rendu les deux configurations réellement partageables. Depuis, mon test ne consiste plus seulement à vérifier que les deux firewalls affichent du vert : je provoque la bascule et je contrôle ce qui continue à fonctionner.

Ce que ce second firewall a réellement changé

Je n’ai pas supprimé tous les points de panne. Les deux VM dépendent toujours du réseau physique, des bridges Proxmox et de ce qui se trouve en amont. La haute disponibilité du firewall ne rend pas magiquement le reste du homelab redondant.

Elle a en revanche retiré un blocage très concret : je peux éteindre un OPNsense sans considérer la coupure comme une étape normale de la maintenance.

Le bénéfice n’est pas spectaculaire quand tout va bien. fw-core-p2 passe l’essentiel de son temps en BACKUP, ce qui est exactement ce que je lui demande. Sa valeur apparaît quand je mets à jour p1, quand je redémarre une VM ou quand je veux vérifier une modification sans jouer toute la connectivité du homelab sur un seul clic.

Au fond, j’ai doublé mon firewall pour pouvoir enfin en éteindre un sereinement. C’était tout le projet.