Rechercher dans la communauté

IT-Connect Publié le 6 mai 2026 Par Florian BURNEL it-connect.fr Environ 14 minutes de lecture Maîtriser le filtrage réseau de votre hyperviseur constitue la première ligne de défense de vos environnements virtualisés. Dans le contexte de Proxmox VE, les administrateurs peuvent compter sur un pare-feu intégré. Il présente l'avantage de permettre une gestion des flux à plusieurs niveaux : datacenter, nœud et ressources (machine virtuelle ou conteneur). Comment s'effectue la configuration du firewall Proxmox VE ? C'est ce que nous verrons dans la suite de cet article. Retrouvez les autres tutoriels Proxmox VE : Débuter avec Proxmox VE : installation et premiers pas La configuration du réseau avec Proxmox VE : le guide pour bien débuter Proxmox VE : bien débuter avec les conteneurs LXC Le fonctionnement du pare-feu Proxmox VE Le pare-feu intégré à Proxmox VE (nommé pve-firewall) est une solution de filtrage basée sur les fonctionnalités natives du noyau Linux, notamment iptables (le module pour nftables est en préversion). Ici, il n'est pas question de déployer une appliance virtuelle assumant la fonctionnalité de firewall. En effet, le pare-feu Proxmox s'exécute directement sur chaque nœud (serveur physique) de l'environnement virtualisé, que ce soit un hôte autonome ou un cluster. Le système de pare-feu de Proxmox VE est hiérarchique et se divise en trois zones distinctes : Le Datacenter (idéal pour un cluster) : définit les règles globales qui s'appliquent à l'ensemble des nœuds de l'infrastructure. C'est ici que l'on crée certains éléments comme les groupes de sécurité (appelés fréquemment Security Groups), les alias d'adresses IP et les listes (IPSets). Le nœud (hôte physique) : les règles spécifiques au serveur Proxmox lui-même, notamment pour protéger ses interfaces d'administration (WebUI, SSH). La machine virtuelle (VM) ou le conteneur (LXC) : les règles de filtrage spécifiques à une seule ressource et adaptées aux services hébergés par cette même ressource (serveur web, base de données, etc.). À ce niveau, les règles du nœud et du datacenter ne sont pas héritées. Grâce à ces différents niveaux, les règles peuvent être appliquées au plus près de la source et de la destination du trafic en fonction des besoins. Surtout, Proxmox VE est en mesure de bloquer les flux avant même qu'ils atteignent la ressource, ce qui est avantageux. Note : Proxmox VE applique les règles de pare-feu sur les nœuds dans un ordre hiérarchique logique, en allant du périmètre le plus éloigné à celui le plus proche. Ce qui donne : Datacenter > Nœud. Activer le pare-feu sur Proxmox VE L'activation du pare-feu dans Proxmox VE s'effectue en plusieurs étapes, et surtout, à tous les niveaux. Si le pare-feu n'est pas activé au plus haut niveau, les configurations inférieures ne seront pas appliquées. Autrement dit, pour appliquer des règles au niveau d'une machine virtuelle, vous devez activer le pare-feu au niveau du datacenter, du nœud, puis de la VM. Attention, si vous activez le pare-feu sans créer de règles en amont, vous perdrez la main sur votre serveur Proxmox VE ! En effet, la politique par défaut consiste à refuser tout le trafic entrant. Avant d'activer le firewall comme spécifié ci-dessous, vous devez donc commencer par le configurer. Activation globale (Datacenter) C'est le prérequis. Dans l'interface web, sélectionnez "Datacenter" dans le menu de gauche, puis naviguez vers "Firewall" > "Options". Modifiez l'option "Firewall" de "No" à "Yes", comme sur l'image ci-dessous. Sans cette action, le service associé au pare-feu reste inactif. Par défaut, la politique d'entrée (Input Policy) est définie sur "DROP", ce qui signifie que tout trafic entrant non explicitement autorisé par une règle est bloqué. La politique de sortie (Output Policy) est généralement sur "ACCEPT", ce qui veut dire que tous les flux sortants sont autorisés. Ce type de manipulation peut être effectué également en ligne de commandes : pvesh set /nodes/pve-01/firewall/options -enable 0 D'une manière générale, toute la configuration peut être effectuée via la ligne de commande et l'édition de fichiers. Activation sur un nœud (hôte) Même après l'activation au niveau Datacenter, chaque nœud dispose de son propre interrupteur. Sélectionnez votre nœud (par exemple "pve-01"), allez dans "Firewall" > "Options" et assurez-vous que le paramètre "Firewall" est bien activé, comme pour le niveau Datacenter. Activation sur une VM ou un conteneur Pour filtrer les flux entrants et sortants au niveau d'une machine virtuelle (ou d'un conteneur), deux conditions doivent être remplies : Dans la section "Firewall" > "Options" de la VM, le pare-feu doit être sur "Yes". Au niveau de la carte réseau virtuelle (Hardware > Network Device), la case "Firewall" doit être cochée dans les paramètres de l'interface réseau. Si cette case est décochée, la carte réseau ignore totalement les règles de filtrage, même si le pare-feu de la VM est activé. Voici l'option à laquelle je fais référence au niveau des paramètres de l'interface réseau de la VM : L'utilisation combinée des trois niveaux offre une grande flexibilité et s'inscrit dans le principe de défense en profondeur. Les règles définies au niveau du Datacenter sont évaluées avant celles du nœud. Cela permet de créer une règle globale (par exemple : bloquer une adresse IP malveillante sur l'ensemble du cluster) qui sera héritée et appliquée partout, tout en laissant la liberté à chaque nœud ou VM d'avoir ses propres règles locales. Mise en pratique avec un cas concret Afin de bien comprendre la mécanique de ce pare-feu, configurons deux scénarios fréquents. Scénario 1 : sécurisation de l'hôte Proxmox L'objectif est de protéger l'hyperviseur lui-même. Vous pourriez alors imaginer créer un ensemble de règles de pare-feu pour limiter l'accès à l'interface d'administration web (port 8006) et au SSH (port 22), uniquement depuis une ou plusieurs adresses IP de confiance. Allez sur le nœud ciblé, puis "Firewall" > "Add" pour créer une règle. Direction : in (flux entrant) Action : ACCEPT (accepter) Interface : ici je précise vmbr0, à savoir le bridge par défaut sur Proxmox VE. Selon votre infrastructure, il peut s'avérer utile de spécifier un autre nom d'interface. Source : si vous mettez rien, tout le monde sera autorisé, donc vous pouvez restreindre à un hôte ou à une machine si besoin. Macro : sélectionnez SSH. Les macros remplissent automatiquement le protocole et le port de destination, ce sont comme des règles prédéfinies pour les services les plus communs. La liste des macros est disponible sur cette page. Ajoutez un commentaire (important pour documenter). Activez la règle en cochant l'option "Enable". Ajoutez la règle avec le bouton "Add". Pour autoriser également l'accès sur l'interface Web, répétez l'opération en choisissant cette fois-ci le port de destination manuel 8006 (avec le protocole TCP). Voici un exemple : En définissant ces règles et en laissant la politique par défaut sur DROP, toute autre adresse IP tentant de se connecter à l'interface de gestion sera rejetée. D'ailleurs, tous les autres flux à destination de votre hôte seront rejetés d'une façon générale (mais pas à destination des VM). Je vous encourage à peaufiner cette liste de règles, notamment si vous êtes en cluster, car il y a d'autres ports à autoriser. La liste des différents services et des ports associés est disponible dans la documentation de Proxmox VE. Pour les règles spécifiques aux clusters, vous pouvez ajuster la source pour autoriser uniquement le trafic entre les nœuds. Interface Web : 8006 (TCP) Console Web VNC : 5900-5999 (TCP, WebSocket) SPICE proxy : 3128 (TCP) SSH: 22 (TCP) rpcbind : 111 (UDP) sendmail : 25 (TCP, outgoing) Trafic Corosync pour le cluster : 5405-5412 UDP Live Migration : 60000-60050 (TCP) Scénario 2 : sécurisation d'une machine virtuelle Prenons une VM (ID 100) hébergeant un serveur web Linux. Nous voulons rendre les sites accessibles en HTTP/HTTPS. Voici comment procéder. Allez sur la VM 100, "Firewall" > "Add". Créons la règle Web : Direction : in Action : ACCEPT Macro : Sélectionnez la macro Web. Elle permet d'autoriser les ports 80 et 443 en TCP, ce qui correspond à notre besoin. Source : laissez la source vide (ce qui équivaut à n'importe quelle adresse, soit 0.0.0.0/0). Créez la règle, mais pensez à l'activer et à ajouter un commentaire. Ce qui donne : Vous remarquerez que nous n'avons pas spécifié de nom d'interface : ce n'est pas nécessaire lorsque la règle s'applique à une machine virtuelle. Par contre, veillez à activer le pare-feu au niveau de la VM et de l'interface réseau de celle-ci. Désormais, cette machine est joignable sur deux ports : 80 et 443. Tous les autres flux sont bloqués (souvenez-vous de la politique par défaut appliquée aux flux entrants). Si vous souhaitez vous connecter en SSH à cette VM, créez une seconde règle. Dans ce cas, il est judicieux de limiter les sources (un sous-réseau bien spécifique, l'IP d'un poste d'administration, etc.). Voici un exemple : Voilà, vous savez désormais comment créer des règles de pare-feu sur votre serveur Proxmox VE. Mais, pour être efficace dans l'administration et la maintenance de ces règles de pare-feu, il me semble judicieux de s'intéresser à certaines fonctionnalités proposées par PVE. Note : appliquez le principe du moindre privilège lorsque vous réfléchirez à votre règle. Security Groups du firewall Proxmox VE Proxmox VE permet de créer des Security Groups au niveau du Datacenter. Un Security Group dans Proxmox VE fonctionne comme un modèle de règles de pare-feu centralisé et réutilisable. Imaginez que vous administrez une dizaine de serveurs web : au lieu de configurer manuellement l'ouverture des ports 80 (HTTP) et 443 (HTTPS) sur chaque machine virtuelle de façon isolée, vous créez un unique groupe nommé "Web_Rules" au niveau global (Datacenter). Ensuite, vous n'avez plus qu'à "insérer" ce groupe dans les paramètres de pare-feu de chaque machine concernée. L'avantage principal est la simplification de la maintenance : si vous devez un jour autoriser un nouveau port pour vos applications web, il vous suffit de modifier ce Security Group une seule fois pour que la mise à jour se déploie instantanément sur l'ensemble des serveurs virtuels qui y sont liés. Pour en créer un nouveau : Datacenter > Firewall > Security Group > Create. Donnez-lui un nom, par exemple "Web_Rules". Puis, sélectionnez-le sur la gauche pour ensuite ajouter une règle de pare-feu dans ce groupe. Ici, on crée une règle toute simple pour autoriser les flux entrants HTTP/HTTPS en sélectionnant la macro Web. Quand c'est fait, il ne reste plus qu'à appliquer ce Security Group à une ressource. Pour cela, vous n'avez qu'à sélectionner la VM, à cliquer sur l'onglet "Firewall" puis choisissez "Insert: Security Group". Ici, vous n'aurez qu'à le sélectionner pour créer une règle qui va reprendre toutes celles intégrées au Security Group. Pensez à cocher l'option "Enable" également. Si par la suite vous modifiez les règles de ce Security Group, les ressources qui l'utilisent hériteront de cette modification. Ainsi, vous pouvez rendre vos configurations plus facilement homogènes. Les alias avec le firewall Proxmox VE Dans le pare-feu de Proxmox VE, les Alias et les IPSets sont deux autres outils conçus pour simplifier la gestion de vos adresses réseau, mais ils répondent à des besoins différents. Un Alias fonctionne comme un contact dans votre répertoire téléphonique. Au lieu de saisir manuellement une adresse IP (comme 192.168.1.50) dans vos règles de pare-feu, vous lui donnez un nom user-friendly, par exemple "PC_Florian". Un Alias ne peut contenir qu'une seule adresse IP ou un seul sous-réseau. Vous pouvez donc aussi créer un alias pour disposer d'un objet faisant référence à un sous-réseau (un VLAN, par exemple). Son but premier est d'améliorer la lisibilité et la maintenance : si l'adresse IP de votre administrateur change un jour, il vous suffit de mettre à jour l'Alias à un seul endroit pour que toutes les règles qui l'utilisent soient automatiquement actualisées. Pour créer un alias : Datacenter > Firewall > Alias > Add. Vous devez nommer l'alias et spécifier l'adresse IP correspondantes (/32 pour un hôte unique). Par la suite, quand vous créez une règle de pare-feu, vous pouvez sélectionner cet alias en tant que source ou destination. Par exemple : Les IPSet avec le firewall Proxmox VE Un IPSet (ensemble d'IP), en revanche, s'apparente à une liste de diffusion ou un groupe de contacts. Il est conçu pour regrouper plusieurs adresses IP, de multiples sous-réseaux, ou même des Alias sous une étiquette unique (par exemple "Postes_administration" ou "Blacklist_IP"). Son atout : le pare-feu utilise une structure de données très optimisée dans le noyau Linux (table de hachage). Ainsi, vérifier si un trafic entrant correspond à l'une des 10 000 adresses IP contenues dans un IPSet se fait de manière quasi instantanée, ce qui serait impossible si vous deviez créer 10 000 règles de pare-feu individuelles. Vous pourrez ensuite associer l'IPSet à une règle de firewall, sur le même principe que l'affectation d'un alias. En résumé : Utilisez un Alias pour identifier une ressource unique dont l'IP pourrait changer à l'avenir (vous modifierez l'Alias et toutes les règles liées seront mises à jour). Utilisez un IPSet dès que vous devez appliquer une politique réseau identique à un groupe, une liste ou une plage hétérogène de plusieurs machines. La journalisation du firewall La journalisation (logging) est utile pour le débogage et l'audit de sécurité. Sur chaque règle, vous avez la possibilité de définir un niveau de log (info, warning, err, etc.). Il est judicieux d'activer les logs sur les règles de type "DROP" pour identifier d'éventuelles problèmes. Attention toutefois à ne pas journaliser l'intégralité du trafic valide au risque de saturer l'espace disque de vos nœuds. Le niveau de log par défaut est déterminé au niveau de chaque noeud et de chaque ressource (VM/CT). Vous pouvez définir un niveau de log différents pour les flux entrants et les flux sortants. Ensuite, au niveau de chaque règle, vous pouvez aussi faire un choix spécifique. Vous devez cocher la case "Advanced" pour faire apparaître l'option nommée "Log level". Pour consulter l'activité du pare-feu d'une ressource spécifique (ici, la machine virtuelle 100 (Debian-12)) : Sélectionnez la ressource concernée dans l'arborescence de gauche. Déroulez le menu "Firewall". Cliquez sur la sous-section "Log" En haut de l'écran, Proxmox propose deux boutons pour gérer l'affichage des logs : Live Mode : C'est le mode actif par défaut. Il affiche les flux en temps réel. Dès qu'un nouveau paquet est traité et journalisé par le pare-feu, la ligne apparaît instantanément à l'écran. Select Timespan : ce mode permet de filtrer les logs sur une période précise en utilisant les champs Since (Depuis) et Until (Jusqu'à). L'écran principal affiche les logs bruts générés par le composant du pare-feu (iptables ou nftables). Prenons le temps de décomposer les informations essentielles que contient une ligne : 100 6 tap100i0-IN 06/May/2026:10:56:25 +0200 ACCEPT: IN=fwbr100i0 [...] SRC=192.168.1.73 DST=192.168.110.12 Voici quelques explications : 100 : l'identifiant (ID) de la machine virtuelle concernée. tap100i0-IN : indique l'interface virtuelle impliquée (l'interface réseau 0 de la VM 100) et la direction du trafic. Ici IN signifie qu'il s'agit d'une règle de trafic "Entrant" (vers la VM). 06/May/2026:10:56:25 +0200 : l'horodatage exact de l'événement. ACCEPT : c'est l'action prise par le pare-feu. Ici, le trafic a été autorisé. (Vous pourriez y voir DROP pour un trafic bloqué silencieusement ou REJECT pour un trafic rejeté). IN=... OUT=... PHYSIN=... : ces champs décrivent le parcours complexe du paquet à travers les différents ponts (bridges) virtuels internes de Proxmox (fwbr, fwln) avant d'atteindre l'interface de la VM (tap). MAC=... : l'adresse MAC source et destination. SRC=192.168.1.73 : l'adresse IP source (l'ordinateur ou le serveur qui a initié la connexion). DST=192.168.110.12 : l'adresse IP de destination (en principe, vous verrez ici l'adresse IP de votre machine virtuelle). Forcer la désactivation du firewall Proxmox VE En cas de mauvaise manipulation vous bloquant l'accès à l'interface web (WebUI), il est nécessaire d'intervenir directement en ligne de commande depuis la console locale du serveur (via un KVM, un accès console physique...). Pour désactiver le pare-feu au niveau du Datacenter, éditez le fichier de configuration principal : nano /etc/pve/firewall/cluster.fw Au sein de ce fichier, localisez la section [OPTIONS] située au tout début. Modifiez la directive enable: 1 en remplaçant le 1 par un 0 (enable: 0), puis sauvegardez le fichier (avec Ctrl+O puis Ctrl+X sous nano). Proxmox détectera automatiquement ce changement et désactivera le pare-feu, vous rendant ainsi l'accès ! L'autre solution consiste à stopper temporairement le pare-feu via l'exécution de cette commande : pve-firewall stop Cette commande coupe le processus de pare-feu sur le nœud actif. C'est une solution de secours pratique pour récupérer la main le temps de corriger la règle fautive - ou manquante - dans l'interface graphique. Une fois votre configuration réparée, n'oubliez pas de relancer le service avec la commande pve-firewall start ou de réactiver le pare-feu depuis l'interface web. Conclusion Le pare-feu intégré de Proxmox VE est une solution complète, performante et distribuée, adaptée à la protection des environnements virtualisés. Sa gestion à trois niveaux (Datacenter, Nœud, VM) permet de créer des politiques de sécurité fines, granulaires et facilement maintenables (souvenez-vous des IPSet, Alias et Security Group), que vous gériez un serveur isolé ou un cluster. En appliquant une politique de blocage par défaut, en utilisant les groupes de sécurité et les macros, et en ciblant les flux nécessaires au bon fonctionnement de vos services, vous disposez d'un filtrage cohérent sans toucher au pare-feu de l'OS de vos VM ou conteneurs. Ingénieur système et réseau, cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Je souhaite partager mon expérience et mes découvertes au travers de mes articles. Généraliste avec une attirance particulière pour les solutions Microsoft et le scripting. Bonne lecture. Afficher l’article complet

Je suis enfin arrivé à jouer à mes jeux favoris sous Linux, et sans trop de difficulté finalement... J'ai installé la distribution Linux Pop!_OS qui est prête pour jouer sous Linux, en suivant ce tuto : Après l'installation et le redémarrage, ainsi que les quelques outils supplémentaires indiqués dans la vidéo précédente, voici la copie d'écran réalisée en jouant à Trackmania Stadium. Le jeu est très fluide, comme sous Windows, c'est parfait.

Korben Publié le 18 avril 2026 Par Korben, Manuel Dorne korben.info Environ 2 minutes de lecture L'interface web de Proxmox (l'outil de virtualisation que tout bon homelabber connaît), c'est bien... pour UN serveur. Dès que vous commencez à empiler les nodes et les clusters, ça devient vite le bazar avec 15 onglets ouverts. PegaProx , c'est tout simplement un dashboard open source qui unifie tout ça dans un seul écran. Et vous allez voir, le truc cool, c'est que ça gère aussi les clusters XCP-ng ! L'interface de PegaProx - une vue unifiée de tous vos clusters Proxmox et XCP-ng Concrètement, vous branchez tous vos hyperviseurs sur cette interface web (port 5000) et hop, vous avez la vue complète. VMs, conteneurs, métriques de perf... tout remonte en temps réel via Server-Sent Events. Du coup, plus besoin de jongler entre les interfaces de chaque node pour savoir quel serveur rame. Côté fonctionnalités, accrochez-vous les amis parce que pour une beta, c'est déjà bien garni ! Migration live de VMs entre nodes, gestion du stockage Ceph, consoles navigateur via noVNC et xterm.js, et même de la migration cross-hypervisor entre ESXi, Proxmox VE 8.0 et XCP-ng (encore expérimental côté ESXi, mais ça avance). Y'a aussi des règles d'affinité pour placer vos VMs, du rolling update avec évacuation automatique, et des alertes sur les seuils CPU/RAM/disque. Pour une beta, c'est assez dingue ce qu'ils ont déjà mis dedans. Côté sécurité, c'est pas en reste non plus. Y'a du RBAC avec 3 rôles (Admin, Operator, Viewer, pas plus pas moins), du TOTP pour le 2FA, de l'intégration LDAP et OIDC compatible Active Directory, Entra ID, Keycloak ou Google Workspace, du chiffrement AES-256-GCM pour stocker les credentials en base, et même du scan de CVE via debsecan. Autrement dit, ils ont pensé aux admins sérieux. Pour ceux qui ont déjà configuré un provider OIDC sur leur homelab , ça se branche directement. Pour l'installer, le plus simple c'est Docker. Un docker compose up -d, 30 secondes d'attente, et c'est plié. Mais y'a aussi un script de déploiement automatique, un repo APT communautaire maintenu par gyptazy, ou le classique git clone + pip pour les puristes. Une fois lancé, vous pointez votre navigateur sur https://votre-ip:5000, et un assistant vous accueille avec les identifiants par défaut (pegaprox/admin, à changer immédiatement bien sûr). L'interface est dispo en 5 langues : français, anglais, allemand, espagnol et portugais. D'ailleurs, si vous utilisez déjà ProxMenux pour administrer votre Proxmox en terminal, les deux sont en fait complémentaires. Disons que ProxMenux couvre l'admin système en ligne de commande, alors que le dashboard apporte la vue unifiée multi-clusters en web. Initialement j'aurais dit que c'était redondant, mais non, ça se marie plutôt bien. Et y'a même un système de plugins avec un portail client pour vos utilisateurs et une page de statut publique à la StatusGator. Attention c'est comme je vous le disais, encore une beta. L'OIDC avec Authentik par exemple, ça fonctionne pour le login mais les groupes ne remontent pas encore correctement (retour d'un lecteur qui l'utilise au quotidien). Par contre si vous n'avez qu'un seul serveur Proxmox, honnêtement c'est un peu overkill, l'interface native suffit largement. Quelques glitchs traînent ici ou là, et l'API Token pour se connecter à la place de root n'est pas super bien documenté. Mais le projet avance vite donc c'est plutôt bon signe ! Bref, ça promet pas mal. Merci à Maxime pour la découverte ! Afficher l’article complet

Korben Publié le 17 avril 2026 Par Korben, Manuel Dorne korben.info Environ 3 minutes de lecture Quand on fait du self-hosting, y'a toujours ce moment où on se dit "tiens, y'aurait pas un truc open source pour ça". Tenez par exemple, là je suis en train de chercher un machin open source pour un mariage qui permet aux invités de balancer leurs photos sur un serveur en scannant un QR Code. Et donc je me retrouve à scroller awesome-selfhosted sur GitHub, qui est une liste fleuve de +1500 projets, en essayant de deviner lesquels sont encore vivants. Et c'est exactement ce problème qu'a voulu résoudre Ethan Sholly en lançant selfh.st/apps en 2024. En gros, c'est un annuaire d'applications auto-hébergées avec des vrais filtres, du tri, et surtout des indicateurs d'activité. Le mec est aussi derrière la newsletter Self-Host Weekly. L'interface de selfh.st/apps, avec fiches, filtres et indicateurs d'activité Comme ça, au lieu de vous taper une liste brute, vous avez des fiches pour chaque app avec le nombre d'étoiles GitHub, la licence, le langage, les tags, et surtout un code couleur sur la date de dernière activité. Vert si le projet a reçu un commit dans les 6 derniers mois, jaune entre 6 et 12 mois, rouge au-delà d'un an. Pratique pour éviter d'installer un truc que plus personne ne maintient, genre un serveur Plex alternatif mort depuis 2022 ! Et le tri par défaut, c'est pas juste les étoiles GitHub sinon les gros projets à 50 000 étoiles écraseraient tout. L'algo prend en compte l'âge du repo, la date du dernier commit, et même l'intérêt Google Trends pour les projets non-GitHub. Du coup un outil avec 200 stars mais hyper actif peut remonter devant un dinosaure à 30k stars qui dort depuis 18 mois. J'ai trouvé ça pas bête comme filtrage. D'ailleurs, chaque projet a son propre flux RSS filtré qui ne remonte que les releases stables. Pas de bêtas, pas de RC... juste les versions prêtes pour la prod. Comme ça, vous branchez ça dans votre FreshRSS ou Miniflux et vous êtes au courant des mises à jour sans checker chaque repo GitHub à la main ! Par contre, si vous aimez vivre dangereusement sur les nightly, là faudra passer par les flux officiels GitHub. Le site va également plus loin que la simple liste d'apps puisqu'il propose aussi une section "companions", contenant des apps compagnons qui étendent d'autres logiciels auto-hébérgés (genre les extensions navigateur pour Linkedin ou les clients tiers pour Immich...etc). La collection d'icônes pour personnaliser votre Homarr ou Dashy Et surtout, y'a selfh.st/icons avec des milliers d'icônes de dashboard en SVG, PNG et WebP, toutes en 512x512 ratio 1:1, indispensable pour personnaliser votre page d'accueil sur Homarr ou Dashy ! Le catalogue d'apps est sous licence CC0-1.0 (domaine public) et mis à jour tous les matins à 5h du mat' heure de New York (les icônes, elles, sont en CC-BY-4.0, donc pensez à créditer si vous les réutilisez). En 2 minutes de fouille j'y ai trouvé trois projets que je connaissais pas. Et si vous voulez ajouter le vôtre, le repo est ouvert sur https://github.com/selfhst . Et si vous connaissez un outil pour mon projet de QR Code d'upload de photo de mariage, n'hésitez pas à me contacter. Voilà, pour ceux qui font de l'auto-hébergement au quotidien, c'est clairement un bookmark à garder sous le coude. Que vous cherchiez une alternative à Notion, un dashboard pour votre homelab, ou juste un truc pour remplacer un service cloud qui vous gonfle, y'a de quoi fouiller ! Et si vous cherchez des pistes pour commencer, OpenCloud ou Pocket ID sont de bons points de départ. Bref, une mine d'or pour les homelabbers. Merci à Maxime pour le lien ! Afficher l’article complet

