Infrastructure

Ubuntu 26.10 « Stonking Stingray » est sortie le 15 octobre 2026. Elle apporte GNOME 51, Linux 7.3 et termine le passage des utilitaires de base vers Rust, avec une première version de la dictée locale Myna. Pour un poste de travail ou un homelab, plusieurs changements méritent le détour, à condition de prévoir la suite : cette version intermédiaire sera maintenue jusqu’en juillet 2027.

Pangolin 1.24 ajoute les nœuds de sortie : un ordinateur ou un téléphone peut faire transiter son trafic Internet IPv4 par un site choisi. Publiée le 30 septembre 2026, cette version améliore aussi la connexion automatique des clients et ajoute une passerelle pour les appareils sans client Pangolin. Pour un homelab, l’intérêt est concret : utiliser la sortie Internet du domicile en déplacement et raccorder davantage d’équipements au réseau privé.

Pangolin étend son contrôle d’accès aux modèles d’IA et simplifie son déploiement sur plusieurs serveurs. La version 1.22 ajoute une passerelle pour les API cloud ou auto-hébergées et ouvre plusieurs accès distants à Community Edition. La 1.23 rend le clustering déployable sans accompagnement du fournisseur et intègre le connecteur de site à la CLI. Deux versions qui méritent un détour, que l’on cherche à partager un Ollama dans son homelab ou à rendre une instance Pangolin plus disponible.

Au départ, tu veux héberger Home Assistant, un bloqueur DNS et deux services Docker. Puis arrivent une VM de test, une supervision, un petit cluster Kubernetes « juste pour apprendre ». Le mini-PC n’a pas changé de taille. La liste des projets, si. Pour choisir, je regarde d’abord ce qui risque de coincer dans six mois : la RAM, la place pour un second SSD, le réseau vers le NAS. Le processeur le plus cher du catalogue ne règle pas un manque de mémoire ou un disque déjà plein. Avec 200 € maximum, je prendrais le HP ProDesk 600 G3 reconditionné en 16 Go / 256 Go, relevé à 179,99 €. Le Lenovo M910q descend à 144,25 € avec 8 Go de RAM pour un lab plus léger. Pour un homelab évolutif autour de 500 €, je prendrais le Minisforum NAB6 Lite en 16 Go / 512 Go. Tu peux commencer avec quelques services, puis augmenter la RAM et ajouter un disque SATA. Si tu veux 32 Go dès l’achat, le NiPoGi H1 est au même niveau de prix. Les huit modèles sont classés du moins cher au plus cher, jusqu’au MS-01 en 10 Gb/s.

Meta présente Muse comme un assistant capable de réserver un restaurant, de préparer un voyage ou de s’occuper des mails. Moi, je me suis arrêté sur un autre détail : il a sa propre machine Linux. Avec un terminal, un navigateur et de la place pour ses fichiers. Les premiers utilisateurs parlent de 2 vCPU, 8 Go de RAM et 100 Go de disque, y compris avec l’offre gratuite. Forcément, j’ai déjà quelques idées de scripts à lui confier. Le restaurant attendra : d’abord, un df -h. Lancé le 8 septembre 2026, Muse n’est pas encore officiellement disponible en Europe au moment où j’écris ces lignes. Je n’ai donc pas pu le prendre en main. Mais la documentation et les retours d’utilisateurs donnent déjà de quoi s’intéresser à ce qui tourne derrière la fenêtre de discussion.

Un fichier .env ignoré par Git reste un fichier en clair. Dans une stack Docker Compose, il finit facilement dans une copie de migration, une sauvegarde, une archive de support ou, un jour, l’historique du dépôt. SOPS et age permettent de corriger une partie du problème sans déployer un gestionnaire de secrets centralisé. Le principe est simple : le dépôt contient un fichier chiffré, les clés privées restent hors de Git et le serveur ne déchiffre que les valeurs nécessaires au déploiement. Docker Compose reçoit ensuite ces valeurs sous forme de fichiers montés dans /run/secrets/. Les mots de passe ne passent plus par environment: et ne finissent plus dans la configuration du conteneur. Cette méthode convient bien à un homelab, à quelques VPS ou à une petite infrastructure pilotée par Git. SOPS reste un outil de chiffrement de fichiers, pas un gestionnaire de secrets centralisé, et ne protège pas un hôte déjà compromis.

