WAF, IDS, IPS : trois sigles, trois métiers

Commençons par le début, parce que WAF, ça veut dire quoi au juste ?

WAF, c’est Web Application Firewall. Un pare-feu applicatif. Contrairement au pare-feu classique qui regarde des IP et des ports, lui il lit le contenu HTTP : l’URL, les en-têtes, le corps de la requête, les cookies. Et il bloque ce qui ressemble à une attaque applicative : injection SQL, XSS, chemin d’URL douteux, quelqu’un qui vient renifler si tu n’aurais pas laissé traîner un fichier .env à la racine.

Deux autres sigles vont avec, et ils reviennent tout le temps.

IDS, Intrusion Detection System. Il détecte et il alerte, sans agir. C’est un capteur.

IPS, Intrusion Prevention System. Même chose, mais il agit : il coupe la connexion, il bannit l’IP.

Et CrowdSec, lui, il est tout ça à la fois. Le moteur lit les logs, corrèle et décide : c’est l’IDS. Les bouncers appliquent la sanction là où ça compte, dans le reverse proxy par exemple : ça en fait un IPS. Et son composant AppSec inspecte les requêtes HTTP avant qu’elles n’atteignent ton appli : c’est le WAF. Trois casquettes, un seul conteneur.

Communautaire, ça veut dire quoi exactement

C’est le gros argument de CrowdSec, et c’est celui qu’on résume souvent mal. Alors voilà ce qui se passe vraiment.

Quand ton moteur repère une IP qui fait n’importe quoi, il la signale à CrowdSec. Et il envoie seulement ça : l’adresse, et ce qu’elle a tenté. Tes logs ne bougent pas de chez toi.

En face, CrowdSec compare avec ce que remontent tous les autres. Une IP dénoncée par un seul serveur ne fait rien, ça évite les petits malins qui voudraient faire bannir 8.8.8.8 par la terre entière. Mais quand elle est signalée par plein de serveurs qui ne se connaissent pas, elle part dans la liste noire commune, et tout le monde la reçoit.

Résultat : tu bloques des IP malveillantes avant même qu’elles t’aient visé. C’est ça le vrai gain. Un serveur seul apprend de ce qu’il subit, un serveur branché sur CrowdSec apprend de ce que subissent les autres.

Deux nuances honnêtes quand même. D’abord, l’accès à la liste dépend de ta contribution : si tu envoies des signaux régulièrement, ton moteur est abonné automatiquement à la liste complète, sinon tu reçois une version allégée. Ensuite, le partage se désactive, ce n’est pas imposé. Mais si tu le coupes, tu gardes seulement la détection locale et tu ne reçois plus la liste. Donnant-donnant.

Pour savoir où tu en es, une commande suffit :

docker exec crowdsec cscli capi status

You can successfully interact with Central API (CAPI)
Sharing signals is enabled
Pulling community blocklist is enabled

L’installer

Comme d’habitude je passe par Portainer, je trouve que c’est le mieux. Voilà mon compose, adapte les chemins à ta machine :

services:
  crowdsec:
    image: crowdsecurity/crowdsec:latest
    container_name: crowdsec
    restart: unless-stopped
    network_mode: host
    environment:
      GID: "1000"
      COLLECTIONS: "crowdsecurity/linux crowdsecurity/sshd crowdsecurity/http-cve crowdsecurity/base-http-scenarios crowdsecurity/nginx ZoeyVid/npmplus"
    volumes:
      - /path/de/ton/npmplus/data/nginx/logs:/var/log/npmplus:ro
      - /var/log:/var/log/host:ro
      - /home/ton-user/crowdsec/config:/etc/crowdsec
      - /home/ton-user/crowdsec/data:/var/lib/crowdsec/data
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

Les COLLECTIONS, ce sont les paquets de scénarios installés au démarrage. Là je prends le Linux de base, SSH, les CVE web connues, les scénarios HTTP génériques, nginx, et celui dédié à NPMplus. Le network_mode: host est important : le moteur doit être joignable en local par le bouncer et par le WAF, sur les ports 8080 et 7422.

Côté NPMplus, il y a quand même trois choses à faire

Sur mon reverse proxy, je pensais qu’il n’y avait rien à toucher. En fait si, un peu. Rien de méchant, mais si tu sautes ces étapes tu auras un CrowdSec qui tourne dans le vide et qui ne bloquera jamais rien.

Un. Créer la clé du bouncer côté CrowdSec :

docker exec crowdsec cscli bouncers add npmplus

Deux. Coller cette clé dans crowdsec.conf, dans le dossier de données de NPMplus, et passer ENABLED à true. Pendant que tu y es, vérifie ces lignes, ce sont elles qui branchent le moteur et le WAF :

ENABLED=true
API_URL=http://127.0.0.1:8080
APPSEC_URL=http://127.0.0.1:7422
APPSEC_FAILURE_ACTION=deny

Trois. Déclarer l’acquisition côté CrowdSec, dans un fichier acquis.d/npmplus.yaml. Il y a deux sources : les fichiers de logs, et le WAF qui écoute en direct.