IT-Connect Publié le 16 mars 2026 Par Florian BURNEL it-connect.fr Environ 8 minutes de lecture Proxmox VE Helper-Scripts : derrière ce nom se cache une collection de plus de 500 scripts Bash prêts à l'emploi. Ils sont conçus pour faciliter l'administration de Proxmox VE et le déploiement d'applications par l'intermédiaire de conteneurs LXC ou de machines virtuelles. L'utilisation de ces scripts facilite l'automatisation des tâches, en particulier pour le déploiement rapide d'applications. C'est particulièrement pratique pour déployer un environnement de développement rapidement : une seule commande suffit à déployer une application. En effet, chaque service dispose de son propre script Bash conçu pour Proxmox et qui permet de déployer une instance avec un service opérationnel. Si vous désirez en savoir plus, regardez la vidéo ci-dessous ou poursuivez la lecture de cet article. A lire également : Proxmox VE : bien débuter avec les conteneurs LXC Proxmox VE : exécuter des images OCI (Docker) nativement dans LXC Proxmox VE : comment créer des conteneurs Docker ? Que sont les Proxmox VE Helper-Scripts ? Les Proxmox VE Helper-Scripts constituent une collection de scripts shell (développés en Bash) conçus pour interagir directement avec l'interface en ligne de commande de Proxmox. Ces scripts ont pour vocation principale d'automatiser le cycle de vie des conteneurs LXC (Linux Containers) et des machines virtuelles (VM). Au lieu de télécharger manuellement un template de distribution Linux, de créer le conteneur, de configurer les interfaces réseaux, d'allouer l'espace de stockage, puis de mettre à jour le système avant d'installer un applicatif, le script se charge de l'ensemble de ces opérations. Le concept plaît : plus de 500 scripts sont disponibles et ils ont été utilisés plus de 2 millions de fois. Ces scripts, référencés sur le site community-scripts.org et référencés sur GitHub, sont organisés par catégories : Docker, réseau, authentification, sécurité, sauvegarde, et j'en passe. Ce sont les sources officielles liées à ce projet : attention à ne pas tomber sur une autre page lors de vos recherches. En parcourant ces catégories, vous pourrez visualiser des scripts pour : Configurer Proxmox VE et en assurer la maintenance, Déployer une application dans un conteneur LXC, Déployer un système d'exploitation (OPNsense, par exemple) ou une application dans une machine virtuelle. Utilisation d'un Helper-Script Quand vous cliquez sur une application ou un service, vous aurez accès à la description, à la ligne de commande permettant de lancer l'installation ou la tâche, et à des informations supplémentaires pour en savoir plus. À chaque fois, je vous encourage à lire la section "NOTES", elle donne des précisions sur le Helper-Script associé et les éventuelles subtilités. De plus, la section de droite nommée "DETAILS" est précieuse puisqu'elle indique : La version déployée du service, Un lien vers le site web de la solution et vers sa documentation, Le fichier de configuration et le numéro de port (utile pour l'accès à l'interface web), Le code source du script d'installation (avec aussi un lien vers la page sur GitHub), Ce dernier point est important : avant d'exécuter un script provenant d'Internet sur votre serveur Proxmox VE, prenez le temps de le consulter ! Même si c'est une source de confiance, soyez vigilant : c'est une règle d'or. Pour lancer l'opération, c'est simple : vous copiez-collez la ligne de code et vous l'exécutez sur votre serveur Proxmox, depuis le Terminal (local ou SSH). Néanmoins, en basculant sur le mode "Advanced", vous pouvez ajuster la configuration du conteneur qui sera créé : CPU, RAM et disque. Par défaut, chaque service a une configuration prédéfinie, mais vous gardez la main. Dans ce cas, des variables avec les nouvelles valeurs seront ajoutées de façon dynamique à la ligne de commande que vous devez exécuter. Par exemple : var_ram="8192" var_disk="32" bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/immich.sh)" Les scripts s'exécutent via une commande de type bash -c associée à l'utilitaire curl chargé de récupérer le script Bash depuis GitHub (ou Gitea). Ainsi, cette commande récupère le code source brut et l'exécute. Un menu interactif s'affiche alors directement dans le terminal afin de vous guider pendant l'installation (sauf si vous passez par le "Generator") L'assistant propose plusieurs modes d'installation : Default Install : ce mode applique des paramètres prédéfinis. Il alloue la RAM, le nombre de cœurs CPU et l'espace disque jugés adéquats par le développeur du script. L'adresse IP sera obtenue via DHCP. Ce mode convient pour des tests rapides. Advanced Install : il est recommandé de choisir ce mode pour personnaliser le déploiement. En effet, il permet de définir manuellement l'ensemble de la configuration : L'ID du conteneur (CT ID). Le type de conteneur (Privilégié ou Non-privilégié). Le mot de passe root de l'instance. Les ressources matérielles allouées (Cœurs CPU, RAM, Swap). Le volume de stockage à utiliser. L'adresse IP statique, le masque de sous-réseau et la passerelle par défaut. Le VLAN tag, utile si votre réseau est segmenté. Etc... User Defaults : il permet d'utiliser les valeurs par défaut définies par vous, l'utilisateur. Quand vous installez une application une première fois, vos choix sont stockés dans un fichier et ce dernier peut être réutilisé par la suite (vous conservez ainsi vos préférences). Une fois les paramètres validés, le script télécharge l'image du système d'exploitation, configure l'instance, la démarre, puis exécute un script de post-installation à l'intérieur du conteneur pour installer l'application (ici, Docker). L'installation s'effectue en totale autonomie et le retour console permet de suivre la progression des opérations. A la fin, quand une application est installée, vous aurez toujours l'URL d'accès, comme ici : http://192.168.110.13:2283. Il suffit d'accéder à cette URL pour accéder à l'application ! Voyez par vous-même. Le générateur de scripts personnalisés Depuis le site officiel de ce projet, vous pouvez accéder à un générateur de scripts pour automatiser l'installation selon une approche sans surveillance. Il vous suffit de cliquer sur "Generator" dans le menu. Vous choisissez le script à personnaliser, à savoir celui de l'application à déployer. Vous définissez ensuite les ressources à attribuer à ce conteneur LXC ou à cette VM. Puis, vous pouvez personnaliser tout le reste : ID de conteneur, nom d'hôte, mot de passe, pont réseau sur lequel se connecter, ID de VLAN ou encore les options comme le SSH, le GPU Passthrough et le Nesting. Une fois la configuration effectuée via cette interface en ligne, vous obtenez une commande prête à l'emploi. Cette commande contient des variables préconfigurées qui sont le reflet des choix effectués via le formulaire du générateur. Voici un exemple : mode=generated var_ctid="500" var_hostname="immich-itconnect" var_vlan="10" var_tags="media" var_gpu="yes" bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/immich.sh)" Si vous lancez la commande obtenue, l'installation sera lancée et vous n'aurez rien à faire ! Tout est automatique (vous noterez la présence de mode=generated). Gérer la maintenance et les opérations d'administration Les Helper-Scripts ne se limitent pas à la création d'instances. De nombreux scripts participent à la maintenance de l'hyperviseur et des conteneurs. Script pour la post-installation de Proxmox VE Il existe également des scripts destinés à configurer l'hôte Proxmox lui-même, en particulier après une nouvelle installation. Ces outils appelés "Post-Install Scripts" automatisent des tâches d'administration courantes et s'adressent à Proxmox VE, mais aussi Proxmox Mail Gateway et Proxmox Backup Server (PBS). Dans le cas de Proxmox VE, le script nommé PVE Post Install effectue un ensemble d'actions : La désactivation du message d'avertissement lié à l'absence de souscription commerciale (Enterprise Repository). L'ajout des dépôts communautaires (No-Subscription Repository) pour permettre les mises à jour du système via apt. La mise à jour du nœud Proxmox VE (paquets) La désactivation des services inutiles si vous n'envisagez pas d'être en mode cluster (réversible) Etc... À chaque fois, vous avez le choix : vous gardez le contrôle. Le script n'impose rien. Script de mise à jour des conteneurs LXC Certains applicatifs hébergés en LXC ne disposent pas de mécanisme de mise à jour interne simple. Des scripts spécifiques permettent d'automatiser ce processus. En exécutant un script de mise à jour (souvent nommé update script), le système se connecte au conteneur, arrête les services concernés, télécharge la dernière version de l'application depuis son dépôt officiel, l'installe et redémarre le service, le tout en préservant les données de configuration de l'utilisateur. Il y a en réalité deux catégories de scripts de mises à jour : Les scripts pour mettre à jour l'OS dans les conteneurs LXC (ils ne touchent pas à l'application). Les scripts pour mettre à jour l'application en elle-même. Par exemple, le script PVE LXC Updater sert justement à mettre à jour le système d'exploitation. De son côté, le script PVE LXC Apps Updater met à jour les applications. Pour cela, il surveille les tags sur les conteneurs LXC afin de cibler les conteneurs avec le tag community-script ou proxmox-helper-scripts (par défaut, car c'est personnalisable). Script de sauvegarde Proxmox VE Un dernier cas d'usage et script que l'on peut citer : PVE Host Backup. Ce script permet aux utilisateurs de sauvegarder des données, tout en offrant la possibilité de sélectionner les fichiers et répertoires spécifiques à sauvegarder. Cette flexibilité lui permet une compatibilité large, qui va au-delà de Proxmox (merci Bash). Dans le contexte de Proxmox VE, ce script facilite la sauvegarde des fichiers systèmes. Conclusion L'utilisation des Proxmox VE Helper-Scripts représente une méthode efficace pour rationaliser les déploiements de services en limitant les opérations manuelles et répétitives. Si vous aimez tester différentes applications, cela représentera un gain de temps ! Vous pouvez aussi vous inspirer de ces scripts pour coder vos propres scripts d'installation. Veillez toujours à privilégier l'utilisation de conteneurs non privilégiés et à réviser le code source du script avant l'exécution. Ceci est particulièrement vrai pour les applications où il y a peu d'installations, bien que les Helper-Scripts soient largement utilisés et révisés par la communauté. Ingénieur système et réseau, cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Je souhaite partager mon expérience et mes découvertes au travers de mes articles. Généraliste avec une attirance particulière pour les solutions Microsoft et le scripting. Bonne lecture. Afficher l’article complet

