Ldfa

Korben pour cette info que je ne connaissais pas, je découvre également ahrefs. J'espère que ça comptera pour un bon Backlink.

Korben Publié le 13 mars 2026 Par Korben, Manuel Dorne korben.info Environ 5 minutes de lecture Le SEO poisoning, vous connaissez ? C'est quand votre référencement se fait flinguer parce que votre site se retrouve associé à des sites de casino, de porno et de téléchargement illégal. Et devinez quoi... ça m'arrive depuis bientôt un an ! Tout a commencé l'année dernière quand un nom de domaine reprenant mon pseudo a été enregistré depuis la Chine. Un clone quasi parfait de korben.info, avec tout mon contenu aspiré, sauf que tous les liens avaient été remplacés par des redirections frauduleuses. Mon Patreon, mon Twitter, ma newsletter, mes liens Twitch... tout renvoyait vers des trackers douteux. En fait, ça a été fait via un service de clonage de sites à quelques yuans par mois (genre 50 yuans, soit 6 euros), capable d'aspirer l'intégralité des pages HTML, CSS, images et même l'ID Google Analytics. Sympa ! Hasard du scrapping, ils ont chopé ma version spéciale Pluribus que j'avais mise en ligne à l'époque. Sur le coup, quand je m'en suis rendu compte, j'ai signalé le truc au registrar et j'ai attendu. Naïvement, je pensais que ça resterait un cas isolé. Par contre, attention... c'était juste l'apéro. Car en décembre, ça s'est sérieusement accéléré. D'un coup, c'est pas un mais plusieurs réseaux distincts de sites qui se sont mis à publier du contenu m'associant à tout et n'importe quoi. Je vous parle de dizaines et de dizaines de sites, des .fr pour la plupart, montés de toute pièce avec du contenu bidon. Et là, bienvenue dans le monde merveilleux des PBN. Un PBN, c'est un Private Blog Network. En gros, un ensemble de sites web qui ont l'air indépendants mais qui sont contrôlés par la même personne. À la base, ça sert à créer des backlinks pour faire monter un site dans les résultats de référencement naturel . Ça peut être utilisé de manière plus ou moins légitime pour booster sa visibilité. Mais ça peut aussi servir à démolir celle des autres, en les noyant sous des liens toxiques, en les mélangeant avec des sites de casino en ligne, de contenus pour adultes ou de téléchargement illégal. Et c'est exactement ce qui arrive à mon site en ce moment. Concrètement, dans mon cas, ça fonctionne de deux manières. La première, c'est du cloaking. Ces sites présentent à Googlebot du contenu qui reprend mes meta descriptions, mon nom, mon contenu... sauf que quand un vrai visiteur clique dessus depuis Google, il tombe sur une fausse page RedTube. Du porno, quoi. L'idée c'est que Google finisse par associer korben.info à du contenu pour adultes. La deuxième technique, c'est de noyer mon nom dans du contenu qui n'a rien à voir avec la tech. Des articles, des liens vers des casinos... Le but c'est que Google se dise "ah mais en fait korben.info c'est pas un média tech", et que ma thématique soit complètement diluée dans les résultats de recherche. Du coup, depuis 4 mois, mon quotidien c'est ça : contacter Google pour signaler les domaines frauduleux, écrire aux registrars pour faire fermer les noms de domaine, relancer les hébergeurs pour couper les serveurs. À vrai dire, entre les mails aux registrars, les formulaires abuse et les captures d'écran pour les dossiers, je passe 2-3 heures par jour là-dessus au lieu d'écrire des articles. J'ai même déposé des signalements auprès de la police. Première fois en 20 ans de blog que j'en arrive là ! Heureusement, à force de creuser, mes capacités en OSINT m'ont permis de cartographier tout le réseau : les connexions entre les sites, les gens qui se trouvent derrière... j'ai tout. Mais tant que les procédures sont en cours, je garde ça pour moi. Je ne peux pas vous mettre les captures d'écran les plus croustillantes de toute cette opération dont je suis la victime, j'en suis désolé... Et le problème, c'est que tous les jours, y'a des nouveaux qui apparaissent. Des .fr, des .site, des .website, des .online... Dans mon fichier disavow.txt sur la Search Console de Google, j'ai inscrit +93 domaines à rejeter. Le disavow, pour ceux qui connaissent pas, c'est un fichier que vous soumettez à Google pour lui dire "ces liens qui pointent vers mon site, ignore-les, c'est pas moi". Google dit que ses algorithmes détectent et ignorent déjà la plupart des liens toxiques automatiquement, mais le disavow reste une précaution supplémentaire. Sauf que quand vous voyez la liste s'allonger tous les jours, ça rassure pas des masses. Vous le savez, le SEO c'est pas trop le domaine dans lequel je brille . Du coup, me retrouver sur mon ordi à éplucher des rapports WHOIS, des logs et des exports CSV de backlinks toxiques, c'est vraiment pas mon kiff. Et franchement, ça me fait flipper parce que mon site, c'est 20 ans de boulot et si demain il se fait blacklister ou noyer dans du contenu pourri, je perds une part de mon trafic... voire plus. Et comme Korben c'est littéralement ma vie, mon identité, c'est tout ce que j'ai. Le truc dingue aussi, c'est que ces techniques datent du début des années 2010. C'est du old school mais bon, on s'y fait pas. J'ai l'impression de vider la mer avec une cuillère. Le problème c'est que ça ne s'arrête jamais. Vous en fermez 5, il en apparaît 10 !!! Maintenant, si vous êtes dans le même cas, voici ce que vous pouvez faire. D'abord, surveillez vos backlinks via la Search Console ou des outils comme Ahrefs . Attention, ne regardez pas forcement que les nouveaux liens, vérifiez aussi les anciens qui auraient pu changer de destination. Si vous repérez des domaines louches qui pointent vers votre site, créez un fichier disavow.txt et soumettez-le à Google. Ensuite, signalez les sites frauduleux aux registrars (les infos sont dans le WHOIS) et aux hébergeurs. Et si c'est grave, n'oubliez pas le signalement auprès de la police ou de la gendarmerie via cybermalvaillance. Ça crée une trace officielle, même si les suites judiciaires prennent du temps. Bref, si parmi vous il y en a qui veulent me mettre un lien vers korben.info depuis leur site ou leur blog, reprendre un de , un mot sur les réseaux... ça m'aiderait. Chaque backlink sain aide à contrebalancer la merde ❤️. 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

