— Permalien

Les Linuxiens ont beau dire que Linux peut TOUT faire, ils gardent presque tous un dual-boot ou une VM Windows planquée quelque part pour lancer Photoshop ou remplir une page web administrative qui plante sous Firefox. C’est ça la définition du déni, les amis ^^.

Alors bien sûr, y’a Wine qui existe depuis plus de 20 ans, mais bon faut bidouiller des préfixes, installer des DLL manquantes, fouiller sur WineHQ et au final, c’est toujours du rafistolage à se taper.

Alors comme le fait Winapps , il y a aussi WinBoat , un outil capable de faire tourner un Windows dans un container Docker. Pas d’émulation, pas de traduction d’API, pas de prière à saint Wine pour que votre app se lance. Ça lance de vraies apps Windows !

Techniquement, WinBoat utilise donc Docker et KVM pour faire tourner Windows dans un container. Electron gère l’interface, FreeRDP se connecte à Windows via le protocole RemoteApp, et vos apps Windows apparaissent comme des fenêtres normales sur votre bureau Linux.

Vous cliquez sur une icône, hop, l’app se lance, et vous oubliez qu’il y a une VM qui tourne en arrière-plan.

L’installation de Windows est également automatisée. Vous lancez WinBoat, ça télécharge et configure tout, tout seul, et après c’est prêt. L’intégration filesystem permet d’accéder vos fichiers Linux depuis les apps Windows et le passthrough USB et smartcard fonctionne, ce qui règle le problème des signatures électroniques pour les démarches administratives dont je parle un peu plus haut.

Photoshop, Illustrator, InDesign, c’est clair que ces apps ne tourneront jamais correctement sous Wine parce qu’Adobe n’a jamais pensé son code pour être portable alors qu’avec WinBoat, elles tournent. Office 365 aussi, pour les boîtes qui imposent Teams et SharePoint. Ah et Affinity Photo pareil ça roule impecc aussi.

WinBoat assume quand même ses limites dès le départ car y’a pas de passthrough GPU pour le moment, donc les apps lourdes en 3D rameront. Pas de support non plus des jeux avec anti-cheat, mais le Steam Deck fait ça mieux de toute façon. Et notez qu’il vous faudra minimum 4 Go de RAM rien que pour WinBoat, parce qu’un Windows léger ça n’existe pas !

Le projet est open source sous licence MIT, gratuit, dispo en AppImage, .deb, .rpm, ou via AUR pour Arch. Docker CLI est obligatoire, mais pas Docker Desktop et FreeRDP 3.x.x avec le support son aussi. KVM aussi doit être activé sur votre système.

Bref, WinBoat c’est comme Winapps, très sympa à tester car ça marche très bien même si les perfs ne seront jamais celles d’un Windows natif. C’est dispo sur GitHub avec toute la doc si ça vous chauffe.

Merci à Lorenper pour le soft.

• lien nᵒ 1 : Le programme de la 12e édition
• lien nᵒ 2 : l'ensemble des interventions
• lien nᵒ 3 : notre mascotte aux habits de 2025
• lien nᵒ 4 : les speakers vu par notre Frank national
• lien nᵒ 5 : Kernel Recipes en photos
• lien nᵒ 6 : le live blog

Commentaires : voir le flux Atom ouvrir dans le navigateur

Vous faites du pentest, de la recherche en sécu ou vous êtes juste un curieux qui aime bidouiller des environnements de test ? Dans ce cas, il faut absolument que vous vous montiez un lab cybersécurité ! Mais c’est vai que c’est souvent la galère… Y’a Active Directory à configurer, des VMs Windows à déployer, des réseaux isolés à créer, tout ça manuellement… Ça prend des heures, voire des jours. Heureusement, Ludus règle le problème ! Vous décrivez ce que vous voulez dans un fichier YAML, vous tapez une commande, et hop, votre lab est prêt.

Ludus , c’est donc un système d’automatisation open-source qui tourne sur Proxmox. Vous définissez votre environnement de test (ce qu’ils appellent un “range”) dans un fichier de config, et Ludus s’occupe de tout déployer. Active Directory, machines Windows avec Office et Chocolatey, réseaux isolés, firewall rules personnalisées, DNS interne… Tout ce qu’il faut pour un lab de red team, blue team ou purple team.