IT-Connect Publié le 6 avril 2026 Par Florian BURNEL it-connect.fr Environ 24 minutes de lecture Ce guide technique explique comment installer et configurer la solution open source AdGuard Home pour bloquer les publicités et les sites malveillants à l'échelle d'un réseau. La question suivante sera aussi abordée : comment bénéficier du blocage des publicités depuis n'importe où ? Grâce à la mise en place de la solution AdGuard Home, vous reprenez le contrôle sur votre navigation. Je dirais même que, d'une façon générale, vous allez avoir plus de contrôle sur les connexions effectuées par les appareils connectés à votre réseau. En effet, au-delà de bloquer les publicités, une solution comme celle-ci peut aussi bloquer les solutions de tracking et de suivi, ainsi que des sites indésirables ou malveillants. AdGuard Home est capable de nettoyer les flux réseau sur l'ensemble des appareils : de votre ordinateur à votre smartphone, en passant par votre TV connectée à Internet. Se pose alors une première question : comment fonctionne ce mécanisme de blocage ? Avant de parler de la solution AdGuard Home et du choix de cette solution, prenons un instant pour évoquer le mécanisme de blocage. Tout va jouer au niveau du DNS. Pour rappel, le système de noms de domaine (DNS) agit comme l'annuaire d'Internet. Lorsque vous tapez l'adresse d'un site web dans votre navigateur, votre ordinateur interroge un serveur DNS pour traduire ce nom de domaine en une adresse IP compréhensible par les machines. Sans cela, on serait obligé de connaître les adresses IP des sites par cœur : c'est tout simplement impossible. Ainsi, quand vous accédez à un site web comme www.domaine.fr, votre machine interroge le serveur DNS configuré dans les paramètres réseau de votre ordinateur pour obtenir l'adresse IP correspondante. Le blocage au niveau DNS, souvent appelé "DNS sinkholing" (que l'on appelle aussi trou noir DNS, ou DNS menteur), intervient exactement à cette étape. Lorsqu'une page web tente de charger une publicité ou un script de suivi, elle effectue une requête vers un domaine spécifique (par exemple, ads.serveur-publicite.com). Si vous utilisez AdGuard Home comme serveur DNS, celui-ci compare chaque requête à une liste de filtres (blocklists). Si le domaine demandé figure dans ces listes, AdGuard Home refuse de résoudre l'adresse IP réelle et renvoie une réponse invalide (comme 0.0.0.0). Le résultat est direct : l'appareil ne peut pas contacter le serveur publicitaire, et la publicité ne s'affiche pas. Cette méthode est légère, rapide et s'applique à tous les appareils utilisant ce serveur DNS. Le site web visité, quant à lui, continuera de fonctionner correctement. En effet, si vous accédez à IT-Connect via www.it-connect.fr et que vous bloquez les publicités chargées depuis www.domaine-pub.fr, il n'y a que les contenus relatifs à la publicité qui sont bloqués. Pour certains sites mondiaux, c'est parfois difficile, car les publicités et le site web sont chargés depuis le même domaine : dans ce cas, le blocage des publicités par DNS ne peut pas fonctionner. Les fonctionnalités principales d'AdGuard Home AdGuard Home est une solution open source, gratuite et éprouvée. Elle est développée et maintenue depuis plusieurs années. Sa principale alternative est elle aussi open source et s'appelle Pi-Hole. Il en existe d'autres, comme Blocky. AdGuard Home se distingue par une interface moderne et des fonctionnalités complètes, on peut citer : Filtrage des requêtes DNS : blocage des publicités, des traqueurs et des domaines malveillants en s'appuyant sur des listes maintenues par la communauté. Sur le papier, vous pouvez bloquer n'importe quel site web grâce aux règles personnalisées. Contrôle parental : possibilité d'activer la recherche sécurisée (Safe Search) sur les principaux moteurs de recherche (Google, Bing, DuckDuckGo) pour filtrer les contenus inappropriés. Blocage de services : une section dédiée permet de bloquer rapidement des applications ou des services populaires (comme TikTok, YouTube, WhatsApp, etc.) sans avoir à chercher manuellement les domaines associés. Du blocage en 1-clic. Gestion par client (appareil) : vous pouvez appliquer des règles de filtrage spécifiques en fonction de l'adresse IP, de l'adresse MAC ou du nom de l'appareil. Cette gestion par appareil offre beaucoup de souplesse. Chiffrement DNS : par défaut, les flux du DNS ne sont pas protégés (pas de chiffrement). AdGuard Home offre l'avantage de supporter nativement des protocoles sécurisés comme DNS-over-HTTPS (DoH) et DNS-over-TLS (DoT). Cela est vrai pour échanger avec les clients et les serveurs DNS upstreams (résolveurs). Où peut-on installer AdGuard Home ? AdGuard Home est conçu pour être léger et peu gourmand en ressources, ce qui permet de le déployer sur une grande variété d'équipements. Il existe des images Docker et des programmes d'installation pour différents OS. On peut donc imaginer les scénarios d'installation suivants : Sur un NAS : Docker est pris en charge par toutes les marques (Synology, QNAP, ASUSTOR, UGREEN, etc.). Sur un nano-ordinateur : un Raspberry Pi est parfaitement adapté (via cette commande : curl -s -S -L https://raw.githubusercontent.com/AdguardTeam/AdGuardHome/master/scripts/install.sh | sh -s -- -v) Sur un serveur Linux ou un VPS : que ce soit sous Debian, Ubuntu ou Alpine Linux (via cette commande : curl -s -S -L https://raw.githubusercontent.com/AdguardTeam/AdGuardHome/master/scripts/install.sh | sh -s -- -v) Directement sur Windows ou macOS : bien que ce soit moins courant pour un usage en réseau, des exécutables sont disponibles. Ce qui est important, c'est que l'appareil soit disponible 24/7 sur votre réseau, car AdGuard Home va devenir indispensable pour assurer le bon fonctionnement de votre connexion Internet. Un NAS ou un Raspberry Pi, c'est l'idéal. Dans le cadre de ce tutoriel, nous nous concentrerons sur une installation conteneurisée via Docker. L'avantage étant de pouvoir reproduire cette configuration sur différents types d'équipements à partir du moment où Docker est présent. Tutoriel - Installer AdGuard Home sur un NAS Synology AdGuard Home : ce qu'il peut bloquer & ce qu'il ne peut pas bloquer Entre les services en ligne et les bloqueurs de publicités, c'est un peu le jeu du chat et de la souris. Chacun essaie de prendre le dessus sur l'autre. Résultat, AdGuard Home ne peut pas bloquer toutes les publicités. Ce n'est pas qu'il est mauvais, c'est qu'il est limité par son mode de fonctionnement basé sur le DNS et aussi parce qu'en face, il y a beaucoup de services qui utilisent des techniques difficiles à contourner. Voici un état des lieux : Type de contenu AdGuard Home Explication technique Bannières classiques et pop-ups ✅ Bloqué La publicité provient d'un serveur tiers. AdGuard Home bloque la résolution DNS du domaine externe. Selon la façon dont est implémentée la publicité, cela peut laisser un espace blanc sur le site web. Télémétrie et traqueurs ✅ Bloqué Excellente efficacité contre les outils d'analyse (Google Analytics), le pistage Windows, IoT ou Smart TV qui communiquent avec des serveurs dédiés. Pubs "In-App" (smartphones/jeux) ✅ Bloqué Les applications mobiles gratuites font généralement appel à des régies publicitaires externes (domaines tiers) facilement identifiables et neutralisables. Publicités vidéo (YouTube, Twitch) ❌ Non bloqué La publicité et la vidéo légitime sont diffusées par le même domaine de streaming. Bloquer la pub revient à bloquer le site, ce qui empêche son fonctionnement. Posts sponsorisés sur les réseaux sociaux ❌ Non bloqué Sur Facebook, Instagram ou X (Twitter), les annonces sponsorisées sont injectées directement dans le flux d'actualité depuis les serveurs de la plateforme. AdGuard Home ne peut rien y faire. Installation d'AdGuard Home avec Docker Pour ce déploiement, je vous propose d'utiliser un mode réseau bien spécifique au niveau de Docker : le macvlan. Ce mode permet d'attribuer une adresse IP distincte de celle du serveur Docker directement au conteneur AdGuard Home. Ainsi, il aura sa propre adresse IP pour communiquer avec les appareils du réseau. Vous pourriez tout à fait utiliser le mode habituel (bridge) pour ce conteneur, mais AdGuard Home partagerait l'adresse IP du serveur Docker. Dans ce cas, et à cause du mécanisme de NAT interne à Docker, vous ne pourriez pas voir l'adresse IP source des clients. Donc, au niveau d'AdGuard Home, toutes les requêtes seront associées à un seul client, ce qui veut dire que vous n'aurez pas de statistiques par client (ni la possibilité de faire des règles par client) dans AdGuard Home. Si ce n'est pas important pour vous, alors l'utilisation d'un réseau macvlan est facultative. Personnellement, je trouve cela contraignant. Avant de commencer, je vous rappelle que le conteneur AdGuard Home doit être joignable sur le port 53 (standard pour le DNS). D'autres ports seront utilisés en fonction des services activés (serveur DHCP géré par AdGuard Home, par exemple). Création du réseau MacVlan en ligne de commande Il est préférable de créer le réseau MacVlan manuellement en amont. La raison est simple : vous ne pouvez avoir qu'un seul réseau MacVlan rattaché à une interface physique. Peut-être même que vous en avez déjà un, selon les services déjà déployés sur votre serveur Docker. Si ce n'est pas le cas, l'idée c'est de le créer puis d'y connecter ensuite le conteneur AdGuard Home. Par la suite, vous pourriez tout à fait connecter d'autres conteneurs à ce réseau. Pour cela, ouvrez un Terminal sur votre serveur ou lancez une connexion SSH. ssh <nom utilisateur>@<IP du serveur Docker> Une fois connecté en SSH, exécutez la commande docker network indiquée ci-dessous. Attention : veillez à adapter l'interface parent (eth0), le sous-réseau (subnet), la passerelle de votre routeur (gateway) et la plage d'IP souhaitée (ip-range) à votre propre réseau local. Si vous avez connecté l'interface 1 de votre serveur Docker au réseau, cela devrait être eth0. Vous pouvez le vérifier en saisissant la commande ip a et en regardant quel est le nom de l'interface où est configurée l'adresse IP de votre serveur. Voici la commande à exécuter pour créer le réseau MacVlan : docker network create -d macvlan \ -o parent=eth0 \ --subnet=192.168.10.0/24 \ --gateway=192.168.10.254 \ --ip-range=192.168.10.144/28 \ macvlan_net Dans l'exemple ci-dessous, un masque /28 est utilisé. Ainsi, avec la plage 192.168.10.144/28, cela mettra à disposition de Docker les adresses allant de 192.168.10.144 à 192.168.10.159. De quoi vous permettre de connecter jusqu'à 14 conteneurs via ce réseau MacVlan. Ensuite, vous pouvez vérifier l'existence de ce réseau et afficher sa configuration via ces deux commandes : docker network ls docker network inspect macvlan_net Note : l'idéal, c'est que cette plage d'adresses IP (de .144 à .159) soit exclue de la plage de distribution de votre serveur DHCP (votre box Internet ou votre routeur). Cela assure qu'il n'y aura pas de conflits. Déploiement AdGuard Home avec Docker Compose Maintenant que le réseau macvlan_net existe, nous pouvons créer notre fichier docker-compose.yml. Mais avant cela, créons l'arborescence de dossiers pour la persistance des données d'AdGuard Home. sudo mkdir -p /opt/docker-compose/adguard-home/{workdir,confdir} Note : le dossier confdir contiendra le fichier de configuration AdGuardHome.yaml. Ce fichier contient l'ensemble de la configuration d'AdGuard Home. Créez un fichier docker-compose.yml : sudo touch /opt/docker-compose/adguard-home/docker-compose.yml Insérez la configuration suivante dans ce fichier : services: adguardhome: image: adguard/adguardhome:latest container_name: adguard restart: unless-stopped volumes: - ./workdir:/opt/adguardhome/work - ./confdir:/opt/adguardhome/conf networks: macvlan_net: ipv4_address: 192.168.10.151 # L'IP accessible par tous les appareils du réseau local adguard_bridge: ipv4_address: 10.10.10.2 # L'IP interne accessible par le NAS/serveur hôte networks: macvlan_net: external: true adguard_bridge: driver: bridge ipam: config: - subnet: 10.10.10.0/24 gateway: 10.10.10.1 Lancez ensuite la création du conteneur en vous plaçant dans le dossier contenant le fichier, puis exécutez : docker compose up -d L'application va s'initialiser et si vous consultez les journaux (docker compose logs), vous devriez voir ceci : adguard | [info] webapi: AdGuard Home is available at the following addresses: adguard | [info] go to http://127.0.0.1:3000 adguard | [info] go to http://[::1]:3000 adguard | [info] go to http://10.10.10.2:3000 adguard | [info] go to http://192.168.10.151:3000 adguard | [info] starting plain server server=plain addr=0.0.0.0:3000 Premiers pas avec AdGuard Home Une fois le conteneur démarré, ouvrez votre navigateur web et rendez-vous sur l'adresse IP que nous avons définie, suivie du port d'installation par défaut : http://192.168.10.151:3000. Si cela ne fonctionne pas, et que votre machine Docker est une machine virtuelle, le commutateur virtuel (vSwitch) de votre hyperviseur bloque très probablement la connexion. Pourquoi ? En réalité, le réseau Macvlan génère une nouvelle adresse MAC virtuelle pour le conteneur. Par sécurité, les hyperviseurs bloquent le trafic destiné à une adresse MAC qu'ils n'ont pas explicitement attribuée à la VM. La solution consiste à modifier les paramètres de la machine virtuelle pour autoriser ce phénomène. Ce sera une configuration à effectuer sur plusieurs plateformes (Hyper-V, VMware, Proxmox...). Dans le cas d'Hyper-V, utilisé pour cet exemple, voici l'option à activer. Configuration initiale Un assistant de configuration va vous accueillir. Cinq étapes rapides à compléter nous attendent. Cliquez sur le bouton pour commencer. Vous devez indiquer sur quelle interface réseau (et quel port) sera joignable l'interface d'administration. La même chose est demandée pour le serveur DNS (port 53). Laissez par défaut (important pour le DNS si le serveur Docker doit aussi utiliser AdGuard Home comme DNS) ou sélectionnez l'interface correspondant à votre IP 192.168.10.151. Créer un compte administrateur : choisissez un nom d'utilisateur et un mot de passe robuste. AdGuard Home vous explique rapidement comment configurer vos appareils. En effet, la mise en œuvre d'une telle solution implique une modification de la configuration des appareils de votre réseau. Il ne sera pas nécessaire de configurer manuellement chaque appareil, comme nous le verrons ensuite. Une fois ces étapes validées, le tableau de bord principal sera accessible sur http://192.168.10.151 (sans le port 3000). Voilà, la configuration initiale est terminée ! Le tableau de bord affiche des statistiques d'utilisation (requêtes DNS totales, requêtes bloquées, etc.). Le menu présent en haut permet d'accéder aux différentes sections de la configuration. Actuellement, AdGuard Home est opérationnel. Sa configuration en sortie de boîte permet de filtrer les publicités. Néanmoins, il est préférable d'ajuster sa configuration pour en profiter pleinement, c'est ce que nous allons voir. Configuration des DNS upstreams (serveurs en amont) AdGuard Home ne connaît pas toutes les adresses IP des sites web. Lorsqu'il reçoit une requête DNS légitime, il doit la transmettre à un serveur DNS externe capable de la résoudre. C'est un tiers de confiance et vous avez le choix du serveur, ou je dirais même, des serveurs, que vous souhaitez solliciter. Allez dans Paramètres > Paramètres DNS. Dans la section "Serveurs DNS en amont", vous pouvez renseigner les serveurs DNS de votre choix. Certains sont réputés pour être plus respectueux de la vie privée que d'autres, certains feront eux aussi du filtrage, etc... Il y a le choix. Surtout, AdGuard Home peut interroger ces serveurs DNS via le protocole DNS traditionnel (flux en clair) ou via DoH ou DoT, ce qui permet de chiffrer les flux. Il est donc préférable d'utiliser des serveurs DNS upstreams compatibles DoH ou DoT. Par exemple les serveurs de Quad9 et Cloudflare via DNS-over-HTTPS : https://dns10.quad9.net/dns-query https://dns.cloudflare.com/dns-query Vous pouvez visiter cette page pour avoir une liste complète de serveurs que vous pouvez solliciter en tant que résolveur DNS. Par défaut, le mode "Équilibrage de charge" est sélectionné, ce qui signifie que tous les serveurs présents dans votre liste de serveurs upstreams seront sollicités. Par exemple, AdGuard pourra solliciter un serveur DNS pour répondre à un client, et à la prochaine sollicitation, il contactera l'autre serveur DNS. Même si en réalité, AdGuard priorisera celui qui offre les meilleures performances (vous le verrez dans les statistiques). Vous pouvez aussi choisir le mode "Requêtes en parallèle" pour qu'AdGuard sollicite plusieurs serveurs en même temps. Un peu plus bas dans la page, vous allez tomber sur une section nommée "Serveurs DNS d'amorçage". Il s'agit de serveurs DNS qu'AdGuard sollicitera pour résoudre les adresses des serveurs DoH. En effet, quand on indique à AdGuard d'utiliser https://dns10.quad9.net/dns-query comme serveur upstream, il doit forcément résoudre ce nom au moins une fois (dns10.quad9.net). D'autres paramètres sont disponibles pour vous permettre de gérer le comportement du cache, de définir des résolveurs privés (notamment pour les zones de recherche inversées) et le type de blocage. Ce dernier point fait écho à mes propos précédents. En effet, vous indiquez à AdGuard Home comment il doit bloquer les sites correspondant à de la publicité ou autre... Le mode par défaut indique bien "Répondre avec adresse IP zéro", ce qui veut bien dire qu'AdGuard Home va mentir au client DNS en lui indiquant que l'IP de la ressource est 0.0.0.0. Pensez à enregistrer les paramètres modifiés au niveau de chaque section de cette même page. Gestion des listes de filtrage Par défaut, AdGuard Home utilise sa propre liste de blocage. Pour aller plus loin et améliorer la sécurité de votre réseau, je vous recommande d'ajouter des listes supplémentaires. La gestion de ces listes s'effectue ici : Filtres > Listes de blocage DNS. Cliquez sur le bouton "Ajouter liste de blocage". Vous pouvez sélectionner des listes communautaires depuis une liste préconfigurée dans AdGuard Home ou ajouter vos propres listes. L'objectif étant d'utiliser des listes qui offrent un bon ratio de blocage avec très peu de faux positifs (sites légitimes bloqués par erreur). Sinon, cela va devenir un enfer à gérer. Je vous recommande ces listes : Steven Black (reconnue mondialement) : https://adguardteam.github.io/HostlistsRegistry/assets/filter_33.txt Phishing URL Blocklist (PhishTank and OpenPhish) : https://adguardteam.github.io/HostlistsRegistry/assets/filter_30.txt Nicolas Pawlak (Red Flag Domains) pour bloquer les domaines malveillants (tentative d'usurpation de marques) : https://dl.red.flag.domains/adguard/red.flag.domains.txt Ajoutez ces listes une par une. Comme le montre l'image ci-dessous, ces listes contiennent plusieurs dizaines de milliers de règles. Si vous piochez directement dans la liste des listes proposées par AdGuard Home, vous verrez qu'elles sont organisées par catégorie. Je vous invite à cliquer sur le bouton en forme de maison pour accéder au site de la liste afin d'en savoir plus avant de l'activer. Par ailleurs, dans le menu "Filtres", il y a une entrée nommée "Règles de filtrage personnalisées". Cela vous permet de déterminer des règles de blocage ou d'autorisation personnalisées. Quand vous allez créer des exclusions via le "Journal des requêtes", cela viendra alimenter cette section. AdGuard Home intègre son propre moteur de gestion de règles, ce qui vous permet de créer du sur-mesure. Une règle || sert à bloquer, tandis qu'une règle @@|| sert à autoriser (débloquer). L'exemple ci-dessous permet de débloquer la plateforme d'affiliation awin.com, que j'utilise pour IT-Connect. C'est un système très flexible. En effet, vous pouvez gérer des clients dans AdGuard Home (c'est-à-dire vos appareils) et chaque appareil peut avoir un type (PC, NAS, mobile, etc...). Ainsi, vous avez la possibilité de créer des règles qui s'appliqueront uniquement à certains clients nommés ou certains types de clients. L'exemple ci-dessous sert à bloquer le domaine exemple.fr pour tous les clients, sauf ceux qui ont le tag device_phone. ||exemple.fr^$ctag=~device_phone La syntaxe des règles de blocage est expliquée sur cette page. Blocage des services L'une des forces de l'outil AdGuard Home, c'est sa capacité à bloquer des services populaires : ChatGPT, Tinder, Xbox Live, Dropbox, Microsoft Teams, Proton, Amazon, eBay, etc.... Une liste prédéfinie est disponible ici : Filtres > Services bloqués. Si vous souhaitez empêcher l'accès aux réseaux sociaux (ou à un autre service) sur une plage horaire ou de manière permanente, il suffit de cocher le nom du service et de sauvegarder. AdGuard Home s'occupe alors de bloquer tous les domaines liés à ce service ! En bas de page, vous pouvez aussi créer des règles selon une plage horaire. Gestion des clients Pour appliquer des règles de filtrage ou d'exclusion spécifiques, AdGuard Home doit pouvoir identifier l'origine des requêtes DNS. La solution propose quatre méthodes pour effectuer une identification des clients : Adresse IP (192.168.1.98) : la méthode la plus directe est d'identifier le client à partir de son adresse IP. Mais, attention, l'équipement doit disposer d'une IP fixe (ou d'une réservation DHCP) pour garantir que l'identification reste fiable dans le temps. S'il change d'adresse IP, cela va perturber forcément le bon fonctionnement. Plage CIDR (192.168.1.0/24) : permet d'appliquer une stratégie à un sous-réseau entier. Idéal pour traiter par lots un réseau invité ou un VLAN dédié aux objets connectés (IoT). Vous fonctionnez par sous-réseau plutôt que par client. Adresse MAC (AA:BB:CC:DD:EE:FF) : fiable car cette méthode est liée à l'interface matérielle de l'appareil. Néanmoins, cette fonctionnalité requiert que le service DHCP soit géré par AdGuard Home lui-même, et non par votre box ou routeur. ClientID (DNS chiffré) : une approche avancée réservée lors de l'utilisation des protocoles sécurisés (DoH, DoT ou DoQ). Le client s'identifie au travers d'une URL personnalisée (par exemple : https://dns.domaine.fr/dns-query/mon-client). La gestion des clients permet d'avoir une idée précise de "qui a accédé à quoi" au niveau du réseau, bien que ce soit tout de même restreint à tout accès qui implique une requête DNS en amont. Mais, c'est aussi une façon de ne pas appliquer les mêmes règles à tous les appareils. Pour gérer les clients, accédez à : Paramètres > Paramètres du client. Vous pouvez identifier une machine par son adresse IP ou son adresse MAC et lui attribuer une politique spécifique : par exemple, désactiver le blocage de certains services pour votre ordinateur de travail, mais l'activer pour les tablettes des enfants. Vous pouvez visualiser vos clients existants et en ajouter des nouveaux. Quand vous ajoutez un client, vous devez le nommer, lui associer des mots-clés (c'est-à-dire un ou plusieurs tags), et surtout un identifiant (selon l'une des méthodes évoquées ci-dessus). Vous avez la possibilité de lui associer des règles spécifiques, comme l'activation du contrôle parentale, la recherche sécurisée, etc. Les journaux d'accès La section "Journal des requêtes" accessible depuis le menu principal, permet de visualiser, en temps réel, quelles sont les requêtes DNS traitées par AdGuard Home. Vous verrez les requêtes autorisées et celles bloquées. Quand c'est bloqué, vous saurez de quelle liste provient le blocage (AdGuard DNS Filter, sur l'exemple ci-dessous). Pour chaque ligne, vous avez plusieurs informations : la date et l'heure, le nom de domaine cible, l'action, et le client à l'origine de la demande. Sur chaque ligne, vous avez aussi trois points verticaux permettant d'accéder à un menu. Quatre actions sont proposées : Débloquer : pour créer une règle permettant d'autoriser le domaine en question (de quoi gérer les faux positifs), Débloquer uniquement pour ce client : comme l'action précédente, mais en autorisant le flux uniquement pour ce client, Interdire ce client : pour bloquer totalement cet appareil. Ajouter comme client persistant : pour ajouter cet appareil comme nouveau client persistant dans votre base (ce qui va alimenter Paramètres > Paramètres du client). Vous pouvez aussi rechercher un domaine, un client, ou filtrer par type de journaux. Ci-dessous, le filtre est positionné sur "Services bloqués", ce qui permet d'afficher les requêtes pour les services bloqués via la section suivante : Filtres > Services bloqués. AdGuard Home bloque un site, que faire ? N'allez pas croire qu'AdGuard Home est une solution miracle qui ne nécessite pas de maintenance. Au début, vous aurez forcément besoin de faire des ajustements dans la configuration, notamment pour débloquer les faux positifs ou les services que vous utilisez et qui ont été bloqués. Par exemple, si vous utilisez le service de streaming TF1+ pour regarder des programmes en ligne, vous serez confronté à une erreur comme celle-ci : La raison est simple : TF1+ dispose de capacités de détection lui permettant de voir que vous essayez de bloquer les publicités. Par conséquent, il vous empêche de lire la vidéo. Face à cette situation que vous allez très certainement rencontrer, que faire ? Voici trois options pour contourner ce blocage : La liste blanche (ciblée) : ajoutez manuellement les adresses des serveurs publicitaires de TF1 dans vos règles de filtrage personnalisées AdGuard. L'analyse en direct (sur-mesure) : lancez la vidéo, consultez le journal des requêtes d'AdGuard et débloquez à la volée les lignes rouges qui s'affichent au moment du blocage. L'exclusion de l'appareil (déconseillé) : enregistrez l'adresse IP de votre TV ou Box dans les paramètres clients d'AdGuard pour désactiver totalement le filtrage antipub sur cet écran précis. Vous devez donc passer par le "Journal des requêtes" pour identifier les flux bloqués et faire le nécessaire. Pour TF1+, à l'heure actuelle, vous pouvez ajouter ces règles dans le filtrage personnalisé (pour débloquer ces domaines) : @@||pub.tf1.fr^ @@||s.tf1.fr^ @@||adproxy.tf1.fr^ @@||ads.stickyadstv.com^ @@||tf1-fram.adswizz.com^ La configuration des clients pour AdGuard Home Votre serveur AdGuard Home est activé, il est configuré, mais pour autant, il ne bloque pas encore les publicités sur vos appareils. C'est normal. Vous devez l'utiliser en tant que serveur DNS. Sur un réseau domestique, la Box est utilisée par défaut en tant que DNS. Mais, là, vous devez solliciter votre serveur AdGuard Home. Plusieurs options sont possibles pour effectuer la configuration des clients : Modifier la configuration du DHCP sur votre box (ou routeur) pour diffuser l'adresse IP de votre serveur AdGuard Home comme DNS. Au niveau des options, cela dépend si vous utilisez une Box Orange, Free, Bouygues, etc. Utiliser AdGuard Home comme DHCP, et donc diffuser son IP comme serveur DNS. Veillez à désactiver le DHCP de la Box si vous partez sur cette méthode. Éditez manuellement la configuration IP d'un appareil pour spécifier l'adresse IP du serveur AdGuard Home comme serveur DNS. Méthode nécessaire sur les appareils avec une adresse IP fixe, et dans un premier temps pour faire un test de bon fonctionnement. Sur Windows, cela revient à spécifier l'adresse IP du serveur AdGuard Home de cette façon : À partir du moment où la configuration sera effective, vous verrez de premières lignes arriver dans le journal des accès d'AdGuard Home. Bloquer les publicités depuis n'importe où Si vous désirez profiter du blocage des publicités depuis n'importe où, c'est-à-dire y compris lorsque vous n'êtes pas connecté à votre réseau local, sachez que c'est possible. Vous devez utiliser une connexion VPN vers votre réseau local, afin d'appliquer le même principe : utiliser le serveur AdGuard Home comme serveur DNS. Pour mettre en place cette connexion à distance, plusieurs solutions sont envisageables : Utiliser un VPN de type OpenVPN ou WireGuard, ce second étant recommandé pour de meilleures performances, Utiliser une solution comme Tailscale ou Twingate pour mettre en place un réseau maillé sécurisé entre vos appareils (approche ZTNA). Il existe tout de même une autre solution qui n'implique même pas l'utilisation d'un VPN : DNS-over-HTTPS. Vous pouvez exposer votre serveur AdGuard Home sur Internet sous la forme d'un serveur DNS compatible DNS-over-HTTPS (DoH). Ainsi, vous n'exposez pas directement l'interface d'administration de la solution, mais bien le point d'entrée sécurisé en HTTPS. Pour cela, vous devez : Activer l'option "Activer le chiffrement (HTTPS, DNS-over-HTTPS et DNS-over-TLS)" dans les paramètres de chiffrement d'AdGuard Home. Ce qui implique également d'importer un certificat TLS pour chiffrer les connexions. Publier AdGuard Home via un reverse proxy ou Cloudflare, de façon à publier de façon sécurisée votre instance comme vous pourriez le faire avec une autre solution. Note : sans cette configuration, AdGuard Home peut tout de même contacter les résolveurs DNS externes (upstreams) via DoH ou DoT. Conclusion Le déploiement d'AdGuard Home sur un réseau local est une démarche efficace pour assainir sa navigation web. En centralisant le filtrage au niveau du protocole DNS, vous protégez d'un seul coup l'ensemble des équipements de votre réseau, y compris les objets connectés ou les TV connectées sur lesquels l'installation d'un bloqueur de publicités n'est pas toujours possible. Je publierai très prochainement des articles complémentaires pour vous expliquer comment utiliser AdGuard Home en tant que DoH, mais pas seulement. Qu'est-ce qu'AdGuard Home ? C'est un logiciel open source agissant comme un serveur DNS pour filtrer les requêtes réseau, bloquant ainsi les publicités et le suivi à l'échelle de tout un réseau. Quelle est la différence entre AdGuard Home et Pi-hole ? Pi-hole est l'outil historique, très populaire. AdGuard Home, écrit en Go, est plus récent et propose nativement des fonctionnalités comme le chiffrement DNS (DoH/DoT) et le blocage d'applications spécifiques, sans nécessiter de configurations additionnelles. Les deux applications répondent aux mêmes besoins : le blocage des publicités. AdGuard Home bloque-t-il les publicités sur YouTube ? Le blocage des publicités YouTube via DNS est complexe car Google sert ses vidéos et ses publicités depuis les mêmes noms de domaine. AdGuard Home ne peut pas bloquer ces publicités de manière fiable sans risquer de bloquer la vidéo elle-même. Est-ce qu'AdGuard Home ralentit ma connexion Internet ? Non, je dirais même qu'il aura a tendance à l'accélérer ! En bloquant les publicités et les scripts lourds avant même qu'ils ne soient téléchargés, les pages web se chargent plus rapidement et la bande passante est économisée. Puis-je utiliser AdGuard Home en dehors de mon réseau local ? C'est possible si vous le couplez avec un serveur VPN personnel (comme WireGuard ou OpenVPN) ou des solutions de réseau maillé comme Tailscale ou Twingate. Vos appareils mobiles profiteront ainsi du filtrage même en 4G/5G. Qu'est-ce qu'un serveur DNS "upstream" ou en amont ? C'est le serveur DNS public (comme ceux de Cloudflare, Google, ou Quad9) vers lequel AdGuard Home transfère vos requêtes si le domaine demandé n'est pas bloqué par vos listes. C'est ce qui vous permet d'avoir accès à Internet. Ingénieur système et réseau, cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Je souhaite partager mon expérience et mes découvertes au travers de mes articles. Généraliste avec une attirance particulière pour les solutions Microsoft et le scripting. Bonne lecture. Afficher l’article complet

IT-Connect Publié le 12 mars 2026 Par Florian BURNEL it-connect.fr Environ 7 minutes de lecture Exécuter des conteneurs Docker sur un environnement Proxmox VE, c'est une action que beaucoup d'entre vous cherchent à réaliser. Quelles sont les options possibles pour utiliser Docker sur Proxmox VE ? Quels sont les avantages et les inconvénients de ces méthodes ? Voici l'essentiel à savoir à ce sujet. Pour approfondir le sujet des conteneurs sur un environnement Proxmox VE, je vous invite à lire mes deux précédents articles à propos des conteneurs LXC : Proxmox VE : bien débuter avec les conteneurs LXC Proxmox VE : exécuter des images OCI (Docker) nativement dans LXC L'option à éviter : Docker sur l'hôte Proxmox VE Commençons par ce qu'il est préférable d'éviter : l'installation de Docker directement sur l'hôte Proxmox VE en lui-même ! Cela revient à positionner Docker au même niveau que Proxmox VE, à savoir directement sur le système d'exploitation de l'hôte (Debian). Je vous déconseille d'adopter cette méthode, je trouve que ce n'est pas propre. Docker doit venir se positionner sur une couche supérieure vis-à-vis de l'hyperviseur. De plus, Proxmox VE modifie Debian pour en faire un hyperviseur, ce qui pourrait donc créer des conflits avec Docker. Par exemple, Docker modifie la configuration réseau de la machine sur laquelle il est installé. Cela pourrait donc interférer avec la gestion du réseau opérée par Proxmox VE. Option n°1 : installer Docker dans une machine virtuelle Exécuter Docker au sein même d'une machine virtuelle Proxmox VE, c'est l'option la plus robuste et qui assure une compatibilité complète avec l'ensemble des fonctionnalités de Docker. L'idée est la suivante : vous installez une machine virtuelle, sous Debian ou Ubuntu, par exemple, et vous installez les paquets Docker (et Docker Compose). La machine virtuelle est isolée vis-à-vis de l'hôte Proxmox VE et chaque partie dispose de son propre noyau Linux. Sur cette machine virtuelle, vous pouvez installer tous les conteneurs dont vous avez besoin. L'inconvénient de cette méthode, c'est qu'elle implique une augmentation de la consommation des ressources : plus de RAM, plus de processeur, car au-delà des conteneurs, il faut des ressources pour exécuter l'OS invité. C'est une différence notable vis-à-vis des conteneurs LXC réputés pour leur légèreté. Vous devez aussi assurer la maintenance du système d'exploitation invité (celui de la VM), comme pour n'importe quelle machine virtuelle. Pour la production, c'est l'approche que je préfère, et elle ressemble aussi à ce que l'on peut faire avec toutes les plateformes de virtualisation. Cette machine virtuelle avec Docker peut être facilement sauvegardée, restaurée, voire même migrée vers un autre nœud Proxmox VE. Lors de la création de cette machine virtuelle, veillez à : Activer l'agent QEMU, tout en sachant qu'il sera installé par défaut si vous utilisez une image Debian 13 Choisissez un adaptateur réseau de type VirtIO Bien que ce soit facultatif, vous pouvez ajouter un second disque qui sera dédié au stockage des données des conteneurs Docker. Vous pouvez le monter dans /opt, ce qui permet ensuite de stocker vos données de projets sous /opt/docker-compose/. Une fois la machine créée et le système d'exploitation installé, effectuez l'installation de Docker. Vous pouvez utiliser la méthode "manuelle" via les dépôts officiels ou exécuter le script d'installation. Pour la première méthode, consultez mon tutoriel d'installation de Docker sur Debian. Pour la méthode basée sur le script, exécutez simplement ceci : apt update && install curl curl -fsSL https://get.docker.com -o get-docker.sh sh get-docker.sh Voilà, vous n'avez plus qu'à créer vos premiers conteneurs (mais lisez la suite de cet article avant cela). Option n°2 : exécuter Docker dans un conteneur LXC Déployer Docker à l'intérieur d'un conteneur LXC sur Proxmox VE (via le mécanisme d'imbrication ou nesting) est une seconde option. C'est une pratique courante associée à un avantage majeur : elle consomme beaucoup moins de ressources qu'une machine virtuelle (VM). Le problème, c'est que certaines applications conteneurisées exécutées via Docker ne fonctionneront pas si ce dernier est exécuté sur un conteneur LXC. L'explication est la suivante : contrairement à une VM, un conteneur LXC utilise le noyau Linux de l'hôte Proxmox. Les conteneurs Docker à l'intérieur du LXC partagent donc ce même noyau, et les restrictions sur les conteneurs LXC peuvent ne pas plaire à toutes les applications... Pour les applications légères et ce qui s'apparente à des applications Web, cela fonctionnera bien. Je vous donne quelques exemples : Dozzle, Vaultwarden, IT-Tools, Traefik, ou encore Homer. À l'inverse, il y a des chances d'avoir des problèmes et des limitations (ou besoin de tuning spécifique) avec les applications qui ont besoin de faire un lien avec le matériel, au niveau réseau via WireGuard, par exemple. On peut citer aussi Home Assistant. Pour contourner certaines limitations, vous pourriez être amené à configurer un conteneur LXC en mode privilégié. Néanmoins, il vaut mieux éviter, car cela signifie que l'utilisateur root dans le conteneur a des permissions qui s'étendent au niveau de l'hôte Proxmox VE. Pas top niveau sécurité. En cas de difficultés, privilégiez l'utilisation d'une machine virtuelle au sein de laquelle vous installez Docker. Si vous optez pour un conteneur LXC avec Docker, la méthode propre est de rester en Unprivileged et d'activer les fonctionnalités Nesting et Keyctl. Dans un précédent article, je vous ai expliqué comment créer un conteneur LXC en ligne de commande via la commande pct. Nous pouvons utiliser cette technique pour créer un conteneur LXC correctement configuré pour Docker. Il est important d'activer les options keyctl=1 et nesting=1 (comme précisé ci-dessus). CTID=306 CTTEMPLATE="local:vztmpl/debian-13-standard_13.1-2_amd64.tar.zst" CTHOSTNAME="lxc-docker" pct create $CTID $CTTEMPLATE \ --hostname $CTHOSTNAME \ --unprivileged 1 \ --cores 2 --memory 1024 --swap 512 \ --net0 name=eth0,bridge=vmbr0,firewall=1,ip=dhcp,tag=10,type=veth \ --rootfs local-lvm:8 \ --features keyctl=1,nesting=1 \ --password VotrePassword Cette commande crée un conteneur avec 2 cœurs de CPU, 1 Go de RAM et un disque de 8 Go. C'est largement suffisant pour faire tourner certaines applications conteneurisées. Vous pourrez alors créer d'autres conteneurs LXC sur le même principe, ou avec un peu plus de ressources, selon les besoins. Une fois le conteneur déployé, installez Docker à l'intérieur, sur le même principe que pour la machine virtuelle. La gestion au quotidien avec Dockhand (ou Portainer) Proxmox VE n'intègre pas d'outils natifs pour gérer les conteneurs Docker. C'est normal, ce n'est pas son rôle. De ce fait, vous pouvez déployer une solution comme Dockhand ou Portainer pour administrer vos conteneurs au quotidien. Ayant une préférence pour le premier cité, voyons comment l'installer rapidement. Ce qui suit doit être effectué sur la machine virtuelle Docker ou le conteneur LXC Docker. Commencez par créer un dossier nommé dockhand sous /opt/docker-compose, afin de stocker les données de ce projet. Au sein de ce répertoire dédié au projet Dockhand, il conviendra de créer également un sous-dossier nommé data. Il servira à stocker les données de l'application de façon persistante (dont la base de données SQLite). sudo mkdir -p /opt/docker-compose/dockhand/data Dans le dossier /opt/docker-compose/dockhand/, créez le fichier docker-compose.yml. Ci-dessous, le code à insérer dans votre fichier Docker Compose. Par défaut, Dockhand s'appuie sur une base SQLite. Si vous avez besoin de meilleures performances, vous pouvez configurer le conteneur pour utiliser une base PostgreSQL. services: dockhand: image: fnsys/dockhand:latest container_name: dockhand restart: unless-stopped ports: - "3000:3000" volumes: - /var/run/docker.sock:/var/run/docker.sock - ./data:/app/data Lancez la construction du projet : docker compose up -d Vous pourrez alors vous connecter à votre instance Dockhand via l'adresse IP de la VM/du conteneur où Docker est installé. Précisez le port 3000 puisque Dockhand est accessible sur ce port par défaut. L'interface de Dockhand se présente à vous, vous n'aurez qu'à ajouter l'environnement Docker local pour commencer à l'administrer. Pour apprendre à utiliser Dockhand, découvrez mon guide complet : Tutoriel - Prise en main de Dockhand pour l'administration de Docker Ainsi, vous disposez de l'interface de Proxmox VE pour administrer vos machines virtuelles, les conteneurs LXC et la plateforme virtualisée en elle-même, puis de Dockhand pour l'administration des environnements Docker. Une seule instance Dockhand peut se connecter à X moteurs Docker. Docker sur Proxmox VE : quelle méthode choisir ? Si vous avez les ressources (RAM/CPU), privilégiez la VM. C'est la méthode "zéro souci", mais elle ne permet pas d'optimiser l'utilisation des ressources. Sinon, vous pouvez mixer entre une machine virtuelle et des conteneurs LXC avec Docker pour vous adapter aux besoins des applications à déployer. Autrement dit, vous pouvez utiliser des conteneurs LXC (plus légers, plus rapides) autant que possible, tout en ayant une machine virtuelle pour certains projets plus exigeants et incompatibles avec cette approche. On peut aussi voir la situation de cette façon : Machine virtuelle à privilégier en entreprise pour la stabilité et la sécurité (isolation plus forte), Conteneur LXC à privilégier pour un Homelab ou s'il y a énormément de conteneurs, pour optimiser l'utilisation des ressources, en particulier sur du matériel modeste. Conclusion Vous pouvez utiliser l'une de ces deux méthodes ou mixer les deux pour exécuter des conteneurs Docker sur Proxmox VE. Vous pouvez aussi regarder du côté des images OCI (utilisées aussi par Docker), même si cette approche manque encore de maturité à l'heure actuelle (Proxmox VE 9.1) et n'a pas encore la même souplesse que de passer directement par Docker. Si vous avez l'habitude d'exécuter des applications conteneurisées via Docker sur Proxmox VE, n'hésitez pas à partager votre retour d'expérience en commentaire. Cela sera enrichissant pour les autres lecteurs de cet article. Documentation - Proxmox VE Ingénieur système et réseau, cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Je souhaite partager mon expérience et mes découvertes au travers de mes articles. Généraliste avec une attirance particulière pour les solutions Microsoft et le scripting. Bonne lecture. Afficher l’article complet

IT-Connect Publié le 11 mars 2026 Par Florian BURNEL it-connect.fr Environ 5 minutes de lecture La suppression d'une machine virtuelle ou d'un conteneur LXC est une opération basique qu'il convient de maîtriser lorsque l'on administre un hyperviseur Proxmox VE. Toutefois, quand on débute avec cette solution, on peut se demander où se cache l'option de suppression. Cela m'a donné l'idée de rédiger ce tutoriel pour vous éclairer à ce sujet, tout en évoquant aussi les méthodes en ligne de commande. Créer une machine virtuelle ou un conteneur sur Proxmox VE (alias PVE), c'est facile : il y a deux gros boutons en haut à droite de l'interface pour le faire. Mais, l'opération inverse, à savoir la suppression, est un peu plus planquée. Pourtant, vous serez forcément amené à l'utiliser, que ce soit dans le cadre de tests ou pour supprimer un serveur décommissionné. D'un côté, ce n'est pas plus mal, cela évite que ce soit trop évident, trop direct, de pouvoir supprimer un élément. Ce tutoriel va vous guider pas à pas pour accomplir cette tâche, via l'interface d'administration web et la méthode en ligne de commande (CLI). Vous pouvez aussi lire mes précédents tutoriels dédiés à Proxmox VE : Bien débuter avec Proxmox VE : le guide complet Proxmox VE : comment créer une machine virtuelle Windows 11 ? Proxmox VE : la gestion des snapshots La configuration du réseau avec Proxmox VE : le guide pour bien débuter Ce qu'il faut savoir avant de commencer Avant de procéder à la destruction de votre machine virtuelle ou de votre conteneur LXC, prenez connaissance des points suivants : Vérifier les sauvegardes : l'action de suppression est irréversible. Il peut s'avérer judicieux de faire une dernière sauvegarde de la ressource avant sa suppression. Sait-on jamais... Arrêter la ressource : Proxmox VE intègre une sécurité qui empêche la suppression d'une machine virtuelle ou d'un conteneur en cours d'exécution. Vous devez envoyer une commande d'arrêt avant de pouvoir agir de la sorte sur une ressource. Vérifier les droits : votre utilisateur doit posséder les permissions adéquates sur le nœud et sur la machine cible pour effectuer cette action. Si vous êtes administrateur, aucun problème. Sur les infrastructures étendues, votre champ d'action sera peut-être plus réduit. Supprimer une VM ou un conteneur via l'interface web Proxmox Que ce soit pour supprimer une machine virtuelle ou un conteneur LXC via l'interface web de Proxmox VE, la manipulation est identique. Voici les étapes à suivre. 1 - Connectez-vous à l'interface d'administration de Proxmox VE via votre navigateur web (https://<IP_PROXMOX>:8006). 2 - Dans le panneau de navigation à gauche, sélectionnez le nœud hébergeant la VM ou le conteneur à supprimer. 3 - Cliquez sur la machine virtuelle ou le conteneur que vous souhaitez supprimer. 4 - Assurez-vous que la ressource est arrêtée. Si ce n'est pas le cas, cliquez sur le bouton "Shutdown" en haut à droite (accessible aussi via un clic droit sur la ressource). 5 - Une fois la machine éteinte, cliquez sur le bouton "More" situé en haut à droite de l'interface, puis sélectionnez "Remove". Une boîte de dialogue de confirmation apparaît alors. Cette étape de validation permet d'éviter les suppressions accidentelles. Pour valider, le système vous demande de taper l'ID de la machine ou du conteneur. Par exemple : 304. Je vous rappelle que cet ID est visible dans l'inventaire à gauche, à côté du nom. On note aussi la présence de deux options : Purge from job configurations : cette case à cocher permet à Proxmox VE de faire le nettoyage, par exemple en supprimant aussi les tâches de réplication ou les tâches de sauvegarde planifiées associées à cette ressource. Destroy unreferenced disks owned by guest : cette case permet un nettoyage plus en "profondeur" des disques créés par cette ressource, mais qui ne lui sont plus associés actuellement. Une fois que c'est bon, cliquez sur le bouton "Remove". La ressource est immédiatement supprimée. D'ailleurs, dans la fenêtre des tâches en bas de l'écran, vous verrez une tâche "Destroy" apparaître. Supprimer une machine virtuelle avec la commande qm Pour la suite de cet article, nous allons basculer en ligne de commande. Commençons par apprendre à supprimer une machine virtuelle en ligne de commande. Sur Proxmox VE, les machines virtuelles basées sur KVM/QEMU sont gérées par la commande qm. Connectez-vous en SSH à votre serveur Proxmox VE ou directement via la console en mode Web. Afin d'identifier l'ID de la machine virtuelle à supprimer, vous pouvez lister toutes les VM présentes sur le nœud avec la commande suivante : qm list # Exemple de sortie VMID NAME STATUS MEM(MB) BOOTDISK(GB) PID 100 Debian-12 running 2048 32.00 1467 101 Ubuntu-2404 stopped 4096 32.00 0 102 PVE-DOCKER-DEMO running 4096 32.00 752323 Une fois l'ID repéré (par exemple l'ID 101), assurez-vous que la VM est éteinte. Si l'état affiché par qm list est running, arrêtez-la avec : qm stop <ID> qm stop 101 Enfin, procédez à la suppression de la machine virtuelle à l'aide de la commande destroy : qm destroy <ID> qm destroy 101 Vous pouvez ajouter le paramètre --purge 1 pour reproduire le comportement de la case à cocher de l'interface web, ce qui supprimera la VM de l'ensemble des jobs de sauvegarde ou de réplication : qm destroy 101 --purge 1 # Exemple de sortie Logical volume "vm-101-disk-0" successfully removed. purging VM 101 from related configurations.. Le fichier de configuration /etc/pve/qemu-server/101.conf associé à cette machine virtuelle sera effacé, ainsi que les volumes de stockage associés. Supprimer un conteneur LXC avec la commande pct Pour la gestion des conteneurs LXC en ligne de commande, Proxmox VE dispose d'un outil dédié nommé pct. Je l'ai présenté en détail dans mon article sur la prise en main des conteneurs LXC sur Proxmox VE. La logique reste identique à celle des machines virtuelles, sauf que le nom de la commande est différent. Listez vos conteneurs pour trouver l'ID du conteneur que vous souhaitez supprimer (il vaut mieux vérifier !). pct list # Exemple de sortie VMID Status Lock Name 301 stopped lxc-deb-01 302 stopped lxc-wordpress 303 stopped lxc-oci-uptime-kuma Stoppez le conteneur si nécessaire : pct stop 301 Lancez la commande de suppression : pct destroy 301 Pour associer la suppression de la configuration des travaux, comme pour la machine virtuelle : pct destroy 301 --purge Comme pour qm, l'outil pct supprimera le fichier de configuration situé dans /etc/pve/lxc/301.conf et demandera la suppression du volume du conteneur. Conclusion Nous avons abordé l'ensemble des étapes permettant de supprimer de manière définitive une machine virtuelle ou un conteneur sur une machine Proxmox VE. C'est simple à effectuer, mais il faut savoir comment s'y prendre. Les commandes qm destroy et pct destroy sont pratiques pour agir facilement sur un ensemble de ressources, à condition de savoir ce que l'on fait ! Ingénieur système et réseau, cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Je souhaite partager mon expérience et mes découvertes au travers de mes articles. Généraliste avec une attirance particulière pour les solutions Microsoft et le scripting. Bonne lecture. Afficher l’article complet

IT-Connect Publié le 9 mars 2026 Par Florian BURNEL it-connect.fr Environ 9 minutes de lecture Proxmox VE 9.1 a introduit une nouveauté attendue pour les conteneurs LXC : la possibilité de lancer des images de conteneurs applicatifs (provenant de Docker Hub ou GitHub), sans passer par une machine virtuelle intermédiaire ni installer Docker. La raison : la prise en charge des images OCI. Dans notre tutoriel sur la prise en main des conteneurs LXC, nous avons vu comment déployer des "conteneurs systèmes" (une Debian ou une Ubuntu complète). Aujourd'hui, nous allons apprendre à exploiter l'intégration native des images OCI (Open Container Initiative). Cette fonctionnalité permet, par exemple, de déployer une solution de monitoring comme Uptime Kuma ou un serveur web Nginx très rapidement, en piochant dans la bibliothèque d'images existantes, tout en bénéficiant de la légèreté de LXC. Vous pouvez aussi lire mes précédents tutoriels dédiés à Proxmox VE : Bien débuter avec Proxmox VE : le guide complet Proxmox VE : comment créer une machine virtuelle Windows 11 ? Proxmox VE : la gestion des snapshots La configuration du réseau avec Proxmox VE : le guide pour bien débuter OCI sur LXC : ce que ça change Pour bien saisir ce que change cette nouveauté (encore considérée comme étant en préversion), il faut s'intéresser à la différence entre un conteneur système et un conteneur applicatif. Jusqu'ici, pour faire tourner une application "dockerisée" sur Proxmox VE, l'administrateur devait effectuer les actions suivantes : Créer une machine virtuelle ou un conteneur LXC standard (Debian). Installer le moteur Docker au sein de la VM ou du conteneur. Lancer le conteneur via docker run ou Docker Compose. Avec la prise en charge native des images OCI, Proxmox supprime l'intermédiaire, c'est-à-dire ce besoin de créer un conteneur LXC ou une machine virtuelle. L'hyperviseur est capable de télécharger l'image et de l'exécuter directement avec le moteur LXC. Pour autant, il est important de comprendre que Proxmox VE n'a pas de moteur Docker ! Vous exécutez l'image nginx:alpine ou uptime-kuma directement sur le noyau de Proxmox via un conteneur LXC. Pas de Daemon Docker, pas de VM, juste les couches de l'image OCI. Zoom sur les images OCI : au-delà de Docker Avant de manipuler ces images en pratique sur Proxmox VE, il me semble important de démystifier le terme images OCI. Une image OCI n'est pas - obligatoirement - une image Docker. OCI signifie Open Container Initiative Il s'agit d'une norme commune adoptée par les géants de la tech (Docker, Google, Red Hat, IBM) pour les images de conteneurs. Ce standard est important pour éviter une guerre entre les standards des uns et des autres qui aurait fragmenté le marché. Pour faire une analogie simple : imaginez que l'image OCI soit au conteneur ce que le format MP3 est à la musique. Peu importe que vous utilisiez VLC, Windows Media Player ou iTunes (le Runtime) pour écouter la musique, tant que le fichier est au format MP3 (le Standard), il sera lu correctement. Docker sait lire des images OCI, tout comme Proxmox VE. Chacun à sa façon, mais le résultat est là. De quoi est composée une image OCI ? Concrètement, quand vous téléchargez une image Docker (qui est en fait une image OCI), vous récupérez une archive structurée contenant trois éléments clés : Le manifeste (Manifest) : il liste les fichiers à télécharger et l'architecture CPU cible (amd64, arm64). Les couches (Layers) : c'est le système de fichiers, sous la forme d'un millefeuille de couches empilées permettant de former, ensemble, l'image. Par exemple, une couche pour l'OS de base (Alpine), une couche pour les binaires Python, une couche pour votre application. La configuration : un fichier JSON qui dit "Au démarrage, lance la commande /app/start.sh" . C'est grâce à cette standardisation que Proxmox VE est capable de faire opérer la magie de "lire" les images OCI. On peut imaginer que Proxmox VE effectue les étapes suivantes : Télécharger les couches depuis le Docker Hub. Les décompresser et les assembler. Les "donner à manger" à son propre moteur LXC, sans avoir besoin d'installer le moteur Docker. LXC reste donc le composant clé et Docker inexistant dans ce processus. Création d'un conteneur LXC avec une image OCI Dans le cadre de cette démonstration, nous allons prendre pour exemple l'outil de surveillance Uptime Kuma. Il est léger, moderne et parfait pour ce contexte d'utilisation. Télécharger une image applicative La première étape consiste à télécharger l'image OCI. Il n'est pas nécessaire de déclarer le Docker Hub comme dépôt, car il est déjà déclaré dans Proxmox VE. Depuis l'interface Web de Proxmox VE, suivez ces étapes : Allez dans votre stockage (par exemple : local). Cliquez sur la section "CT Templates", comme pour les templates LXC classiques. Cliquez sur le bouton "Pull from OCI Registry" situé à côté des autres boutons (si vous ne le voyez pas, c'est que vous devez mettre à jour PVE). Vous devez ensuite compléter le formulaire pour spécifier l'image OCI à télécharger. Dans le champ "Reference", saisissez le nom de l'image de façon explicite. Utilisez la syntaxe proprietaire/image ou repository/proprietaire/image. Ici, cela donnerait louislam/uptime-kuma ou alors de façon plus précise : Pour Docker Hub : docker.io/louislam/uptime-kuma Pour GitHub (GHCR) : ghcr.io/louislam/uptime-kuma Vous devez ensuite cliquer sur "Query tags", et si l'image a été trouvée, la liste des tags (et versions) sera affichée. Ici, je sélectionne le tag 2 pour récupérer la dernière version de la V2 d'Uptime Kuma. Lancez le téléchargement et patientez un instant. L'image OCI apparaît dans la bibliothèque aux côtés des autres modèles déjà téléchargés. Création et configuration du conteneur La création du conteneur est très similaire à celle d'un LXC classique. Une fois l'image téléchargée, cliquez sur le bouton "Créer CT". Onglet Général Donnez un ID, par exemple 303, et un nom comme lxc-oci-uptime-kuma. Décochez "Unprivileged container" si vous rencontrez des soucis de droits, bien que dans notre cas, Uptime Kuma fonctionnera bien dans un conteneur non-privilégié. Onglet Template Sélectionnez l'image louislam/uptime-kuma que vous venez de télécharger, même si elle apparaît avec le nom de l'archive. Onglets Disques/CPU/Mémoire Allouez les ressources. Ici, il convient d'adapter en fonction des besoins de l'application. Uptime Kuma avec peu de sondes n'a pas besoin de beaucoup de ressources. Le fait d'associer un disque au conteneur implique que son stockage sera persistant. Onglet réseau La mise en réseau du conteneur est différente selon si l'image OCI est exécutée via LXC ou Docker. En effet, avec Docker, vous feriez un mappage de port (-p 3001:3001), tandis qu'avec LXC, le conteneur a sa propre adresse IP sur votre réseau (via le pont vmbr0 ou une autre interface sélectionnée). Vous avez le choix entre le DHCP ou la configuration d'une adresse IP statique. Configurez le DNS si nécessaire. Confirmez pour lancer la création du conteneur. Patientez le temps que la magie opère côté Proxmox. Personnaliser les variables d'environnement Avant d'exécuter un conteneur, vous pouvez personnaliser sa configuration en ajustant les variables d'environnement. En effet, dans le cas de l'utilisation d'une image OCI sur Proxmox VE en mode natif, il n'est pas possible de jouer sur les arguments de la commande docker run ou d'utiliser les directives d'un Docker Compose. De ce fait, c'est via cette méthode que l'on peut tenter de personnaliser la configuration d'une application. Dans la section "Options" du conteneur, double-cliquez sur "Environment". Une fenêtre avec les variables d'environnement définies dans l'image OCI va s'afficher. Vous pouvez en configurer d'autres, en fonction de ce qui est pris en charge par l'application déployée (consultez la documentation de la solution en question). Dans le cas d'Uptime Kuma, il existe de nombreuses variables d'environnement. Par exemple, la variable UPTIME_KUMA_PORT sert à personnaliser le port pour accéder à l'interface Web. Cela pourrait permettre de préciser 3002 à la place de 3001 (port par défaut). Une fois vos modifications effectuées, validez. C'est éditable à tout moment, mais la prise en charge des nouvelles valeurs implique un redémarrage du conteneur. Premier démarrage du conteneur Effectuez un clic droit sur le conteneur pour le démarrer via le bouton "Start". Cliquez sur l'onglet "Network" pour afficher l'adresse IP du conteneur. Ce sera utile pour récupérer l'adresse IP dans le cas où la carte réseau est configurée en DHCP. De plus, sur ce type de conteneurs applicatifs, vous n'avez pas toujours un shell interactif complet, donc l'onglet "Console" ne sera pas d'une grande utilité (cela varie d'une image à l'autre). Ouvrez un navigateur et spécifiez l'adresse IP du conteneur suivie du port 3001 (ou 3002 si la variable avec le port personnalisé a été appliquée). Voilà, l'interface de l'application apparaît à l'écran. Il ne reste plus qu'à faire la configuration initiale et profiter de cette application conteneurisée ! Pour le reste, c'est propre à l'application Uptime Kuma en elle-même, notamment pour la création de sondes. Conclusion L'intégration des images OCI dans Proxmox VE 9.1 marque une étape importante en matière de maturité pour les conteneurs LXC avec cet hyperviseur open source. Elle offre une méthode alternative, située à mi-chemin entre Docker et LXC, bien que ce dernier soit utilisé directement, pour exécuter des conteneurs applicatifs. Cette fonctionnalité est idéale pour des applications comme Uptime Kuma, Home Assistant, Pi-hole, etc.... puisque cela évite d'utiliser un conteneur avec un système complet ou même une machine virtuelle. Néanmoins, ce n'est pas encore adapté pour les projets avec plusieurs conteneurs (comme une stack Docker Compose basée sur un ensemble de microservices). La mise à jour des conteneurs LXC basés sur une image OCI semble être également une opération délicate, que j'aborderai dans un prochain article. Ai-je besoin d'installer Docker sur mon Proxmox pour utiliser les images OCI ? Non, absolument pas. C'est tout l'intérêt. Proxmox utilise LXC pour exécuter le contenu de l'image OCI. Le moteur Docker n'est pas présent. Puis-je utiliser des fichiers docker-compose.yml ? Non. Cette fonctionnalité ne gère que des conteneurs unitaires. Vous ne pouvez pas orchestrer plusieurs conteneurs avec un fichier YAML comme avec Docker Compose. À voir si une future version de Proxmox VE apporte des améliorations à ce sujet. Est-ce que Portainer peut gérer ces conteneurs LXC ? Non. Portainer parle à l'API Docker. Ici, il n'y a pas d'API Docker. Vous devez gérer ces conteneurs via l'interface web de Proxmox ou la commande pct. Les images "Alpine" fonctionnent-elles bien ? Oui, très bien. Elles sont extrêmement légères et démarrent quasi instantanément dans un conteneur LXC. Elles sont plus légères qu'une image Debian, Ubuntu ou autre. Quelle est la différence de consommation RAM par rapport à une VM Docker ? Elle est significative. Une VM Linux consomme minimum 512 Mo à 1 Go juste pour le système d'exploitation et le moteur Docker. Un conteneur OCI sur LXC ne consomme que la RAM du processus applicatif (parfois quelques méga-octets seulement). C'est un gain énorme. Le réseau fonctionne-t-il comme le "Bridge" de Docker ? Non. Par défaut, le conteneur est relié au pont de Proxmox (vmbr0, par exemple). Il se comporte comme une machine connectée sur votre réseau local (il demande une adresse IP à votre routeur/DHCP ou utilise une IP statique). Puisque docker logs n'existe pas, vous devez consulter la console du conteneur dans Proxmox, ou regarder directement les fichiers de logs dans /var/log (si l'application écrit dedans). Ingénieur système et réseau, cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Je souhaite partager mon expérience et mes découvertes au travers de mes articles. Généraliste avec une attirance particulière pour les solutions Microsoft et le scripting. Bonne lecture. Afficher l’article complet

IT-Connect Publié le 9 mars 2026 Par Florian BURNEL it-connect.fr Environ 16 minutes de lecture L’utilisation des conteneurs LXC sur Proxmox VE représente une méthode efficace pour exécuter plusieurs environnements Linux sur un même noyau, sans la lourdeur liée à l'utilisation de machines virtuelles complètes. Ce tutoriel vous explique pas à pas comment créer vos premiers conteneurs LXC sur Proxmox VE. Si vous avez régulièrement besoin d'exécuter des services légers qui ne nécessitent pas une machine virtuelle complète, alors le conteneur LXC (Linux Container) est la réponse adaptée. La raison : il offre des performances quasi natives. Il y a trois façons d'exécuter des conteneurs avec Proxmox VE : Exécuter un conteneur LXC à partir d'une image d'un système d'exploitation Linux de base Exécuter un conteneur LXC à partir d'une image OCI Exécuter un conteneur via Docker par l'intermédiaire d'une machine virtuelle ou d'un conteneur LXC dédié (ce qui est vrai aussi avec Podman) Les deux premières méthodes évoquées ci-dessus sont natives, tandis que la troisième méthode repose sur l'utilisation de Docker comme composant additionnel. Vous pouvez aussi lire mes précédents tutoriels dédiés à Proxmox VE : Bien débuter avec Proxmox VE : le guide complet Proxmox VE : comment créer une machine virtuelle Windows 11 ? Proxmox VE : la gestion des snapshots La configuration du réseau avec Proxmox VE : le guide pour bien débuter Comprendre l'architecture LXC vs KVM Avant de manipuler Proxmox VE pour créer votre premier conteneur, il est nécessaire de bien comprendre l'architecture de Proxmox VE. Celle-ci repose sur deux technologies : KVM et LXC. Contrairement à une VM KVM qui émule du matériel (carte mère, BIOS, disque) et charge son propre noyau (Kernel complet et indépendant), un conteneur LXC partage le noyau de l'hyperviseur (Proxmox VE). C'est une différence majeure entre une machine virtuelle et un conteneur. L'isolation, quant à elle, est assurée par deux mécanismes du noyau Linux : Les Namespaces : ils isolent les groupes de processus et de ressources les uns des autres. Le conteneur LXC "pense" être seul sur la machine. Les Cgroups (Control Groups) : ils limitent et mesurent l'utilisation des ressources (CPU, RAM, I/O) pour éviter qu'un conteneur ne sature l'hôte. En comparaison des machines virtuelles, les conteneurs ont deux avantages majeurs : ils démarrent très rapidement et l'empreinte mémoire est réduite (moins de RAM, moins d'espace disque). Néanmoins, il est à noter que les conteneurs LXC sont limités à l'exécution de distributions Linux (donc pas de Windows). La dépendance vis-à-vis du noyau du système d'exploitation hôte (Debian utilisé par Proxmox VE) s'avère être une contrainte dans certains cas. Autrement dit, certaines applications ne pourront pas s'exécuter dans un conteneur LXC (c'est d'autant plus vrai si vous utilisez un LXC pour exécuter des conteneurs Docker). Enfin, LXC n'est pas une technologie développée par Proxmox. Vous pouvez créer des conteneurs LXC sur Linux sans utiliser Proxmox VE. Quelques mots d'histoire : LXC est utilisé par Proxmox VE depuis la version 4.0, tandis qu'auparavant, il s'appuyait sur OpenVZ. Proxmox VE - Conteneur LXC vs Machine virtuelle Ci-dessous un comparatif permettant de bien comprendre les différences majeures entre un conteneur LXC et une machine virtuelle au niveau des fonctionnalités. Fonctionnalité Conteneur LXC Machine virtuelle Noyau Partagé (Hôte) Indépendant OS Supportés Linux uniquement Windows, Linux, BSD... Sauvegarde ✅ Oui ✅ Oui Instantané (Snapshot) ⚠️ Partiel (pas la RAM) ✅ Complet Migration à chaud ❌ Non (contrairement à LXD, qui ne doit pas être confondu avec LXC) ✅ Oui Pare-feu ✅ Oui ✅ Oui Modification de la RAM et du CPU à chaud ✅ Oui ✅ Hotplug (configuration de la VM et prise en charge par l'OS invité) Docker (Imbrication) ⚠️ Possible (option "Nesting") ✅ Natif Sécurité / Isolation Moyenne (namespace) Élevée (matériel virtuel) Créer son premier conteneur LXC sur Proxmox VE Gestion des modèles de conteneurs LXC Pour créer un conteneur, vous n'utilisez pas une image ISO d'installation classique, mais un Template (modèle). C'est une archive pré-installée et prête à l'emploi d'une distribution. Voyons comment importer un premier modèle. Connectez-vous à l'interface web de Proxmox. Dans l'arborescence à gauche, sélectionnez votre stockage (par défaut nommé local). Cliquez sur la section "CT Templates". Cliquez sur le bouton "Templates" dans la barre d'outils. Une liste de modèles officiels apparaît (Debian, Ubuntu, Alpine, CentOS, AlmaLinux, etc.). Recherchez le mot clé debian afin d'installer le modèle Debian 13 intitulé debian-13-standard. Sélectionnez-le et cliquez sur le bouton "Download". Je vous recommande Debian pour une raison simple : le conteneur LXC aura la même base que l'hôte Proxmox VE, ce dernier étant basé sur Debian. Et aussi, je dois l'avouer, j'apprécie beaucoup cette distribution. L'opération est relativement rapide car les fichiers sont légers (une centaine de mégaoctets pour une Debian sans interface graphique). Le modèle de conteneur est téléchargé. Il est prêt à l'emploi. La liste des modèles disponibles sur Proxmox VE contient un ensemble de modèles Turnkey Linux. Il s'agit d'images pré-configurées avec des applications prêtes à l'emploi, comme WordPress, Apache Tomcat, etc... Il y a des dizaines de modèles applicatifs prêts à l'emploi. Cela peut s'avérer pratique pour déployer rapidement une application à des fins de tests. Création d'un conteneur LXC Une fois le modèle récupéré, nous pouvons passer à la création d'un premier conteneur LXC basé sur celui-ci. Au sein de l'interface de Proxmox VE, cliquez sur le bouton bleu "Create CT" situé en haut à droite. Un assistant étape par étape similaire à celui disponible pour créer une machine virtuelle s'affiche à l'écran. Onglet Général Node : sélectionnez votre serveur Proxmox. CT ID : l'identifiant unique de ce conteneur, vous pouvez laisser Proxmox VE gérer. Hostname : le nom du conteneur, mais aussi du système dans le conteneur (par exemple : lxc-deb-01). Privileged vs Unprivileged : par défaut, la case "Unprivileged container" est cochée. Pour des raisons de sécurité, il est recommandé de conserver cette option cochée. Dans un conteneur non privilégié, l'utilisateur root à l'intérieur du conteneur est mappé vers un utilisateur sans privilèges sur l'hôte. Cela empêche le conteneur LXC de pouvoir impacter le système hôte (évasion du conteneur). Nesting : décochez cette option, sauf si vous souhaitez exécuter un conteneur dans ce conteneur (via Docker, par exemple). Néanmoins, elle est aussi nécessaire pour certains systèmes, comme Debian 13 (à cause de Systemd), donc ici nous devons cocher l'option, sinon le conteneur sera inutilisable. Password : définissez le mot de passe root du futur conteneur LXC. Vous pouvez aussi charger une clé SSH publique pour l'authentification par clé (recommandé) Onglet Template Sélectionnez ici le stockage où vous avez téléchargé votre template, puis choisissez l'image Debian 13 téléchargée précédemment. Onglet Disks Définissez la taille du disque virtuel. Pour un service web simple, 8 Go peuvent suffire. Ici, tout dépend de vos besoins en fonction de la finalité du conteneur LXC. Onglet CPU Spécifiez le nom de cœur de CPU alloué à ce conteneur. Adaptez éventuellement par la suite en fonction de la charge de ce conteneur. Onglet Memory Définissez la RAM, par exemple 512 Mo et le Swap. Contrairement aux VMs, la mémoire non utilisée par le conteneur reste disponible pour l'hôte. C'est aussi l'un des avantages de LXC. Onglet Network C'est ici que vous définissez la configuration réseau de votre conteneur. Bien souvent, une adresse IP sera allouée s'il s'agit d'un conteneur destiné à la production. Sinon, vous pouvez conserver le mode DHCP. Veillez également à sélectionner la bonne interface réseau (Bridge) et, si besoin ajoutez un numéro de VLAN. Onglet DNS Par défaut, le nom de domaine du serveur Proxmox et le même serveur DNS seront utilisés. Si besoin, adaptez ces valeurs ici. Lancez la création du conteneur, puis patientez un instant. Une fois le conteneur LXC créé, il apparaît dans l'inventaire de votre hôte. Vous remarquerez que les conteneurs ont un icône différent de celui des machines virtuelles. Pour démarrer le conteneur, effectuez un clic droit sur son nom, puis cliquez sur "Start". Utilisation du conteneur LXC Pour commencer à configurer ce conteneur LXC, utilisez la même méthode que pour l'administration d'une machine virtuelle : la console. L'accès SSH est aussi une option, même s'il faudra commencer par récupérer l'adresse IP du conteneur s'il est en DHCP (via l'onglet "Network" ou la ligne de commande). Via la console, connectez-vous à partir du mot de passe précisé lors de la configuration du conteneur. Le service SSH est déjà installé et configuré par défaut. La suite des opérations vous appartient ! Administration des conteneurs LXC avec pct Pour l'administration des conteneurs Proxmox VE, vous pouvez utiliser un outil en ligne de commande : Proxmox Container Toolkit. Il est accessible via la commande pct, et celle-ci s'exécute directement sur l'hôte Proxmox VE (et non dans le conteneur). Découvrons ensemble quelques commandes. Gestion des modèles LXC La commande pct contient les options nécessaires pour parcourir les modèles et effectuer le téléchargement d'un modèle. Nous aurions pu télécharger le modèle précédent à l'aide de cette commande. # Mettre à jour la liste des modèles pveam update # Lister les modèles Debian pveam available --section system | grep debian # Télécharger le modèle (aidez-vous de l'autocomplétion pour le nom) pveam download local debian-13-standard_13.1-2_amd64.tar.zst Vous pouvez ensuite lister les modèles de conteneurs disponibles sur l'espace de stockage, c'est-à-dire ceux déjà téléchargés. pveam list local NAME SIZE local:vztmpl/debian-13-standard_13.1-2_amd64.tar.zst 123.70MB Lister les conteneurs pct list # Exemple de sortie VMID Status Lock Name 301 running lxc-deb-01 302 running lxc-wordpress 303 running lxc-oci-uptime-kuma Afficher la configuration d'un conteneur LXC pct config <ID> # Exemple pct config 301 arch: amd64 cores: 1 features: nesting=0 hostname: lxc-deb-01 memory: 1024 net0: name=eth0,bridge=vmbr0,firewall=1,hwaddr=BC:24:11:CF:75:CF,ip=dhcp,tag=10,type=veth ostype: debian rootfs: local-lvm:vm-301-disk-0,size=8G swap: 512 tags: lxc unprivileged: 1 Sachez que vous pouvez également consulter la configuration en allant lire directement le fichier brut (le nom du fichier correspond à l'ID du conteneur) : cat /etc/pve/lxc/301.conf Entrer dans un conteneur depuis l'hôte (sans SSH) C'est une fonction très pratique si vous avez perdu le mot de passe root, coupé l'accès réseau du conteneur ou simplement pour éviter d'exposer un accès distant. pct enter 301 # Exemple root@pve-01:~# pct enter 301 root@lxc-deb-01:~# root@lxc-deb-01:~# hostname lxc-deb-01 Dans la commande ci-dessus, remplacez 301 par l'ID de votre conteneur. Arrêter un conteneur proprement pct shutdown <ID> pct shutdown 301 Démarrer un conteneur LXC pct start <ID> pct start 301 Modifier la configuration du conteneur Vous pouvez modifier la configuration d'un conteneur à chaud, c'est-à-dire avec le conteneur en cours d'exécution. Si vous procédez via la commande pct, voici la syntaxe à respecter : p ct set <id> [OPTIONS] Si vous souhaitez ajouter de la RAM sans passer par l'interface graphique, vous pouvez utiliser cette technique. Voici comment passer à 1 024 Mo de RAM sur le conteneur avec l'ID 301. pct set 301 -memory 1024 Vous pourriez aussi décider de configurer, comme par exemple l'option "Nesting" directement via la ligne de commande. pct set 301 --features nesting=1 Créer un conteneur LXC en ligne de commande La commande pct est également capable de créer un conteneur LXC sur votre hôte Proxmox. Cela permet d'automatiser la création de conteneurs ! De ce fait, cette commande tout-en-un accepte énormément d'arguments lorsqu'il est question de créer et configurer un conteneur en une seule fois. La commande ci-dessous permet de créer et de configurer un conteneur sur le même principe que ce qui a été fait via l'interface graphique. À savoir, un conteneur avec l'image Debian 13, 512 Mo de RAM, 1 cœur de CPU, 8 Go de disque et une interface réseau en DHCP avec un tag sur le VLAN 10. En complément, l'option --start 1 permet de démarrer automatiquement le conteneur dès qu'il est prêt. pct create 304 local:vztmpl/debian-13-standard_13.1-2_amd64.tar.zst \ --hostname lxc-deb-04 \ --cores 1 \ --memory 512 \ --swap 512 \ --rootfs local-lvm:8 \ --net0 name=eth0,bridge=vmbr0,firewall=1,ip=dhcp,tag=10,type=veth \ --unprivileged 1 \ --features nesting=0 \ --tags lxc \ --password <MOT_DE_PASSE> \ --start 1 Suite à l'exécution de cette commande, un conteneur nommé lxc-deb-04 avec l'ID 304 a été créé. Exemple de sortie : Creating filesystem with 2097152 4k blocks and 524288 inodes Filesystem UUID: 17312070-d712-442d-9317-d0d98d72f201 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632 extracting archive '/var/lib/vz/template/cache/debian-13-standard_13.1-2_amd64.tar.zst' Total bytes read: 551505920 (526MiB, 430MiB/s) Detected container architecture: amd64 Creating SSH host key 'ssh_host_rsa_key' - this may take some time ... done: SHA256:BLCIFdoaZ9M2aD8ammlmpvK8vI9c1GsvB5mPUPMUyD4 root@lxc-deb-04 Creating SSH host key 'ssh_host_ed25519_key' - this may take some time ... done: SHA256:Ivil+To1toVQMFRBFywn+mmdsM1A/6Sg7q2CDD6u2M8 root@lxc-deb-04 Creating SSH host key 'ssh_host_ecdsa_key' - this may take some time ... done: SHA256:MF9qEM33I+yRINHylGAumllD2i2Jdui+LHYPwgygyLU root@lxc-deb-04 WARN: Systemd 257 detected. You may need to enable nesting. WARN: Systemd 257 detected. You may need to enable nesting. Task finished with 2 warning(s)! Task finished with 1 warning(s)! Dans la sortie de cette commande, cette ligne est intéressante : WARN: Systemd 257 detected. You may need to enable nesting.. Elle laisse sous-entendre que ce conteneur a besoin du mode Nesting pour fonctionner, notamment à cause de Systemd qui a besoin de pouvoir utiliser la fonction de namespaces. C'est un avertissement qui est lié à Debian 13 (et à sa version de Systemd), comme je l'évoquais précédemment. Le mode Nesting doit être activé dans le conteneur. Je vous rappelle que c'est possible d'éditer la configuration du conteneur en ligne de commande : pct set 304 --features nesting=1 Grâce à un script Bash, notamment avec une boucle for et quelques variables, vous pourriez créer un script pour automatiser la création d'un ensemble de conteneurs. Supprimer un conteneur LXC Pour supprimer un conteneur LXC directement depuis le Terminal, vous devez l'arrêter puis le supprimer. Mais, attention, cette action est irréversible. Cette commande supprime le conteneur, sa configuration et son disque. pct stop <ID> && pct destroy <ID> --purge # Exemple : pct stop 304 && pct destroy 304 --purge Logical volume "vm-304-disk-0" successfully removed. purging CT 304 from related configurations.. Gestion avancée du stockage : bind mounts Si vous souhaitez partager un dossier de l'hôte Proxmox directement dans le conteneur LXC, c'est envisageable. C'est ce qu'on appelle un Bind Mount. On peut citer les cas d'usage suivants : Accéder à votre répertoire personnel (home) dans le système invité du conteneur, Accéder au contenu d'un périphérique USB dans le système invité du conteneur, Accéder aux données d'un partage NFS monté sur l'hôte dans le système invité du conteneur. Pour effectuer la configuration, vous avez deux options : éditer le fichier de configuration du conteneur (par exemple : /etc/pve/lxc/301.conf) ou utiliser la commande pct. Bien que cette pratique soit possible techniquement, elle a un impact au niveau de la sécurité. Avec un conteneur Unprivileged, vous rencontrerez des problèmes de permission. Pour corriger cela, il est nécessaire de basculer le conteneur en Privileged ou d'ajuster les permissions avec un mapping au niveau des ID... Une méthode est détaillée sur ce GitHub et, comme vous le verrez, cela implique de créer des groupes sur l'hôte Docker, puis d'ajuster la configuration dans le conteneur LXC, le tout sans passer le conteneur en Privileged. Dans le cas où le dossier doit être accessible uniquement en lecture seule dans le conteneur, cette contrainte n'existe pas. Imaginez que vous disposiez d'une banque de données sur l'hôte Proxmox dans /var/lib/vz/partage et que vous souhaitiez que votre conteneur puisse lire ces fichiers. Connectez-vous en SSH sur votre serveur Proxmox (l'hôte) et créez un dossier avec un fichier de test : mkdir -p /var/lib/vz/partage echo "Ceci est un fichier de démo pour IT-Connect" > /var/lib/vz/partage/demo.txt Vous devez ensuite configurer le point de montage. Nous allons utiliser la commande pct set pour ajouter ce point de montage à la configuration du conteneur. Nous utilisons l'option -ro 1 (Read-Only) pour garantir que le conteneur ne pourra pas supprimer ou modifier les données de l'hôte (lecture seule). Exécutez cette commande sur l'hôte (remplacez 301 par l'ID de votre conteneur) : pct set 301 -mp0 /var/lib/vz/partage,mp=/mnt/partage_pve,ro=1 Pour vous expliquer cette commande : mp0 : définit le premier point de montage (Mount Point 0). /var/lib/vz/partage : le chemin source sur l'hôte Proxmox. mp=/mnt/partage_pve : le chemin de destination à l'intérieur du conteneur. ro=1 : active le mode lecture seule. Redémarrez le conteneur pour appliquer les changements, puis connectez-vous à l'intérieur : pct reboot 301 pct enter 301 cat /mnt/partage_pve/demo.txt # Résultat : root@pve-01:~# pct enter 301 root@lxc-deb-01:~# cat /mnt/partage_pve/demo.txt Ceci est un fichier de démo pour IT-Connect Vous devriez voir le contenu du fichier créé sur l'hôte Proxmox ! Note : si vous avez besoin que votre conteneur puisse écrire dans ce dossier, la configuration se complexifiera ! Comme je l'expliquais précédemment, vous devrez soit basculer votre conteneur en mode "Privileged" (moins sécurisé), soit configurer un "ID Mapping" (mappage des utilisateurs) pour faire correspondre les droits de l'utilisateur du conteneur avec ceux du dossier de l'hôte. Privilégiez les montages en lecture seule ou l'utilisation de volumes de stockage dédiés directement sur les conteneurs. Sauvegarder et restaurer des conteneurs LXC La protection des données ne doit jamais être négligée, et cela est également vrai pour les conteneurs. La bonne nouvelle : Proxmox VE intègre un outil de sauvegarde pour les LXC. Le moteur de sauvegarde utilisé est vzdump. Il existe trois modes principaux pour les conteneurs : Mode Workflow Interruption de service Stop Arrêt complet du conteneur ➔ Sauvegarde ➔ Redémarrage. Longue (le temps de la copie !) Suspend 1er rsync (à chaud) ➔ Suspension ➔ 2ème rsync (différentiel) ➔ Reprise. Minimale (le temps de copier les différences) Snapshot Suspension ➔ Snapshot stockage ➔ Reprise immédiate ➔ Archivage en arrière-plan. Très faible (quasi imperceptible) Le mode "Stop" est très utile pour les services critiques où la cohérence des données doit être parfaite (une application qui pourrait y être sensible). Pour compléter ce tableau, voici deux informations à prendre en considération (ce qui fait notamment écho à la notion évoquée précédemment) : Les "Bind Mounts" sont exclus : Proxmox ne sauvegarde jamais le contenu des dossiers montés depuis l'hôte (les fameux Bind Mounts). C'est à vous de gérer leur sauvegarde séparément, côté hôte. Exclusion de volumes : si vous utilisez le mode Snapshot, tous les volumes du conteneur doivent supporter les snapshots. Si vous avez un disque spécifique qui ne le supporte pas, vous devez l'exclure de la sauvegarde en définissant une option sur le point de montage : backup=no. Pour réaliser une sauvegarde, vous avez deux options : une sauvegarde manuelle et immédiate directement depuis la section "Backup" du conteneur à sauvegarder, une sauvegarde planifiée via une tâche créée dans la section "Backup" du Datacenter. Pour programmer une sauvegarde automatique : Allez dans Datacenter > Backup. Créez un nouveau job. Sélectionnez l'heure, le stockage de destination et les conteneurs concernés. Sélectionnez le mode de sauvegarde (référez-vous au tableau ci-dessus). Validez la création du job. Un article complet sur la fonction de sauvegarde native de Proxmox VE sera publié prochainement. Conclusion En suivant ce guide, vous devriez être en mesure de créer vos premiers conteneurs LXC sur un hyperviseur Proxmox VE ! Pour aller plus loin, consultez l'article dédié à l'utilisation des images OCI avec les conteneurs LXC : Proxmox VE : exécuter des images OCI (Docker) nativement dans LXC Pour rappel, bien que les conteneurs soient isolés, ils partagent le même noyau que l'hôte physique. Voici quelques règles à respecter pour limiter l'impact au niveau sécurité : Privilèges : utilisez des conteneurs "Unprivileged" autant que possible. Nesting : activez l'option "Nesting" uniquement si nécessaire, SSH : si vous autorisez SSH dans le conteneur, interdisez le login root par mot de passe et préférez les clés SSH, exactement comme sur une VM ou un serveur physique. Ingénieur système et réseau, cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Je souhaite partager mon expérience et mes découvertes au travers de mes articles. Généraliste avec une attirance particulière pour les solutions Microsoft et le scripting. Bonne lecture. Afficher l’article complet