Bon, je vais faire un peu le point sur Arc Raiders. J'en suis à 155 heures de jeu, j'ai atteint le niveau 75 maxi sans déclencher l'expédition, qui réinitialise pas mal de chose... Je ne suis pas décidé à me lancer dans la prochaine expédition, je n'en vois pas vraiment l'intérêt.

A la suite de cet article : Je viens juste de recevoir mon Cheap Yellow Display, commandé avant le 1 mars 2026, donc sans la taxe de 2€ supplémentaire et pour un peu moins de 10€. Je l'ai commandé pour pouvoir essayer de développer sur ESP32, après ma découverte de la Maison connectée Keyestudio KS5009. Cette carte est équipée d'un écran tactile de 2.8 pouces, elle dispose d'un port micro USB et d'un port USB-C, ainsi que de ports d'entrées/sorties : Je découvre juste, mais ça semble vraiment très intéressant.

Korben Publié le 11 mars 2026 Par Korben, Manuel Dorne korben.info Environ 2 minutes de lecture Un développeur a créé Galagino, un émulateur open source qui fait tourner Pac-Man, Galaga, Donkey Kong et trois autres classiques de l'arcade sur un simple microcontrôleur ESP32. Le projet est gratuit, le code est sur GitHub, et avec quelques composants et une imprimante 3D vous fabriquez votre propre mini borne pour presque rien. Six jeux d'arcade sur une puce à quelques euros Galagino est un projet open source développé par Till Harbaum. Le principe : émuler des jeux d'arcade des années 80 sur un ESP32, cette petite puce à double coeur cadencée à 240 MHz qui coûte une poignée d'euros. Et ça ne rigole pas côté catalogue, puisque six titres sont pris en charge : Galaga, Pac-Man, Donkey Kong, Frogger, Dig Dug et 1942. L'émulation est complète, avec le son et la vidéo, le tout affiché sur un petit écran TFT de 320 x 240 pixels en 2 à 3 pouces. Pour les contrôles, cinq boutons poussoirs suffisent, ou un joystick si vous préférez. Le Galaga d'origine tournait sur trois processeurs Z80 plus deux puces dédiées aux entrées et au son. Ici, l'ESP32 gère tout seul, et les deux coeurs sont quand même bien sollicités. Le Cheap Yellow Display, la solution tout-en-un Pour ceux qui ne veulent pas souder trop de composants, il existe une alternative bien pratique : le Cheap Yellow Display. C'est une carte ESP32 qui intègre l'écran tactile, un slot micro SD, la sortie audio et le module Wi-Fi dans un seul boîtier. Il suffit d'y brancher une manette Nunchuk de Wii et un petit haut-parleur pour avoir une borne fonctionnelle. La communauté a aussi développé des boîtiers imprimés en 3D, et certains ont même recyclé des coques de mini bornes My Arcade du commerce pour y glisser la carte. Tout le code, les fichiers 3D et les instructions de montage sont disponibles sur GitHub. Seul détail : les ROM des jeux ne sont pas incluses pour des raisons évidentes de licence, il faut les fournir vous-même. Un projet qui vit bien Le dépôt GitHub compte 186 commits et une communauté active qui continue d'ajouter des jeux comme Frogger, Dig Dug et 1942, et des contributeurs travaillent sur d'autres titres. Davide Gatti, du collectif Survival Hacking, a même porté le projet sur Arduino et publié un tuto vidéo complet pour fabriquer sa borne de A à Z. Le résultat tient dans la paume de la main, avec en option un éclairage LED pour le fronton, histoire de faire comme les vraies. https://www.youtube.com/watch?v=a3-wctRAIds C’est trop chouette, et c’est exactement le genre de projet qui donne envie de ressortir le fer à souder. Pour quelques euros de composants et un week-end de bricolage, vous repartez avec une borne d'arcade de poche qui fait tourner Pac-Man et Donkey Kong. Difficile de faire plus chouette en termes de rapport effort/résultat. Et puis le fait que la communauté continue d'ajouter des jeux montre que le projet a de beaux restes devant lui. En tout cas, si vous cherchiez une excuse pour acheter un ESP32, la voilà. Source : Hackster 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