filenames:
  - /var/log/npmplus/*.log
labels:
  type: npmplus
---
listen_addr: 0.0.0.0:7422
appsec_config: crowdsecurity/appsec-default
name: appsec
source: appsec
labels:
  type: appsec

Et là, le piège dans lequel je suis tombé sans m’en rendre compte : NPMplus n’écrit pas ses logs d’accès sur le disque par défaut. Il faut passer LOGROTATE à true dans son compose. Sinon le dossier reste désespérément vide, et la moitié « lecture de logs » de CrowdSec ne voit rien passer.

Je l’ai découvert en regardant mes métriques, des mois après : mon dossier de logs est vide, et absolument tout mon trafic analysé est passé par AppSec. Ça marchait très bien, remarque, mais je me privais de la moitié des scénarios. Va vérifier chez toi, ça prend dix secondes :

docker exec crowdsec cscli metrics show acquisition

Une interface web pour voir ce qui se passe

Le moteur se pilote très bien en ligne de commande, mais j’ai rajouté un petit projet qui donne une vraie vue sur ce qui se passe, et honnêtement je ne reviendrai pas en arrière : CrowdSec Web UI.

Il se branche sur l’API locale avec un compte machine, à créer d’abord côté CrowdSec, en choisissant son mot de passe :

docker exec crowdsec cscli machines add crowdsec-web-ui --password 'ton-mot-de-passe'

Puis le compose, avec ce même mot de passe :

services:
  crowdsec-web-ui:
    image: ghcr.io/theduffman85/crowdsec-web-ui:latest
    container_name: crowdsec-web-ui
    restart: unless-stopped
    ports:
      - "127.0.0.1:3060:3060"
    volumes:
      - /home/ton-user/crowdsec-web-ui/data:/app/data
    environment:
      PORT: "3060"
      CROWDSEC_URL: http://host.docker.internal:8080
      CROWDSEC_USER: crowdsec-web-ui
      CROWDSEC_PASSWORD: "ton-mot-de-passe-genere"
      DB_DIR: /app/data
    extra_hosts:
      - "host.docker.internal:host-gateway"
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

Note le 127.0.0.1:3060 devant le port : le conteneur n’écoute que sur la machine elle-même, rien n’est exposé au monde. C’est le reverse proxy qui décidera qui a le droit d’entrer.

Ensuite j’ai fait ce que je fais toujours : un sous-domaine chez Duck DNS, et un proxy host dans NPMplus pointé sur le port 3060. Et sur celui-là, mets une Access List, ou ton SSO si tu en as un. C’est un tableau de bord de sécurité, ce serait dommage de le laisser en libre-service. Le SSO, j’en parlerai la prochaine fois, promis.

Et là, tous tes sites sont protégés

C’est ça le vrai truc. Une fois le bouncer branché, tout ce qui passe par NPMplus passe par CrowdSec. Tous tes domaines, d’un coup, sans rien faire de plus. C’est limite magique.

Et si un site fait des faux positifs, tu peux couper l’inspection domaine par domaine, dans les options du proxy host :

La nuance vaut le coup d’être dite : cet interrupteur désactive l’inspection AppSec pour ce domaine, donc la partie WAF. Le bannissement des IP déjà connues, lui, continue de s’appliquer. C’est plutôt une bonne chose, tu lèves la contrainte gênante sans lever la protection.

Et si c’est une IP précise qui se fait jeter à tort, la tienne au hasard, tu la sors du lot :

docker exec crowdsec cscli allowlists create mes-ip -d "IP de confiance"
docker exec crowdsec cscli allowlists add mes-ip 203.0.113.42
docker exec crowdsec cscli decisions delete --ip 203.0.113.42

Ou alors tu ne tapes rien du tout et tu passes par l’interface web : la page Décisions liste les bans en cours et tu débannis en un clic. Elle sait aussi faire l’inverse, bannir une IP à la main avec la durée que tu veux, si tu en croises une qui t’agace.

Ce que ça donne chez moi

Des chiffres, tant qu’à faire, parce que c’est ça qui parle. Depuis que ça tourne : 483 850 requêtes inspectées par le WAF, 10 110 bloquées. 1 420 alertes remontées. Et au moment où j’écris, deux bans actifs seulement, parce qu’un ban expire tout seul au bout de quelques heures.

Le scénario qui se déclenche le plus chez moi, et de loin, c’est vpatch-env-access : des robots qui tournent en boucle en cherchant un fichier .env à télécharger, en espérant y trouver des mots de passe de base de données. Ils viennent en grande majorité de machines louées chez un gros hébergeur cloud. Ce ne sont pas des hackers dans une cave, ce sont des scanners industriels qui ratissent l’Internet entier, en permanence, et qui tombent sur toi parce que tu existes.

Aucune de ces requêtes n’a atteint mes applis. C’est exactement le boulot.

Franchement, c’est devenu indispensable

Je le recommande vraiment. C’est une protection en plus, elle se pose en une soirée, et elle évite les mauvaises surprises. Le jour où une CVE sort sur un truc que tu héberges, le virtual patching est déjà en place avant que tu aies eu le temps de mettre à jour.

Et si vraiment ça te gêne quelque part, tu ajoutes une IP en liste blanche, ou tu désactives carrément le WAF sur un domaine. Tu gardes la main. Mais ça vaut le coup de le laisser travailler : après tout, il fait le tri pendant que tu dors.

Image d’en-tête générée par IA.

C’est la première fois que je parle programmation sur ce blog, et pourtant je ne vais pas parler de code. Je vais parler de ce qu’il y a autour : la façon dont on structure la stack d’un projet. Parce qu’un projet qui part bien, c’est d’abord un projet facile à lancer, à builder et à déployer. Le reste vient après.

Le Makefile que je trimballais de projet en projet

Que ce soit du JS, du PHP ou autre chose, tout passe chez moi par un Makefile. Les commandes de dev, le build, les tests, et même les environnements de recette et de production. Une seule porte d’entrée, la même partout, quel que soit le langage derrière.

Le problème, c’est que ce Makefile était un fichier que je copiais. Nouveau projet, copier-coller. Et le jour où j’améliorais quelque chose dedans, il fallait répéter la modification projet par projet. Fastidieux, et surtout jamais fait jusqu’au bout : au bout d’un moment, je ne savais plus quel projet abritait quelle version, ni quelles commandes il connaissait. Deux projets côte à côte, deux comportements différents pour le même make.

D’où Auto Makefile. L’idée tient en une phrase : garder dans le projet uniquement ce qui lui est propre, et aller chercher le générique ailleurs, au moment où on en a besoin.

Un Makefile qui en charge un autre

Concrètement, voilà à quoi ressemble le Makefile d’un projet :

# configuration #

# external resource #
export MAKEFILE_URL=https://raw.githubusercontent.com/Smeagolworms4/auto-makefile/master
export IMPORT_MK=root.mk

# import #
$(shell [ ! -f .makefiles/index.mk ] && mkdir -p .makefiles && curl -L --silent -f $(MAKEFILE_URL)/$(IMPORT_MK) -o .makefiles/index.mk)
include .makefiles/index.mk

export CUSTOM_VAR  ## My custom variable 1
export CUSTOM_VAR2 ## My custom variable 2

##########
# Custom #
##########

## My custom rule
hello-world:
	echo Hello world

Tu lui donnes une URL, il va chercher le fichier distant et le pose dans .makefiles/. C’est là que tout se range, et c’est un dossier à ignorer dans git : rien de ce qu’il contient n’a besoin d’être versionné, tout se retélécharge.

La seule vraie condition, c’est que le système ait curl. Il faut bien télécharger les fichiers distants un jour. Et justement, ce n’est qu’un jour : le test [ ! -f .makefiles/index.mk ] fait que le téléchargement n’a lieu que si le fichier manque. Une fois le premier make passé, le projet fonctionne hors ligne comme n’importe quel Makefile classique.

make tout court, et tu as l’aide

La première chose que ça apporte, c’est une commande help qui n’est pas à écrire. make sans argument, ou make help, et tu obtiens ça :

Le mécanisme est bête et efficace. Un commentaire ## juste au-dessus d’une règle devient sa description. Un ## à la fin d’une ligne export documente la variable. Et les blocs de dièses encadrés servent de titres de section pour regrouper les règles :

############
# Symfony  #
############

## Installe les dépendances
install:
	composer install

Écrire la doc et écrire la règle, c’est le même geste. Ce qui fait qu’elle reste juste : personne n’oublie de mettre à jour une aide qui se trouve sur la ligne d’au-dessus.

Les .env chargés dans le bon ordre

Le fichier de base, root.mk, gère aussi les variables d’environnement, et c’est de loin ce dont je me sers le plus. Tu as un .env, il est chargé tout seul. Tu as un .env.local, il est chargé aussi, par-dessus. Et si tu lances make ENV=prod et qu’il trouve un .env.prod, il le prend au passage.

Avec deux fichiers dans le projet et une règle qui se contente d’afficher la variable, ça donne ça :

$ cat .env
APP_SECRET=secret-de-dev

$ cat .env.prod
APP_SECRET=secret-de-prod

$ make debug
ENV=dev  APP_SECRET=secret-de-dev

$ make ENV=prod debug
ENV=prod APP_SECRET=secret-de-prod

Il n’y a rien à écrire dans ton Makefile pour ça, c’est le comportement par défaut. Tu poses tes fichiers, ils sont pris.

La variante Docker

Et ça ne s’arrête pas là. Le fichier que tu importes n’est pas figé : il suffit de changer une ligne pour charger une autre variante de l’outil.

export IMPORT_MK=docker.mk

Celle-ci ajoute les commandes Docker de base : make list pour voir les conteneurs, make killall pour repartir de zéro, make clean-none pour dégager les images sans nom. Des commandes qui ne sont liées à aucun projet en particulier, mais que je tape tous les jours.

Attention avec killall : il supprime tous les conteneurs de la machine, pas seulement ceux du projet courant, puis fait un prune des réseaux et des volumes. C’est exactement ce que je veux sur mon poste de dev quand plus rien ne répond. C’est aussi exactement ce qu’il ne faut pas taper sur une machine qui héberge autre chose.

docker-compose.mk, celui que j’utilise vraiment

La dernière variante est celle qui m’intéresse le plus, parce que mes stacks sont full Docker :

export IMPORT_MK=docker-compose.mk

Elle ajoute up, down, logs, docker-build et docker-pull. Et surtout, elle choisit le fichier compose en fonction de l’environnement.

Le principe, dans le détail. Par défaut, l’outil cherche docker/docker-compose.yml. Quand tu lances make ENV=prod up, il regarde d’abord si docker/docker-compose.prod.yml existe. S’il le trouve, c’est celui-là qu’il utilise. Sinon il retombe sur le fichier de base, sans rien dire et sans planter.

$ make debug
COMPOSE_PATH=/projet/docker/docker-compose.yml

$ make ENV=prod debug
COMPOSE_PATH=/projet/docker/docker-compose.prod.yml

Le point important, et c’est un choix de ma part : c’est un remplacement, pas une superposition. Docker Compose sait empiler plusieurs fichiers avec -f base.yml -f prod.yml, où le second ne contient que les différences. Ici, non : le fichier de l’environnement est utilisé à la place de l’autre. Il doit donc être complet, et décrire toute la stack. C’est plus verbeux, mais tu lis un seul fichier pour savoir ce qui tourne en prod, sans reconstituer mentalement une fusion de deux YAML.

Et comme les .env suivent la même variable ENV, une seule commande bascule tout ensemble : le bon fichier compose et les bonnes variables.

make up            # docker-compose.yml   + .env
make ENV=prod up   # docker-compose.prod.yml + .env + .env.prod

Autre détail commode : si tu définis DOCKER_NAME, il est passé en nom de projet à Compose. Deux stacks avec le même nom de dossier ne se marchent plus dessus.

À noter aussi, la mécanique s’empile toute seule. docker-compose.mk télécharge docker.mk, qui télécharge root.mk. Tu n’écris qu’un seul curl dans ton Makefile, et tu te retrouves avec les trois fichiers dans .makefiles/ et toutes les commandes des trois niveaux.

Tout se surcharge

Aucune règle fournie n’est verrouillée. Chaque commande est rangée dans une variable protégée par un ifndef, donc si tu la définis dans ton Makefile, c’est la tienne qui gagne. Trois niveaux d’intervention :

# remplacer complètement ce que fait la règle
export RULE_CMD_UP=$(COMPOSE) up -d --remove-orphans

# ajouter une dépendance : up construira les images avant
export RULE_DEP_UP=docker-build

# greffer une commande avant ou après
export RULE_CMD_UP_AFTER=$(COMPOSE) exec php composer install

Dans les faits, c’est ce que j’utilise le plus : je garde la règle générique et je greffe le spécifique du projet autour. Un make up qui installe les dépendances et joue les migrations derrière, sans avoir réécrit la commande Docker.

Mettre à jour, ou figer une version

Puisque le fichier vient d’ailleurs, il faut pouvoir le rafraîchir. C’est la règle update-makefile, qui vide .makefiles/ et relance make : au passage suivant, tout est retéléchargé.

make update-makefile

Et pour mon problème d’origine, celui de ne jamais savoir quelle version un projet abritait, la réponse tient dans la ligne d’URL. Le dépôt est étiqueté, donc rien n’oblige à pointer sur master :

export MAKEFILE_URL=https://raw.githubusercontent.com/Smeagolworms4/auto-makefile/v1.4.1

Le projet dit alors noir sur blanc de quelle version il dépend, et il s’y tient. Sur mes projets qui bougent, je reste sur master et je fais un update-makefile de temps en temps. Sur ceux qui doivent juste continuer à marcher, j’épingle.

Ce que ça vaut

Ça reste un outil basique et très simple, et c’est volontaire. Il ne compile rien, il ne devine rien de ton projet, il ne remplace pas ton gestionnaire de dépendances. Il fait juste en sorte que make réponde la même chose partout, que le projet soit en PHP, en JS ou en Java, et il est parfait sur une stack full Docker comme j’aime les monter.

Le résultat que je cherchais est atteint : quand j’arrive sur un projet, même vieux de deux ans, je tape make et il me dit ce qu’il sait faire. Le Makefile du projet ne contient plus que ce qui est propre au projet, et il tient en vingt lignes.

Tout est sur le dépôt, avec la doc complète. C’est libre et ouvert, alors j’attends vos retours, et vos suggestions si vous voyez ce qui manque.

Image d’en-tête générée par IA.

L’outil que j’utilise pour ça s’appelle Komga.

Pourquoi Komga et pas autre chose

Parce qu’il est autohébergé, libre, et qu’il marche plutôt bien. Ça peut paraître court comme argument, mais dans le monde des gestionnaires de bibliothèque numérique, cocher les trois cases en même temps n’est pas si courant.

Le seul reproche que je lui fais, et c’est un avis perso : il est un peu lourd niveau RAM. Merci Java, les vrais valideront. Ceci dit, une fois l’analyse de la bibliothèque passée, au repos ça tourne sans trop de problèmes. C’est pas lui qui va faire tomber votre serveur.

C’est un gestionnaire de bibliothèque, rien de plus

Ni plus ni moins que ça : il range vos livres, et il vous les sert. Je crois qu’il a d’abord été conçu pour les mangas et les comics, j’avoue que j’ai pas vérifié. Mais je m’en sers aussi pour les eBooks, et c’est super bien.

Il y a un lecteur intégré directement dans l’interface. Pas d’appli à installer pour commencer : on ouvre une page, on lit. Sur PC comme sur téléphone, et il reprend là où on s’était arrêté.

Il permet de trier, de ranger, d’organiser ses séries. Et il va chercher tout seul la description, la couverture et le reste des informations associées.

Il sait aussi lire les métadonnées attachées à vos fichiers, et surtout les éditer pour que tout soit rangé précisément comme vous le voulez. Je vous avais dit que j’étais monomaniaque de l’ordre dans mes fichiers, mdr. Ben voilà, c’est encore vrai ici.

OPDS : brancher sa liseuse dessus

Deuxième point important, et pour moi le vrai argument : Komga expose sa bibliothèque en OPDS. C’est un protocole standard, fait exactement pour ça, et la doc de Komga en fait un très bon guide.

Dans les faits c’est assez simple : l’URL de votre serveur avec le bon chemin, votre identifiant, votre mot de passe, et c’est bon. Votre chère liseuse accède à vos eBooks, directement, sans câble USB et sans copier des fichiers à la main. Ou bien Moon+ Reader sur Android, c’est ce que j’utilise pour lire mes eBooks.

L’installer, en Docker évidemment

Pour l’installer, très simple, on repart sur Docker et Portainer. Le compose vient de la doc officielle :

services:
  komga:
    image: gotson/komga
    container_name: komga
    user: 1000:1000
    ports:
      - 25600:25600
    volumes:
      - /chemin/vers/config:/config
      - type: bind
        source: /chemin/vers/ma/bibliotheque
        target: /data
    environment:
      - TZ=Europe/Paris
    restart: unless-stopped

Ensuite, toujours pareil : on branche un DNS et un reverse proxy devant, et le service est joignable proprement de l’extérieur. C’est aussi ce qui vous permettra de donner une vraie adresse à votre liseuse plutôt qu’une IP locale.

Et voilà

Tout fonctionne. Vous parcourez votre bibliothèque d’eBooks, vous avez le service en ligne et autohébergé pour cette dernière, lecteur inclus. Et votre liseuse se sert toute seule.

Image d’en-tête générée par IA.

Le besoin revient, la solution jamais

Ça fait des années que je tombe dessus. Sur ce blog, pour les statistiques : savoir de quel pays viennent les visiteurs, c’est une des rares informations vraiment utiles quand tu ne veux poser aucun cookie. Sur Teambudd.io, mon jeu, dont je vous parlerai une autre fois. Et sur à peu près tout ce que j’ai bricolé entre les deux.

À chaque fois, même réflexe : je cherche une API en ligne. Et à chaque fois, même mur. Ces services existent, ils marchent très bien, mais ils sont construits sur des quotas. Mille requêtes par jour, parfois moins, et au-delà tu passes à la caisse. Pour un site qui a un peu de trafic, mille requêtes c’est une matinée. Sans compter le détail qui me gêne le plus : tu envoies l’adresse de tes visiteurs à quelqu’un d’autre, et ce quelqu’un d’autre s’en fait une idée assez précise de qui vient chez toi.

Un seul appel externe, et il n’a lieu qu’une fois par jour

Alors j’ai fabriqué IP Info. L’idée tient dans une bascule toute simple : au lieu d’interroger un service à chaque adresse, tu télécharges la base une fois et tu la lis toi-même.

La base, c’est GeoLite2, publiée par MaxMind. Tu crées un compte, tu récupères une clé de licence, c’est gratuit. Tu poses la clé dans une variable d’environnement et le service fait le reste : il télécharge le fichier au démarrage, le range dans son volume, et va vérifier une fois par jour s’il y a une version plus fraîche. C’est ça, l’unique dépendance externe. Tout le reste tourne chez toi.

Un fichier .mmdb, c’est un arbre de recherche binaire. Le service le parcourt bit par bit et te répond en quelques microsecondes, sans serveur de base de données, sans réseau, sans rien. Autant dire que la notion de quota n’a plus de sens : tu peux lui envoyer un million de requêtes, c’est ta machine qui décide, pas une grille tarifaire.

Ce qu’il te répond

Et il ne te rend pas que le pays. C’est justement là que ça devient intéressant pour des statistiques :

curl https://ip.exemple.fr/81.2.69.200

{
  "ip": "81.2.69.200",
  "version": 4,
  "type": "public",
  "hostname": null,
  "continent": "EU",
  "continent_name": "Europe",
  "country": "GB",
  "country_name": "Royaume-Uni",
  "country_is_eu": false,
  "region": "England",
  "region_code": "ENG",
  "city": "Londres",
  "postal": "OX1",
  "latitude": 51.5142,
  "longitude": -0.0931,
  "accuracy_radius": 10,
  "timezone": "Europe/London",
  "network": "81.2.69.192/26",
  "asn": 12345,
  "as_name": "Test ISP Ltd",
  "as_network": "81.2.69.0/24"
}

Le pays, la région, la ville, le fuseau horaire, les coordonnées, et même l’opérateur derrière l’adresse. Tous les champs sont toujours présents : une valeur inconnue vaut null, jamais une clé qui disparaît. Ça évite d’écrire du code défensif partout.

Quand tu n’as besoin que d’une seule information, tu la demandes seule et tu la reçois en texte brut. C’est le mode que j’utilise pour les statistiques du blog :

curl https://ip.exemple.fr/8.8.8.8/country
# US

curl 'https://ip.exemple.fr/81.2.69.200?fields=country,city&lang=fr'
# {"country":"GB","city":"Londres"}

Deux champs méritent qu’on s’y arrête. accuracy_radius donne le rayon en kilomètres dans lequel MaxMind situe l’adresse : sans lui, quatre décimales de latitude ressemblent à une adresse postale, ce qu’elles ne sont absolument pas. Et type dit ce que l’adresse raconte d’elle-même, public, private, loopback et compagnie. Une adresse privée n’est dans aucune base de géolocalisation, et le service te le dit au lieu de te rendre un objet vide à interpréter.

Une adresse toute seule, sans rien préciser, te renvoie celle de l’appelant. Pratique pour un « quelle est mon IP » maison.

Deux façons de le faire tourner

Comme pour Image Resizer, il y a deux chemins, et c’est le même code derrière.

Le premier, c’est une fonction Lambda serverless. Aucun serveur, aucune infra à surveiller, la facture suit strictement l’usage. Chaque version publie une archive zip prête à déposer, et une seule fonction suffit : pas de seconde fonction pour tenir la base à jour, pas de tâche planifiée. Le démarrage à froid télécharge le fichier, et chaque invocation vérifie son âge au passage. Le LAMBDA.md du dépôt déroule la marche à suivre.

Le second, c’est Docker, et donc Portainer. La configuration tient en quelques lignes :

services:
  ip-info:
    image: smeagolworms4/ip-info:latest
    restart: unless-stopped
    user: "${PUID:-1000}:${PGID:-1000}"
    environment:
      MAXMIND_LICENSE_KEY: "ta-clé-de-licence"
      TRUST_PROXY: "true"
      DEFAULT_LANGUAGE: "fr"
    ports:
      - "3000:3000"
    volumes:
      - ${DATA_DIR}/ip-info:/data

Le volume sur /data n’est pas décoratif : c’est là que les bases sont rangées. Sans lui, chaque redémarrage retélécharge 70 Mo, et MaxMind les décompte de ta clé.

Et si tu veux le joindre depuis l’extérieur, c’est le duo habituel : un nom de domaine avec Duck DNS, et un reverse proxy avec Nginx Proxy Manager devant. Une seule chose à ne pas oublier dans ce cas : TRUST_PROXY. Sans elle, le service voit l’adresse du proxy et te la renvoie à toi comme aux autres.

Les images couvrent amd64, arm64 et arm/v7, donc le même tag marche sur ton PC, ton NAS ou ton Raspberry Pi.

Une clé secrète, pour que les petits malins aillent voir ailleurs

Le jour où ton service est exposé sur Internet, rien n’empêche quelqu’un de s’en servir gratuitement à ta place. Là encore c’est le même mécanisme que sur Image Resizer : tu poses une clé secrète, et le service ne répond plus qu’aux adresses correctement signées.

SIGNATURE_KEY=ta-clé-secrète

Une URL signée porte alors deux paramètres, un horodatage et un HMAC :

/8.8.8.8?d=1770000000&s=cc5849a839193e59

La signature se génère côté serveur, évidemment, avec la clé secrète que tu es seul à connaître. La règle tient en une ligne :

const s = createHmac('sha256', KEY).update(`8.8.8.8?d=${d}`).digest('hex').slice(0, 16);

L’horodatage fait partie de ce qui est signé, donc il ne peut pas être déplacé, et il borne la durée de vie de l’adresse : une heure par défaut. C’est toute la différence entre une URL qui a fuité par accident et une clé volée. Le SIGNATURE.md du dépôt contient la spécification complète, des valeurs de référence pour vérifier ton implémentation, et les mêmes trois lignes écrites en JavaScript, PHP, Python, C# et Java.

Et si tu sais ce que tu fais, réseau privé ou proxy déjà authentifié, tu laisses la clé vide : le service répond à tout le monde, et c’est très bien comme ça.

Ce que ça vaut vraiment

Je ne vais pas te vendre ça comme indispensable. Si tu as besoin de dix géolocalisations par mois, une API externe toute faite te coûtera moins de temps que de monter un conteneur. Et il faut être honnête sur la précision : GeoLite2 est la version gratuite d’une estimation. La ville affichée est souvent celle de l’opérateur, pas celle du visiteur, et un VPN déplace la réponse dans un autre pays. Décider quoi que ce soit d’important là-dessus, un paiement, un droit, une identité, c’est une erreur, quelle que soit la base.

Mais pour ce à quoi ça sert vraiment, remplir la colonne « pays » de tes statistiques, adapter une langue par défaut, repérer d’où arrive un pic de trafic, c’est parfait. Pas de quota, pas de facture qui grimpe avec le trafic, et surtout l’adresse de tes visiteurs qui ne sort jamais de ta machine. C’est exactement pour ça que je m’en sers ici.

Le tout est sur GitHub, en licence MIT. Comme d’habitude, je suis preneur de tout retour, et les pull requests sont les bienvenues.

Image d’en-tête générée par IA.

On ne sait jamais vraiment ce qui tourne

Un Homelab, ça finit toujours pareil. Tu empiles les applis, tu ajoutes une machine, tu testes un truc que tu oublies d’arrêter, et six mois plus tard tu ne sais plus ce qui tourne ni ce que ça coûte.

Et il y a les vraies questions, celles qui arrivent un soir sans prévenir. Pourquoi la machine rame ? Est-ce que j’ai encore assez de RAM pour ajouter un service ? Est-ce que le disque va tenir jusqu’à la fin du mois ? Et la meilleure de toutes : est-ce que quelqu’un m’a posé un cryptomineur sur le serveur ? Parce que ça m’est arrivé, et je peux vous dire qu’on aime bien avoir une courbe sous les yeux ce jour-là.

Bien sûr, vous pouvez toujours vous connecter en SSH et lancer htop, ou docker stats. Ça marche très bien. Mais c’est un instantané : aucun historique, aucune vue d’ensemble sur plusieurs machines, et rien qui vous prévienne pendant que vous dormez. Rien ne vaut un outil graphique.

Je vous présente Beszel. Un outil de supervision vraiment complet, très visuel, et qui ne consomme quasiment rien lui-même. Ce qui, pour un outil censé surveiller la consommation, est plutôt la moindre des politesses.

Deux conteneurs qui se parlent

Le découpage est ce qui rend l’outil aussi simple. Il y a deux morceaux, tous les deux en conteneur :

• le hub, c’est l’interface. Une seule instance, quelque part chez vous. C’est elle que vous ouvrez dans le navigateur ;
• l’agent, qu’on pose sur chaque serveur qu’on veut observer. Il mesure, il envoie, il ne fait rien d’autre.

Conséquence directe : ajouter une machine à la supervision, c’est poser un conteneur dessus. Pas d’installation système, pas de paquet à maintenir, rien à compiler.

La liste, d’abord

Vous installez, vous ajoutez vos serveurs, et hop, tout est là.

Le point vert, le CPU, la mémoire, le disque, le réseau, la température, l’uptime. C’est déjà 80 % de ce qu’on regarde au quotidien, et c’est sur un seul écran.

Le détail, et surtout le détail par conteneur

Ensuite vous cliquez sur un serveur, et là ça devient intéressant.

L’état des disques, la RAM, le processeur, et les entrées/sorties disque, ce qui est hyper important et qu’on oublie tout le temps de regarder. Une machine qui rame sans que le CPU bouge, neuf fois sur dix c’est le disque qui sature.

Mais le vrai truc, c’est la colonne de droite. Chaque courbe est séparée par conteneur. Vous ne voyez pas seulement que la RAM est à 4 Go, vous voyez lequel de vos conteneurs les prend. Et quand une bande rouge grimpe toute seule à deux heures du matin, vous savez immédiatement de qui il s’agit.

C’est parfait pour notre stack, vu que chez nous tout s’installe dans Docker, et que Docker chez nous c’est Portainer. Une bande dans le graphe, une stack dans Portainer, c’est le même objet.

Installer le hub

Comme toujours, un compose. Soit à la main, soit directement en stack dans Portainer, ce qui est ma méthode.

services:
  beszel:
    image: henrygd/beszel:latest
    container_name: beszel
    restart: unless-stopped
    environment:
      APP_URL: http://mon-serveur:8090
    ports:
      - 8090:8090
    volumes:
      - ./beszel_data:/beszel_data
      - ./beszel_socket:/beszel_socket

Vous lancez, vous ouvrez le port 8090, vous créez votre compte administrateur. Et là vous avez l’interface. Mais elle est vide : aucun serveur n’est branché dessus.

Brancher un serveur

Pour ça, direction l’interface, bouton Ajouter Système.

Vous donnez un nom, une adresse et un port. Si vous voulez surveiller la machine du hub elle-même, l’adresse c’est 127.0.0.1, tout simplement. Le port par défaut est le 45876.

Ensuite vous cliquez sur Copier docker compose, puis sur Ajouter Système. Vous créez une nouvelle stack sur la machine à observer, vous y collez ce que vous venez de copier, vous lancez, et hop, elle apparaît dans l’interface de Beszel. C’est tout.

Le compose en question ressemble à ça, avec la clé et le token déjà remplis pour vous :

services:
  beszel-agent:
    image: henrygd/beszel-agent:latest
    container_name: beszel-agent
    restart: unless-stopped
    network_mode: host
    volumes:
      - ./beszel_agent_data:/var/lib/beszel-agent
      - /var/run/docker.sock:/var/run/docker.sock:ro
    environment:
      LISTEN: 45876
      KEY: "ssh-ed25519 AAAA..."
      TOKEN: "le-token-donne-par-le-hub"
      HUB_URL: "http://mon-serveur:8090"

Les deux lignes à comprendre : network_mode: host, indispensable pour que l’agent voie les statistiques réseau de la machine et pas seulement celles de son propre conteneur, et la socket Docker montée en lecture seule, qui est exactement ce qui lui permet de découper par conteneur.

Y accéder de l’extérieur

Vous pouvez aussi lui monter un nom de domaine, avec Duck DNS par exemple, et le brancher derrière Nginx Proxy Manager. Là vous ouvrez votre supervision depuis le téléphone, en HTTPS, sans retenir un port.

Et surtout, ça vous permet d’ajouter des serveurs qui ne sont pas sur votre réseau. Un VPS, la machine d’un copain, un Raspberry chez vos parents : tout ça remonte dans la même interface. C’est sécurisé par clés et chiffré, l’agent n’accepte que le hub qui détient la bonne clé, donc aucun souci de ce côté.

Les alertes, parce qu’on ne regarde pas l’écran toute la journée

Un outil de supervision qu’il faut penser à ouvrir ne sert pas à grand-chose. Beszel sait donc envoyer des notifications, par mail si vous voulez, et il embarque toute la panoplie classique :

• un serveur qui ne répond plus ;
• un processeur en surcharge trop longtemps, ce qui évite d’être réveillé par le moindre pic de deux secondes ;
• un disque qui se remplit ;
• la mémoire, la température, la bande passante.

C’est le genre de réglage qu’on fait une fois et qu’on oublie, jusqu’au jour où le mail arrive et vous évite une vraie panne.

Ce que j’en retiens

Beszel est vraiment un super outil de supervision. Il y a sûrement plus complet ailleurs, du côté de Prometheus et Grafana notamment, mais c’est aussi beaucoup plus lourd à monter et à maintenir. Lui, il est hyper adapté à Docker et à Portainer, il s’installe en dix minutes et il ne coûte rien à faire tourner.

Autrement dit, il est parfait dans notre Homelab. Et depuis que je l’ai posé, je ne me demande plus ce qui consomme : je le vois.

Image d’en-tête générée par IA.

Le problème, ce n’est jamais l’image. C’est ses variantes

Le jour où tu veux un bon référencement et un site optimisé aux petits oignons, tu tombes toujours sur le même mur. Une image, ce n’est pas une image : c’est huit fichiers. Une version pour le mobile, une pour la tablette, une pour le grand écran, et chacune en double pour les écrans à forte densité. Le tout en WebP, parce que le JPEG coûte trois fois plus lourd pour le même rendu.

Et ça, c’est la partie facile. La partie pénible, c’est le contributeur. Il t’envoie une photo de 30 Mo en HEIC sortie de son iPhone, et il s’en fout complètement : il ne regarde même pas. Toi, derrière, tu voulais juste une vignette de 200 pixels de côté.

Il existe des services tout faits pour ça. Généralement payants, et pas forcément clé en main : il faut quand même leur mâcher le travail. Plus j’avais ce problème en tête, plus je me disais qu’il fallait trouver une solution. Et plus je cherchais, moins je la trouvais.

« Allez, ça va prendre 10 lignes de JS »

Bon, j’avais un peu tort. Mais ça a donné Image Resizer, une petite application qui ne fait qu’une chose : elle sert la variante que tu lui demandes, calculée au moment où tu la demandes.

C’est du full JavaScript. Elle tourne dans un conteneur Docker, elle tourne très bien dans Portainer, et elle tourne aussi sur une fonction Lambda serverless. Cette dernière option est celle que je trouve la plus marrante : tu as l’outil pour presque zéro euro, sans serveur, sans rien à maintenir.

L’URL, c’est la commande

Un exemple vaut mieux que dix mots. Voici une image PNG du blog, celle de l’article sur Duck DNS, un canard de 1536 × 1024 pixels. Je lui demande un bandeau de 1024 × 100, en WebP, avec un recadrage cover :

https://smea.tech/img/u/2026/08/duckdns-canard-bouee.png/_cover_1024_100_.webp

Même taille, même image, mais je change la mécanique de redimensionnement et je demande du JPEG :

https://smea.tech/img/u/2026/08/duckdns-canard-bouee.png/_contain_1024_100_.jpg

Rien d’autre n’a bougé que l’adresse. La structure est toujours la même :

/<source>/<chemin/du/fichier>/_<fit>_<largeur>_<hauteur>_<qualité>.<format>

Les champs vides prennent la valeur par défaut, donc /photo.jpg/_.webp suffit à obtenir du WebP correctement dimensionné. Le fit prend les cinq modes de sharp : cover, contain, fill, inside, outside. En sortie, tu as du JPEG, du PNG, du WebP et de l’AVIF. En entrée, il avale même le HEIC de l’iPhone dont je parlais plus haut.

Le choix de tout mettre dans le chemin plutôt qu’en paramètres d’URL n’est pas cosmétique. Chaque variante devient une adresse unique, et une adresse unique, les caches savent quoi en faire. Un ?w=320&h=240, beaucoup moins.

Je m’en sers sur ce blog

WordPress fabrique une demi-douzaine de vignettes à chaque téléversement, les garde pour toujours, et n’en sert jamais que deux ou trois. Le dossier des médias est le seul du site que je ne sais pas régénérer, donc le seul que je sauvegarde, et il grossissait de fichiers que personne ne regarde.

Maintenant je ne range qu’un fichier : l’original, en pleine résolution. Les variantes existent bien sur le disque elles aussi, mais dans le cache nginx, et ça change tout : ce dossier-là se jette et se refait tout seul. Toutes les images que tu vois sur ce blog, y compris celle en haut de cette page, sortent d’ici. La configuration tient en quelques lignes :

  images:
    image: smeagolworms4/image-resizer:latest
    restart: unless-stopped
    user: "${PUID:-1000}:${PGID:-1000}"
    environment:
      SOURCE_U: /uploads
      BASE_PATH: /img
      MAX_SIZE: "2560"
      DEFAULT_QUALITY: "82"
      ALLOWED_FORMATS: jpeg,png,webp,avif
    volumes:
      - ${DATA_DIR}/uploads:/uploads:ro
      - ${DATA_DIR}/img-cache:/cache

Le montage des médias est en lecture seule : le service n’a aucune raison d’écrire dans le dossier qui compte. Et SOURCE_U: /uploads déclare une source nommée u, ce qui explique le /img/u/… des adresses plus haut. C’est important pour la suite : aucune URL ne peut faire requêter au service une source qui n’a pas été déclarée.

Bénéfice inattendu, le jour où j’ai changé la largeur de la colonne du thème, je n’ai eu strictement rien à regénérer. Juste de nouvelles adresses.

Le cache devant, ce n’est pas une option

Le seul vrai bémol, et il faut le dire tout de suite : c’est un outil de redimensionnement, absolument pas un outil de cache. Il garde bien les originaux téléchargés et quelques conversions coûteuses sous le coude, mais chaque variante est calculée à la volée. Si tu ne mets rien devant, ton CPU va encaisser.

Donc tu mets un cache. nginx, Varnish, CloudFront, Cloudflare, ce que tu veux. Image Resizer est fait pour vivre derrière : il émet déjà les bons en-têtes, Cache-Control avec un s-maxage long, ETag, stale-while-revalidate. Chez moi c’est nginx, et voilà l’essentiel de la configuration :

proxy_cache_path /var/cache/nginx/images levels=1:2 keys_zone=images:50m
                 max_size=20g inactive=90d use_temp_path=off;

location ^~ /img/ {
    proxy_pass http://images:3000;

    proxy_cache images;
    proxy_cache_valid 200 90d;
    proxy_cache_valid 400 404 1m;
    proxy_cache_lock on;
    proxy_cache_use_stale updating error timeout http_500 http_502 http_503;

    # Tout est dans le chemin : ignorer les paramètres évite qu'un lien
    # traînant un ?utm_source crée une seconde entrée pour la même image.
    proxy_cache_key $uri;
}

Les deux lignes qui font tout le travail sont proxy_cache_lock et proxy_cache_use_stale. La première garantit qu’une rafale de requêtes sur une variante encore froide ne déclenche qu’un seul calcul, et pas cinquante en parallèle : c’est exactement ce genre de bousculade qui met un redimensionneur à genoux. La seconde fait qu’une variante déjà servie continue de l’être même si le service est arrêté.

Sur Lambda, ça coûte à peu près rien

C’est le mode que je préfère pour un petit site. Tu n’as ni serveur à louer, ni conteneur à surveiller, et la facture suit strictement l’usage.

Chaque version publie une archive zip prête à déposer, une par architecture. Prends celle en arm64 : sur Graviton, c’est environ 20 % moins cher à l’usage, et ça marche exactement pareil. L’archive fait dans les 10 Mo compressés, on est très loin des limites d’AWS.

La marche à suivre tient en quatre points :

• créer la fonction en Node.js 22, architecture arm64, et déposer le zip ;
• mettre le handler sur src/lambda.handler, la mémoire à 2048 Mo et le timeout à 30 secondes ;
• poser les variables d’environnement : tes sources, plus CACHE_DIR=/tmp/cache parce que /var/task est en lecture seule, et HEIC_ENABLED=false puisque l’outil de conversion n’existe pas dans le runtime ;
• activer une Function URL pour avoir une adresse publique, et c’est emballé, c’est pesé.

N’oublie surtout pas le CloudFront devant, avec la politique CachingOptimized et le transfert des paramètres d’URL désactivé. Sans lui, la même vignette est recalculée et facturée à chaque affichage, et l’intérêt de la manœuvre disparaît. Tout est détaillé dans le LAMBDA.md du dépôt.

Un piège dans lequel je suis tombé : si l’architecture du zip ne correspond pas à celle de la fonction, tu récupères un Could not load the sharp module parfaitement opaque. Vérifie ce point avant de chercher ailleurs.

Une clé secrète pour que personne ne s’amuse

Une adresse d’image est publique par définition, et rien n’empêche un plaisantin de demander 10 000 variantes différentes juste pour voir. On peut fermer la porte en générant une clé secrète : le service signe alors chaque URL en HMAC, et une adresse fabriquée à la main est refusée.

SIGNATURE_KEY=ta-clé-secrète

La signature se glisse dans le preset, avant l’extension :

/photos/beach.jpg/_cover_320_320_80_3dc222d73386b95c.webp

Dans le même esprit, les métadonnées sont supprimées par défaut à la sortie. Les données GPS de la photo prise avec le téléphone ne finissent pas en ligne sans que personne ne l’ait demandé.

C’est du MIT, et j’attends vos retours

C’est un outil vraiment pratique pour un site web, même petit. Il tourne facilement, et même sans conteneur si le cœur t’en dit. Les images publiées couvrent amd64, arm64 et arm/v7, donc le même tag marche sur ton PC, ton NAS ou ton Raspberry Pi.

Le tout est sur GitHub, en licence MIT. Je suis bien sûr friand de tout retour, et les pull requests sont les bienvenues si vous voulez bosser avec ou dessus.

Image d’en-tête générée par IA.

Un NAS, c’est quoi au juste

NAS, ça veut dire Network Attached Storage. En gros, un espace de stockage sur le réseau. Une machine allumée en permanence, avec des disques dedans, et tous tes autres appareils qui viennent lire et écrire dessus comme si c’était un dossier local.

Tu en trouves des tout faits, clé en main, chez Synology par exemple. J’en ai moi-même un vieux, mais il est là comme outil secondaire. Sauf que c’est aussi possible de s’en fabriquer un soi-même. Oui oui, avec un vieil ordi ou un Raspberry Pi.

Le mien : un Raspberry Pi 5 et une pile de disques USB

Moi j’en ai fait un avec un Raspberry Pi 5 et des disques durs externes. On peut lui associer une carte RAID, ou brancher des disques SATA en direct sur une machine qui a ce qu’il faut. Chez moi c’est juste des disques durs branchés en USB 3 sur un hub USB 3.

Plusieurs disques, c’est important. Par contre, pas de réplication. Je stocke des films, des séries, quelques données, des jeux. Rien d’irrécupérable, rien d’important. Pour ça j’ai justement mon vieux Synology, et un duplicata en ligne (je vous parlerai de Duplicati un jour).

Le but, c’est d’avoir plein de place disque, de stocker de façon plutôt fiable sans se prendre la tête, et que tout ça soit accessible sur le réseau. Rien de plus.

Et c’est là qu’arrive Open Media Vault

C’est l’outil NAS open source, facile et ouvert. Oui, c’est pas parfait. Des fois ça galère un peu. Mais ça marche, ça répond au besoin, et ça a une vraie interface web de gestion. C’est plutôt cool.

On parlera après de comment on l’installe sur un Raspberry Pi ou ailleurs. Mais en tout cas, une fois dedans, tu vois tes disques durs.

Disque, partition, dossier partagé

Tu formates tes disques comme il faut. Moi je les mets en ext4, mais je sais qu’on peut faire du BTRFS et d’autres choses. Ensuite tu montes tes partitions.

Après tu peux créer des dossiers partagés. Mais attention, ça, c’est juste pour les marquer prêts au partage pour les différents services. Le dossier partagé n’est pas encore partagé, il est juste déclaré.

Les services, c’est eux qui partagent vraiment

Et ces services, c’est quoi ? Eh bien ce n’est ni plus ni moins que Samba (la lalala) pour partager le dossier vers Windows, ou NFS pour tout ce qui est Linux ou Mac.

Mais aussi du FTP, que je ne vais pas forcément expliquer ici. Du Rsync pour synchroniser des données. Du SSH et du SFTP. Il y a des tonnes de services, et des plugins qu’on peut rajouter par dessus.

Et hop, tu as ton dossier partagé.

Pas parfait mais ça marche et c’est simple

Alors oui, c’est pas parfait, comme je disais. Je trouve parfois l’interface pas super pratique : il faut valider chaque changement, à chaque fois. Et la chaîne disque, puis partition montée, puis dossier partagé, puis service qui utilise ce dossier, ça peut paraître un peu rebutant au début.

Mais ça marche. Et une fois que c’est en place, à part rajouter un disque de temps en temps, on n’y touche plus trop. Surtout que même si je ne m’en sers pas, il y a du RAID physique ou logiciel, et plein d’options que je n’approche même pas. C’est vraiment complet.

L’installer

Sur une machine x86, il y a une image ISO toute faite. Tu la graves ou tu la mets sur une clé USB, tu démarres dessus, et c’est un installeur classique. Là on ne passe pas par Portainer, c’est trop intégré pour ça, mais on verra après qu’on lui met un Portainer dedans.

Pour un Raspberry Pi (un Pi 5 chez moi), tu installes Raspberry Pi OS Lite avec Imager. Lite, pas la version bureau : le script d’installation détecte l’environnement graphique et refuse tout net de continuer. Tu branches un câble réseau, tu mets à jour, et c’est parti :

sudo apt-get update
sudo apt-get upgrade -y
wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/preinstall | sudo bash
sudo reboot

Puis, une fois redémarré, l’installation elle-même :

wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/install | sudo bash

Comptez jusqu’à une demi-heure, le Pi redémarre tout seul à la fin, et c’est bon sur http://adresse.ip.du.serveur avec admin / openmediavault. Pas très complexe.

Le preinstall, celui du premier bloc, ce n’est pas l’installeur, et il n’est pas obligatoire : l’installation passe très bien sans lui, le second script ne le réclame nulle part. Il fait deux choses. Il vire cloud-init, qui se bat avec Open Media Vault pour la configuration réseau. Et surtout il lit l’adresse MAC de ta carte réseau et fige le nom de l’interface sur eth0, une fois pour toutes.

C’est ce deuxième point qui vaut les trente secondes. Sur une machine sans écran ni clavier, une interface qui change de nom au redémarrage, c’est une machine que tu ne retrouves plus. Et tant qu’on y est, dans le même esprit : ne préconfigure pas le wifi et ne touche pas à raspi-config avant l’installation. Le câble réseau et rien d’autre, le script se débrouille avec le reste.

Pourquoi pas dans Docker, mais avec Portainer dedans

Un dernier point important. Open Media Vault, je ne le mets pas dans Docker, parce que c’est vraiment intégré à l’OS. C’est l’OS lui-même, en vrai. En plus il n’y a pas vraiment d’image Docker d’Open Media Vault, lol. Le script d’installation refuse même de démarrer s’il détecte qu’il tourne dans un conteneur, il te sort OMV does not work in Docker! et il s’arrête là. Comme Home Assistant, c’est l’autre exception à ma règle du tout-Portainer.

Mais ça ne veut pas dire qu’on ne peut pas mettre Portainer dans Open Media Vault. D’ailleurs c’est exactement ce que je fais. J’installe le module docker compose d’Open Media Vault, je crée un dossier partagé pour les fichiers dont Docker a besoin, et le seul compose que je lance avec, c’est Portainer.

Après, je passe dans Portainer lui-même. Je branche mes DNS avec Nginx Proxy Manager, et c’est tout.

Résultat : j’ai une machine NAS qui gère mes fichiers à distance, avec Portainer par dessus pour les applis externalisées, et en plus les services de fichiers d’Open Media Vault lui-même. Si ça vous intéresse, je vous parlerai de File Browser dans un autre article, celui-là permet de naviguer dans vos fichiers depuis une page web.

Le dernier morceau du puzzle

C’est le dernier gros chantier de mon Homelab. Avec lui, la boucle est bouclée : le NAS pour les fichiers, Jellyfin pour les médias, les DNS mappés avec Nginx Proxy Manager, et Portainer pour structurer les applications et leurs versions.

Comme je disais, il n’est pas parfait. Mais il fait vraiment bien le travail et il répond à tous les besoins.

Je dis pas que c’est fini, hein. Le NAS aussi sera utile, et c’est l’article suivant parce que c’est un gros morceau. Mais niveau plomberie, le reverse proxy c’est le dernier maillon, ou plutôt le dernier tuyau ^^.

Un reverse proxy, c’est quoi

C’est simple. C’est lui qui va te dire : tel domaine, genre jellyfin.mon-homelab.duckdns.org, c’est telle appli, sur telle machine, sur tel port.

Parce que sans lui, ta vie ressemble à ça : tu retiens que Jellyfin c’est le port 8096, que ton Portainer c’est le 9443, que ton autre truc c’est le 7575, et tu tapes des adresses IP à la main dans ton navigateur. Sur ton téléphone, à l’extérieur, bon courage.

Avec un reverse proxy, tu tapes jelly.mon-domaine.fr et c’est réglé. Ça marche. Pour peu que le domaine soit bien branché sur ton IP, et là on en revient à Duck DNS, lol.

Les trois briques qui vont ensemble

Dans mon homelab, tout tient sur trois trucs, et ils marchent en équipe.

Portainer, d’abord : c’est là que j’héberge toutes mes applis. Ensuite les applis elles-mêmes, comme mon relais POP3 vers SMTP ou Jellyfin. Et enfin Nginx Proxy Manager, le reverse proxy, celui qui donne une vraie URL à tout ça.

Tu configures le tout sur Duck DNS si tu veux du gratuit, ou sur un vrai domaine à toi avec autant de sous-domaines que tu veux. Le principe est identique.

Pourquoi Nginx Proxy Manager Plus (et oui, le Plus est important)

Parce qu’en vrai il est hyper hyper simple. Voyez vous-même.

Là on a des domaines qui pointent vers tel port de ma machine. Jellyfin tourne dans Portainer sur le port 8096, sur telle machine : tu lui dis jelly.mon-domaine.com, tu remplis deux champs, et c’est réglé.

Nginx Proxy Manager se veut hyper simple, mais il reste ultra configurable, avec des options avancées quand tu en as besoin. Il gère aussi les authentifications HTTP classiques, vous savez, quand le navigateur te demande un identifiant et un mot de passe avant même d’afficher la page. Et le filtrage par IP. Bref, tout ce que vous voulez.

Le Plus, c’est quoi au juste

Le Plus, c’est juste un fork qui rajoute des options. NPMplus, de son vrai nom. Grosso modo, voilà ce qu’il ajoute par rapport à l’original :

• CrowdSec se branche beaucoup plus facilement dessus. C’est un genre de fail2ban moderne et communautaire : il lit tes logs, repère les comportements pourris, et bannit. La différence, c’est que les signalements sont partagés entre tous les utilisateurs, donc tu bloques des IP malveillantes avant même qu’elles t’aient visé.
• Un SSO, c’est-à-dire une authentification unifiée. Tu te connectes une fois, et tous tes services derrière le proxy te reconnaissent. Il sait causer OpenID Connect, et se brancher sur Authelia, Authentik, VoidAuth ou tinyauth.
• Du HTTP/3, du Brotli et du Zstd, du mTLS, et une config TLS bien plus sévère par défaut.
• GoAccess intégré, pour avoir des stats de fréquentation lisibles sur tes logs nginx.

Mais rien de tout ça n’est obligatoire. Vraiment rien. Tu peux l’installer et ne jamais toucher à ces options, il marchera exactement comme l’original.

Parce que même Nginx Proxy Manager sans le Plus, c’est une révolution. Avant, on utilisait Traefik, ou directement nginx. Et je vous assure que se taper les fichiers de config à la main, c’était une plaie. Un server, un location, les en-têtes à recopier, le certificat à pointer, un rechargement, une virgule oubliée, on recommence. Maintenant c’est quelques clics et c’est fait.

Le truc que tous les admins web détestent : le HTTPS

J’allais oublier, et c’est peut-être le plus gros morceau. Il gère Let’s Encrypt de façon quasi automatisée. Tu coches une case, tu mets ton adresse mail, et tu as ton certificat. Le renouvellement se fait tout seul.

Il sait même le faire en mode DNS si tu veux un certificat wildcard, du genre *.mon-domaine.fr, valable pour tous les sous-domaines d’un coup. Perso je n’en ai jamais eu besoin, lol, mais c’est là.

Quand on se souvient du temps où obtenir et renouveler un certificat était une corvée trimestrielle, franchement, ça pique.

L’installer

Tu passes par Portainer, ou par un compose à la main. Mais bon, on a mis un super Portainer, pourquoi s’en priver.

Attention, celui-ci c’est bien le compose de NPMplus, pas celui de l’original :

name: npmplus
services:
  npmplus:
    restart: unless-stopped
    image: docker.io/zoeyvid/npmplus:latest
    network_mode: host
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE
      - SETGID
    security_opt:
      - no-new-privileges:true
    volumes:
      - "/opt/npmplus:/data"
    environment:
      - "TZ=Europe/Paris"

Le network_mode: host n’est pas là par hasard : le conteneur doit écouter sur les ports 80 et 443 de la machine, c’est lui la porte d’entrée. L’interface d’administration, elle, arrive sur le port 81, en HTTPS. Au premier démarrage il te génère un mot de passe aléatoire et l’écrit dans les logs du conteneur : va le chercher là, tu ne le trouveras nulle part ailleurs.

Le proxy qui se sert lui-même

Et là il y a un truc que je fais systématiquement : je rajoute nginx.mon-homelab.com dans NPM lui-même, pointé sur son propre port 81. Et ça marche vraiment.

Concrètement, tu ouvres l’interface sur https://ip-de-la-machine:81, tu cliques sur « Add Proxy Host », et tu remplis quatre champs :

• Domain Names : nginx.mon-homelab.com
• Scheme : https, parce que l’interface de NPMplus ne parle qu’en HTTPS
• Forward Hostname / IP : 127.0.0.1, la machine se parle à elle-même
• Forward Port : 81

Puis tu passes sur l’onglet SSL, tu choisis « Request a new SSL Certificate », tu coches « Force SSL », et tu enregistres. Le certificat est demandé dans la foulée.

À partir de là tu administres ton reverse proxy depuis https://nginx.mon-homelab.com, avec un vrai certificat reconnu. Fini l’adresse IP et le numéro de port à retenir, fini l’avertissement du navigateur sur le certificat auto-signé.

Un conseil quand même : sur celui-là, mets une Access List, ou un filtrage par IP, ou ton SSO. C’est la porte d’entrée de tout le reste, autant ne pas la laisser grande ouverte sur Internet.

C’est lui qui change tout

Je vous le dis, c’est vraiment le dernier maillon d’une chaîne d’outils qui vont ensemble. Il ne faut pas l’oublier. Portainer héberge, les applis tournent, Duck DNS fait arriver le monde chez toi, mais c’est le reverse proxy qui rend tout ça utilisable au quotidien.

Essayer, c’est l’adopter.

Image d’en-tête générée par IA.

Parce qu’on a tous pris l’habitude avec Netflix. Un truc fluide, joli, où tu retrouves toutes tes séries et tes films au même endroit. Tu choisis, t’as le résumé, la jaquette, les acteurs, parfois même la bande-annonce. C’est vraiment bien fait. Et à l’époque c’était même pas cher.

Sauf qu’il y a des gens qui ont voulu garder leur indépendance là-dessus. Ne pas payer dix abonnements différents pour retrouver le catalogue qu’ils avaient déjà chez eux. C’est comme ça que Plex est né.

Plex, le roi qui doit tomber

Alors pourquoi je vous parle de Plex dans un article sur Jellyfin ? Parce que dans les serveurs multimédia, Plex domine le marché. C’est le premier, c’est le roi. Mais le roi doit tomber, et il va forcément tomber.

Petit point d’histoire. Plex est né pour répondre au besoin, et en face il avait un concurrent direct : Emby. Libre, mais piloté par une boîte, et qui avançait moins vite. Plex était gratuit mais fermé, Emby était libre avec quelques options payantes ou à compiler soi-même.

Et puis Plex a mis des prix. Un abonnement, puis un pass à vie. Et ce pass à vie, regardez le chemin qu’il a fait :

Fois dix. Oui oui, fois dix. Pour regarder des fichiers qui sont sur ton disque dur, chez toi. Ils ont même sorti un pass cinq ans à 249,99 $ dans la foulée, histoire de rattraper ceux que le prix à vie a fait fuir.

Emby, lui, a essayé de s’en sortir mais n’a jamais trouvé son modèle économique. Fin 2018, il a fermé son code. Et c’est exactement là que Jellyfin est né : un fork d’Emby, lancé en décembre 2018, à partir de la dernière version encore libre.

Aujourd’hui, Jellyfin a largement dépassé Emby. Et selon moi il a aussi largement dépassé Plex. Plex garde son avance parce qu’il est le plus ancien et que beaucoup de gens ont un pass à vie. Mais il est moins ouvert, moins simple à configurer, et je trouve qu’il a finalement moins de fonctionnalités. Pendant ce temps Jellyfin évolue tellement plus vite que c’est ouf.

Plex, c’est l’Internet Explorer du serveur multimédia. Mdr.

Un serveur multimédia, c’est quoi au juste

C’est un Netflix perso. Et pour l’utiliser il te faut deux choses.

D’abord un serveur : c’est lui qui héberge tes médias, qui les range, les trie, les décrit, les détaille, et les prépare à être lus. Ensuite un client pour lire tout ça, à distance. À distance, oui, mais à distance ça peut très bien être ton serveur qui est à deux mètres dans le meuble d’à côté.

Des clients, il y en a de toutes sortes. Sur TV LG, tu l’installes directement (et si tu la rootes, il y a même des alternatives). Sur Android, il y a une pléiade d’applis en plus de l’officielle, qui marche déjà très bien. Sur certains Samsung et sur les autres télés, il faut juste tripatouiller un peu. Et bien sûr il y a le client web : tu ouvres une page, et ça marche.

Le serveur, c’est ça la différence avec un lecteur comme VLC, ou même avec Kodi qui est très connu. Kodi, il est le client et le serveur à la fois. Tu dois limite avoir un Kodi par appareil. Alors qu’avec Jellyfin, là tout de suite, mon fils regarde Il était une fois la vie sur sa tablette pendant que je regarde House of the Dragon sur la télé. Il est pas dans la même pièce que moi je vous rassure mdr.

Ce que ça donne une fois rangé

En face tu te retrouves avec la liste de tes médias préférés, rangée comme tu veux. Il détecte automatiquement le film, la jaquette, l’épisode, les détails, la description, les vignettes, les chapitres, la bande-annonce. Tout.

Et tu peux aussi tout ajuster à la main pour bien ranger, si t’es monomaniaque comme moi. Avoir tous les épisodes spéciaux, et même la petite vidéo bonus trouvable uniquement sur des sites de vidéo perdus au fin fond d’internet.

Il y a aussi des plugins : sous-titres automatiques, webhooks, Trakt.tv. Par rapport aux concurrents, il est hyper facile à ranger, à éditer, à ajuster les métadonnées comme on veut. C’est énorme et c’est très bien fait.

Le transcodage, le seul truc qui coûte cher

Alors est-ce que tout est parfait ? Oui et non. Jellyfin peut être assez gourmand, et surtout sur une chose : le transcodage. Ce qui n’est pas obligatoire, et c’est pareil chez Plex ou Emby.

En gros, si le client est pas capable de lire le codec de la vidéo, ou s’il veut une résolution plus faible parce qu’il a un débit de merde, alors Jellyfin est capable de transcoder la vidéo à la volée. Il repasse le média dans le bon codec en temps réel, et le client y voit que du feu.

Sauf que transcoder, ça se paye en CPU. Sauf si tu laisses le boulot à une puce faite pour ça.

Le matériel : pourquoi j’ai pris un N100

On va vous conseiller un PC correct avec une carte NVIDIA, parce qu’elles sont assez balèzes pour faire ça. Et c’est vrai, ça marche très bien.

Mais moi j’ai visé une autre approche : un mini PC en N100, avec sa carte graphique intégrée. Elle décode de l’AV1, du H.265 et bien sûr du H.264 (celui que réclament tous les clients ou presque) ultra rapidement. Et il y a un truc auquel tout le monde pense pas : il consomme entre 11 W et 30 W au pire des moments. C’est minuscule.

Un Raspberry Pi 4 est vraiment limite, mais il a au moins un bloc de décodage et d’encodage H.264. Pas hyper fiable, mais ça marchera. Par contre je déconseille énormément le Pi 5 : il n’y a plus du tout d’encodage H.264 dessus. Pour un serveur multimédia c’est rédhibitoire.

Le N100 est limite fait pour ça. C’est plutôt magique. C’est d’ailleurs la machine dont je vous parlais dans l’article sur Home Assistant : je l’ai gardée pour Jellyfin.

L’installer, en Docker évidemment

Et bien sûr, Portainer c’est l’idéal, ou en Compose direct. Le compose de base tient en quelques lignes, il vient de la doc officielle :

services:
  jellyfin:
    image: jellyfin/jellyfin
    container_name: jellyfin
    user: 1000:1000
    ports:
      - 8096:8096/tcp
      - 7359:7359/udp
    devices:
      - /dev/dri:/dev/dri
    volumes:
      - /chemin/vers/config:/config
      - /chemin/vers/cache:/cache
      - type: bind
        source: /chemin/vers/mes/medias
        target: /media
    restart: unless-stopped

La ligne devices avec /dev/dri, c’est ce qui donne au conteneur l’accès à la puce graphique. Sans elle, pas d’accélération matérielle, et c’est ton processeur qui va souffrir.

Chez moi, je monte les disques de mon NAS en NFS. Mais sinon un accès aux fichiers quelconque suffit. Attention par contre : Jellyfin ne gère pas les volumes distants tout seul. Il faut que le montage soit déjà fait côté machine. NFS ou CIFS, c’est parfait.

Ensuite tu accèdes à http://adresse-du-serveur:8096, tu suis l’assistant, tu pointes tes dossiers, et il fait le reste. Après ça tu peux connecter ton client sur ton téléphone, ta télé, ce que tu veux.

Libre, gratuit, et vraiment

C’est libre, c’est gratuit, sans option d’abonnement caché (oui Plex, on te voit). Et ça marche vraiment bien.

Si vous avez une collection qui traîne sur un disque dur et que vous la regardez encore en branchant une clé USB sur la télé, essayez. Vous reviendrez pas en arrière.

Image d’en-tête générée par IA.

Ça a commencé par une news sur GOG

Il y a quelque temps, j’ai vu passer la news : GOG allait sortir une version native Linux de GOG Galaxy. J’étais content, et dans ma tête ça cogite. Je me dis tiens, je vais aller voir les jeux gratos sur Prime Gaming.

Sauf que ça a changé de nom, c’est rangé ailleurs, bref c’est le bordel. Je ne retrouve plus mes jeux, j’en ai marre.

Et là je commence à me demander combien de jeux Epic j’ai loupés. Combien de jeux Prime aussi. Je me souviens que The Witcher a été offert un jour, un jeu que j’ai toujours voulu faire. Enfin je suppose, en fait j’en sais rien : je n’y ai jamais joué, alors que j’ai lu les bouquins.

10 000 clics pour rien

Récupérer ses jeux gratuits, c’est une perte de temps. Quatre sites, quatre connexions, cliquer, valider, recommencer. C’est long, c’est pour rien, et de toute façon tu en oublies tout le temps.

Entre-temps, au taf, on m’a fait faire les tests end to end de l’appli. En gros, des tests où le navigateur se pilote tout seul pour vérifier que l’interface marche. Et là, le déclic : ça suffit, on va automatiser tout ça.

claim-auto : tu branches tes comptes, il fait le reste

Ça a donné claim-game-auto. Tu connectes tes comptes Epic, Steam, GOG et Prime Gaming une bonne fois, il analyse les jeux gratuits du moment et les ajoute directement dans tes collections. Avec leur clé quand il y en a une. Zéro clic, ou presque.

Il tourne deux fois par jour par défaut, mais la planification se règle. Le reste du temps, tu ouvres la page quand tu veux voir ce qui est tombé.

Le « ou presque », c’est les captchas

Pour en arriver là, j’ai tranché deux choses.

La première : la connexion n’est pas en full API. L’outil lance de vrais navigateurs, dans des environnements virtuels cachés, et clique comme le ferait un humain. C’est ce qui permet de couvrir quatre boutiques qui n’ont aucune envie qu’on automatise quoi que ce soit. Et forcément, à un moment, un anti-captcha se réveille.

La deuxième découle de la première : quand un captcha est détecté, l’interface te propose d’ouvrir une fenêtre VNC, du contrôle à distance, sur ce navigateur caché. Mais dans une page web. Oui, un navigateur dans ton navigateur, lol. Tu résous le truc à la main, tu cliques sur « J’ai fini », le VNC se coupe et tout repasse en headless.

C’est le même écran qui sert pour les connexions initiales, mot de passe et 2FA compris. Une fois le profil enregistré, tu n’y reviens plus. Et il récupère même tes clés GOG et Legacy Games tout seul.

Une notif quand il a besoin de toi

Par-dessus ça, il peut te prévenir. Quand un captcha bloque, il t’envoie une notification sur le canal que tu veux : Discord, Telegram, Slack, ntfy, un webhook maison, un mail, ou même un SMS si tu es chez Free. Tu cliques sur le lien reçu et ça t’ouvre directement le contrôle à distance sur le navigateur coincé, celui de juste au-dessus. Tu règles le captcha, et la réclamation repart toute seule derrière.

Et si vraiment ça coince, l’interface te donne les liens directs pour claim à la main, à l’ancienne. Comme ça, même si un problème persiste, ça reste gérable.

L’installation, c’est un docker compose

Rien à cloner, rien à compiler : l’image est publiée sur Docker Hub. Tu fais un compose, ou tu le colles direct dans Portainer (va voir l’article), tu verras c’est hyper simple.

services:
  claim-auto:
    image: smeagolworms4/claim-game-auto:latest
    container_name: claim-auto
    restart: unless-stopped
    stop_grace_period: 45s
    user: "${PUID:-1000}:${PGID:-1000}"
    env_file:
      - .env
    environment:
      HOME: /data/home
    ports:
      - "${WEB_PORT_HOST:-8080}:8080"
    volumes:
      - ./data:/data
    shm_size: "1gb"

Tu lances, tu ouvres 127.0.0.1:8080, et tu connectes tes boutiques une par une. Il y a même une image pour Raspberry Pi.

Si tu l’exposes sur le web, mets un mot de passe

Attention à ce point, il est important : cette interface donne accès à tes comptes de jeu. Quelqu’un qui l’ouvre est connecté à ton Steam et à ton Epic. Donc si tu la sors de chez toi, tu remplis WEB_USER et WEB_PASSWORD, et tu ne publies pas les ports 6080 et 5900 : le VNC passe déjà par l’interface web, protégé par la même authentification.

Pour le nom de domaine, Duck DNS fait très bien l’affaire. Derrière, il te faut un reverse proxy pour gérer le certificat et l’aiguillage. Chez moi c’est Nginx Proxy Manager, et voilà, l’article est là.

C’est fait main, et j’attends vos retours

Je préfère être clair : c’est fait main et peu testé, c’est loin d’être parfait. Les quatre boutiques changent leurs pages quand elles veulent et leurs protections aussi, et régler ce genre de chose est assez complexe. Claudio m’a déjà bien aidé, mais il reste sûrement plein de cas que je n’ai pas vus.

Donc n’hésitez pas si vous avez des soucis, et surtout si vous avez des solutions. Les correctifs et les ajustements sont les bienvenus.

Moi, je voulais surtout tester. Pour le moment ça marche. Peut-être que ça passera plus dans six mois, on verra. Ça ne m’a pas coûté trop de temps à faire, donc à voir. J’attends vos retours.

Image d’en-tête générée par IA.

Pour faire ça bien, il faut deux choses

Une IP fixe, et un nom de domaine. Si tu n’as pas les deux, c’est la galère. Pas impossible, mais la galère.

L’IP fixe, c’est ce qui garantit que l’adresse de ta box aujourd’hui sera la même demain. Le nom de domaine, c’est ce qui t’évite de la retenir. Les deux ensemble, tu tapes un nom dans le navigateur et tu tombes chez toi, point.

Le cas de l’IP partagée, on en reparlera

Je ne vais pas te parler ici du cas où ton IP publique est mutualisée avec d’autres abonnés. J’ai Starlink, c’est exactement ma situation, et je te le dis tout de suite : c’est la merde. Tous tes ports ne sont pas disponibles, et ceux que tu obtiens ne sont jamais les mêmes. Ça mérite son propre article, je le ferai.

Là je pars du cas normal : une IP peut-être dynamique, mais au moins tu es seul dessus.

Le nom de domaine, ce n’est pas cher, mais c’est mieux si c’est 0

Un nom de domaine, ça ne coûte pas grand-chose. Une dizaine d’euros par an chez n’importe quel registrar. Chez OVH il y a même du DNS dynamique. Mais c’est pas 0, et pour du homelab tu as vite l’impression de payer pour pas grand-chose.

Et c’est là que Duck DNS entre en jeu.

Duck DNS, c’est gratuit et ça suffit

En gros, c’est un DNS gratuit. Tu te connectes avec ton compte Google, GitHub, Reddit ou Twitter, tu choisis un nom, et tu récupères un jeton. C’est tout.

Alors oui, il y a duckdns.org dedans. Ton domaine à toi ce sera toto.duckdns.org, pas toto.fr. Mais bon, c’est gratuit, on ne râle pas. Tu associes une IP, et hop, tous les sous-domaines et les sous-sous-domaines que tu veux pointent chez toi. nas.toto.duckdns.org, media.toto.duckdns.org, ce que tu veux : tout arrive au même endroit, à toi de trier derrière avec un reverse proxy.

Au lieu de taper 88.33.55.99 dans ton navigateur, tu tapes toto.duckdns.org et tu es sur ta machine. Il faudra quand même router les ports sur ta box, mais si tu as configuré un client torrent un jour dans ta vie, tu sais faire, mdr.

L’IP dynamique, avant et maintenant

Le vrai must de Duck DNS, c’est qu’il gère les IP dynamiques. Ton fournisseur te change d’adresse en pleine nuit ? Le nom continue de pointer au bon endroit.

À mon époque, on faisait tourner ADSL Auto Connect avec No-IP par-dessus. Ceux de mon âge s’en souviendront, avec le petit exécutable planqué dans la barre des tâches qui tombait une fois sur deux. Aujourd’hui c’est un petit compose Docker et c’est réglé. Si tu ne vois pas de quoi je parle, va d’abord jeter un œil à l’article sur Portainer et les conteneurs, ça te remettra dans le bain.

services:
  duckdns:
    image: lscr.io/linuxserver/duckdns:latest
    container_name: duckdns
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Paris
      - SUBDOMAINS=toto
      - TOKEN=ton-jeton-duckdns
      - UPDATE_IP=ipv4
      - LOG_FILE=false
    volumes:
      - ./config:/config
    restart: unless-stopped

Trois lignes à changer et c’est plié. SUBDOMAINS, c’est juste la partie de gauche : si ton domaine est toto.duckdns.org, tu mets toto, pas le nom complet. Tu peux en mettre plusieurs, séparés par des virgules, sans espace. TOKEN, c’est le jeton que Duck DNS t’affiche sur ton compte. UPDATE_IP accepte ipv4, ipv6 ou both selon ce que ta connexion sait faire.

Une fois lancé, le conteneur va contacter Duck DNS toutes les cinq minutes pour dire « voilà mon IP du moment ». Il ne fait que ça, il ne consomme rien, et tu l’oublies. Si tu veux garder une trace des changements d’adresse, tu passes LOG_FILE à true et tu le retrouves dans le volume /config.

Un nom qui pointe chez toi, et c’est déjà beaucoup

Une fois que c’est configuré, tu as un nom de domaine qui pointe vers ton IP, dynamique ou pas. C’est la première brique, celle sans laquelle rien d’autre n’est accessible de l’extérieur. Derrière, tu peux poser un reverse proxy, des certificats, de l’authentification, mais il faut bien commencer par un nom qui arrive quelque part. Chez moi c’est Nginx Proxy Manager qui s’occupe de tout ça.

Et si par malheur ton IP est mutualisée, on en reparlera. C’est moins cool, désolé.

Image d’en-tête générée par IA.

Home Assistant, c’est quoi

C’est le cerveau de la maison. Un logiciel libre que tu fais tourner chez toi, sur ta machine, qui va parler à tous tes appareils connectés quelle que soit leur marque et leur techno, et te donner un seul endroit pour tout voir et tout piloter. Pas de cloud obligatoire, pas d’abonnement, pas de service qui ferme dans deux ans en emportant tes ampoules avec lui.

Tu branches ta box, ton imprimante, tes prises, tes capteurs, ta voiture, et tout ça se retrouve au même endroit. Après, tu fais ce que tu veux avec : des tableaux de bord, des automatisations, des notifications.

Le pilier, parce que tout passe par là

J’ai des Alexa à la maison (oui, je préférerais ne pas en avoir, mais compliqué d’avoir mieux pour le moment). Elles communiquent avec Home Assistant. Et c’est là qu’est toute l’astuce : je mets pas mes appareils sur Alexa, je mets Home Assistant sur Alexa. Une seule intégration, et tout ce que connaît Home Assistant devient pilotable à la voix. Le jour où je change d’assistant vocal, je change une brique, pas cinquante appareils.

Pareil pour le reste. Je dois contrôler l’état d’un appareil, faire une action, ou même surveiller un de mes serveurs du home lab, c’est Home Assistant qui gère. Il est au centre, et tout le reste se branche dessus.

Grosso modo, mon install

J’ai des relais de différentes marques, du wifi et du Zigbee (si ça vous parle pas, j’y reviendrai dans un billet dédié). Je vais pas vous détailler tout ce que j’ai, sinon l’article fera 200 pages lol, je garde pour la suite. Mais un petit exemple : je contrôle toutes mes lumières, mes volets, les températures. Et même ma piscine (je vis à la campagne, ça donne certains avantages ).

On peut aussi gérer sa consommation électrique. Avec des appareils dédiés, ou sans : on peut remonter les infos Enedis directement (je vous en parlerai aussi, même si finalement je m’en sers plus, j’ai la donnée en direct).

La domotique ne s’arrête pas au physique

C’est là que je voulais en venir. Une ampoule connectée ou un volet, c’est vrai que c’est assez facile à imaginer. Mais tout ce qui est virtuel rentre dedans aussi.

L’état d’un serveur Minecraft. Ta télé connectée. Plex, Jellyfin. Ton imprimante. L’état de ton PC, ou de ton home lab. Tous les services que renvoie internet. Moi je reçois un mail, et ça déclenche une action ailleurs dans la maison.

Le plus simple, c’est d’installer et de regarder ce qu’il trouve tout seul sur votre réseau. Vous serez étonnés de découvrir la quantité de choses connectables que vous avez déjà, sans même le savoir. Il les trouve pour vous.

Pourquoi Home Assistant et pas autre chose

Parce qu’il est simple, convivial et facile à prendre en main. Et parce qu’il y a des milliers d’intégrations. Une intégration, c’est le module pour brancher un truc : ta Freebox, ton imprimante, un réseau Zigbee, ta voiture. Il fait toute la logique pour chaque appareil, tu as juste à remplir deux champs.

Rien que dans les intégrations officielles, on trouve son bonheur. Ensuite tu rajoutes les modules communautaires (je vous parlerai de HACS plus tard) et là, tu vois un truc qui existe, tu peux être sûr qu’un mec l’a branché mdr.

Et tu rajoutes encore ce qu’ils appellent les apps : en gros des conteneurs Docker préconfigurés pour Home Assistant, qui ont eux aussi leurs propres modules communautaires. À ce stade, ton Home Assistant peut à peu près tout faire.

Comment l’installer : pas en Docker

Alors même si tu peux le faire tourner en conteneur, je le déconseille. Pourquoi ? Parce que Home Assistant, c’est pas juste une appli, c’est un ensemble d’outils. Et ils proposent Home Assistant OS, qui s’installe facilement sur une machine monocarte (64 bits uniquement depuis peu), une VM, ou un vieux laptop ou PC qui traîne.

Une mini machine N100 serait parfaite. Un gros PC bien puissant juste pour Home Assistant, c’est peut-être un peu trop, mais ça serait super : ça consomme tellement peu que tu peux mutualiser (le mien, je l’ai gardé pour Jellyfin). Chez moi, c’est Home Assistant OS sur un Raspberry Pi 4.

L’intérêt de l’OS, c’est justement de proposer ces fameuses apps (on disait add-ons il y a encore quelques mois) qui permettent de centraliser tous les outils liés à la domotique sur la machine Home Assistant : un serveur MQTT, la passerelle Zigbee, ce genre de choses. J’y reviendrai aussi.

Pour l’installer, c’est Raspberry Pi Imager, tu choisis Home Assistant OS, et c’est parti.

Et oui, je déroge à ma règle du tout-Portainer. Mais ici c’est particulier, ça se justifie (le seul autre qui déroge, c’est mon NAS lol).

Essayez, même juste pour voir

Je vous conseille fortement d’essayer, même dans une VM VirtualBox, rien que pour découvrir ce qui est connectable chez vous. Et je sais qu’il y en a forcément.

Après, vous aurez envie d’avoir des lumières, des interrupteurs et tout le reste (promis, vous aurez un billet dédié aux relais). Et ça, ça va vous changer la vie.

Image d’en-tête générée par IA.

Il faut une machine qui tourne, pas forcément une grosse

80 % des outils techniques que je vais vous présenter s’exécutent sur un serveur. Souvent un tout petit : un Raspberry Pi (bon, ok, les vieux RPi 32 bits sont en fin de vie), une machine pourrie qui traîne, un vieux laptop. Un serveur dédié si vous y mettez le prix. Dans tous les cas il faut un truc qui tourne en permanence pour avoir un home lab.

Et je maintiens que garder son PC fixe ultra puissant allumé, avec toute sa config, juste pour faire tourner un serveur de redirection de mail ou un lecteur de comics et d’ebooks, c’est peut-être pas la meilleure des idées. Attention, je dis pas qu’on peut pas. Mais bon.

On trouve des N100 (le petit processeur Intel), des RPi reconditionnés pas chers, des cartes monocarte pas trop chères, même si la crise de la RAM est passée par là. Et ça vaut vraiment le coup : pour pas grand-chose, t’as un home lab de fou.

Une distrib Linux, Docker, et rien d’autre

Un PC pour un home lab c’est bien, mais tu mets quoi dessus pour avoir des services cool ? Allez, on va coller un bon gros Windows qui te bouffera 50 % de ta RAM juste pour exister. Je plaisante à moitié, y en a qui le font.

Moi c’est simple : une mini distrib Linux. Debian, Ubuntu, Red Hat, ce que tu veux, à la limite on s’en fout. Et Docker dessus, avec docker compose, le petit outil pour tout ranger. Rien d’autre.

Je vais pas vous détailler dans cet article tout ce que fait Docker. En gros c’est des containers, comme des VM, sauf que tu vires toute la couche matérielle, l’émulation du proco et compagnie. Tu fais juste tourner un OS dans ton OS, au niveau machine. C’est transparent, ça vit tout seul dans son coin.

Administrer tout ça à la main, c’est la merde

Sauf que le jour où tu commences à empiler les conteneurs, les administrer, c’est la merde. Et là on prend quoi ? Je te le fais dans le mille : comme le titre de l’article le dit, on prend Portainer.

Alors première question, pourquoi Portainer et pas K8s ou un autre orchestrateur ultra balèze ? Et bien parce que je suis tout seul. C’est assez simple, et même si j’utilise même pas 50 % de ce qu’il propose (tu vas me dire, on fait tous ça avec Word depuis des années et ça n’a jamais dérangé personne), on s’y retrouve, on contrôle ce qui se passe, et c’est plutôt facile.

Une stack par outil

En gros tu fabriques une stack par outil. Une stack, c’est quoi ? C’est juste ce qui regroupe ton compose.

Tu récupères le compose dans la doc de l’outil que tu veux monter, tu le colles, et ça démarre ou pas. Au pire, maintenant, tu te fais aider par Claudio (faudra que je parle de Claude un jour), il te fera très bien les choses. Ou son équivalent gratos, lol.

Et il te met tous les services dont t’as besoin. Ton outil a besoin d’une base de données dans telle version, c’est bon. D’un serveur web intégré, c’est bon. De l’outil lui-même, c’est bon. Une petite redirection de port, un serveur proxy pour taper dessus avec un nom de domaine, et hop, t’as ton outil. C’est trop bien.

La version entreprise, gratuite pour un usage perso

Petit bonus : tu peux avoir la version Business gratos pour un usage perso. Comme ça tu vois les mises à jour d’image et tout le reste. Sur la capture des stacks, la pastille orange au bout de chaque ligne, c’est exactement ça : une image plus récente est dispo.

Bon, c’est pas K8s, et je gère quand même pas mal de trucs à la main. Mais ça simplifie grandement la vie.

Le seul compose que tu lanceras à la main

Je vous file la doc d’installation, et un compose tout simple. C’est le seul que tu démarreras toi-même avec un docker compose up : tous les suivants passeront par l’interface.

services:
  portainer:
    image: portainer/portainer-ee:latest
    container_name: portainer
    restart: always
    ports:
      - "9443:9443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - portainer_data:/data

volumes:
  portainer_data:

Attention à l’image : portainer/portainer-ee, c’est celle de la version Business, celle qui attend une clé de licence (la perso, gratuite, que tu demandes sur leur site). Si tu veux rester sur l’édition communautaire, tu ne charges pas ee, tu prends l’autre image, portainer/portainer-ce:latest. C’est le même compose, juste cette ligne qui change.

Le volume /var/run/docker.sock n’est pas un détail : c’est par là que Portainer parle à Docker, donc c’est ce qui lui donne la main sur toute la machine. À garder en tête avant d’exposer l’interface au grand large.

Après le docker compose up -d, tu ouvres https://127.0.0.1:9443, tu suis les consignes, emballé c’est pesé.

Sans cette base, le reste n’a pas de sens

Comme je le disais, c’est pas hyper sexy comme article. Mais sans cette base, tout le reste qui devient sexy n’a aucun sens. Ça sert à quoi que je te présente un outil si tu sais même pas comment le faire tourner ?

En tout cas bonne lecture à tous, et je reviens très vite avec des outils plus cool.

Image d’en-tête générée par IA.

« Protocole vieillissant et sécurité »

L’annonce est habillée comme il faut : Google retire POP3 de ses serveurs « pour des questions de protocole vieillissant et de sécurité ». Mettez les guillemets, ils comptent.

Franchement, c’est surtout que ça leur coûte. Aller relever les boîtes des autres, c’est des connexions sortantes à maintenir, des serveurs en face qui répondent mal, des erreurs à absorber. À l’époque où il fallait arracher les gens à Free, Orange et compagnie, ça valait l’investissement : on rapatriait tout son passé chez Gmail et on ne repartait plus. Maintenant qu’ils ont le monopole, récupérer les mails des concurrents, ils s’en contrefichent.

Moi, j’ai des tonnes de mails à rapatrier

Mon cas n’a rien d’original : des adresses sur mes domaines OVH, du Free, et le reste, tout ça remonte dans Gmail depuis des années par la relève POP3. Ma configuration existante marche toujours. Mais pour en ajouter une nouvelle, c’est mort. Et comme c’est voué à disparaître, le jour où ils coupent pour de bon, je me retrouve le bec dans l’eau avec des boîtes que plus personne ne relève.

Attendre ce jour-là pour chercher une solution, très peu pour moi. J’ai donc écrit l’outil : pop3_to_smtp.

Ce que faisait Gmail, mais pas que vers Gmail

Le principe tient en une phrase : ça relève un mail en POP3 et ça l’envoie à une autre adresse, comme une redirection. Exactement le boulot que Gmail s’apprête à arrêter de faire.

La différence, c’est la destination : le serveur SMTP se configure, celui qu’on veut. Gmail si on y tient, ou tout autre. Et le message part intact : expéditeur d’origine, signature DKIM préservée, pièces jointes conservées. Ce n’est pas un transfert qui réécrit tout au nom du relais, c’est un relais.

Le reste se fait à la souris : ajouter une boîte, ajouter une destination, tester les réglages avant d’enregistrer, forcer une relève tout de suite au lieu d’attendre le prochain passage. Le bouton « Tester » m’a évité pas mal d’allers-retours. Un mot de passe d’application refusé, on le voit sur place plutôt qu’en fouillant des logs.

Les notifications, le vrai confort

Une redirection de mails qui tombe en panne sans rien dire, c’est le pire scénario. On ne s’aperçoit de rien pendant des semaines, jusqu’au jour où on cherche un message qui n’est jamais arrivé.

Du coup on peut recevoir des notifications sur son téléphone ou ailleurs quand ça foire : par mail, par ntfy, par webhook générique, ou par SMS avec l’API Free Mobile. Par défaut, seules les défaillances déclenchent une alerte. On peut aussi se faire prévenir à chaque succès, mais on s’en lasse vite.

Ça se déploie en Docker, et ça tourne sur un Raspberry Pi

Je ne vais pas vous dérouler la doc d’installation ici, c’est du Docker et on en reparlera une autre fois. Promis, je vous ferai un article sur Portainer, Docker et toute ma stack. En résumé : une image, un volume pour les données, un port pour l’interface.

docker run -d --name pop3_to_smtp \
  -p 8080:8080 \
  -v ./data:/data \
  -e WEB_USER=admin \
  -e WEB_PASSWORD=un_mot_de_passe_solide \
  smeagolworms4/pop3_to_smtp:latest

L’image est publiée pour amd64 et pour arm64, donc pour les petits RPi aussi : j’essaie de penser à eux. Un relais de mails qui tourne toute la journée, c’est typiquement le genre de service qui n’a rien à faire sur une grosse machine.

Pensez quand même à sécuriser l’accès. Il y a des variables pour ça, WEB_USER et WEB_PASSWORD, et ce n’est pas optionnel : l’interface contient les identifiants de toutes vos boîtes. Chez moi c’est mon SSO qui fait le boulot en amont, mais tout le monde n’a pas un SSO sous la main.

Chez moi, les deux tournent en même temps

Je n’ai pas fait sauter ma configuration Gmail : tant qu’elle tient, elle tient. Les deux font donc le même job en ce moment. Mais le jour où Gmail fera feu, moi je serai déjà bien caché à l’abri.

Le code est ouvert et je suis ouvert aux suggestions. Il y a sûrement des cas d’usage auxquels je n’ai pas pensé, et des serveurs POP3 exotiques qui vont me sortir des surprises. Je vous laisse essayer.

Image d’en-tête générée par IA.

Basic 1.0 / Écran bleu et texte jaune

J’ai codé mon premier jeu vidéo à 8 ans, sur un Amstrad CPC 6128 — une machine qui avait déjà sûrement dix ans d’existence à l’époque, j’avoue que je n’ai pas compté. C’était un morpion. Bête et tout simple, mais il marchait — fallait juste 30 secondes pour dessiner la croix, mdr.

Ça fait maintenant plus de 20 ans que je bosse dans la tech. Entre les deux, j’ai touché à vraiment toutes les technos, sans distinction. J’ai mes amours — le JS, j’adore, et ça se verra ici — mais je n’ai jamais été du genre à me ranger dans une seule chapelle. Un bon outil est un bon outil, peu importe le langage sur la boîte.

Quand je dis vraiment tout, c’est vraiment tout. Du Java, en écrivant des mods Minecraft. Du PHP, où j’ai bossé sur les tout premiers frameworks — avant même que le mot « framework » soit connu du commun des développeurs. Du Python, du .NET, de l’assembleur. Et même du Lisp et du Cobol, j’avoue que j’ai un peu envie d’oublier cette partie-là, lol.

Pourquoi un blog, et pas ailleurs

Le problème, c’est que je n’ai jamais eu d’espace pour parler de tout ça. Sur Reddit, c’est le bordel : le fil intéressant est noyé sous trois pages de bruit, et ce que tu écris a disparu le lendemain. Il y a bien de très bons Discord, mais aucun généraliste — chacun son sujet, sa techno, sa chapelle. Du coup c’est un peu nul quand tu veux juste parler de ce que tu bricoles, quel que soit le sujet du jour.

Ici, ce sera ce que je veux et comme je veux. Pas de karma, pas d’algo, pas de modérateur qui décide que mon post n’est pas dans le bon salon.

Ce que tu vas trouver ici

Concrètement : mes bouts de code, mes libs, mes outils, les technos que je trouve bonnes et pourquoi. Le genre de question que je me pose tous les jours au boulot — pourquoi utiliser ce pattern-là plutôt qu’un autre à cet endroit précis du code — et sur laquelle je n’ai jamais trouvé de réponse satisfaisante en trois lignes sur Stack Overflow.

Il y aura aussi des manières d’utiliser l’informatique, des trucs que j’ai mis en place et qui me servent tous les jours, et de l’info tech pure quand le sujet le mérite. Et à chaque fois la même chose : ce que j’ai essayé, ce qui a coincé, et ce que j’en ai gardé.

Toute ma maison est connectée (oui, toute)

Je fais énormément de domotique. J’ai eu la chance de faire construire, alors j’en ai profité pour que la maison soit pensée connectée dès le départ : j’ai pu poser directement le bon matériel au bon endroit, et réfléchir en amont pour que tout s’emboîte. Ça évite de bricoler des rustines une fois que tout est en place.

Résultat : j’en suis au point où je demande à ChatGPT ce que je pourrais bien rajouter, parce que je n’ai plus d’idées. Je plaisante à moitié. J’en parlerai sûrement dans un article, voire plusieurs — il y a de quoi faire.

Le gros nerd barbu derrière le clavier

Parce qu’il n’y a pas que le code : je suis un gros fan de SF, en séries TV comme en littérature. J’adore les mangas, mais un peu à l’ancienne, je l’avoue. Ajoute les comics et la culture pop par-dessus et tu obtiens le gros nerd bien barbu par excellence — et maintenant j’en ai assez pour le dire, mdr.

Ça débordera forcément sur le blog de temps en temps. Autant prévenir tout de suite.

Les commentaires sont ouverts — gardons-les ouverts

J’ai ouvert les commentaires, mais je sais très bien que ça peut vite devenir le bordel, et je ne veux pas passer ma vie à modérer. Alors faut être respectueux, SVP. Ça m’embêterait vraiment qu’il n’y ait pas de lieu d’échange sous mes articles : c’est souvent là que se trouve la moitié la plus intéressante d’un billet.

En tout cas, bienvenue sur mon blog, et j’espère que ce que je vais vous publier va vous plaire. Encore merci de m’avoir lu, et bienvenue à tous.