Korben.info Publié le 11 février 2026 Par Korben, Manuel Dorne korben.info Environ 2 minutes de lecture Proxmox, c'est génial pour la virtualisation... sauf que configurer des VMs, des conteneurs LXC, le GPU passthrough et les sauvegardes à la main, ça finit par nous coller de grosses cernes sous les neuneuils ! Trop de commandes les amis !! Heureusement, un dev a eu la bonne idée de tout coller dans un menu interactif bash ! ProxMenux , c'est donc un outil open source qui vous ajoute une commande menu dans le terminal de votre serveur Proxmox. Vous tapez ça et vous avez alors un joli menu en mode texte qui vous propose toutes les opérations courantes sans avoir à retenir 45 commandes différentes. Et c'est compatible Proxmox VE 8.x et 9.x. L'installation tient en une seule ligne bash. bash -c "$(wget -qLO - https://raw.githubusercontent.com/MacRimi/ProxMenux/main/install_proxmenux.sh)" Et c'est plié en 30 secondes. Alors c'est pas le premier ni le dernier de sa catégorie, mais là où d'autres se contentent de 3-4 raccourcis, ProxMenux embarque des menus pour à peu près tout. Création de VMs, gestion des conteneurs LXC, configuration réseau, stockage, GPU passthrough (le truc qui rend dingue tout le monde), et même un mode réparation d'urgence. D'ailleurs, y'a aussi un système de sauvegarde/restauration intégré et des scripts de post-installation pour configurer votre Proxmox aux petits oignons. En gros, c'est le couteau suisse que tous les admins Proxmox rêvent d'avoir. Même si c'est quand même du script bash exécuté en root sur votre hyperviseur. Je sais, ça pique un peu quand on y pense mais c'est tellement utile ! Et comme le code est sur GitHub, c'est auditable donc jetez-y un œil avant de foncer tête baissée. Voilà, si vous avez déjà les Proxmox Helper Scripts pour installer vos services, ProxMenux c'est un super complément. Les Helper Scripts gèrent l'installation de conteneurs préconfigurés (Home Assistant, Plex, Jellyfin...) alors que ce menu interactif couvre l'administration système de votre hyperviseur. Du coup, les deux ensemble, c'est pas mal du tout pour votre homelab . Y'a aussi des fonctionnalités qu'on voit rarement dans ce genre d'outils, comme la configuration du Coral TPU pour ceux qui font tourner Frigate sur leur serveur. Détection IA, NVR, le tout depuis un menu. Ou encore un dashboard web pour surveiller votre infra en temps réel. Attention quand même, ça ne remplace pas l'interface web native de Proxmox mais c'est un bon complément pour le terminal. Bref, si vous avez un Proxmox à la maison et que vous en avez marre de chercher des commandes sur Google ou ChatGPT, allez jeter un œil ! Un grand merci à Maxime pour le partage ! Afficher l’article complet