Je termine Platine pour la 1ère semaine de la saison 9.

Je termine encore Platine cette semaine.

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

Changements principaux : Maxthon PC 7.5.2.5801 : * Mise à jour du noyau vers la version 140.0.7339.210, apportant des améliorations de performances et des optimisations de la mise en page, ainsi que des outils de développement remaniés. + Ajout d'une poignée de déplacement pour déplacer la fenêtre d'édition des notes. Ajout du tri des résultats de recherche Maxnote par date et par titre. + Ajout de la fonction d'impression Maxnote. + Ajout d'une fonctionnalité de barre latérale dynamique : permet d'ajouter des icônes d'outils à la barre latérale et d'ouvrir des panneaux dans celle-ci. * Prise en charge de la lecture vidéo HDR en couleurs réelles. * Interaction de zoom de page optimisée : prise en charge d'un rapport de zoom personnalisé. Cliquez à gauche du bouton de zoom pour modifier le rapport. * Extensions mises à jour vers la version V3, offrant un environnement d'exécution des extensions plus sûr et plus efficace. - Correction du problème de chargement des avatars dans le menu principal. - Correction des plantages connus. Maxthon PC 7.5.2.5800 : - Correction d'un problème où le bouton des signets de la barre d'outils n'affichait pas tous les signets. - Correction d'un problème où la page du nouvel onglet ne pouvait pas télécharger les fonds d'écran. - Correction d'un problème où le glissement d'autres signets vers le haut dans la barre de signets n'était pas valide. - Correction de plantages connus.