J’ai longtemps gardé tout mon homelab sous Docker Compose. Pas par rejet de Kubernetes : Compose faisait le travail, les volumes étaient faciles à retrouver et je savais remettre un service en route sans relire une pile de manifests. K3s est arrivé plus tard, quand j’ai voulu uniformiser les déploiements et préparer l’ajout d’autres machines. Je n’ai pas tout migré pour autant. Aujourd’hui, les deux cohabitent encore. C’est volontaire. Pour trancher, je regarde surtout la panne : avec lequel des deux vais-je retrouver les données et remettre le service en route sans improviser ?

SPF, DKIM, DMARC, BIMI : comment configurer une chaîne anti-spoofing solide pour vos emails, avec les commandes et vérifications qui comptent vraiment.

Pangolin commence souvent comme un reverse proxy Zero Trust pour des interfaces web. Mais son intérêt ne s’arrête pas aux dashboards HTTP. L’accès SSH est probablement l’un des cas d’usage les plus intéressants, parce qu’il touche à une surface sensible : l’administration système. Le réflexe classique reste d’ouvrir 22/tcp sur Internet, de filtrer par IP, puis de compter sur Fail2ban, CrowdSec ou une configuration OpenSSH correcte. Ça peut fonctionner. Mais dès que plusieurs personnes doivent accéder à plusieurs machines, le modèle devient vite pénible à maintenir proprement. Pangolin SSH propose une autre approche : ne pas exposer directement SSH sur Internet ; contrôler l’accès par identité, rôle et machine ; utiliser un tunnel Pangolin vers le réseau cible ; garder des ressources limitées, au lieu de donner accès à tout un LAN ; offrir soit un terminal web, soit un accès CLI classique. À noter avant d’aller plus loin : d’après la documentation Pangolin consultée le 2 juillet 2026, les fonctionnalités SSH décrites ici sont disponibles avec Pangolin Cloud et Pangolin Enterprise Edition. En self-hosted Community Edition, vérifiez ce que votre instance expose réellement dans l’interface. C’est la suite logique des deux premiers articles de la série : installation de Pangolin et premiers sites Newt ; exposition d’une interface sensible derrière le SSO ; puis maintenant : accès shell, bastion, OpenSSH et provisioning. Je ne vais pas refaire la documentation Pangolin. Le but est de poser une architecture exploitable, avec les choix qui évitent de transformer un bon outil d’accès en nouveau point faible.

Immich 3.0 apporte l’édition photo non destructive sur mobile, les workflows d’automatisation, le HLS, l’OCR, et plusieurs améliorations de maintenance. La migration est simple pour la plupart des utilisateurs, mais les intégrations API tierces nécessitent une vérification.

Podman 6.0.0 est disponible depuis fin juin 2026, avec un billet de présentation publié début juillet. C’est une version majeure avec plusieurs suppressions de composants historiques : fin du support cgroups v1, retrait de slirp4netns et iptables, abandon de BoltDB pour SQLite, et refonte du parsing des fichiers de configuration. Si vous utilisez Podman en production ou dans des pipelines CI, cette montée de version demande une vraie préparation. Ce n’est pas une simple mise à jour. Plusieurs changements peuvent rendre une installation inutilisable si la migration n’est pas anticipée.

Le tag latest est confortable. On écrit un compose.yml, on lance docker compose up -d, et le service démarre. Pas besoin de choisir une version de PostgreSQL, Redis, Traefik, Gitea, Vaultwarden ou n’importe quelle application auto-hébergée. Le problème, c’est que latest ne veut pas dire “dernière version stable adaptée à mon environnement”. Ça veut seulement dire : “ce tag pointe vers quelque chose dans le registre au moment où Docker le résout”. Ce quelque chose peut changer sans que votre fichier Compose change. Pour une stack de test, ce n’est pas très grave. Pour une base de données, un reverse proxy exposé, un service d’authentification ou une application avec des volumes persistants, c’est une mauvaise convention d’exploitation. Le vrai sujet n’est pas Docker. C’est la reproductibilité.

Je suis tombé sur Hermes Agent début 2026, et il m’a fallu quelques semaines pour comprendre ce que le projet apportait par rapport aux autres frameworks d’agents. Le pitch officiel - “self-improving AI agent with a built-in learning loop” - ne rend pas bien service à ce que le logiciel fait concrètement. Après plusieurs mois d’utilisation quotidienne, voici ce que j’en retire.