IT-Connect Publié le 2 juin 2025 Par Mickael Dorigny it-connect.fr Environ 7 minutes de lecture I. Présentation Dans cet article, je vous présente LanguageTool, un correcteur d’orthographe et de syntaxe intelligent, basé sur l’IA et intégré directement à votre navigateur. Ce n'est pas tout : en plus d'être open source, il s'intègre à d'autres applications ! Quelle que soit l’époque où les technologies utilisées, les fautes d’orthographe ont la vie dure. Les technologies actuelles nous permettent cependant d’avoir une aide supplémentaire pour identifier et corriger nos fautes d’orthographe, de frappes et de syntaxe. LanguageTool fait partie de ces technologies. Nous allons voir comment l’installer rapidement sur les principaux navigateurs, mais aussi améliorer la confidentialité via une installation locale basée sur Docker. En effet, LanguageTool est un correcteur d'orthographe que vous pouvez auto-héberger (en local sur votre machine ou sur un serveur). Note : LanguageTool se présente comme une alternative à d'autres solutions comme Antidote et Grammarly. Cliquez ici pour regarder la vidéo sur YouTube II. Présentation du correcteur orthographique LanguageTool LanguageTool est un outil gratuit et open source qui permet de vérifier en temps réel la grammaire, l'orthographe et le style de vos textes. Il est disponible sous forme d'extension pour les navigateurs, mais aussi en tant qu'application locale (utile pour l'utiliser dans Word ou d'autres applications) ou service en ligne. Il prend en charge plus de 30 langues, même s’il est probable que vous n’en utilisiez qu’une ou deux. Remarque : il existe également une version Premium de LanguageTool, avec des fonctionnalités supplémentaires. Les tarifs sont raisonnables, notamment pour un usage personnel. Ce qui est particulièrement intéressant avec cet outil de relecture est qu’il s’intègre parfaitement à tout champ d’édition de n’importe quelle application web (y compris l’interface WordPress dans laquelle je saisis ce texte). Que ce soit l’interface web d’un webmail, un tchat en ligne ou un blog, LanguageTool est en capacité d’analyser le texte saisi par l'utilisateur. Une fois installé, la relecture de LanguageTool se matérialise par la présence de l’icône suivant proche du champ de saisie : Présence de la fenêtre LanguageTool dans un formulaire web. Cliquer dessus permet d’avoir un pop-up qui détaille les fautes découvertes et les corrections proposées. Dans un texte relu, toutes les erreurs sont signalées par un soulignage en rouge (mot inconnu, faute ou typo) ou jaune (syntaxe, formulation, etc.) : Corrections proposées par LanguageTool. Également, lorsque l’on écrit une phrase beaucoup trop longue, il est possible que l’outil la souligne en violet. Cela permet de montrer qu’il y a une phrase qui pourrait être réécrite de façon plus lisible : Signalement d'une phrase trop longue dans un mail par LanguageTool. En complément, il est aussi possible d’accéder à une interface dédiée dans laquelle saisir un texte, dont on pourra ensuite copier la version relue et corrigée ailleurs : Interface web dédiée de LanguageTool. LanguageTool dispose de nombreuses options comme l’activation du mode méticuleux, qui permet de passer en revue le registre des mots utilisés, l’ouverture du pop-up sur un double clic, la désactivation rapide via un raccourci, etc. Dans ces options, il est aussi possible d’ajouter des mots à notre dictionnaire personnel (qui seront ignorés par la suite), de choisir les langues qui nous intéressent ou activer/désactiver l’analyse de LanguageTool pour certains sites, etc : Extrait de quelques-unes des options du plugin LanguageTool. Pour finir sur cette brève présentation, il s’agit d’un outil qui m’est devenu indispensable. Il n’est certes pas parfait, mais pour une version gratuite qui n’expose quasiment pas de limite pour une taille raisonnable de texte et une intégration dans les navigateurs, difficile d’avoir mieux ! III. Installation de LanguageTool sur un navigateur L'installation de LanguageTool sur un navigateur est simple et rapide, elle se fait de façon classique. Voici les étapes à suivre pour les principaux navigateurs : A. Google Chrome Ouvrez Google Chrome et rendez-vous sur le Chrome Web Store. Recherchez "LanguageTool" dans la barre de recherche. Cliquez sur "Ajouter à Google Chrome" puis sur "Ajouter l'extension". Une fois installé, l'icône de LanguageTool apparaîtra dans la barre d'outils de votre navigateur. B. Mozilla Firefox Ouvrez Firefox et allez sur le site Firefox Add-ons. Recherchez "LanguageTool" dans la barre de recherche. Cliquez sur "Ajouter à Firefox" puis sur "Ajouter". L'extension sera ajoutée à votre navigateur et vous pourrez commencer à l'utiliser. C. Microsoft Edge Ouvrez Microsoft Edge et accédez aux Microsoft Edge Add-ons. Recherchez "LanguageTool" dans la barre de recherche. Cliquez sur "Obtenir" puis sur "Ajouter l'extension". L'extension sera installée et prête à l'emploi. Quel que soit le navigateur, la présence de l’extension se manifeste par cet icône dans la barre supérieure : Icône LanguageTool dans la barre du navigateur. Mais également par une petite fenêtre cliquable dès que l’on commence à saisir du texte, comme vu plus haut. Au-delà de l'extension pour navigateur Web, il existe aussi des applications LanguageTool, notamment pour Windows, macOS, iOS et des modules Thunderbird et Outlook. L'installation sur le système d'exploitation permet d'en profiter dans d'autres applications (Word, par exemple). Attention à la confidentialité ! Il va de soi que le petit code d’un plugin ne permet pas d’effectuer des analyses syntaxiques et orthographiques avancées comme le fait LanguageTool. Cela signifie que le texte saisi est analysé sur des serveurs hors de votre ordinateur. Si la confidentialité est de mise (notamment dans le contexte professionnel), sachez qu’il existe des solutions. Le serveur LanguageTool peut être déployé en local, sur un serveur d’entreprise et notamment via Docker. Ainsi, tout le texte saisi est analysé par des systèmes que vous maitrisez. C’est ce que nous allons voir par la suite. Pour faire simple, nous allons déployer le serveur LanguageTool sur un Docker local à notre système. Cela permet de démontrer rapidement qu’une utilisation de LanguageTool respectueuse de la confidentialité est possible. IV. Installation en local de LanguageTool via Docker Pour ceux qui souhaitent une solution plus privée et sécurisée, il est possible d'installer LanguageTool en local via Docker. Une fois que Docker est en place et fonctionnel sur notre système, on commence par télécharger l’image Docker de LanguageTool. Il n’existe pas d’image Docker officielle de LanguageTool. Mais, certains dépôts Github proposent des DockerFile et sont référencés dans le dépôt GitHub officiel de la solution. Nous utiliserons ceux-ci en priorité. Source Docker Hub utilisée : github.com/Erikvl87/docker-languagetool Pour ma part, je vais créer un répertoire dans ~/Documents/ pour le déploiement : mkdir -p ~/Documents/LanguageTool/ngrams Comme vous pouvez les voir, j’ai créé un répertoire /ngrams/ dans lequel nous allons stocker des fichiers à télécharger depuis le site officiel. Nous pouvons voir les "ngrams" comme des dictionnaires ou bases de données de mots sur lequel LanguageTool se base pour trouver des erreurs. Ils sont regroupés par langue, nous devons donc récupérer le "ngram" français (ngrams-fr-<data>.zip, 1,8 Go) sur l’URL suivante : languagetool.org/download/ngram-data/ Je décompresse ensuite son contenu dans le répertoire ~/Documents/LanguageTool/ngrams/. Dans un second temps, nous pouvons télécharger et déployer l’image Docker erikvl87/languagetool en spécifiant un volume partagé avec l’hôte afin qu’il puisse trouver nos ngrams : docker run --name langtool -p 8010:8010 -d -e langtool_abTest=null -e langtool_abTestClients=null -e langtool_languageModel=/ngrams -v ~/Documents/LanguageTools/ngrams/:/ngrams:ro erikvl87/languagetool L’option -p permet d’exposer le port TPC/8010 du Docker sur le réseau, pour que le service soit accessible à d’autres systèmes. Une fois ce déploiement réalisé, nous pouvons aller dans la configuration du plugin LanguageTool de nos clients et nous rendre dans la partie Paramètres avancés, sélectionner Autre serveur, et saisir l’URL suivante : http://192.168.56.122:8010/v2 (pensez à adapter l’IP/DNS de la cible à votre contexte) : Dans mon contexte, le conteneur Docker LanguageTool est sur un autre système qui expose le port TCP/8010 sur le réseau et qui possède l’IP 192.168.56.122. Dans le cas d’une utilisation à partir d’un conteneur déployé sur le même système que votre plugin, vous pourrez tout à fait saisir http://127.0.0.1:8010/v2. À l’inverse, dans un environnement d’entreprise, il s’agira plutôt d’un nom DNS. Paramétrage du serveur LanguageTool dans la configuration du plugin. Bref, une fois cette configuration en place, pensez bien à paramétrer explicitement les langages à relire, au risque d’avoir de mauvaises surprises. Il faut pour cela vérifier la configuration des langues prises en compte (Options de langue). Pour ma part, j’utiliserai uniquement le français : Paramétrage des langues prisses en charge par LanguageTool. Une fois cette configuration sauvegardée, vous pourrez retourner dans n’importe quel champ de saisi de n’importe quel site et constater que LanguageTool relit bien votre texte : Fonctionnement du plugin LanguageTool avec un serveur local. Au passage, vous pourrez rapidement constater que la relecture par LanguageTool consomme beaucoup de ressources serveur. C’est une chose à considérer si vous le mettez en place au sein d’une entreprise avec plusieurs centaines d’utilisateurs : Consommation CPU lors de la relecture LanguageTool (côté serveur). L’installation du serveur LanguageTool sur un serveur dédié (sans Docker) est décrite dans la documentation GitHub (github.com/languagetool-org/languagetool). V. Conclusion J’utilise LanguageTool quotidiennement et le déploiement du serveur via Docker est largement suffisant pour mes besoins. Les fonctionnalités et l’intégration de LanguageTool dans tous les champs des applications web est vraiment un gros plus. N’hésitez pas à tester le plugin sur votre navigateur, mais n’oubliez pas l’aspect confidentialité si vous êtes sur un poste d’entreprise ! Si vous avez un NAS Synology, vous pouvez le déployer en local à l'aide de Docker en suivant ce tutoriel : Comment installer LanguageTool sur un NAS Synology ? Co-fondateur d'IT-Connect.fr. Auditeur/Pentester chez Orange Cyberdéfense. Afficher l’article complet

Cachem Publié le 4 février 2026 Par Fx cachem.fr Environ 1 minute de lecture LanguageTool est un outil gratuit de correction d’orthographe et de grammaire. Il dépanne au quotidien pour rédiger un e-mail, un commentaire ou un document plus long. Mais une question revient souvent : où partent les données ? Quel est le niveau de confidentialité ? Que se passe-t-il si je n’ai plus de connexion Internet ? J’ai une bonne nouvelle pour vous, il est possible d’installer LanguageTool sur un NAS. Vous allez voir, c’est assez simple 🙂 LanguageTool sur son NAS LanguageTool peut fonctionner en mode serveur via une API HTTP. Cette configuration permet aux extensions de navigateur par exemple de s’y connecter sans jamais envoyer de données vers Internet. Si vous souhaitez l’installer sur votre NAS, il faut que ce dernier soit capable d’executer des conteneurs Docker. Aussi, LanguageTool est relativement gourmand… il consomme rapidement environ 765 Mo de RAM. Si votre NAS ne dispose que de 1 Go de RAM, ce n’est clairement pas recommandé. Installer sur un NAS Synology Pour cette installation, j’ai choisi l’image Docker erikvl87/languagetool, qui est recommandée par l’éditeur de LanguageTool. Préparation des dossiers Ouvrez File Station Allez dans le dossier docker Créez un sous-dossier nommé languagetool À l’intérieur de celui-ci, créez un dossier nommé ngrams Ce dossier ngrams servira à stocker vos modèles linguistiques personnalisés. Création du conteneur Docker Ouvrez Container Manager Allez dans Projet → Créer Renseignez les informations suivantes : Nom du projet : languagetool Chemin : docker/languagetool Source : Créer un fichier docker-compose.yml Collez ensuite le contenu suivant : services: languagetool: image: erikvl87/languagetool container_name: languagetool restart: unless-stopped volumes: - ./ngrams:/ngrams environment: - Java_Xms=512m - Java_Xmx=1g - langtool_languageModel=/ngrams ports: - 8010:8010 Voici ce que vous devriez avoir : Le port 8010 exposera l’API LanguageTool sur le NAS et langtool_languageModel=/ngrams indique l’emplacement des données linguistiques. Cliquez sur Suivant, puis sur Effectué… et patientez quelques minutes le temps que le conteneur démarre. Configuration de LanguageTool dans le navigateur Côté navigateur : Installez l’extension LanguageTool Cliquez sur l’icône de l’extension Ouvrez les paramètres via la roue crantée Descendez jusqu’à « Paramètres avancés (uniquement pour les professionnels) » Dans Serveur LanguageTool, sélectionnez : Autre serveur — le serveur LanguageTool doit fonctionner ici Saisissez l’adresse suivante : http://AdresseIPduNAS:8010/v2/ C’est terminé ! En synthèse Vous utilisez désormais LanguageTool en local, sans aucune connexion à Internet. Toutes les analyses restent strictement sur votre NAS : vos données restent chez vous… vraiment. Afficher l’article complet

Korben.info Publié le 3 février 2026 Par Korben, Manuel Dorne korben.info Environ 9 minutes de lecture L'autre jour, je voulais juste exposer un petit service tournant sur mon NAS pour y accéder à distance quand je suis en déplacement. Alors je me suis dit "Allez, je vais faire ça propre avec Traefik" mais bon, debugger du fichier YAML parce qu'on oublie des indentations à un moment ça casse la tête. J'ai +40 balais et pas que ça à foutre. Si vous hébergez vos propres services à la maison (self-hosting powaaaah !) et que vous êtes un peu bordélique comme moi, vous installez un truc, puis un autre, et vous finissez avec une collection de ports impossible à mémoriser du genre monip:8080, monip:32400, monip:9000… Aarrgh, l'enfer !!! Et ne me lancez pas sur la gestion des certificats SSL !! Si vous voulez faire ça bien, faut générer des certificats Let's Encrypt à la main pour chaque service, modifier les fichiers de conf Nginx en priant pour ne pas oublier un point-virgule… et j'en passe et des pas mûres… Alors je sais, oui ça nous occupe et pendant ce temps là, on n'est pas dehors en train de voler des voitures mais j'sais pas vous, moi j'ai mieux à faire. Hé bien, figurez-vous les copains, qu'il existe un outil qui transforme ce cauchemar en promenade de santé. Ça s'appelle Nginx Proxy Manager, et une fois que vous aurez lu mon article et testé vous penserez : "Mais pourquoi je me suis emmerdé la vie pendant tout ce temps, mortecouille ?!". Nginx Proxy Manager, c'est quoi ce truc ? En gros, c'est une interface graphique super propre pour gérer Nginx. Au lieu de taper des lignes de commandes et d'éditer des fichiers de config obscurs, vous avez un beau tableau de bord pour : Rediriger vos domaines (ex: plex.mondomaine.fr) vers vos conteneurs Docker. Gérer vos certificats SSL (HTTPS) automatiquement. Sécuriser l'accès à certains services avec un mot de passe. Mais en vrai, c'est plus riche que ça. Dans la barre du haut, vous avez tout ce qu'il faut pour piloter votre reverse proxy comme un adulte responsable : des hosts (proxy, redirections, streams, 404), des certificats (Let's Encrypt ou certifs locaux), des utilisateurs, des règles d'accès (Access Lists), et même des logs d'audit pour savoir qui a fait quoi (au cas où un de vos potes "teste un truc vite fait" et casse tout). C'est le reverse proxy pour ceux qui veulent que ça marche, tout de suite, sans devenir ingénieur réseau bac+12 ou devoir se taper 2h d'explications IRL d'un barbu qui pue de la gueule ^^. Installation en 3 minutes chrono (avec Docker) Bon, on ne va pas y passer la nuit. La méthode la plus propre, c'est évidemment Docker Compose. Si vous ne l'avez pas, installez-le (allez, un petit apt install docker-compose et on n'en parle plus). Créez un dossier nginx-proxy-manager et collez-y ce fichier docker-compose.yml : version: '3.8' services: app: image: 'jc21/nginx-proxy-manager:latest' restart: unless-stopped ports: - '8080:80' # Port HTTP public - '8181:81' # Port d'administration (à garder pour vous) - '8443:443' # Port HTTPS public volumes: - ./data:/data - ./letsencrypt:/etc/letsencrypt db: image: 'jc21/mariadb-aria:latest' restart: unless-stopped environment: MYSQL_ROOT_PASSWORD: 'npm' MYSQL_DATABASE: 'npm' MYSQL_USER: 'npm' MYSQL_PASSWORD: 'npm' volumes: - ./mysql:/var/lib/mysql Petit piège à éviter : Faites gaffe si vous avez déjà un serveur web (Apache ou Nginx) qui tourne sur la machine hôte. Il va falloir couper le service ou changer les ports, sinon Docker va vous jeter une erreur parce que le port 80 est déjà pris. Du coup, vérifiez bien avec un petit netstat -tulpn | grep 80 avant de lancer la sauce. Ah oui, et si vous utilisez un pare-feu comme UFW (ce que je vous recommande chaudement), n'oubliez pas d'ouvrir le port 81 : ufw allow 81. Sinon, vous allez pleurer devant une page blanche et vous demander pourquoi ça marche pas. Ensuite, lancez la bête : docker-compose up -d Et voilà ! C'est tout. Votre serveur tourne. Si vous avez des erreurs, c'est probablement parce que vos ports sont déjà utilisés. Ou que les dossiers data, Let's Encrypt et MySQL n'existent pas encore. Moi j'ai ça sur mon NAS : La configuration que même ma grand-mère pourrait le faire Ouvrez votre navigateur et allez sur http://votre-ip:8181 et créez vous un compte. Une fois dedans, pour exposer un service, c'est ridicule tellement c'est easyyyy Cliquez sur "Add Proxy Host". Entrez votre nom de domaine (ex: nextcloud.mondomaine.fr). Indiquez l'IP de la machine et le port du service (ex: 8080). Allez dans l'onglet "SSL", cochez "Request a new SSL Certificate" et "Force SSL". Sauvegardez. En fait, le seul truc qui peut coincer, c'est la propagation DNS. Si vous venez d'acheter votre nom de domaine il y a 5 minutes, pas de panique si Let's Encrypt refuse de générer le certificat. Attendez une petite heure et réessayez. C'est classique. Et hop, fini. Votre service est accessible en HTTPS, avec le petit cadenas vert qui va bien. Nginx Proxy Manager s'occupe de discuter avec Let's Encrypt et de renouveler le certificat tout seul. C'est carrément magique. Tour d'horizon des fonctionnalités qui sauvent des week-ends Parce que oui, Nginx Proxy Manager ne fait pas "juste" proxy + "cadenas". Dans le menu Hosts, vous avez plusieurs types de trucs à créer, et chacun sert à un usage bien précis. Et côté Certificats et sécurité, il y a de quoi faire sans sortir le marteau-piqueur. Certificats Let's Encrypt (HTTP et DNS) + certifs locaux On va commencer par le sujet qui donne des boutons : les certificats. Dans l'onglet Certificates, vous pouvez gérer tout ça au même endroit : Let's Encrypt en HTTP-01 : le classique. NPM ouvre la voie, répond au challenge, et basta. Pratique pour un service.mondomaine.fr exposé "normalement". Let's Encrypt en DNS-01 : là, c'est le mode "j'ai compris la vie". Vous pouvez valider le certificat via votre DNS (donc sans dépendre d'un port 80 accessible), et surtout ça permet les wildcards du style *.mondomaine.fr. Donc un seul certif et roule ma poule, même si vous ajoutez 12 sous-domaines demain à 3h du mat. Certificats locaux : vous pouvez aussi importer un certificat existant (genre un certif de votre boîte, un truc interne, un CA maison, ou même un self-signed si vous aimez vivre dangereusement). Ça évite de dépendre de Let's Encrypt si vous êtes en mode "tout en local, rien sur Internet". Et le meilleur c'est que NPM gère le renouvellement automatique. Donc plus de rappel calendrier "renouveler les certifs" tous les 2 mois, sinon c'est le drame et tout le monde vous écrit "ça marche plus ton truc". Plusieurs comptes, parce que tout le monde n'est pas "admin" Dans Users, vous pouvez créer plusieurs comptes pour accéder à l'interface. Typiquement : un compte admin pour vous, le chef, le patron, le seigneur des reverse proxies. un compte "moins dangereux" pour quelqu'un qui doit juste consulter ou bidouiller un truc sans toucher à toute l'infra. Et ça, couplé aux Audit Logs (j'y reviens juste après), c'est très pratique quand plusieurs personnes mettent les mains dedans. Parce que "c'est pas moi, j'ai rien touché" est une phrase universelle, on la retrouve dans toutes les cultures. Access Lists, le videur à l'entrée Alors ça, c'est une des fonctions les plus sous-cotées. Les Access Lists permettent de mettre en place des règles d'accès et de les réutiliser partout : Basic Auth (login/mot de passe) : parfait pour protéger une appli pas prévue pour être publique, ou un petit outil d'admin que vous ne voulez pas exposer "en clair". Allow/Deny par IP : le top pour dire "seulement depuis mon IP / mon VPN / mon réseau". Et là, même si quelqu'un devine votre URL, il se prend un mur. Vous créez une Access List une fois, et ensuite vous l'appliquez à vos Proxy Hosts. Du coup, pas besoin de refaire 50 fois la même conf. C'est propre, c'est net, c'est carré. Les redirections propres (HTTP -> HTTPS, domaine A -> domaine B, etc.) Besoin de rediriger un vieux domaine vers un nouveau ? Ou de faire un joli http:// qui part systématiquement en https:// ? Les Redirection Hosts servent exactement à ça. C'est bête mais ça évite d'aller trifouiller des règles Nginx à la main. Exemples typiques : mondomaine.fr -> www.mondomaine.fr ancientruc.mondomaine.fr -> nouveautruc.mondomaine.fr http -> https (pour les retardataires) Streams - Quand ce n'est pas du HTTP mais que vous voulez quand même un reverse proxy Le web, c'est bien, mais tout n'est pas en HTTP. Certaines applis parlent en TCP/UDP (bases de données, services réseau, protocoles chelous, etc.). C'est là que Streams entrent en jeu. Cette fonctionnalité vous permet de proxyfier des flux réseau, genre "ce port externe pointe vers ce port interne". Alors oui, c'est plus "brut" que les Proxy Hosts, mais ça dépanne vraiment quand vous avez un service qui n'a rien à faire derrière un vhost HTTP. Et ça se configure aussi en 2 clics, sans incantations démoniaques. 404 Hosts - La sortie de secours Les 404 Hosts, c'est la petite finition qui fait plaisir (non, rien à voir avec votre salon de massage préféré). Vous pouvez définir un "host poubelle" qui répond proprement quand quelqu'un tape un domaine qui n'existe pas chez vous, ou quand un bot scanne votre serveur en espérant trouver /phpmyadmin par magie. Au lieu de laisser traîner une réponse moche ou ambiguë, vous renvoyez une 404 nette, propre, assumée. C'est pas de la sécurité absolue, mais c'est une bonne hygiène, et ça évite de donner trop d'infos aux curieux. Audit Logs Dans Audit Logs, vous avez l'historique des actions effectuées dans l'interface : création/modif de hosts, changements de certifs, etc. C'est le genre de truc dont on se fout… jusqu'au jour où on en a besoin. Et là, vous êtes content de pouvoir remonter le film de l'horreur. Et enfin, mon bonus : Le mode "je sais ce que je fais" (les options avancées Nginx) Et si un jour vous voulez aller un cran plus loin, NPM permet aussi d'ajouter des réglages plus "Nginx pur jus" par host (headers, règles, conf custom). Donc vous commencez en mode clic-clic, et si vous devenez un peu psycho sur l'optimisation, vous pouvez aussi affiner. Sans tout casser, normalement. 2/3 conseils de daron pour éviter les boulettes Ne laissez pas l'admin ouvert au monde : le port 8181 (ou votre port d'admin) c'est "pour vous". Si possible, limitez-le via pare-feu / VPN / IP autorisées. C'est le panneau de commande de votre château, pas un distributeur de bonbons. Utilisez les Access Lists pour tout ce qui est sensible : dashboards, outils d'admin, services pas prévus pour Internet, etc. Pensez au DNS-01 si vous voulez des wildcards ou si vous n'avez pas envie d'exposer le port 80. Et par rapport aux autres ? Je vous vois venir les puristes : "Oui mais Traefik c'est mieux car c'est dynamique". C'est vrai. J'ai testé Traefik, et c'est une tuerie pour les environnements qui bougent tout le temps. Mais sa config en YAML peut vite devenir une usine à gaz si vous débutez. Caddy est top aussi (un seul fichier de conf), mais il faut quand même mettre les mains dans le cambouis. Perso, je pense que Nginx Proxy Manager est un excellent choix pour un homelab par exemple. C'est un peu le choix du confort, celui des grosses feignasses comme moi parce que c'est visuel, c'est du clic-bouton clic clic, et pour un petit serveur perso, c'est franchement imbattable. Bref, si vous galérez encore avec vos vhosts Nginx, arrêtez de vous faire du mal. Installez ça, et profitez de la vie (et de vos week-ends). Nginx Proxy Manager c'est par ici ! Afficher l’article complet

www.microlinux.fr microlinux.fr Environ 5 minutes de lecture Debian serveur Postfix est un serveur mail, et plus exactement un MTA (Mail Transfer Agent). Il gère l'envoi et la réception de mails par Internet en utilisant le protocole SMTP. Le monde de l'Open Source offre toute une panoplie de MTA, parmi lesquels on trouve Postfix, Exim, Qmail et Sendmail. Dans ce premier article sur les serveurs de messagerie, nous allons configurer Postfix sur une machine publique tournant sous Debian 13 Trixie. Notre premier objectif, ce sera l'envoi des messages du système comme par exemple les notifications du système de sauvegardes automatiques Rsnapshot. Prérequis Avant de mettre la main à la pâte, je vérifie si le serveur n'est pas blacklisté quelque part : https://mxtoolbox.com/blacklists.aspx Installation Postfix est fourni par les dépôts officiels de la distribution : $ sudo apt update $ sudo apt install --no-install-recommends postfix Choisissez No configuration dans la fenêtre de configuration post-installation : On installera également la commande mail (paquet bsd-mailx) pour pouvoir tester et gérer les mails en ligne de commande directement sur le serveur : $ sudo apt install bsd-mailx Configurer Postfix Les fichiers de configuration utilisés par Postfix se situent dans /etc/postfix : Le fichier master.cf gère la configuration du démon master de Postfix. Dans la plupart des configurations de base, on n'aura pas à intervenir sur ce fichier. Le fichier main.cf contient les paramètres de contrôle des démons de Postfix. C'est celui que l'on modifiera le plus souvent. Étant donné que nous avons opté pour No configuration lors de l'installation, nous disposons uniquement d'un fichier main.cf.proto censé servir de base pour une configuration personnalisée. Le fichier /etc/postfix/main.cf.proto est une copie exacte du fichier /usr/share/postfix/main.cf.debian. En dehors de cela, le répertoire /usr/share/postfix/ fournit un fichier main.cf.dist amplement documenté qui décrit en détail le rôle de chacune des directives de configuration de Postfix. Si un paramètre n'est pas présent dans main.cf, Postfix utilisera sa valeur par défaut. Pour la plupart, ces valeurs sont définies en dur dans le code source de Postfix, tandis que certaines sont initialisées à la compilation et quelques-unes au moment du lancement du programme. Voici une configuration de mon cru pour envoyer des e-mails depuis une machine publique avec une ouverture frontale sur Internet : /etc/postfix/main.cf # /etc/postfix/main.cf # # Minimal Postfix configuration for Internet-facing servers # Disable backwards compatibility compatibility_level = 3.10 # Dedicated Postfix user mail_owner = postfix # Disable IPv6 inet_protocols = ipv4 # Outbound mail only inet_interfaces = localhost mailbox_size_limit = 0 # Host myhostname = sd-150204.dedibox.fr # Domain mydomain = dedibox.fr # Authorize local machine only mynetworks = 127.0.0.1/32 # Local aliasing alias_maps = hash:/etc/aliases # Debugging debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5 Le programme postconf est très utile pour examiner les valeurs courantes et par défaut du fichier main.cf. Pour afficher la valeurs de certains paramètres de configuration, il suffit de les fournir en argument : $ sudo postconf inet_interfaces inet_interfaces = localhost L'option -d affichera la valeur par défaut des paramètres demandés : $ sudo postconf -d inet_interfaces inet_interfaces = all Servez-vous de postconf à tire-larigot N'hésitez pas à tester chacune des directives de main.cf avec postconf pour retenir les directives qui ne vont pas correspondre à la valeur définie par défaut : $ sudo postconf inet_protocols inet_protocols = ipv4 $ sudo postconf -d inet_protocols inet_protocols = all La configuration que je vous ai fournie en exemple mérite quelques remarques : Si l'IPv6 est désactivé au niveau du système, il faudra également le faire ici grâce à la directive inet_protocols. inet_interfaces = localhost limite l'utilisation de Postfix aux applications locales. myhostname est censé contenir le nom d'hôte pleinement qualifié du serveur, c'est-à-dire le résultat de la commande hostname --fqdn. mynetworks définit les adresses depuis lesquelles Postfix accepte les mails sans authentification via SMTP. alias_maps définit l'emplacement de la table de correspondance. Certaines informations ne peuvent pas être facilement représentées dans main.cf. Les tables de correspondance permettent de les stocker dans des fichiers externes. Postfix n'utilise pas directement les fichiers texte, ce serait trop lent. Au lieu de cela, les tables de correspondance de type hash (ou « tables de hachage ») servent pour construire des fichiers indexés, grâce à la bibliothèque Berkeley DB. Le programme postmap est utilisé pour construire les fichiers indexés. Pour mettre à jour les alias, on utilisera la commande newaliases. Créez la table de correspondance /etc/aliases : /etc/aliases # /etc/aliases postmaster: root root: info@microlinux.fr Indiquez votre adresse e-mail Je vous encourage fortement à utiliser votre adresse e-mail plutôt que la mienne. Ceci étant dit, la quantité de notifications que je reçois quotidiennement par e-mail me donne une vague idée de la popularité de mes articles sur l'administration des serveurs Linux. Construisez le fichier indexé : $ sudo newaliases Cette commande va créer un fichier /etc/aliases.db exploitable par Postfix : $ ls -l /etc/aliases* -rw-r--r-- 1 root root 65 Jan 31 13:17 /etc/aliases -rw-r--r-- 1 root root 12288 Jan 31 13:16 /etc/aliases.db Mise en service Le service postfix est activé dans la configuration par défaut. Il me suffit de le démarrer : $ sudo systemctl start postfix Je vérifie si Postfix tourne correctement : $ systemctl status postfix ● postfix.service - Postfix Mail Transport Agent (main/default instance) Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled; preset: enabled) Active: active (running) since Sat 2026-01-31 13:21:00 CET; 1min 11s ago Invocation: 8f8863dec0434f72abd44f3d708923d7 Docs: man:postfix(1) Process: 35329 ExecStartPre=postfix check (code=exited, status=0/SUCCESS) Process: 35487 ExecStart=postfix debian-systemd-start (code=exited, status=0/SUCCESS) Main PID: 35496 (master) Tasks: 3 (limit: 4634) Memory: 3.4M (peak: 3.9M) CPU: 1.521s CGroup: /system.slice/postfix.service ├─35496 /usr/lib/postfix/sbin/master -w ├─35497 pickup -l -t unix -u -c └─35499 qmgr -l -t unix -u Je peux également jeter un œil dans les logs de Postfix pour savoir si tout se passe comme prévu : $ sudo tail /var/log/mail.log 2026-01-31T13:24:17.238808+01:00 sd-150204 postfix/master[35820]: daemon started -- version 3.10.5, configuration /etc/postfix Envoi d'un e-mail de test J'envoie un e-mail de test vers un compte auquel j'ai accès, en l'occurrence mon adresse principale : $ mail info@microlinux.fr Subject: Test Postfix Ceci est un test. . Cc: Un point c'est tout Lorsque vous rédigez un e-mail en ligne de commande avec mail, un point . tout seul sur une ligne marque la fin du message. Je me connecte à ma messagerie et je vois que le message a bien été reçu : À partir de là, Postfix pourra être utilisé par les applications locales pour l'envoi d'e-mails. La rédaction de cette documentation demande du temps et des quantités significatives de café espresso. Vous appréciez ce blog ? Offrez un café au rédacteur en cliquant sur la tasse. Afficher l’article complet