Pulse est une solution de supervision centralisée permettant de suivre en temps réel l’ensemble d’une infrastructure Proxmox VE et PBS depuis un tableau de bord unique. L’outil envoie des alertes instantanées en cas de panne de nœud, d’échec de sauvegarde ou de saturation de stockage. Les notifications sont compatibles avec email, Discord, Slack, Telegram et […]

Et si votre serveur Linux était comme un appart en coloc où tout le monde partage la même cuisine, le même salon, les mêmes chiottes ?? Forcément, ça finit toujours mal avec quelqu’un qui monopolise les toilettes pendant que vous avez une urgence en spray, un autre fait crasher la machine à laver avec ses expérimentations douteuses de voyage dans le temps, et au final personne n’est content.

Hé bien figurez-vous qu’un développeur nommé Cong Wang de Multikernel Technologies vient de proposer une solution radicale qui consiste à donner à chaque processus son propre kernel Linux, avec ses propres core CPU, comme des colocataires qui auraient enfin chacun leur studio…

Selon le patch soumis sur la Linux Kernel Mailing List (LKML), cette architecture “multikernel” permettrait de faire tourner plusieurs noyaux Linux indépendants sur la même machine physique. C’est pas vraiment de la virtualisation classique façon VMware ou KVM, mais c’est plutôt comme si vous découpiez votre ordinateur en tranches et que chaque tranche vivait sa vie. Le truc marrant, c’est que Cong Wang n’est pas un petit nouveau qui débarque avec ses idées folles. Le bonhomme a déjà contribué à plus de 1000 patches au noyau Linux et il maintient le sous-système de traffic control . Autant dire qu’il sait de quoi il parle quand il touche au code du noyau.

D’ailleurs cette idée de séparer les kernels rappelle furieusement le projet Barrelfish que Microsoft Research et l’ETH Zurich avaient lancé il y a quinze ans. À l’époque, ils voulaient traiter l’OS comme un système distribué où chaque core CPU aurait son propre kernel qui communique avec les autres par messages. Sauf que voilà, c’était trop tôt. Les processeurs n’avaient pas assez de cores pour qu’on puisse se permettre ce genre de luxe, et puis franchement, qui avait besoin de ça en 2009 ?

Aujourd’hui avec nos CPU à 128 cores et nos problèmes de sécurité qui explosent, l’idée prend soudainement tout son sens.

Selon Phoronix et les patches sur la LKML, l’implémentation de Wang utilise kexec, ce mécanisme qui permet normalement de redémarrer directement dans un nouveau noyau sans repasser par un reboot. Sauf qu’ici, au lieu de remplacer le noyau existant, on en charge plusieurs qui vont cohabiter. Chaque kernel se voit attribuer ses propres cores CPU et ils communiquent entre eux via un système d’interruptions inter-processeurs (IPI) spécialement conçu pour l’occasion. Et dans les 7 patches proposés en RFC, Wang prévoit des mécanismes de surveillance pour gérer tous ces petits mondes parallèles.

Et pendant que Cong Wang bricolait son multikernel dans son coin, les géants du cloud comme Amazon, Microsoft et Google ont développé en parallèle une technologie appelée KHO ( Kexec HandOver ) qui permet de préserver l’état système lors du changement de kernel. En gros, ils veulent pouvoir mettre à jour le noyau Linux de leurs serveurs sans perdre les VMs qui tournent dessus. Sauf que si le multikernel de Wang fonctionne vraiment, ça pourrait rendre leur stack de virtualisation complètement obsolète.

Car pourquoi s’embêter avec des hyperviseurs complexes quand on peut juste donner à chaque workload son propre kernel ?

Le plus drôle dans tout ça, c’est que Wang admet candidement dans son RFC que pour l’instant, ça marche “que sur sa machine de dev avec des paramètres hardcodés”.