Maxthon 7.5.2.5801 stable pour Windows est sorti 16/03/2026, il apporte son lot de nouvelles fonctionnalités, d'améliorations et de corrections de bugs. Téléchargement : https://github.com/maxthon/Maxthon/releases/ Les changements en français sont là. Vous pouvez également vous abonner au groupe Telegram NBdomain & MX6 pour faire remonter vos demandes d'améliorations et bugs rencontrés. Source : https://forum.maxthon.com/d/3724-maxthon-pc-7525801

On en avait déjà parlé ici en 2015 : Ça ne nous rajeunit pas !

Geeek.org Publié le 6 mars 2026 Par Ludovic Toinel geeek.org Environ 3 minutes de lecture Vous venez d'installer Windows 11 en suivant mon précédent article ? Félicitations, vous avez un système tout neuf ! Mais avant de commencer à l'utiliser, il reste une étape cruciale : faire le ménage dans la collecte de données. Quelles sont les données que Windows 11 collecte ? Si vous ne voulez pas que vos habitudes d'utilisation finissent sur les serveurs de Microsoft, il existe un outil indispensable, bien que son nom soit un petit défi à l'écriture : O&O ShutUp10++. Par défaut, une installation fraîche de Windows 11 active un nombre impressionnant de mécanismes de collecte : 📡 Télémétrie — Vos données d'utilisation, crashs et comportements envoyés en continu à Microsoft. 📍 Géolocalisation — Position GPS accessible par les apps Windows et les services Microsoft. ⌨️ Saisie & frappe (keylogging) — Journalisation de votre écriture manuscrite et de vos frappes clavier à des fins "d'amélioration". 🎯 Publicités ciblées — Un identifiant publicitaire unique vous suit à travers les applications du Windows Store. 🎙️ Cortana & voix — Vos interactions vocales et historique de recherche alimentent les modèles IA de Microsoft. 🔄 Synchronisation cloud — Mots de passe, activité et historique de navigation synchronisés vers votre compte Microsoft. Un très bon épisode de l'émission d'Underscore présente Un scanner pour vos paramètres cachés Sous ses airs de logiciel ultra-minimaliste, O&O ShutUp10++ liste l'intégralité des réglages de confidentialité enfouis au plus profond de Windows. Rien ne lui échappe. Là où Microsoft vous force à parcourir des dizaines de menus pour désactiver ces options, ShutUp10++ centralise tout sur une seule et même page. Ce que Windows vous cache en 2 heures de navigation dans les paramètres, ShutUp10++ vous l'expose en 2 minutes. ✅ Avantage clé : Le logiciel est 100% portable — aucune installation requise. Comprendre le code couleur Chaque option est associée à une couleur qui indique le niveau de risque : Couleur Signification Conseil 🟢 Vert Option sans risque, recommandée par O&O Activez sans hésiter 🟡 Jaune Impact possible sur certaines fonctionnalités Activez en sachant ce que vous faites 🔴 Rouge Peut perturber des fonctions importantes de Windows Réservé aux utilisateurs avancés Deux approches selon votre "degré de paranoïa" 🔬 La méthode chirurgicale Vous parcourez la liste option par option et cochez manuellement ce que vous souhaitez bloquer, guidé par le code couleur. ✓ Points forts : Contrôle total, vous comprenez chaque paramètre. ⚠ Point faible : Plus long (15 à 30 minutes) ☢️ La méthode "Nucleaire" Via le menu Actions → Appliquer tous les réglages recommandés, vous blindez votre système en un seul clic. ✓ Points forts : Rapide et efficace (2 minutes), idéal pour les débutants ⚠ Point faible : Certaines options jaunes/rouges sont activées sans distinction et peuvent potentiellement faire planter votre système. Dans mon cas, j'ai désactivé toutes les options rouge via cette méthode. Mon système n'a pas planté. Guide pas à pas : 5 minutes chrono Étape 1 — Télécharger l'outil Rendez-vous sur le site officiel d'O&O Software et téléchargez ooshutup10.exe. C'est gratuit, sans inscription. Étape 2 — Créer un point de restauration Au lancement, ShutUp10++ vous propose de créer un point de restauration. Ne passez pas cette étape ! C'est votre filet de sécurité si une option désactivée vous cause des problèmes plus tard (synchronisation du calendrier, Windows Update, etc.). Étape 3 — Appliquer les réglages Utilisez le menu Actions → Appliquer tous les réglages recommandés pour un résultat immédiat, ou parcourez la liste manuellement selon vos préférences. Étape 4 — Redémarrer Windows Certaines modifications nécessitent un redémarrage pour être pleinement appliquées. Faites-le dès que possible. Étape 5 — Relancer après chaque mise à jour majeure Windows Update réactive parfois certaines options de collecte. Pensez à relancer ShutUp10++ après chaque mise à jour de fonctionnalités (ex : 24H2, 25H1…). En résumé O&O ShutUp10++ est gratuit, léger et redoutablement efficace pour transformer Windows 11 en un système un peu plus respectueux de votre vie privée. Un must-have à lancer à chaque nouvelle installation ou mise à jour majeure. 👉 Télécharger O&O ShutUp10++ gratuitement Pour aller plus loins dans la protection de vos données, je vous conseille la lecture de mon article dédié sur AdGuard Home, un serveur DNS local qui permet de vous protéger des entrées DNS malvaillantes sur Internet. Lire d'autres articles de cet auteur Ludovic Toinel Geeek.org est un blog 100% indépendant depuis 21 ans. Passionné de web, dev et tech, il réunit plus de 20k lecteurs sur le feed RSS et 90k visites mensuelles. Abonnez-vous ! Afficher l’article complet