DomoPi Publié le 27 janvier 2026 Par Hexamus domopi.eu Environ 5 minutes de lecture NUT (Network UPS Tools) est une solution open-source de supervision d’onduleur (UPS). Elle récupère les informations de l’UPS (alimentation sur secteur ou batterie, niveau de charge, autonomie estimée, événements…) et peut les exposer sur le réseau. Concrètement, on peut avoir un serveur NUT qui dialogue avec l’onduleur, et des clients NUT (comme Proxmox ou d’autres machines) qui s’y connectent pour déclencher automatiquement un arrêt propre en cas de coupure prolongée. Network UPS Tools - Welcome Power Devices support Welcome Configuration du serveur NUT Dans mon cas, mon onduleur est connecté en USB à mon NAS Synology, qui prendra le rôle de serveur NUT. On se connecte à DSM et on se rend dans Panneau de configuration → Matériel & Alimentation → UPS. Si ce n'est pas déjà fait, cochez Activer la prise en charge UPS ainsi que Activer le serveur réseau UPS un peu plus bas. Cliquez sur le bouton Périphériques Synology NAS autorisés et notez les adresses IP des périphériques (serveur Proxmox dans notre cas) qui pourront s'y connecter. Installation et configuration de NUT sur Proxmox Maintenant que le serveur UPS est activé et configuré, on passe à la configuration côté client. Rendez-vous dans la console de l'hôte Proxmox et installez NUT avec les commandes suivantes : apt update apt install nut-client Éditez le fichier de configuration principal : nano /etc/nut/nut.conf Modifiez la ligne MODE pour avoir ceci : MODE=netclient Éditez le fichier de monitoring : nano /etc/nut/upsmon.conf Recherchez la section MONITOR et ajoutez cette ligne en adaptant les informations (adresse IP et identifiants). Sur Synology, les identifiants sont définis par défaut : monuser / secret. MONITOR ups@192.168.1.100 1 monuser secret slave Il faut également ajouter les lignes suivantes pour la gestion de l'arrêt de Proxmox. Une partie est déjà présente dans le fichier, vérifiez chaque section et n'ajoutez que les lignes nécessaires. SHUTDOWNCMD "/sbin/shutdown -h +0" NOTIFYCMD /usr/sbin/upssched POLLFREQ 5 POLLFREQALERT 5 HOSTSYNC 15 DEADTIME 15 POWERDOWNFLAG "/etc/killpower" NOTIFYMSG ONLINE "UPS %s: Alimentation secteur rétablie" NOTIFYMSG ONBATT "UPS %s: Fonctionne sur batterie" NOTIFYMSG LOWBATT "UPS %s: Batterie faible" NOTIFYMSG FSD "UPS %s: Arrêt forcé en cours" NOTIFYMSG COMMOK "UPS %s: Communication établie" NOTIFYMSG COMMBAD "UPS %s: Communication perdue" NOTIFYMSG SHUTDOWN "UPS %s: Arrêt système imminent" NOTIFYMSG REPLBATT "UPS %s: Batterie à remplacer" NOTIFYMSG NOCOMM "UPS %s: Communication indisponible" NOTIFYFLAG ONLINE SYSLOG+WALL+EXEC NOTIFYFLAG ONBATT SYSLOG+WALL+EXEC NOTIFYFLAG LOWBATT SYSLOG+WALL+EXEC NOTIFYFLAG FSD SYSLOG+WALL+EXEC NOTIFYFLAG COMMOK SYSLOG+WALL+EXEC NOTIFYFLAG COMMBAD SYSLOG+WALL+EXEC NOTIFYFLAG SHUTDOWN SYSLOG+WALL+EXEC NOTIFYFLAG REPLBATT SYSLOG+WALL NOTIFYFLAG NOCOMM SYSLOG+WALL Démarrez le client NUT avec les commandes suivantes, son statut doit être active (running) en vert. systemctl restart nut-monitor systemctl enable nut-monitor systemctl status nut-monitor Enfin, testez la connexion au serveur NUT et à l'UPS : upsc ups@192.168.1.100 Vous devriez obtenir une liste des informations de l'UPS : battery.charge: 100 battery.charge.low: 10 battery.runtime: 3600 device.model: Back-UPS ES 700G input.voltage: 230.0 output.voltage: 230.0 ups.load: 25 ups.status: OL Les codes de statut UPS peuvent prendre les valeurs suivantes : OL: Online (sur secteur). OB: On Battery (sur batterie). LB: Low Battery (batterie faible) Interface Web NUT Notre onduleur est maintenant connecté à notre serveur Proxmox et la communication est configurée entre les deux. Mais j'aime bien aussi avoir une interface pour vérifier facilement la bonne communication et visualiser les données. Pour cela, nous allons installer la page web du client NUT avec la commande suivante : apt install nut-cgi apache2 Modifiez le fichier /etc/nut/hosts.conf et ajoutez la ligne ci-dessous en n'oubliant pas de remplacer l'adresse IP par celle du serveur NUT : MONITOR ups@192.168.1.100 "Onduleur Principal" Activez le module CGI puis redémarrez Apache : a2enmod cgi systemctl restart apache2 Il ne reste qu' procéder à un test de la page web http://IP_PROXMOX/cgi-bin/nut/upsstats.cgi depuis un navigateur. Configuration avancée de l'arrêt automatique L'intérêt d'avoir connecté notre onduleur à Proxmox est de pouvoir réaliser un arrêt propre de l'hôte en cas de coupure de courant. On va passer par la création d'un script : nano /etc/nut/upssched-cmd Dans lequel vous pouvez copier le contenu suivant : #!/bin/bash case $1 in onbatt) logger -t upssched-cmd "UPS sur batterie" ;; online) logger -t upssched-cmd "UPS sur secteur" ;; lowbatt) logger -t upssched-cmd "Batterie faible - Arrêt du serveur" # Arrêter le serveur /sbin/shutdown -h +1 ;; *) logger -t upssched-cmd "Commande inconnue: $1" ;; esac On rend le script exécutable : chmod +x /etc/nut/upssched-cmd Pour configurer le planificateur, on modifie le fichier : nano /etc/nut/upssched.conf Et on ajoute ou adapte son contenu : CMDSCRIPT /etc/nut/upssched-cmd PIPEFN /var/run/nut/upssched.pipe LOCKFN /var/run/nut/upssched.lock AT ONBATT * START-TIMER onbatt 30 AT ONLINE * CANCEL-TIMER onbatt online AT LOWBATT * EXECUTE lowbatt AT COMMBAD * START-TIMER commbad 30 AT COMMOK * CANCEL-TIMER commbad commok Explications : On définit le script qui sera appelé. Si l'UPS passe sur batterie, attends 30 secondes avant de notifier. Si le secteur revient, l'alerte est annulée. Si la batterie est faible, l'arrêt est immédiatement demandé. Enregistrez et redémarrez le service : systemctl restart nut-monitor Pour tester que tout fonctionne correctement, vous pouvez utiliser les commandes suivantes depuis la console Proxmox : # Vérifier l'état de l'UPS upsc ups@192.168.1.100 # Consulter les logs tail -f /var/log/syslog | grep -i ups # Vérifier le service nut systemctl status nut-monitor ‼️Attention à la commande suivante, elle vous permet de tester réellement l'arrêt automatique de Proxmox ! Ne lancez cette commande qu'en connaissance de cause. Vous pouvez pour cela simuler une batterie faible avec : upsmon -c fsd Vous pouvez retrouver la documentation complète de NUT sur le lien suivant : Network UPS Tools User Manual Russell Kroll, Arnaud Quette, Arjen de Korte and Jim Klimov Conclusion Voilà, vous disposez maintenant d'une surveillance et gestion complète de votre onduleur dans Proxmox avec : Un monitoring en temps réel de l'onduleur via NUT. Une interface web pour consultation rapide des informations de l'onduleur. L'arrêt automatique et sécurisé de l'hôte Proxmox en cas de coupure prolongée. Notre infrastructure est désormais protégée des coupures de courant ! N'oubliez pas d'activer le redémarrage automatique de votre serveur dans le BIOS pour que celui-ci redémarre au retour du courant. Nous sommes toujours disponible pour discuter de vos installations, d'améliorations ou vous aider si besoin sur la communauté Telegram ou bien en laissant un commentaire ! Afficher l’article complet