Dans mon setup opencode + Ollama sur RTX 3090, j’avais commencé avec SearXNG comme source web via MCP. Ça fonctionnait, mais ce n’était pas exactement le bon outil pour mon usage. SearXNG est un métamoteur de recherche. Il trouve des pages. Firecrawl est plus proche d’une brique d’extraction : il cherche, scrape, nettoie, crawl et renvoie du contenu exploitable par un agent. Pour un assistant local qui doit lire de la documentation, vérifier une API récente ou comparer plusieurs sources techniques, la différence se sent assez vite.

J’utilise des LLMs comme assistants de code depuis début 2026. D’abord avec des API cloud, puis en local. Ce qui a changé avec une RTX 3090, c’est la bascule vers un modèle de travail où la latence et la confidentialité deviennent moins pénalisantes. L’inférence locale devient crédible pour du code à partir de 24 Go VRAM. Voici mon setup, les chiffres réels et ce qui tient vraiment la route.

Debian 14, nom de code Forky, est la future version stable de Debian. Au 14 mai 2026, elle est encore en branche testing. Aucune date de sortie n’est annoncée, et les étapes du freeze ne sont pas encore planifiées publiquement. Le bulletin de l’équipe Release publié le 10 mai 2026 apporte tout de même plusieurs informations importantes : les builds reproductibles deviennent une contrainte plus forte dans la migration des paquets, les binNMU passent par davantage de tests automatiques, et l’architecture loong64 arrive dans l’archive Debian. Pour un serveur de production, la conclusion immédiate est simple : Debian 13 Trixie reste la version stable à utiliser. Debian 14 est intéressante à tester dès maintenant, mais pas à déployer comme base principale tant qu’elle n’est pas publiée en stable.

Dans le premier article sur Pangolin, j’avais volontairement laissé CrowdSec de côté. Pas parce que CrowdSec n’est pas utile. Au contraire. Mais parce qu’une pile Pangolin doit d’abord être comprise avant d’ajouter des briques de sécurité, des bouncers, des dashboards et des automatisations. Une fois Pangolin stable, la question revient naturellement : Comment visualiser proprement ce que CrowdSec voit et bloque, sans exposer une interface d’administration sensible sur Internet ? C’est là que CrowdSec Manager devient intéressant. L’objectif de ce test est simple : installer CrowdSec Manager à côté de la stack CrowdSec ; ne pas publier son port 8080 sur Internet ; le rendre accessible uniquement via Pangolin ; protéger l’accès avec le SSO Pangolin ; garder les secrets Newt dans Gitea Actions, pas dans Git.

Ubuntu 26.04 LTS est sortie le 23 avril 2026 sous le nom Resolute Raccoon. Pour un poste desktop, c’est une nouvelle LTS avec GNOME 50, Wayland et quelques changements visibles. Pour un serveur, c’est autre chose : une base qui peut rester en production pendant plusieurs années, avec un nouveau noyau, une pile crypto plus stricte, des paquets serveur mis à jour, des changements de comportement sur des services courants, et une stratégie de support à bien comprendre avant de lancer un do-release-upgrade. Je regarde donc Ubuntu 26.04 LTS sous l’angle qui m’intéresse le plus ici : serveurs, VPS, homelab, cloud, sécurité et migration propre.

Quand la contrainte devient un sport # Dans un monde où le cloud facture le moindre CPU burst, il existe un écosystème parallèle : des VPS à 12 $ par an, parfois moins, avec 1 GB de RAM, aucun SLA… et pourtant des services qui tiennent. Ce monde n’est pas tenu par des débutants, mais par une communauté de passionnés de l’optimisation extrême, prêts à faire tourner des services utiles avec presque rien. Pour moins de 12 $ par an, j’exploite un VPS low-end, un nom de domaine dédié et un service de monitoring public. Cet article n’est pas un comparatif marketing. C’est un retour d’expérience sur ce que ces infrastructures permettent et surtout sur ce qu’elles ne permettent pas. Bienvenue dans l’univers Low-End VPS.

Pourquoi Cryptolab documente des expérimentations d’infrastructure, de self-hosting et de logiciels libres.

Installation de Pangolin sur un VPS, configuration des accès Zero Trust, agents Newt et méthode de maintenance.