Maintenant si cette techno décolle, on pourrait voir des trucs assez dingues. Genre un kernel temps réel qui gère les processus critiques pendant qu’un kernel classique s’occupe du reste. Ou alors des kernels spécialisés pour différents types de workloads : un pour le machine learning, un pour les bases de données, un pour le réseau. Vous pourriez même imaginer des kernels avec différents niveaux de sécurité du genre un kernel ultra-paranoia pour vos données sensibles et un kernel plus relax pour Netflix. Et le plus beau c’est que si un kernel plante, les autres continuent de tourner tranquillement.

C’est comme avoir plusieurs systèmes de secours intégrés directement dans la machine.

Mais attention, on parle quand même d’une RFC, et pas encore d’un truc prêt pour la prod. La communauté des barbus du noyau va probablement passer des mois à débattre de chaque ligne de code, et c’est tant mieux parce que toucher à l’architecture fondamentale de Linux, c’est pas comme patcher un bug dans Firefox. Si ça merde, c’est potentiellement des millions de serveurs qui partent en vrille.

Au final, que ce patch soit accepté ou pas, ça montre surtout que Linux continue d’évoluer de manière radicale pour toujours aller plus loin ! Et si vous l’évolution de ce projet, tout se passe sur la LKML .

Source

Lorsqu’on déploie un cluster Ceph, il est essentiel de comprendre les performances du ou des pools. Que ce soit pour des VMs, du stockage objet ou du backup, mesurer le débit, les IOPS et la latence permet d’identifier les goulots d’étranglement et d’optimiser la configuration. Comment créer un benchmark d’un pool Ceph sur Proxmox et […]

Lors du déploiement de l’image KVM d’OpenManage Enterprise proposée par Dell, tout fonctionne correctement… jusqu’à l’installation de plugins. À ce moment-là, malgré une partition système d’environ 400 Go, l’interface web affiche une erreur indiquant que l’espace disque disponible est insuffisant. Ajouter de l’espace disque à la VM Sous Proxmox voir le chapitre « Agrandir l’espace disque […]

Un petit mémo sur comment automatiser l’affichage de l’OS d’une VM dans la partie note de Proxmox. Par défaut, l’interface graphique n’affiche pas cette information : on y retrouve le nom de la VM, son ID, ses ressources, mais pas le système invité. Heureusement, il est possible de récupérer et d’afficher la version de l’OS […]

— Permalien

— Permalink

— Permalink

Alors là, c’est le genre de nouvelle qui fait plaisir ! Canonical vient de rendre Multipass, leur gestionnaire de machines virtuelles Ubuntu, 100% open source. Fini les bouts propriétaires cachés, on peut maintenant fouiller dans absolument tout le code !

Bon, je sais que vous connaissez déjà Multipass. C’est cet outil génial qui vous pond une VM Ubuntu en une seule commande. Super pratique pour tester des trucs sans pourrir votre système principal, ou pour simuler des environnements cloud en local. Mais jusqu’à maintenant, il y avait un hic : une partie du code tournant sur Windows et macOS était encore propriétaire. Et ça, ça faisait grincer des dents dans la communauté.

Un développeur du nom de Petr Beneš vient de partager une technique absolument brillante pour faire croire à une machine virtuelle qu’elle a un ventilateur CPU. Oui, un ventilo virtuel dans une VM.

Mais pourquoi diable faire ça, vous allez me dire ?

Eh bien figurez-vous que les créateurs de malwares sont devenus super malins ces dernières années. Pour éviter que leurs petites saloperies soient analysées par les chercheurs en sécurité, ils ont développé tout un tas de techniques pour détecter si leur code s’exécute dans une machine virtuelle.

Ce mémo décrit les étapes pour déployer Dell OpenManage Enterprise dans une VM sur Proxmox. Descriptif d’OpenManage Enterprise Dell OpenManage Enterprise est une console centralisée de gestion d’infrastructure, conçue pour simplifier l’administration des serveurs Dell PowerEdge. Fonctionnalités clés : Supervision centralisée des serveurs physiques Dell (firmware, matériel, alertes). Mise à jour groupée des BIOS, firmwares […]