IT-Connect Publié le 26 janvier 2026 Par Florian BURNEL it-connect.fr Environ 5 minutes de lecture BentoPDF se présente comme une alternative à Stirling, PDFgear voire même à Adobe Acrobat dans une moindre mesure. Cette boite à outils PDF accessible directement dans votre navigateur Web regroupe des dizaines d'outils pour manipuler vos documents. Au-delà d'être open source, elle se veut respectueuse de la vie privée. Cet article explique comment installer votre instance de BentoPDF à l'aide de Docker. BentoPDF n'est pas la seule boite à outils PDF accessible directement depuis un navigateur et auto-hébergeable : Stirling-PDF reste une référence dans ce domaine, avec en complément des applications pour les ordinateurs. Pour autant, BentoPDF suscite de l'intérêt, la preuve : son nombre d'étoiles sur GitHub est passé de 0 à plus de 10 000 en à peine 3 mois. Voici les avantages de la solution BentoPDF : Application 100% client-side : un gros plus pour la confidentialité, car le traitement s'effectue dans le navigateur de l'utilisateur. Cela signifie que votre fichier n'est pas chargé sur le serveur où est installé BentoPDF. Libre d'accès : l'application est accessible sans authentification, ni compte. Tous les outils du toolkit sont gratuits, sans limitation, que ce soit pour traiter 1 ou X documents. Mode hors ligne pour l'accès aux outils. Conformité RGPD, CCPA et HIPAA. Ce projet open source est distribué sous licence AGPL-3.0. Des licences commerciales abordables sont proposées à ceux qui veulent intégrer BentoPDF au sein d'outils propriétaires (ou en source fermée). Je vous recommande de consulter cette page pour bien comprendre les subtilités selon les cas d'usage. Pour utiliser les outils de BentoPDF, vous avez plusieurs options : l'utiliser directement en ligne depuis le site web de la solution ou l'auto-héberger sur un ordinateur, un serveur ou encore un NAS. Aujourd'hui, je vous propose d'installer BentoPDF à l'aide de Docker Compose. Site officiel - BentoPDF GitHub - bentopdf Les outils de BentoPDF Les nombreux outils de BentoPDF sont organisés au sein de plusieurs catégories. On retrouve notamment : Éditer et annoter Dans la catégorie "Edit & Annotate", BentoPDF met à votre disposition des outils pour retravailler vos documents en profondeur. L'outil central est le PDF Editor, qui transforme votre fichier en espace de travail : vous pouvez y annoter du texte, surligner des passages, ou encore insérer des images et des formes. Il est accompagné par d'autres outils pour générer une table des matières, compléter un formulaire, signer un PDF, supprimer les pages blanches ou encore ajouter un filigrane. Ci-dessous un aperçu de l'outil PDF Editor : Convertir au format PDF Que ce soit un document, une image ou encore certains formats exotiques, BentoPDF est capable de convertir de nombreux formats de fichiers au format PDF. Ci-dessous, un extrait partiel des outils de cette catégorie. Convertir un PDF dans un autre format L'opération inverse est également possible, à savoir convertir un PDF dans un autre format. Cette section contient aussi un outil plutôt cool pour extraire toutes les images d'un document PDF. Organiser et gérer Cette section contient des outils pour diviser, fusionner ou encore supprimer des pages dans un document PDF. Vous pouvez aussi réorganiser les pages, embarquer un fichier dans un document PDF ou simplement effectuer des rotations de page. Optimiser et réparer Cette section contient des outils pour compresser et optimiser un PDF, réparer un document corrompu ou encore supprimer les protections comme un mot de passe. Sécuriser un PDF Enfin, la dernière section concerne la sécurité des documents PDF. Elle contient des outils pour chiffrer et déchiffrer un document PDF (en AES-256 bits), supprimer toutes les métadonnées (voire même tous les éléments comme les annotations, etc.) ou encore verrouiller un document. Ci-dessous, un aperçu de l'outil "Encrypt PDF" permettant de chiffrer un document PDF via l'ajout d'un mot de passe. Toutes ces fonctionnalités sont accessibles directement dans votre navigateur Web, avec un traitement effectué en local. Installation de BentoPDF avec Docker Compose Désormais, passons à l'installation de BentoPDF avec Docker (via Docker Compose). Vous devez donc disposer de Docker sur votre machine, que ce soit sous Windows, Linux ou macOS (ou votre NAS). Tutoriel - Installation de Docker sur Linux Le fichier docker-compose.yml ci-dessous est créé dans le répertoire /opt/docker-compose/bentopdf. Il est à noter que cette application ne stocke aucune donnée, il n'est donc pas nécessaire de déclarer un volume. Cet exemple est basé sur celui mis à disposition sur le site GitHub de BentoPDF. Attention, deux images Docker distinctes sont distribuées : bentopdf qui reprend l'apparence complète du site web officiel et bentopdf-simple qui reprend uniquement la partie boite à outils (cette version me semble plus pertinente pour un déploiement en local). services: bentopdf: image: bentopdf/bentopdf-simple:latest container_name: bentopdf restart: unless-stopped ports: - '8080:8080' environment: - DISABLE_IPV6=true Quelques informations supplémentaires : L'application BentoPDF sera accessible sur le port 8080 ; si vous souhaitez utiliser un autre port, changez la valeur de gauche. La variable d'environnement DISABLE_IPV6=true sert à désactiver IPv6 pour utiliser uniquement IPv4. Elle est facultative (tout dépend de votre environnement). Enregistrez et fermez le fichier. À titre d'information, voici une configuration basique pour publier BentoPDF avec le reverse proxy Traefik : services: bentopdf: image: bentopdf/bentopdf-simple:latest container_name: bentopdf restart: unless-stopped environment: - DISABLE_IPV6=true networks: - frontend labels: - "traefik.enable=true" - "traefik.docker.network=frontend" - "traefik.http.routers.bentopdf-https.rule=Host(`bentopdf.it-connectlab.fr`)" - "traefik.http.routers.bentopdf-https.entrypoints=websecure" - "traefik.http.routers.bentopdf-https.tls=true" - "traefik.http.routers.bentopdf-https.tls.certresolver=ovhcloud" - "traefik.http.services.bentopdf-https.loadbalancer.server.port=8080" - "traefik.http.routers.bentopdf-https.middlewares=crowdsec@file,tinyauth" - "tinyauth.apps.bentopdf.config.domain=bentopdf.it-connectlab.fr" networks: frontend: external: true Cette configuration protège l'application avec Tinyauth (page d'authentification) et CrowdSec (détection des attaques) en tant que middlewares Traefik. Lancez la construction du projet : docker compose up -d Votre boite à outils PDF vous attend ! Elle est accessible sur l'adresse IP de votre hôte Docker sur le port 8080, ou sur un autre port selon la configuration définie. Ensuite, vous n'avez plus qu'à commencer à jouer avec les outils. Conclusion BentoPDF est une boite à outils PDF très complète et prometteuse. Directement accessible dans votre navigateur, elle met à votre disposition un ensemble d'outils pratiques : la manipulation de documents PDF est le quotidien de nombreux utilisateurs. Vous pouvez tout à fait héberger cette application sur votre serveur et la mettre à disposition de plusieurs utilisateurs, le tout en préservant la confidentialité grâce à un traitement effectué du côté client. C'est le gros plus de cette solution et cela vous évite de déployer des applications en local sur chaque machine. Qu'en pensez-vous ? Ingénieur système et réseau, cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Je souhaite partager mon expérience et mes découvertes au travers de mes articles. Généraliste avec une attirance particulière pour les solutions Microsoft et le scripting. Bonne lecture. Afficher l’article complet

Cachem Publié le 26 janvier 2026 Par Fx cachem.fr Environ 5 minutes de lecture Nous sommes en 2026 et les choses ont pas mal évolué ces derniers mois. À une certaine époque, les systèmes DIY pour NAS se comptaient sur les doigts d’une main : ce n’est plus le cas. Aujourd’hui, on trouve des solutions très abouties, avec un niveau de qualité proche du monde professionnel, comme TrueNAS Scale ou Unraid, des options intermédiaires comme OpenMediaVault (OMV), et d’autres plus accessibles et plus souples, comme CasaOS, ZimaOS ou UmbrelOS. Nous aborderons également le cas de Proxmox… Qu’est-ce que le DIY pour les NAS ? Le concept de NAS DIY (Do It Yourself) repose sur une idée simple : s’affranchir du verrouillage matériel des constructeurs (Synology, QNAP, Asustor…). Au lieu d’acheter un boîtier propriétaire, vous sélectionnez vos propres composants (boîtier, processeur, RAM, contrôleurs…) ou vous recyclez un ancien PC. Cette approche offre 2 avantages majeurs : Rapport performance/prix : pour le prix d’un NAS 4 baies du commerce équipé d’un processeur souvent limité, vous pouvez assembler une machine capable de gérer du transcodage 4K, des dizaines de conteneurs Docker, des machines virtuelles… Évolutivité : vous n’êtes plus limité par le nombre de ports, la mémoire soudée ou les choix matériels du constructeur. Votre NAS évolue avec vos besoins. À cela s’ajoute un point souvent sous-estimé : la possibilité de donner une seconde vie à un NAS qui ne reçoit plus de mises à jour… Qu’est-ce qu’un système DIY pour les NAS ? On me pose souvent la question : pourquoi parler de « système » et pas simplement de « système d’exploitation (OS) » pour NAS ? Parce qu’en 2026, un NAS moderne n’est plus seulement un serveur de partage de fichiers (SMB/NFS). C’est une plateforme qui combine trois couches complémentaires : OS : généralement Linux, il gère le matériel et le système de fichiers (ZFS, Btrfs, XFS…) ; Interface web : outil d’administration au quotidien, qui permet de gérer stockage, utilisateurs, services, mises à jour et supervision (sans passer par des lignes de commande) ; Applications : écosystème de services que vous hébergez qui était la force des fabricants historiques… mais maintenant Docker est devenu central. Les poids lourds : Performance et stockage massif Ces solutions visent d’abord la fiabilité et une gestion sérieuse du stockage. TrueNAS Scale : l’incontournable Avec ses évolutions récentes, TrueNAS Scale s’est imposé comme une référence du NAS DIY. Son point fort, c’est la protection des données grâce à ZFS (snapshots, auto-réparation, intégrité), avec une approche très “pro”. En contrepartie, ZFS reste relativement rigide : étendre un pool en ajoutant “juste un disque” n’est pas aussi souple que sur d’autres solutions. Pour exploiter ZFS dans de bonnes conditions, il est recommandé d’avoir beaucoup de mémoire vive/RAM (ECC de préférence). Si votre priorité est la pérennité et la sécurité des données, TrueNAS Scale est un excellent choix. Unraid : la flexibilité avant tout Toujours très populaire chez les particuliers, Unraid brille par sa capacité à gérer des disques hétérogènes (marques et tailles différentes) avec une grande simplicité. Son système de parité permet d’ajouter un disque facilement, au fil de l’eau. Son interface est aussi l’une des plus accessibles et sa gestion de la virtualisation (VM avec passthrough GPU) est une référence pour les configurations hybrides. Le point à intégrer dans l’équation : son modèle économique a évolué. Les mises à jour sont désormais liées à un abonnement, sauf licence à vie plus onéreuse. Cela le place face à une concurrence gratuite de plus en plus solide. Unraid reste un excellent choix pour le multimédia, l’hébergement d’applications et le recyclage de disques, à condition d’accepter le coût de la licence. L’intermédiaire OpenMediaVault est construit autour d’une base Debian, avec une philosophie simple : rester léger, stable et relativement proche de Linux. OMV tourne sur à peu près tout, y compris sur du matériel ancien. Il laisse plus de latitude pour personnaliser l’OS sous-jacent que certaines solutions plus “encadrées”. En revanche, l’interface est plus austère et demande souvent un peu plus de connaissances pour obtenir une configuration parfaitement propre (permissions, services, supervision, sauvegardes). C’est une solution cohérente pour les utilisateurs à l’aise avec Linux qui veulent un NAS sans fioritures, sur du matériel modeste. La nouvelle vague : simplicité et one-click Ici, l’objectif est clair : privilégier l’accessibilité, l’expérience utilisateur et une installation rapide. CasaOS, ZimaOS et UmbrelOS Ces systèmes (ou surcouches, selon les cas) cherchent à transformer un serveur en « cloud personnel » facile à prendre en main. Les interfaces sont modernes, visuelles et l’installation d’applications ressemble à un App Store… On déploie des services en quelques clics, ce qui les rend attractifs pour démarrer vite. La limite est structurelle : ce ne sont pas, à la base, des OS orientés « stockage avancé ». La gestion RAID, la stratégie de protection des données et les scénarios de migration/extension sont sommaires (rien à voir comparé à TrueNAS et Unraid). Ils sont donc très adaptés à un premier serveur multimédia/domotique, mais moins pertinent si vous cherchez une plateforme de stockage « sérieuse » pour des données réellement critiques. HexOS HexOS est très attendu (toujours en Bêta), car l’ambition est séduisante : proposer la puissance d’une base type TrueNAS avec une interface beaucoup plus simple. C’est une piste intéressante pour ceux qui veulent une expérience plus « grand public » sans renoncer à une base technique solide. Point important : c’est un produit payant. Son intérêt dépendra de son niveau de maturité et de la qualité de l’intégration au quotidien. L’alternative : virtualisation avec Proxmox Techniquement, Proxmox VE n’est pas un OS de NAS : c’est un hyperviseur. Mais en 2026, c’est la base de nombreuses installations homelab. Le principe est simple : vous installez Proxmox sur le matériel (bare metal), puis vous déployez votre NAS (TrueNAS, OMV…) dans une machine virtuelle et vos autres services dans d’autres VM ou conteneurs. L’intérêt ici, c’est que vous séparez les rôles. Vous facilitez les sauvegardes complètes (snapshots, export) et vous rendez l’infrastructure plus résiliente. Si un service tombe, le reste continue de tourner et vous pouvez restaurer proprement. Cependant, c’est une approche plutôt réservée aux utilisateurs avancés. Elle demande une bonne maîtrise des notions de stockage (pass-through, contrôleurs, performances, sécurité des données). Que choisir en 2026 ? Le choix ne dépend plus uniquement des fonctionnalités (Docker est devenu un standard), mais de votre priorité? Vous voulez : Protéger vos données avant tout : TrueNAS Scale Recycler des disques variés et évoluer facilement : Unraid Une solution simple, légère, proche de Linux : OMV Une belle interface et démarrage rapide : CasaOS ou ZimaOS Un homelab complet et une infra modulaire : Proxmox Certains diront que le NAS DIY est à son apogée. De mon côté, je le vois plutôt comme une étape : les outils se simplifient, les standards se consolident et le niveau de finition continue de monter. Reste à choisir l’approche qui correspond à vos contraintes… et à votre tolérance à la complexité. Afficher l’article complet

Up and Clear | Reborn upandclear.org Environ 5 minutes de lecture Après avoir mis de côté UNRAiD, dont je me suis lassé, j’ai passé le LincStation N1 sous TrueNAS. Cet OS ne m’apporte rien d’autre que la gestion simplifiée des RAIDs via une WebUI (parce que bon… mdadm… c’est chiant). Enfin je ne cherche pas à utiliser l’OS pour être précis, je ne peux donc pas dire qu’il est nul ou top. M’en tape. Les autres machines, tout aussi peu puissantes que le N1 sont sous Archlinux et Ubuntu. Arch parce que j’aime bien me demander chaque jour si une MàJ va plomber le serveur et comment je vais m’en dépatouiller (et c’est accessoirement mon desktop). Ubuntu, pour changer de Debian, parce que j’ai quand même besoin d’un truc stable dans ma vie de geek. N’utilisant quasi plus de VM/LXC depuis l’avènement de Docker, je n’ai plus de ProxMox. Du coup, je shunte Ubuntu au profit d’une distribution basée sur Debian : ZimaOS ! Jai passé hier l’ensemble de mes services « utiles » sur TrueNAS pour libérer cette machine pour ce test. Avertissement : c’est asiat’. Alors pour les complotistes américains peureux bas du front (rayez ou non les mentions inutiles), n’allez pas plus loin. Je n’ai absolument pas fait de RE pour savoir s’ils ont mis des backdoors. « Mais » CVE-2026-21891 (non encore relayée sur GitHub) / discussion Reddit et si j’ai pas sniffé le trafic, mon DNS ne fait rien ressortir d’extraordinaire. La machine ping même pas Baidu, contrairement à la majorité des objets IoT qui s’assurent d’être connectés à Internet en pingant le de Google chinoix (oui, eux aussi ont leur GAFAM BATX). J’ai découvert cet OS par hasard, quand je cherchais des infos sur des boards de serveurs. J’ai d’ailleurs commencé par découvrir CasaOS, dont j’étais pas fans. Ça faisait un peu Docker in Docker. Pour moi c’est plus à voir comme une alternative à YunoHost (très bon projet pour ceux qui sortent d’une grotte et ne connaissent pas). Même ressenti pour Cosmos d’ailleurs. ZimaOS est développé pour leurs NAS ZimaCube mais on peut l’installer partout. Ils font eux-mêmes la comparaison entre ZimaOS et CasaOS, en gros : C’est un UNRAiD like, avec une interface plus moderne (avis 100% subjectif), avec des clients à la Synology pour Windows, macOS, Linux (AUR), iOS et Android, avec une documentation bien faite sans tomber dans un Wikipedia comme on peut le voir chez certains concurrents, un GitHub et donc la possibilité d’ouvrir des issues (ce qui est bien plus pratique qu’un forum), Ça s’installe en 2-2 avec une clé USB (iso de 1.3Go) créée avec Balena et se gère uniquement via la WebUI. J’utilise la version gratuite. Et il faut activer le Mode Développeur notamment pour désactiver l’indexation du contenu avec leur « IA » (pour faciliter la recherche) et autoriser SSH. Première vraie configuration à faire, mon stockage. De mémoire j’ai que 2 disques dans ce PC mais la version gratuite permet d’en gérer 4 en RAID. Et la version payante coûte 29$ (« à vie »). Comme j’ai qu’un SSD en sus de celui de l’OS, je me contente de le formater et ça l’ajoute bien ensuite en stockage. Ce que je vois d’ailleurs avec le widget de la dashboard, qui passe à 718Go de stockage. Et donc, en standard, ZimaOS intègre un explorateur de fichiers, un outil de backup (depuis ou vers le NAS), un gestionnaire de VM et un PairDrop (je vois la machine sous Windows mais pas mon Arch, faudra que je trouve pourquoi). Depuis un client (Linux/iOS), on peut parcourir les fichiers du serveur et faire du backup. Notamment de photos depuis l’iPhone (arrière plan ou non). On peut ajouter des liens externes à la dashboard, ce qui est une très bonne idée et pourrait m’inciter à me passer de mon brave Heimdall qui m’accompagne depuis maintenant des années… Et nous terminons évidemment avec le fameux AppStore et ses 372 applications (Docker) « prêtes à installer » au moment de cet article. Rien de comparable avec UNRAiD, je vous l’accorde. Mais ici, ça s’installe en 1 clic. Et on peut ajouter des dépôts et doubler, au moins, le nombre d’applications du store. Tout comme il est possible d’installer une app via la WebUI si on elle n’est pas dans le Store et qu’on n’est vraiment pas à l’aise en console. On peut tout à fait utiliser Docker en console ou via Komodo, Arcane, Dockge, Portainer/what ever. Et ça marche « out of the box » dans ce cas, il n’y a rien à adapter pour l’OS. À noter que par défaut, les applications installées via l’AppStore sont dans /DATA, sur le disque système. root@ZimaOS:~ ➜ # tree /DATA/ /DATA/ ├── AppData │ └── pihole │ └── etc │ └── pihole │ ├── adlists.list │ ├── cli_pw │ ├── config_backups │ │ └── pihole.toml.1 │ ├── dhcp.leases │ ├── dnsmasq.conf │ ├── gravity.db │ ├── gravity_backups │ │ └── gravity.db.1 │ ├── gravity_old.db │ ├── hosts │ │ └── custom.list │ ├── listsCache │ │ ├── list.1.raw.githubusercontent.com.domains │ │ ├── list.1.raw.githubusercontent.com.domains.etag │ │ └── list.1.raw.githubusercontent.com.domains.sha1 │ ├── logrotate │ ├── migration_backup │ │ └── adlists.list │ ├── pihole-FTL.db │ ├── pihole-FTL.db-shm │ ├── pihole-FTL.db-wal │ ├── pihole.toml │ ├── tls.crt │ ├── tls.pem │ ├── tls_ca.crt │ └── versions ├── Backup ├── Documents ├── Downloads │ └── ISO ├── Gallery ├── Media │ ├── Movies │ ├── Music │ └── TV Shows └── lost+found Comme ça se voit au-dessus, j’ai installé Pi-Hole depuis l’AppStore pour tester. Faut juste cliquer pour installer. Pratique : en cas d’ajout de disques, on peut migrer les données facilement Même si ZimaOS est basé sur Debian, c’est propriétaire et on ne peut pas utiliser Apt pour y installer ce qu’on veut. C’est une sécurité également, histoire de ne pas mettre en vrac l’OS (ce qu’on est nombreux à avoir fait avec Proxmox hein… mentez pas !!). Ceci dit ils ont prévu le coup. Ceci dit, leur OS embarque déjà bon nombre d’utilitaires tels que ncdu, jq, rclone… Dans l’idéal, j’aimerais un dash qui permet de mieux intégrer quelques applications comme le font Heimdall, Homarr, Organizr etc. Aperçu du client iOS Avec le recul de cet article, je perçois ZimaOS comme un DSM de Synology, enfin plutôt un Xpenology vu qu’on peut l’installer où on veut, avec un peu de combo d’UNRAiD et cousins. Enfin tous ces OS se ressemblent mais ZimaOS serait un peu le « macOS » du groupe, à vouloir proposer une expérience très esthétique, complète (Docker natif ou magasin d’applications), pratique (outils intégrés, y compris pour périphériques) et répondant AMHA à la plupart des besoins. Bien que propriétaire, contrairement à CasaOS qui est open source mais n’est qu’une surcouche. Je pense le faire tourner quelques temps en parallèle de TrueNAS voir remplacer ce dernier. Et j’avais oublié, ça embarque aussi Btop++ pour afficher des stats temps réel. Afficher l’article complet

IT-Connect Publié le 12 janvier 2026 Par Florian BURNEL it-connect.fr Environ 12 minutes de lecture PatchMon est une solution open source de Patch Monitoring pour les serveurs Linux, qu'ils soient sous Debian, Ubuntu, Alma Linux ou encore Red Hat Enterprise Linux (RHEL). L'objectif principal de PatchMon est le suivant : vous offrir une vue d'ensemble sur l'état des mises à jour sur vos machines Linux. Ainsi, vous pouvez identifier facilement les machines sur lesquelles des mises à jour de paquets sont en attente, avec une mise en évidence des mises à jour de sécurité. Les machines sous Linux, au même titre que celles sous Windows, reçoivent des mises à jour. D'une part, il y a les mises à jour du système et du noyau, et d'autre part, les mises à jour des paquets installés (du paquet de la simple bibliothèque à celui d'un service utilisé en production). Comment suivre la disponibilité des mises à jour ? Si l'on prend l'exemple de machines sous Debian, exécuter les commandes apt update et apt upgrade manuellement n'est pas une solution viable et efficace. C'est là qu'un outil comme PatchMon apporte une valeur ajoutée : son tableau de bord affiche l'état des mises à jour de l'ensemble de vos machines Linux. Son fonctionnement repose sur l'installation d'un agent sur les machines à monitorer. À la clé : Un inventaire de vos machines (avec la répartition par type d'OS) Un aperçu du niveau de mises à jour de vos machines (à jour, en attente de mise à jour, en attente d'un redémarrage) Une visibilité sur le type de mises à jour en attente (distinction entre mise à jour standard et correctif de sécurité) Une tendance globale dans le temps Des statistiques globales sur l'ensemble de votre SI L'état de la réception des données de la part des agents Au-delà d'offrir une vue par machine, PatchMon offre aussi une vue par paquet : pratique pour identifier les machines sur lesquelles est installé tel ou tel paquet. Il référence aussi la liste des dépôts (repos) configurés sur vos machines. Précision importante : la version actuelle de PatchMon ne permet pas de gérer la mise à jour des paquets. Nous sommes donc dans une approche de monitoring, sans qu'il soit possible d'appliquer les mises à jour en attente. Mais les choses vont évoluer à l'avenir : la feuille de route évoque des fonctionnalités croustillantes, dont celle-ci. PatchMon est un projet qui a énormément progressé en quelques mois. L'intégration avec Docker pour remonter les informations sur les conteneurs, les images, etc... est actuellement en bêta, tandis que d'autres intégrations sont en préparation (Proxmox VE, etc.). C'est un projet à suivre en 2026 ! GitHub - PatchMon Installation du serveur PatchMon L'installation de PatchMon sera réalisée sur un serveur où Docker a été installé au préalable. Nous utiliserons un fichier Docker Compose car la stack PatchMon repose sur plusieurs conteneurs : Base de données avec PostgreSQL, Cache objet avec Redis, Backend de PatchMon, Frontend de PatchMon Créer un dossier pour le projet Docker Comme à mon habitude, j'ai créé un dossier dédié à ce projet sur mon serveur afin d'isoler les données associées à PatchMon. Le dossier suivant a été créé : /opt/docker-compose/patchmon Par la suite, trois sous-dossiers seront créés dans ce dossier (vous pouvez les créer manuellement ou laisser Docker procéder) : /opt/docker-compose/patchmon | |___ agent_files |___ postgres_data |___ redis_data Note : un quatrième dossier nommé branding_assets peut être ajouté si vous souhaitez déposer des éléments spécifiques pour personnaliser l'apparence de l'interface. Par exemple : remplacer le logo PatchMon par celui de votre entreprise. Générer 3 mots de passe Avant de créer le fichier Docker Compose, je vous invite à générer trois mots de passe qu'il sera nécessaire d'insérer dans ce fichier. Ils seront utilisés pour personnaliser les mots de passe de PostgreSQL et Redis, et pour le secret JWT. Voici à titre d'information les trois valeurs utilisées pour ce tutoriel et obtenues via la même commande que vous pouvez lancer sur votre serveur. # Mot de passe de la base de données openssl rand -hex 64 eb2b687f514ddcd25226de40437a59a0f9fbac5ffe72fda2e5e6d11b31e2b9e99c4aeb6944f73c37f76ba175082821a69fb625d1b080dac7df66a7ff1ea967af # Mot de passe Redis openssl rand -hex 64 0ba2b3084b93fa7bfb49452c23bea7a50c2772a9c1e3e83437db283ea37874e59febd0e09d77e1579348d2fb10cf46e7a7de17656bc7312099622fada8f42f23 # Secret JWT openssl rand -hex 64 e0b7f1ad9bd73bd271b3d161fb013c6a90e5de48e8ed4b0cb80d9717f4cb1886470671f527565158c37a1c78db92614287844eb95135abaee50ac60a0539a2cb Créer le fichier Docker Compose Voici le fichier docker-compose.yml que vous devez créer à la racine de votre projet PatchMon. Vous devez le personnaliser de façon à insérer vos mots de passe. J'ai mis des couleurs distinctes sur les trois valeurs pour que vous puissiez vous y retrouver. Cette configuration s'appuie sur la version disponible sur le GitHub officiel du projet. name: patchmon services: database: image: postgres:17-alpine restart: unless-stopped environment: POSTGRES_DB: patchmon_db POSTGRES_USER: patchmon_user POSTGRES_PASSWORD: eb2b687f514ddcd25226de40437a59a0f9fbac5ffe72fda2e5e6d11b31e2b9e99c4aeb6944f73c37f76ba175082821a69fb625d1b080dac7df66a7ff1ea967af volumes: - ./postgres_data:/var/lib/postgresql/data networks: - patchmon-internal healthcheck: test: ["CMD-SHELL", "pg_isready -U patchmon_user -d patchmon_db"] interval: 3s timeout: 5s retries: 7 redis: image: redis:7-alpine restart: unless-stopped command: redis-server --requirepass 0ba2b3084b93fa7bfb49452c23bea7a50c2772a9c1e3e83437db283ea37874e59febd0e09d77e1579348d2fb10cf46e7a7de17656bc7312099622fada8f42f23 volumes: - ./redis_data:/data networks: - patchmon-internal healthcheck: test: ["CMD", "redis-cli", "--no-auth-warning", "-a", "0ba2b3084b93fa7bfb49452c23bea7a50c2772a9c1e3e83437db283ea37874e59febd0e09d77e1579348d2fb10cf46e7a7de17656bc7312099622fada8f42f23", "ping"] interval: 3s timeout: 5s retries: 7 backend: image: ghcr.io/patchmon/patchmon-backend:latest restart: unless-stopped # See PatchMon Docker README for additional environment variables and configuration instructions environment: LOG_LEVEL: info DATABASE_URL: postgresql://patchmon_user:eb2b687f514ddcd25226de40437a59a0f9fbac5ffe72fda2e5e6d11b31e2b9e99c4aeb6944f73c37f76ba175082821a69fb625d1b080dac7df66a7ff1ea967af@database:5432/patchmon_db JWT_SECRET: e0b7f1ad9bd73bd271b3d161fb013c6a90e5de48e8ed4b0cb80d9717f4cb1886470671f527565158c37a1c78db92614287844eb95135abaee50ac60a0539a2cb SERVER_PROTOCOL: http SERVER_HOST: 192.168.10.200 SERVER_PORT: 3000 CORS_ORIGIN: http://192.168.10.200:3000 # Database Connection Pool Configuration (Prisma) DB_CONNECTION_LIMIT: 30 DB_POOL_TIMEOUT: 20 DB_CONNECT_TIMEOUT: 10 DB_IDLE_TIMEOUT: 300 DB_MAX_LIFETIME: 1800 # Rate Limiting (times in milliseconds) RATE_LIMIT_WINDOW_MS: 900000 RATE_LIMIT_MAX: 5000 AUTH_RATE_LIMIT_WINDOW_MS: 600000 AUTH_RATE_LIMIT_MAX: 500 AGENT_RATE_LIMIT_WINDOW_MS: 60000 AGENT_RATE_LIMIT_MAX: 1000 # Redis Configuration REDIS_HOST: redis REDIS_PORT: 6379 REDIS_PASSWORD: 0ba2b3084b93fa7bfb49452c23bea7a50c2772a9c1e3e83437db283ea37874e59febd0e09d77e1579348d2fb10cf46e7a7de17656bc7312099622fada8f42f23 REDIS_DB: 0 volumes: - ./agent_files:/app/agents networks: - patchmon-internal depends_on: database: condition: service_healthy redis: condition: service_healthy frontend: image: ghcr.io/patchmon/patchmon-frontend:latest restart: unless-stopped ports: - "3000:3000" networks: - patchmon-internal depends_on: backend: condition: service_healthy volumes: postgres_data: redis_data: agent_files: networks: patchmon-internal: driver: bridge Dans ce fichier, vous pourrez constater que : Les conteneurs seront connectés sur le même réseau Docker intitulé patchmon-internal, L'application est exposée sur le port 3000 via le conteneur frontend, Des dépendances sont définies entre certains conteneurs via les instructions depends_on. Au-delà des mots de passe et secrets, vous devez ajuster plusieurs variables pour éviter d'avoir une erreur de sécurité lors de la première connexion : SERVER_PROTOCOL: http : http ou https, selon la méthode d'accès. SERVER_HOST: 192.168.10.200 : le nom public du serveur, mettez l'IP ou le nom. SERVER_PORT: 3000 : le port d'accès, doit être cohérent vis-à-vis du port exposé sur le frontend. CORS_ORIGIN: http://192.168.10.200:3000 : ajustez cette valeur pour qu'elle représente l'adresse publique sur laquelle sera joignable PatchMon. Autrement dit, n'indiquez pas localhost ou 127.0.0.1. Ici, je précise l'adresse IP de mon hôte Docker car les échanges seront uniquement sur le réseau local. Ici, nous effectuons un accès en HTTP à l'application PatchMon. Pour la production, il est bien entendu recommandé d'associer un reverse proxy pour publier l'application en HTTPS, avec un certificat TLS. Pour aller plus loin, il y a d'autres variables d'environnement disponibles : référez-vous à cette page de la documentation. Enregistrez et fermez le fichier. Initialiser le projet Docker Compose Désormais, vous pouvez initialiser le projet Docker. Les images seront téléchargées, le réseau créé, tout comme les différents conteneurs. Patientez un instant. docker compose up -d Si vous avez une erreur, consultez les journaux : docker compose logs Il est possible que le conteneur backend refuse de démarrer à cause d'une erreur de permissions sur le dossier agent_files. Vous pouvez corriger cette erreur via la commande suivante : sudo chown -R 1000:1000 /opt/docker-compose/patchmon/agent_files Première connexion à PatchMon Ouvrez votre navigateur web et tentez d'accéder à l'interface de PatchMon, en saisissant son adresse. Saisissez l'adresse associée au paramètre CORS_ORIGIN. Pour ma part, ce sera donc : http://192.168.10.200:3000. Vous devez commencer par créer un premier compte utilisateur correspondant à l'administrateur de la plateforme PatchMon. Voilà, bienvenue sur votre instance PatchMon ! Je vous encourage à prendre le temps de parcourir les paramètres, en cliquant sur le bouton "Settings" en bas à gauche. Il y a plusieurs sections, que ce soit pour gérer les comptes utilisateurs, les rôles, votre profil, ou encore les groupes d'hôtes. Par exemple, vous pouvez activer le MFA sur votre compte administrateur. Cliquez sur "URL Config" dans la liste pour vérifier que l'adresse du serveur est bien prise en charge. C'est important de le vérifier, même si ça doit déjà être correct grâce aux variables SERVER_* configurées précédemment. Cette page affiche l'adresse qui sera utilisée par les clients pour contacter le serveur PatchMon. Si c'est incorrect, vous allez rencontrer des problèmes par la suite... Une fois que vous avez terminé votre petit tour de l'interface PatchMon, passez à la suite : le déploiement d'un premier agent. Déployer un agent PatchMon sur Linux Pour ajouter manuellement un nouvel hôte à PatchMon, vous devez déployer un nouvel agent. À partir de la section "Hosts", cliquez sur le bouton "Add host" (ou directement sur le "+" dans le menu de gauche). Pour le moment, la liste des hôtes est vide. Donnez un nom à cette machine, en toute logique le nom du serveur cible. Il est aussi possible : d'ajouter l'hôte à un groupe d'hôtes, mais par défaut il n'y a pas de groupe. C'est modifiable par la suite. d'activer une intégration, soit pour le moment l'intégration avec Docker (d'autres sont en cours de développement). Cliquez sur le bouton "Create Host" pour valider. Une fenêtre va s'afficher à l'écran. Elle indique la commande à copier-coller pour automatiser l'installation de l'agent PatchMon et l'inscription auprès du serveur. Pour ma part, la commande à exécuter est la suivante : curl -s http://192.168.10.200:3000/api/v1/hosts/install -H "X-API-ID: patchmon_2a08e8a52f0ae9fb" -H "X-API-KEY: 5bbc4e017f9c4a0ca8e485d11fd911e85e4768a38f5e832be1826d68532714e1" | sh Si vous ne lancez pas la commande directement en tant que root, vous devez ajouter sudo juste devant sh dans la seconde partie de la commande. L'opération est effectuée en quelques secondes. Les informations dans la console permettent d'avoir un aperçu des actions effectuées. Vous devriez voir passer deux lignes indiquant que les identifiants sont valides et que la connexion au serveur a été effectuée avec succès. Quelques précisions : Les identifiants de connexion à l'API sont stockés dans le fichier /etc/patchmon/credentials.yml. Le fichier de configuration, comprenant notamment l'adresse vers le serveur, est le fichier suivant : /etc/patchmon/config.yml. Le fichier journal de l'agent PatchMon est le suivant : /etc/patchmon/logs/patchmon-agent.log Suite à l'installation, l'hôte apparait bien sur l'interface de PatchMon. Vous pouvez actualiser les données en cliquant sur le bouton en haut à droite. Sur cette machine, on voit bien qu'il y a un retard considérable au niveau des mises à jour ! Note : l'agent PatchMon est équipé d'une fonction de mise à jour automatique activée par défaut. PatchMon collecte des informations générales sur la machine, en particulier pour le réseau, le système et le stockage. Vous pouvez naviguer entre les différents onglets : Sur le même principe, vous pouvez ajouter d'autres hôtes. La vue globale offrira alors une vue synthétique sur les hôtes enregistrés. Les commandes pour gérer l'agent PatchMon Voici quelques commandes utiles pour administrer l'agent PatchMon sur un serveur. Tester la connexion : patchmon-agent ping --------------------------------- ✅ API credentials are valid ✅ Connectivity test successful Lancer une synchronisation depuis l'agent : patchmon-agent report Afficher l'état de l'agent : patchmon-agent diagnostics --------------------------------- ✅ API credentials are valid ✅ Connectivity test successful root@srv-haproxy:~# patchmon-agent diagnostics PatchMon Agent Diagnostics v1.3.7 System Information: OS: Debian GNU/Linux 12 (bookworm) Architecture: amd64 Kernel: 6.1.0-25-amd64 Hostname: srv-haproxy Machine ID: 7cf53fba-b483-4621-9d3a-461833b6c214 Agent Information: Version: 1.3.7 Config File: /etc/patchmon/config.yml Credentials File: /etc/patchmon/credentials.yml Log File: /etc/patchmon/logs/patchmon-agent.log Log Level: info Configuration Status: ✅ Config file exists ✅ Credentials file exists Network Connectivity & API Credentials: Server URL: http://192.168.10.200:3000 ✅ Server is reachable ✅ API is reachable and credentials are valid Last 10 log entries: time="2026-01-08T11:06:57" level=info msg="Reboot status check completed" installed_kernel=6.1.0-25-amd64 needs_reboot=false reason= running_kernel=6.1.0-25-amd64 time="2026-01-08T11:06:57" level=info msg="Collecting package information..." time="2026-01-08T11:07:01" level=info msg="Found packages" count=360 time="2026-01-08T11:07:01" level=info msg="Collecting repository information..." time="2026-01-08T11:07:01" level=info msg="Found repositories" count=6 time="2026-01-08T11:07:01" level=info msg="Sending report to PatchMon server..." time="2026-01-08T11:07:02" level=info msg="Report sent successfully" time="2026-01-08T11:07:02" level=info msg="Processed packages" count=360 time="2026-01-08T11:07:07" level=info msg="Checking for agent updates..." time="2026-01-08T11:07:07" level=info msg="Agent is up to date" version=1.3.7 Afficher l'état du service : systemctl status patchmon-agent Afficher les logs de l'agent PatchMon : journalctl -u patchmon-agent -f Redémarrer le service : systemctl restart patchmon-agent Le monitoring de Docker avec PatchMon Si vous installez l'agent PatchMon sur une machine équipée de Docker et que vous activez l'intégration Docker, vous pourrez alors suivre l'état de vos conteneurs depuis l'interface de PatchMon. Toujours dans l'esprit monitoring, l'interface affiche l'état des conteneurs, la liste des images, des réseaux et des volumes. Pour le cas des images, ce qui est cool, c'est que PatchMon indique s'il y a une mise à jour disponible ou non, ainsi que d'autres informations (nom, tag, source, etc.). J'ai constaté qu'au début les images remontent toutes en "Up to date" (à jour), mais que l'état réel apparaît un peu plus tard. Ci-dessous, un exemple. Au niveau de chaque hôte, vous pouvez activer ou désactiver des intégrations, que l'on peut considérer comme des modules, via l'onglet "Integrations". Le site de PatchMon laisse entendre que d'autres intégrations arriveront par la suite : WordPress, Apache, Ubiquiti, Proxmox, Azure ou encore Google (vous pouvez voter d'ailleurs). Conclusion Si vous gérez déjà vos mises à jour de façon automatisée (avec Ansible, par exemple), le fait d'utiliser PatchMon ajoute une couche de monitoring intéressante pour savoir quand il est nécessaire d'agir sur tel ou tel serveur. C'est vrai pour un Home Lab et pour une petite infrastructure où PatchMon peut se faire une place pour apporter une meilleure visibilité. La solution PatchMon est jeune, mais elle évolue vite, et j'ai le sentiment qu'elle va progresser dans la bonne direction. Une communauté d'une dizaine de personnes contribue déjà au développement de la solution et le projet semble bien reçu ! Maintenant, nous attendons avec impatience la gestion des mises à jour et, pourquoi pas, à terme, la prise en charge des machines sous Windows. FAQ PatchMon Qu'est-ce que PatchMon ? PatchMon est un outil open source de surveillance des correctifs (patch monitoring) pour les systèmes Linux. Il offre un tableau de bord centralisé permettant de visualiser l'état des mises à jour (paquets installés, mises à jour de sécurité manquantes, etc.) sur l'ensemble de vos serveurs, sans avoir à s'y connecter individuellement. Il supporte aussi la découverte des conteneurs Docker et des conteneurs LXC sur les hôtes Proxmox VE. Comment fonctionne la communication entre mes serveurs et PatchMon ? L'architecture de PatchMon repose sur un modèle "agent-serveur". Un agent codé en Go est installé sur chaque machine Linux à surveiller. Cet agent initie la connexion vers votre serveur PatchMon (il est donc question d'une communication sortante uniquement). Vous n'avez pas besoin d'ouvrir de ports entrants sur vos serveurs surveillés, ce qui est un bon point pour la sécurité. Comment déployer en masse l'agent PatchMon ? La façon la plus adaptée de déployer l'agent PatchMon en masse sur un ensemble de machines Linux me semble être l'utilisation d'un playbook Ansible. D'ailleurs, au sujet d'Ansible, sachez qu'il y a un plugin d'inventaire dynamique PatchMon pour Ansible (voir cette page). PatchMon peut-il découvrir les conteneurs LXC de Proxmox VE ? Oui, PatchMon dispose d'une fonction nommée "Proxmox Auto-Enrollment" pour découvrir et inscrire automatiquement les conteneurs LXC des hôtes Proxmox VE. Le script de découverte tourne directement sur l'hôte Proxmox VE. Cette fonctionnalité est décrite sur cette page de la documentation. Ingénieur système et réseau, cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Je souhaite partager mon expérience et mes découvertes au travers de mes articles. Généraliste avec une attirance particulière pour les solutions Microsoft et le scripting. Bonne lecture. Afficher l’article complet

Le site de Korben Publié le 2 janvier 2026 Par Korben korben.info Environ 2 minutes de lecture Si vous avez une clé USB RTL-SDR qui traîne dans un tiroir et que vous vous demandez ce que vous pourriez bien en faire, j'ai peut-être trouvé le projet qui va vous occuper pendant quelques soirées. Ça s'appelle Intercept , et c'est un dashboard web qui regroupe les outils de réception radio les plus courants dans une seule interface. Comme ça, au lieu de jongler entre multimon-ng pour décoder les pagers, rtl_433 pour les capteurs météo, dump1090 pour tracker les avions... vous avez tout ça dans une seule interface Flask accessible directement sur votre navigateur. L'installation se fait via pip après un clone du repo, et certaines fonctions nécessitent des privilèges élevés (sudo) pour accéder aux interfaces réseau : git clone https://github.com/smittix/intercept.git cd intercept pip install -r requirements.txt Et pour le lancer : sudo python3 intercept.py Le truc tourne en local sur le port 5050 et agrège les données de six modules différents. Côté signaux, on peut décoder les protocoles POCSAG et FLEX (les pagers qu'utilisent encore certains services d'urgence, notamment aux États-Unis et au Royaume-Uni), surveiller la bande 433MHz où communiquent les stations météo et divers capteurs IoT. Pour le tracking, y'a un module ADS-B qui affiche les avions sur une carte OpenStreetMap avec leur trace historique, et un autre pour les satellites qui prédit les prochains passages au-dessus de votre position. Là où ça devient plus... disons "sensible", c'est avec les modules WiFi et Bluetooth. Le premier peut passer votre carte en mode monitor pour analyser les réseaux environnants et, si un client se reconnecte au bon moment, capturer des handshakes WPA. Le second scanne les appareils Bluetooth à portée. Évidemment, selon les lois de votre pays, ce genre d'analyse peut être encadré voire interdit sur des équipements tiers donc renseignez vous bien avant d'aller en prison bêtement. Le projet affiche d'ailleurs un gros disclaimer au lancement. Techniquement, c'est du Python avec Flask pour le backend, Leaflet.js pour les cartes, et des Server-Sent Events pour le streaming en temps réel. L'interface propose un thème sombre ou clair, des alertes sonores configurables, et l'export des données en CSV ou JSON. Y'a même des raccourcis clavier pour les power users. Pour faire tourner le bazar, il vous faut un dongle RTL-SDR compatible (les modèles à base de RTL2832U font l'affaire), une carte WiFi supportant le mode monitor si vous voulez cette fonction, et les dépendances habituelles : rtl-sdr, multimon-ng, rtl_433, dump1090, aircrack-ng pour le WiFi et BlueZ pour le Bluetooth . Le projet est sous licence MIT, développé par smittix avec l'aide de quelques contributeurs. Ça me rappelle un peu l'époque où on bidouillait avec les femtocells pour intercepter les communications , sauf qu'ici c'est packagé proprement et ça ne nécessite pas de souder quoi que ce soit. Si vous cherchez un projet pour apprendre les bases de l'intelligence des signaux radio ou juste pour voir ce qui se passe dans les ondes autour de vous, c'est un excellent point de départ. Par contre, je vous recommande vraiment de lire les lois de votre pays sur l'interception des communications avant de brancher quoi que ce soit... Afficher l’article complet

www.it-connect.fr Publié le 11 décembre 2025 it-connect.fr Environ 8 minutes de lecture La supervision d'un système Linux directement depuis le Terminal, c'est possible avec Glances. Un outil open source qui va vous faire oublier les commandes top et htop, bien qu'elles restent classiques pour tout administrateur système. Glances propose une approche modernisée avec des options supplémentaires pour visualiser l'état de santé de vos machines en un clin d'œil. Glances est particulièrement pertinent pour : Consulter rapidement l'état général d'un système avec une seule et unique commande, Diagnostiquer un goulot d'étranglement (CPU, I/O disque ou RAM) sur un serveur de production, Mettre en place une surveillance légère via une interface web sur une machine dépourvue d'interface graphique. <iframe class="iframe_youtube" src="https://www.youtube.com/embed/-jg9wvVqBHk" title="Glances : la supervision système facile dans le Terminal" frameborder="0" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen="allowfullscreen">[embedded content]</iframe> Glances est un outil de supervision système libre développé en langage Python. Il a été créé il y a plus de 10 ans par un Français : Nicolas Hennion, connu sous le pseudo de Nicolargo. Sa particularité : il affiche un état complet d'un système directement dans le terminal, ce qui est particulièrement intéressant sur les serveurs où les interactions s'effectuent uniquement en ligne de commande. Site officiel de Glances GitHub de Glances Même si je le présente ici dans le contexte de Linux, Glances présente la particularité de fonctionner sur de multiples plateformes : GNU/Linux, macOS, Windows et FreeBSD. Il prend en charge trois modes d'exécution différents : Standalone : exécution locale classique dans le terminal. Client/Serveur : surveillance à distance. Web Server : affichage des métriques directement via votre navigateur web. L'objectif de Glances n'est pas de remplacer un outil de supervision complet, où vous aurez des alertes et un historique, mais d'offrir un tableau de bord complet et immédiat. Pour autant, Glances peut communiquer avec d'autres applications grâce à son API. Il prend aussi l'export des données via InfluxDB ou vers un simple fichier CSV. On peut aussi nommer la possibilité d'exporter vers Prometheus pour ensuite afficher les informations avec Grafana. Puisque Glances est développé en Python, il a besoin de Python. Pour l'installer, il y a plusieurs méthodes envisageables : installer directement le paquet glances (et ses dépendances) via apt sur Debian / Ubuntu, ou encore directement avec pipx. Il est dans la majorité des dépôts officiels des distributions Linux. C'est la méthode la plus simple pour une intégration rapide, bien que la version distribuée ne soit pas nécessairement la dernière. Par exemple, actuellement, Debian 13 distribue la version 4.3.1 alors que la plus récente est la 4.4.1. Pour installer Glances sur Debian ou Ubuntu : sudo apt update sudo apt install glances Comme le montre l'image ci-dessous, de nombreuses dépendances Python seront aussi installées. Une fois tous les paquets installés, vous pouvez profiter de Glances ! Pour bénéficier des dernières fonctionnalités, l'installation avec Pipx directement via Python est recommandée. Vous devez, au préalable, installer Python sur votre machine et préparer votre environnement. # Installation de Glances avec pipx (toutes les fonctionnalités activées) pipx install 'glances[all]' # Installation de Glances avec pip (toutes les fonctionnalités activées) pip install --user glances[all] # Installation de base de Glances + interface web pipx install --user 'glances[web]' Vous pouvez retrouver le détail des fonctionnalités sur cette page du site PyPi. Des images Docker de Glances sont disponibles sur le Docker Hub. C'est plutôt intéressant car cela évite d'installer Glances et toutes ses dépendances sur la machine si vous disposez de Docker. Sachez que Glances est aussi compatible avec LXC. Ci-dessous un exemple de fichier Docker Compose (docker-compose.yml) pour déployer Glances avec Docker : services: glances: container_name: glances image: nicolargo/glances:latest ports: - 61208:61208 environment: - TZ=Europe/Paris - GLANCES_OPT=-w pid: host restart: unless-stopped volumes: - /var/run/docker.sock:/var/run/docker.sock:ro L'application Glances sera accessible via un navigateur web sur l'adresse de l'hôte Docker, via le port 61208 : http://<IP Docker>:61208. Cela est possible grâce à l'activation de l'interface web de Glances via GLANCES_OPT=-w. Pour aller plus loin, voici un autre exemple où Glances est publié via Traefik et l'accès à son interface est protégé par une page d'authentification Tinyauth. services: glances: container_name: glances image: nicolargo/glances:latest environment: - TZ=Europe/Paris - GLANCES_OPT=-w pid: host restart: unless-stopped volumes: - /var/run/docker.sock:/var/run/docker.sock:ro networks: - frontend labels: - traefik.enable=true - traefik.http.routers.glances-https.rule=Host(`glances.domaine.fr`) - traefik.http.routers.glances-https.entrypoints=websecure - traefik.http.routers.glances-https.tls=true - traefik.http.routers.glances-https.tls.certresolver=ovhcloud - traefik.http.routers.glances-https.middlewares=crowdsec@file,tinyauth - traefik.http.services.glances-https.loadbalancer.server.port=61208 - tinyauth.apps.glances.config.domain=glances.domaine.fr - tinyauth.apps.glances.users.allow=adm_fb networks: frontend: external: true Remarque : si vous envisagez de personnaliser la configuration de Glances, vous devez ajouter un volume pour le fichier glances.conf. Par exemple : - "./glances.conf:/glances/conf/glances.conf". D'autres exemples sont disponibles sur GitHub du projet Glances : Docker Compose Glances. Pour lancer l'outil, ouvrez simplement votre terminal et tapez cette commande : glances L'interface de Glances apparaît immédiatement à l'écran. Elle se divise en plusieurs zones dynamiques où les informations sont actualisées en permanence (avec un délai d'actualisation de 2 secondes par défaut). Sur les versions récentes, il y a aussi un mode plus synthétique pour obtenir un résumé de votre machine. Ce mode s'exécute de cette façon : glances --fetch C'est probablement l'une des fonctionnalités les plus appréciées. Glances peut lancer un petit serveur web intégré, vous permettant de consulter vos métriques depuis n'importe quel navigateur, y compris sur mobile. Pour lancer ce mode, rajoutez simplement cette option : glances -w Glances Web User Interface started on http://0.0.0.0:61208/ Glances RESTful API Server started on http://0.0.0.0:61208/api/4 Announce the Glances server on the LAN (using 0.0.0.0 IP address) INFO: Started server process [5087] INFO: Waiting for application startup. INFO: Application startup complete. INFO: Uvicorn running on http://0.0.0.0:61208 (Press CTRL+C to quit) Le terminal affiche un message précisant que Glances écoute sur http://0.0.0.0:61208. Vous pouvez donc y accéder en local ou à distance en précisant l'adresse IP de votre machine. Note : par défaut, le mode web est ouvert à tous. Il est conseillé de définir un mot de passe avec l'option --password. Ce qui donne : glances -w --password. Il conviendra alors de définir un mot de passe associé au compte utilisateur glances (pour changer, utilisez --username). Ce mode permet de centraliser la surveillance. Vous lancez Glances en mode "serveur" sur la machine à surveiller, et vous vous y connectez depuis votre poste de travail (le client). Sur le serveur (la machine à surveiller) : glances -s Sur la machine de supervision (client) : glances -c <IP_SERVEUR_GLANCES> L'interface de Glances, qu'elle s'affiche dans le Terminal ou via la page Web, affiche un ensemble de métriques sur votre système. Ces informations sont réparties dans un ensemble de zones. La zone principale se situe en bas à droite et donne un aperçu sur tous les processus en cours d'exécution sur la machine. Il y a plusieurs métriques, dont : usage du CPU, usage de la RAM, PID, temps d'exécution, le compte associé, ou encore la commande complète ou le service associé au processus. Juste au-dessus, vous avez la liste des conteneurs en cours d'exécution sur la machine locale. Avec là encore, des métriques spécifiques : le nom du conteneur, le statut, l'uptime, la consommation en RAM et CPU, et les ports exposés. Glances supporte Docker et Podman. En complément, il y a d'autres zones permettant d'avoir des informations sur l'état du stockage, l'état du réseau, la charge globale du système sur 1, 5 et 15 minutes, et la charge de la RAM et du CPU à l'échelle du système. Glances utilise un système de seuils colorés pour attirer votre attention, ce qui facilite la lecture rapide : Vert (OK) : tout est normal. Bleu (Careful) : une vigilance est requise (exemple : CPU > 50%). Violet (Warning) : la charge est élevée (exemple : CPU > 70%). Rouge (Critical) : le système est en situation critique (exemple : CPU > 90%). Ces seuils sont entièrement configurables via le fichier de configuration glances.conf. Bien qu'il y ait quelques zones cliquables, la navigation sur l'interface de Glances s'effectue majoritairement au clavier. Au-delà de la navigation avec les flèches directionnelles, voici quelques raccourcis pratiques : c : trier les processus par utilisation CPU. m : trier les processus par utilisation mémoire. p : trier les processus par nom. q : quitter l’application. L'aide, accessible via la touche h du clavier, permet d'obtenir la liste complète des raccourcis clavier : Glances dispose d'un fichier de configuration en mode texte que vous pouvez utiliser pour affiner le comportement de la solution. Ce n'est pas obligatoire d'éditer la configuration, car Glances est prêt à l'emploi dès sa sortie de boite. Sur Linux (Debian/Ubuntu), le fichier de configuration est le suivant : /etc/glances/glances.conf. Si vous utilisez Glances sur Windows, ce sera bien entendu différent : %APPDATA%\glances\glances.conf. Vous pouvez notamment utiliser ce fichier de configuration pour personnaliser les seuils d'alerte de Glances et la fréquence à laquelle les données doivent être rafraichies. Le fichier de configuration commence par la section [global] : [global] # Temps d'actualisation global, personnalisable au niveau de chaque module # Par exemple, un temps d'actualisation plus rapide pour le CPU. refresh=2 # Vérifier la présence de mises à jour check_update=true # Taille de l'historique, en nombre de valeurs # 1200 valeurs = 1 heure avec le refresh à 2 secondes history_size=1200 Il y a ensuite des sections par module, par exemple [system] (première ligne de l'interface Glances), [cpu] pour les informations globales sur le processeur ou encore [mem] pour la RAM. Vous avez à chaque fois des paramètres communs, comme disable=False si un module est activé, et des paramètres pour la personnalisation des seuils (careful, warning, critical). Par ailleurs, vous pouvez configurer l'exporter Prometheus pour ensuite afficher les informations avec Grafana. Cette configuration s'effectue dans le même fichier de configuration, via la section [prometheus]. Voici la configuration suggérée (et par défaut) : [prometheus] host=localhost port=9091 prefix=glances labels=src:glance Pour activer l'export, vous devez lancer Glances de cette façon : glances --export prometheus Pour en savoir plus et obtenir des précisions sur les paramètres, consultez cette page : Documentation Glances - Configuration. Glances se positionne comme un outil de monitoring "tout-en-un" très pertinent pour l'administration système quotidienne. Sa capacité à s'exécuter en mode web ou client/serveur lui confère une polyvalence que les outils standards n'ont pas toujours. Bien qu'il ne remplace pas une solution de supervision complète comme Centreon ou Zabbix pour l'historisation à long terme, il est un allié de choix pour l'analyse en temps réel. Afficher l’article complet

www.cachem.fr Publié le 24 octobre 2025 cachem.fr Environ 2 minutes de lecture Après une année de développement et de tests intensifs, Jellyfin 10.11.0 marque l’une des évolutions les plus importantes du projet open source. Cette nouvelle version met l’accent sur la performance, la fiabilité et la préparation du futur, avec une refonte du système de gestion des métadonnées, de nouveaux outils d’administration et plusieurs améliorations côté utilisateur. Regardons de plus près cette nouvelle version… Jellyfin 10.11.0 : le changement, c’est maintenant Visuellement, Jellyfin 10.11.0 n’apporte que peu de modifications. Les véritables avancées se situent à l’intérieur du moteur : la base de données de la bibliothèque a été entièrement migrée vers EF Core. Concrètement, Jellyfin abandonne les requêtes SQLite dispersées au profit d’une gestion centralisée des données. Résultat : des requêtes plus rapides, des migrations plus sûres, et une base bien plus facile à faire évoluer. Cette refonte ouvre également la voie à la prise en charge future d’autres moteurs de base de données, comme PostgreSQL, pour plus de flexibilité et de robustesse. Maintenance simplifiée La migration des bibliothèques s’accompagne d’un processus de déduplication et de nettoyage des données (suppression d’entrées orphelines ou doublons). Selon la taille et l’ancienneté de la base, cette étape peut durer de quelques minutes à plusieurs heures. Avant toute mise à jour, il est impératif de : sauvegarder manuellement les dossiers de données et de configuration, être déjà sur la version 10.10.7, et ne jamais interrompre la migration en cours. Autre nouveauté appréciable : la fonction de sauvegarde et restauration intégrée. Elle permet de créer des instantanés (snapshots) de la base de métadonnées et de les restaurer facilement, un vrai plus pour la maintenance et la sécurité des données. Performances et consommation mémoire Le moteur de base de données tire désormais parti d’un cache en mémoire plus agressif, ce qui réduit les accès disque et améliore nettement la réactivité, notamment sur les grandes bibliothèques. En contrepartie, Jellyfin utilise davantage de RAM, mais cette mémoire est libérée automatiquement si d’autres processus en ont besoin. De nouveaux modes de verrouillage (locking) viennent aussi améliorer la stabilité dans les environnements sollicités. Compatibilité et évolutions techniques Jellyfin abandonne définitivement le support des systèmes ARM 32 bits (armhf). Pour continuer à bénéficier des mises à jour, il faut désormais utiliser un système d’exploitation ARM64. Autre changement annoncé : la suppression prochaine du support TLS/SSL interne (prévue pour la version 10.12.0). Les développeurs recommandent désormais d’utiliser un reverse proxy (comme Nginx ou Caddy) pour la gestion des certificats, plus fiable et plus simple à maintenir. Nouvelles fonctionnalités et améliorations clés Parmi les nouveautés les plus notables de Jellyfin 10.11.0 : Recherche plus rapide et gestion enrichie des favoris (Live TV, clips, albums photo, saisons, etc.) ; Support HEVC dans Firefox 134+ et option pour désactiver le style natif des sous-titres ; Affichage en collections des séries et ajout d’un splash screen personnalisable sur la page de connexion ; Tableau de bord enrichi, avec statistiques médias et suivi de l’espace disque ; Support AV1 via VideoToolbox et passage à FFmpeg 7.1, pour de meilleures performances en décodage et transcodage ; Amélioration du rendu HDR et Dolby Vision sur certains matériels compatibles ; Nouvelle API de sauvegarde (BackupApi) et migration complète des plugins vers EF Core. Cette version corrige également plusieurs failles de sécurité, y compris des correctifs issus de projets externes. En synthèse Jellyfin 10.11.0 pose des fondations solides pour l’avenir du projet. Plus rapide, plus stable et mieux structurée, cette version facilite la maintenance tout en préparant de futures innovations. Une mise à jour vivement conseillée, à condition de la planifier avec soin…. pensez aux sauvegardes. source Afficher l’article complet

upandclear.org upandclear.org Environ 5 minutes de lecture J’ai migré mon LincStation N1 d’UNRAiD à TrueNAS CE (ex TrueNAS Scale, ex FreeNAS), que je redécouvre avec grand plaisir. EDIT : on peut passer l’interface en français dans les options, tout comme on peut choisir son shell (zsh de base, je suis repassé en Bash) EDIT2 : oui, mon titre est réducteur. Très longtemps utilisateur de ProxMox, depuis l’avènement de Docker je me servais de moins en moins les VM/CT. Après l’avoir utilisé avec Docker (directement sur l’hôte), j’ai ensuite bifurqué sur du 100% Linux sans interface chez moi avec Debian, Ubuntu et ArchLinux. Ce dernier n’étant pas le plus stable pour un serveur, vu le principe de rolling release, il faut être à l’aise avec Arch dans ce contexte. Trouvant OpenMediaVault inadapté à mes besoins, Xpenology (comme un hackintosh mais pour DSM de Synology) encore moins pour un serveur de prod, j’avais fait un passage par TrueNAS Scale à l’époque mais le trouvais là encore trop peu pratique dans mon cas (manquant de simplicité). En me rapprochant de SuperBoki, je m’étais acheté une licence Pro à vie d’UNRAiD puis un LincStation N1 à l’occasion de sa promotion sur le site d’UNRAiD. Petit serveur, aussi bien physiquement qu’en terme de ressources, ce petit NAS basse consommation répond toujours très bien à mes besoins (hors post sur Usenet, le pauvre CPU ayant morflé quelques fois…). Au fil du temps, j’allais surtout sur UNRAiD pour parcourir le magasin d’applications et faire quelques découvertes, UNRAiD étant très populaire chez les hoarders et dans l’univers de l’auto-hébergement lié au P2P and co. Mais je n’y allais que pour ça. Au final, UNRAiD ne me servait qu’à avoir une gestion simplifiée et très user-friendly du stockage. Je gérais, quasi depuis le début, mes Dockers comme j’aime, donc pas via UNRAiD : en console, via Dockge voire Portainer ou plus récemment Arcane. Des outils qui, à mon sens, ne dépendant pas de l’OS, permettent une plus grande liberté d’actions, manipulations et migrations entre machines (j’en ai actuellement 3 au garage). Et en plus quand un truc tourne rond, je suis de ceux qui ne sont pas contents, je pense que c’est le lot des bidouilleurs. J’ai récemment remisé dans un tiroir ma clé USB UNRAiD et décidé passer ce petit NAS sous TrueNAS CE, l’évolution de Scale (donc la version gratuite). Mon but cette fois-ci était précis : trouver un gestionnaire de stockage simple et efficace, qui me laisse beaucoup de liberté de gestion tout en me permettant de gérer mon stockage de manière très intuitive (autrement qu’en console via mdadm). Je ne vais pas présenter l’OS vu que je ne m’y suis pas vraiment attardé autrement que pour la gestion des disques et partages. Il permet de créer VM, CT et mettre en place des Dockers. Il propose, comme UNRAiD mais bien moins fourni, un magasin d’applications (environ 300 pour l’instant, rien de comparable à UNRAiD donc et logiquement orientées pro/services plus que P2P etc). J’utilise ZFS pour créer mes pools (des VDEVs) de stockage. Docker, RAID1 de 2 NVMe de 250Go. Ne remplace pas une sauvegarde régulière mais me permet la perte d’un disque pour reconstruire le RAID sans perdre les données. Fichiers, en stripped (RAID0) de 2 SSD de 2To. Si un disque meurt, tout le pool est irrécupérable. Dédié à BitTorrent etc, que des données que je peux perdre. Usenet, composé d’un seul disque NVMe d’1To. Parce que je ne savais vraiment pas quoi en faire… Il pourrait me servir à faire un peu de DL/Post pour Usenet. Il me reste encore un disque d’inutilisé. Si je décide de remettre Plex/Jellyfin, il pourrait servir de cache. J’ai pas utilisé de chiffrement, il n’y a aucun service confidentiel dessus et en plus c’est stocké chez moi. Je fais des backups de mes Dockers à l’ancienne via un script Bash pour l’instant (oui je sais, on arrive en 2026). Il va falloir que je me penche sur les options intégrées à TruenAS ! J’aime la gestion simplifiée des services Idem pour les partages. On voit d’ailleurs que j’ai fait en sorte de pouvoir monter Fichiers sur mon Windows de jeu, vu que j’ai le temps de jouer en ce moment (…) pour récupérer mes jeux téléchargés. Là encore, la gestion des utilisateurs est étonnante de simplicité et pourtant très complète Je redécouvre cet OS avec grand plaisir, notamment avec le recul que j’ai pris à écrire cet article. Je le trouve bluffant de simplicité sans pour autant faire de concession sur la sécurité ou les options. Même si j’ai conscience de ne pas l’exploiter, j’ai enfin trouvé un OS qui répond à mes besoins du moment, se configure en 8 minutes et me laisse libre de l’utiliser comme bon me semble. On peut gérer cron et systemd via ses options également. Ravi d’avoir retenté l’expérience TrueNAS 🙂 Afficher l’article complet

Vous avez apprécié mon calendrier de l'Avent spécial Open Source ? Ou pire encore, vous l'avez totalement manqué ? Voici un récapitulatif complet des outils présentés du 1er au 24 décembre 2025 dans le cadre du calendrier de l'Avent publié sur mon compte LinkedIn. Pour clôturer cette année 2025, je vous ai proposé un voyage quotidien au cœur de l'Open Source en reprenant le principe d'un calendrier de l'Avent. Le principe était simple : présenter chaque jour un nouvel outil open source. Il y a des milliers de projets open source, alors comment choisir ? Surtout pas au hasard. J'ai sélectionné des projets que je connaissais déjà ou qui me semblaient avoir un potentiel intéressant. Voici désormais la synthèse complète des 24 outils présentés jour après jour. Nuclei est un scanner de vulnérabilités rapide et personnalisable basé sur des modèles (templates) simples à écrire. Il permet aux équipes de sécurité et aux professionnels de l'IT d'une manière générale, d'automatiser la détection de failles sur des applications web et des infrastructures. Grâce à sa communauté active, de nouveaux modèles sont constamment ajoutés et mis à jour pour détecter les dernières CVE. On peut citer notamment les points clés suivants : Détection de CVE connues Repérage de fichiers sensibles et logins par défaut Identification de pages d'administration Identification des signatures applicatives Création de templates personnalisables en YAML Voici quelques ressources utiles : Pangolin se positionne comme une alternative complète et auto-hébergée aux tunnels Cloudflare, utilisant la puissance de WireGuard et que vous pouvez déployer sur votre machine. Cette solution de plus en plus populaire permet d'exposer vos applications locales sur Internet sans que vous ayez à ouvrir de ports sur votre routeur, ni à vous prendre la tête avec des problèmes de NAT. L'outil intègre un tableau de bord intuitif pour gérer vos accès et sécuriser vos flux. Quelques points clés : Exposition d'applications via des tunnels WireGuard Gestion des règles d'accès contextuelles (IP, Géo, etc.) : application du principe Zero-trust Tableau de bord de configuration complet Routage du trafic vers n'importe quel réseau privé Applications pour Mac, Windows et Linux Voici quelques ressources utiles : GitHub : fosrl/pangolin Site officiel : pangolin.net Source : GitHub - Pangolin FossFLOW est un outil spécialisé dans la création de diagrammes d'infrastructure réseau avec une approche bien à lui : une vue isométrique. Je trouve qu'il est idéal pour schématiser des architectures, des flux applicatifs ou des topologies réseau de manière claire. L'application fonctionne directement dans le navigateur et facilite la documentation technique visuelle : vous pouvez l'auto-héberger sur votre serveur. Voici quelques ressources utiles : GitHub : stan-smith/FossFLOW Démo en ligne : fossflow Source : GitHub - FossFLOW BunkerWeb est un pare-feu applicatif web (WAF) open source de nouvelle génération, basé sur le célèbre serveur Nginx. Développé par une équipe de Français, il est conçu pour s'intégrer dans des environnements modernes comme Docker et Kubernetes, tout en prenant en charge les hôtes classiques. Son interface d'administration full-web rend plus agréable la gestion de la sécurité de vos sites et applications web. Administration 100% web Protection contre les bots et les IP malveillantes (intégration de certaines listes) Intégration native de ModSecurity (moteur pour le WAF) Compatible Linux, Docker et orchestrateurs Quelques ressources utiles : Référence historique de l'open source, Samba continue d'évoluer pour offrir une alternative crédible et gratuite à Microsoft Active Directory. Il permet de monter un contrôleur de domaine complet, gérant l'authentification et les droits des utilisateurs dans un réseau Windows/Linux. C'est la solution idéale pour avoir les avantages d'un Active Directory sans s'appuyer sur Windows Server, et ainsi s'affranchir des coûts de licences CAL Microsoft. En résumé, on peut citer la prise en charge des fonctions suivantes : Contrôleur de domaine (DC) Gestion des GPO (Group Policy Objects) Authentification Kerberos Partage de fichiers et compatibilité RSAT Quelques ressources utiles : GitLab : samba-team/samba Site officiel : samba.org Jellyfin est le système multimédia qui vous permet de reprendre le contrôle sur vos données audio et vidéo. Il centralise vos films, séries, musiques et photos pour les diffuser sur n'importe quel appareil via une interface moderne. Contrairement à Plex, il est totalement gratuit et sans fonctionnalités payantes. Une solution stable et agréable à utiliser au quotidien, surtout pendant les longues soirées d'hiver. Quelques points clés : Centralisation de tous vos médias Transcodage vidéo matériel (Hardware Transcoding) Gestion automatique des métadonnées (recherche dans plusieurs bases connues) Prise en charge de nombreux appareils et systèmes d'exploitation, autant desktop que mobile et TV Fonction SyncPlay pour regarder à plusieurs Voici des ressources utiles : Source : Jellyfin.org Immich est une solution de sauvegarde de photos et vidéos auto-hébergée conçue pour remplacer Google Photos. Avec son interface web moderne, elle offre une expérience utilisateur agréable avec de nombreuses fonctionnalités pour organiser vos photos et vidéos. L'outil intègre même des fonctionnalités avancées d'intelligence artificielle locale pour la reconnaissance faciale et la recherche : j'insiste sur le mot "locale", car immich est une solution focus sur la privacy. Quelques fonctionnalités clés : Gestion et partage d'albums Applications mobiles pour la sauvegarde automatique de vos clichés en arrière-plan. Vue cartographique et recherche intelligente Gestion multi-utilisateurs Corbeille et archivage de données Voici les liens vers des ressources utiles : Tabby est un terminal ultra-personnalisable : il va au-delà du simple terminal en intégrant un gestionnaire de connexions complet et le support de multiples protocoles (SSH, Telnet, Serial). Son interface moderne et ses plugins en font un outil intéressant dans la catégorie "productivité" pour aller plus loin que Windows Terminal sur Windows. Terminal moderne et personnalisable Gestionnaire de connexions et coffre-fort intégré Support de nombreux types de connexion : SSH, Telnet, Serial, etc. Support de PowerShell, Bash, WSL, etc. Cross-platform (Windows, Mac, Linux) Quelques liens utiles : GitHub : Eugeny/tabby Site officiel : tabby.sh Source : Tabby.sh SearXNG est un métamoteur de recherche gratuit qui agrège les résultats de plus de 70 services de recherche tout en protégeant votre vie privée. Il ne traque pas les utilisateurs et ne crée pas de profilage, garantissant des résultats neutres. En l'hébergeant vous-même, vous reprenez le contrôle total sur vos requêtes web sans pour autant vous passer de Google. Agrégateur de résultats (Google, Bing, etc.) Respect total de la vie privée Résultats neutres sans bulles de filtres Sources et interface personnalisables (onglets de recherche personnalisés selon un contexte) Quelques liens utiles : GitHub : searxng/searxng Site officiel : docs.searxng.org Quand on parle de no-code, on pense à n8n : c'est normal, c'est un outil très à la mode et qui est vraiment top ! Mais, il n'est pas open source (fair-code), donc il n'a pas été retenu pour ce calendrier de l'Avent. Une autre alternative que j'apprécie a été présentée : Activepieces, une plateforme d'automatisation open source conçue pour être une alternative à différents outils comme Zapier (et n8n). Elle permet de connecter vos applications entre elles (noeuds) et de créer des flux de travail complexes via une interface visuelle. Avec le support de TypeScript et des agents IA, c'est un outil flexible pour automatiser vos tâches. Automatisation de workflows via éditeur visuel Création d'agents IA personnalisés et prise en charge de serveurs MCP Plus de 500 connecteurs disponibles Pièces (modules) écrites en TypeScript avec une grosse participation de la communauté Voici quelques liens utiles : GitHub : activepieces/activepieces Site officiel : activepieces.com DocuSeal offre une plateforme pour signer, gérer et stocker vos documents numériques sans utiliser des outils comme DocuSign ou Adobe Sign. Elle permet de créer des formulaires PDF remplissables et de les faire signer légalement par des tiers, en respectant l'ordre de signature. La version auto-hébergée lève les limites de volume, idéale pour les entreprises soucieuses de la souveraineté de leurs données. Signature numérique et audit légal Création de formulaires PDF Signatures illimitées en version self-hosted Intégration d'un certificat personnel pour avoir une signature valide et vérifiable API et Webhooks pour l'intégration Quelques ressources utiles : Uptime Kuma est un outil de surveillance self-hosted facile à déployer, doté d'une interface à la fois soignée et épurée. Il surveille la disponibilité de vos services en effectuant une vérification simple (HTTP, HTTPS, TCP, DNS, etc.) et vous alerte instantanément en cas de panne sur le canal de votre choix (des dizaines de services sont pris en charge). Il permet également de créer des pages de statut publiques pour vos utilisateurs, comme le font les hébergeurs. Monitoring HTTP(s), TCP, Ping, DNS, Docker, etc. Tableau de bord moderne et réactif Page de statut publique (Status Page) Notifications via E-mail, Telegram, Slack, etc. Quelques ressources utiles : LanguageTool est un assistant d'écriture intelligent qui va bien au-delà du simple correcteur orthographique classique. Il analyse la grammaire, le style et le ton de vos textes dans plusieurs langues pour améliorer la qualité de vos écrits. En version auto-hébergée, il garantit que vos textes ne quittent jamais votre serveur et cela permet d'avoir une instance centralisée pour plusieurs utilisateurs. Je l'utilise au quotidien depuis plusieurs années, notamment pour la rédaction des articles, et je ne peux plus m'en passer. Il y a des extensions pour les principaux navigateurs et certaines applications comme Word et LibreOffice (sans oublier le module Google Docs). Quelques ressources utiles : Stirling-PDF est une application web regroupant des dizaines d'outils pour manipuler des fichiers PDF. En gros, vous avez tout ce qu'il vous faut pour fusionner, découper, convertir, signer ou encore effectuer de l'OCR sur vos documents, le tout via une interface web unique. C'est un outil pertinent pour remplacer les services PDF en ligne où vous ne savez pas ce que deviennent vos données : là, vous pouvez l'auto-héberger. Plus de 50 outils pour manipuler les PDF Fonctionne directement dans le navigateur OCR (Reconnaissance optique de caractères) Signature numérique et conversion de formats Une API pour faciliter les interactions avec des outils tiers Interface configurable en 40 langues différentes Dans le même esprit, il y a un autre projet qui mérite une attention particulière et qui monte bien ces derniers temps : BentoPDF. Quelques liens utiles : GitHub : Stirling-Tools/Stirling-PDF Site officiel : stirlingpdf.com Stirling-PDF (ancienne version) XCP-ng est une plateforme de virtualisation, née comme alternative communautaire à Citrix Hypervisor. C'est un hyperviseur de type bare-metal qui offre toutes les fonctionnalités attendues en production, et qui se présente donc comme une alternative à VMware ESXi, Proxmox VE ou encore Hyper-V. Il est soutenu par une entreprise française (Vates) et une communauté grandissante : une solution qui mérite un peu plus de lumière ! Live Migration de machines virtuelles (migration à chaud) Haute disponibilité avec le clustering Aucune restriction sur le CPU ou la RAM Support Pro pour les entreprises Quelques liens utiles : GitHub : xcp-ng/xcp-ng Site officiel : xcp-ng.org Source : GitHub - XCP-ng BorgBackup (ou Borg pour les intimes) est une solution de sauvegarde en ligne de commande qui dispose d'un jeu de commandes très complet. BorgBackup supporte la déduplication des données (top pour optimiser l'utilisation du stockage) et permet de réaliser des sauvegardes quotidiennes, tout en chiffrant les données côté client. C'est un outil très intéressant pour la sauvegarde de serveurs Linux. Déduplication efficace (gain de place) Sauvegardes incrémentales Chiffrement authentifié et compression Support natif du SSH Grâce au projet Borg-UI, vous pouvez lui ajouter une interface web pour faciliter la configuration ! Source : GitHub - Borg-UI Quelques liens utiles : GitHub : borgbackup/borg Site officiel : borgbackup.org Papra est une plateforme d'archivage de documents minimaliste pour organiser vos archives personnelles ou professionnelles. Beaucoup plus légère que Paperless-Ngx, la solution Papra facilite le tri, le taggage et la recherche de documents numérisés ou importés. L'outil propose des fonctionnalités pratiques comme l'importation automatique depuis une boîte mail. Papra est développé par un Français, qui est aussi à l'origine de IT-Tools. Archivage et organisation par tags Recherche efficace dans les documents API, Webhooks et CLI disponibles Importation automatique par e-mail Quelques liens utiles : GitHub : papra-hq/papra Site officiel : papra.app Source : GitHub - Papra Sync-in est une solution de cloud privé qui met l'accent sur la collaboration et le partage sécurisé de fichiers. Chaque utilisateur dispose de son espace personnel (comme un Drive) pour stocker ses fichiers et y accéder depuis n'importe où. En tant qu'alternative à nextCloud, Sync-in permet aussi de créer des espaces de travail dédiés où plusieurs utilisateurs peuvent éditer et synchroniser des documents en ligne (via l'intégration d'OnlyOffice). Espaces collaboratifs (spaces) Édition en ligne multi-utilisateurs Applications officielles et prise en charge du WebDAV Recherche full-texte Visionneuse en ligne Partage via liens publics sécurisés Quelques liens utiles : Source : Sync-in.com CrowdSec est un système de détection d'intrusions (IDS) collaboratif qui protège vos serveurs en temps réel. Le principe est simple : lorsqu'une adresse IP attaque votre serveur, elle est bloquée sur votre serveur. Ce n'est pas tout, elle est aussi signalée à la communauté, permettant à tous les utilisateurs de se prémunir contre cette menace (s'il y a plusieurs signaux négatifs à son sujet). Pour aller plus loin, grâce à son modèle AppSec, il peut agir comme un WAF capable de sécuriser les services exposés. Détection et blocage d'IP malveillantes Logique communautaire (l'attaque de l'un protège les autres) que n'a pas Fail2ban Module AppSec pour le transformer en véritable WAF Console de Threat Intelligence Synchronisation des adresses IP bloquées entre plusieurs instances CrowdSec Quelques liens utiles : GitHub : crowdsecurity/crowdsec Site officiel : crowdsec.net IT-Connect : les tutoriels CrowdSec Audiobookshelf est un serveur multimédia spécialisé conçu pour gérer et diffuser vos collections de livres audio et de podcasts. Il propose une interface web dans le même style que Spotify et des applications mobiles qui synchronisent votre progression de lecture partout. C'est l'outil adéquat pour les amateurs de contenu audio ! On peut citer quelques fonctions clés : Applications pour Android & iOS Gestion de plusieurs utilisateurs Synchronisation de la progression de lecture Gestion avancée des métadonnées Interface utilisateur intuitive Voici quelques liens utiles : GitHub : advplyr/audiobookshelf Site officiel : audiobookshelf.org Source : GitHub - Audiobookshelf Netdata est un outil de monitoring en temps réel conçu pour offrir une visibilité immédiate et granulaire sur les performances de vos systèmes. On parle alors d'observabilité. Il adopte une approche Zero Config pour faciliter la découverte des services et collecte de nombreuses métriques, présentées dans des graphiques interactifs (et une superbe interface). Il vous permet de mieux comprendre vos systèmes. Monitoring en temps réel Tableau de bord interactif et moderne Plus de 800 intégrations disponibles Approche "Zero Config" avec alertes pré-configurées Quelques liens utiles : GitHub : netdata/netdata Site officiel : netdata.cloud Source : Netdata ChangeDetection.io est un outil de veille qui surveille les changements sur n'importe quelle page web. Que ce soit pour suivre l'évolution d'un prix, la disponibilité d'un produit en stock, la publication d'une nouvelle version (logiciel, pilote, etc.) ou la modification d'un texte sur une page, il vous notifie dès qu'une différence est détectée. Il supporte des scénarios complexes grâce à son intégration avec Playwright où il peut simuler l'exécution d'un navigateur Chrome. Quelques liens utiles : PatchMon est une solution dédiée à la surveillance de l'état des mises à jour de vos serveurs Linux. Il permet de visualiser en un coup d'œil quels serveurs nécessitent des correctifs, en mettant notamment en évidence les correctifs de sécurité. L'outil utilise des agents légers qui remontent l'inventaire des paquets vers un tableau de bord central (donc pas de port à ouvrir sur vos serveurs, puisqu'on pousse l'information vers le serveur PatchMon). Voici quelques liens utiles : GitHub : PatchMon/PatchMon Site officiel : patchmon.net Source : GitHub - PatchMon RustDesk est une solution de prise en main à distance open source codée en Rust. Vous l'aurez compris, c'est une alternative à TeamViewer ou AnyDesk. Sa particularité, c'est qu'il vous permet d'héberger votre propre serveur relais (Rendezvous Server), pour une meilleure confidentialité et surtout sans dépendre d'un tiers. Côté sécurité, les connexions sont chiffrées de bout en bout, garantissant la sécurité des sessions. On peut citer : Prise en main à distance (Windows/Mac/Linux) Applications mobiles et version portable Serveur auto-hébergeable pour une souveraineté totale Connexion P2P avec chiffrement de bout en bout Je l'avais présenté sur IT-Connect il y a quelques années, mais il faudrait que j'actualise mon contenu. Voici quelques liens utiles : GitHub : rustdesk/rustdesk Site officiel : rustdesk.com Source : RustDesk.com J'espère que cette sélection vous donnera des idées pour vos projets en 2026, que ce soit dans un contexte professionnel ou pour votre Home Lab. N'hésitez pas à tester ces outils ! J'envisage d'en présenter certains avec des articles dédiés et probablement des vidéos. Pensez à me dire en commentaire ceux que vous aimeriez voir présentés par mes soins sur IT-Connect ! Passez une belle fin d'année. Source : https://www.it-connect.fr/calendrier-de-lavent-2025-24-outils-open-source-a-decouvrir/