Projet on Mook’s Lab Chronicles

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.

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.