Je termine encore Platine cette semaine ici aussi.

Ça m'étonnerait fort malheureusement...

Je termine encore Platine cette semaine.

Un test avant la sortie officielle de demain en français.

Demain, c'est la sortie de la saison 9, une très grosse MAJ en perspective, entièrement gratuite avec énormément de nouveautés. J'ai hâte !!!

Changements principaux : * Optimisation de la fonction UUMail dans la barre latérale, améliorant la commodité de la gestion des alias d'e-mails. - Correction d'un problème empêchant le glissement des groupes de balises. - Correction d'un problème empêchant Maxnote d'ouvrir toutes les URL d'un dossier. - Correction d'un problème empêchant l'ouverture des onglets copiés à l'emplacement prédéfini. - Correction d'un problème entraînant la disparition des signets lors de leur glissement si le menu n'était pas fermé. - Correction d'un problème empêchant la lecture des vidéos sur certains sites Web et affichant une erreur « Flash non installé ». - Correction de plantages connus.

Maxthon 7.5.2.5600 stable pour Windows est sorti aujourd'hui, il apporte son lot de nouvelles fonctionnalités, d'améliorations et de corrections de bugs. Téléchargement : https://github.com/maxthon/Maxthon/releases/ Les changements en français sont là. Vous pouvez également vous abonner au groupe Telegram NBdomain & MX6 pour faire remonter vos demandes d'améliorations et bugs rencontrés. Source : https://forum.maxthon.com/d/3595-maxthon-pc-7525600

C'est la 1ère fois que je fais un tel score dans le Custom Show. Je termine Platine cette semaine ici aussi, c'était plus facile que la semaine dernière...

Je termine encore Platine ici cette semaine.