Lateo.net - Flux RSS en pagaille (pour en ajouter : @ moi)

🔒
❌ À propos de FreshRSS
☷
△ 🔃
Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
Hier — 23 octobre 2026Informatique & geek
À partir d’avant-hierInformatique & geek

Nvidia’s OCP Moves Highlight How Openness Can Help Scale AI

Par : Zeus Kerravala

At the 2026 OCP Global Summit, Nvidia opened up its Vera Rubin rack designs, released open-source AI factory software, and announced plans with Cisco for a new pluggable-optics specification. Here's why openness has become a scaling requirement, and what IT pros should do about it.

The post Nvidia’s OCP Moves Highlight How Openness Can Help Scale AI appeared first on TechRepublic.

Nvidia Run Is Now Open Source: What’s Free and Paid

Par : TechRepublic Staff

Nvidia has made its complete Run:ai GPU orchestration platform open source. Here's what's free, which support options cost money, and what IT teams still need to operate.

The post Nvidia Run Is Now Open Source: What’s Free and Paid appeared first on TechRepublic.

Tart - Une VM Windows 11 jetable sur votre Mac

Par : Korben ✨

Windows 11 dans une machine virtuelle sur un Mac Apple Silicon, ça se fait depuis looooongtemps avec des outils comme Parallels ou UTM. Mais tart, l'outil en ligne de commande qui crée et clone des VM comme on le ferait avec des conteneurs, n'en est pas capable, parce que la virtualisation d'Apple sur laquelle il repose ne gère officiellement que macOS et Linux.

Sauf qu'un dev nommé Mustafa Akin, vient de publier un fork qui permet d'installer Windows 11 avec tart sans un seul clic.

Je viens de le tester sur mon Mac Studio M4 Max avec l'ISO française de Windows 11 et j'ai trouvé que ça fonctionnait super, d'où ce petit tuto.

Ce qu'il vous faut avant de commencer

Pour vous lancer là dedans, il vous faut donc un Mac Apple Silicon sous macOS 26.6 ou 27, Xcode pour compiler tout ça, et bien sûr une ISO de Windows 11 ARM64 ( faudra vous démerder ensuite avec la licence ). Par contre, faut le savoir, ce fork repose sur deux réglages privés d'Apple, non documentés, qu'une mise à jour de macOS pourra shooter à tout moment. Donc ne montez pas votre futur homelab là dessus sans un plan de repli.

Compiler tart et créer la VM

Sur son site, Mustafa Akin publie un binaire tout fait, mais j'ai préféré compiler le programme car le script de création du paquet de son fork signe proprement l'application en local avec le droit de virtualisation qui va bien.

git clone --branch windows-guest-extras https://github.com/mustafaakin/tart.git
cd tart
git checkout e4c623c
./scripts/package-windows-preview.sh 0.1.0-windows-preview
export PATH="$PWD/dist/windows-preview/tart.app/Contents/MacOS:$PATH"

La commande export rend ce tart.app accessible au niveau du système prioritaire devant un éventuel tart déjà installé. Il ne reste alors qu'à lui passer votre ISO... tart téléchargera alors les pilotes virtio-win et WinFsp, fabriquera son propre média d'installation et démarrera Windows sans rien demander de plus.

tart create win11 --from-iso ~/Downloads/Win11_Arm64.iso

Ça m'a pris en tout et pour tout 26 minutes pour obtenir cette VM Windows fonctionnelle. Notez également que l'installation force l'anglais américain et que d'autres langues peuvent poser souci mais avec mon ISO française, l'interface est bien restée en français. Seul le clavier est resté en QWERTY au départ.

Installer le pilote et l'agent à la mano

L'auteur écrit sur son blog que l'install de l'agent doit se faire manuellement pour l'instant mais ce qu'il a oublié de préciser c'est que le pilote viosock, celui qui relie le Mac à la VM, n'est pas dans la liste des pilotes que tart injecte (viostor, viogpudo, NetKVM, viorng et viofs). Résultat, chez moi, tart exec ne fonctionnait pas. Comme ce pilote se trouve dans l'ISO virtio-win que tart a gardée dans son cache, il suffit donc de le copier dans un dossier partagé, contenant l'agent publié avec la préversion :

hdiutil attach -readonly -nobrowse ~/.tart/cache/windows/sha256:303f7ae40dad495d6ae474fdc571df58958a4dbc5c37a522d80f9a203867949d.iso
mkdir -p ~/tart-share
cp -R /Volumes/virtio-win-0.1.302/viosock/w11/ARM64 ~/tart-share/viosock
hdiutil detach /Volumes/virtio-win-0.1.302
curl -L -o ~/tart-share/tart-guest-agent.exe https://github.com/mustafaakin/tart/releases/download/windows-preview-0.1.0/tart-guest-agent.exe
tart run win11 --dir=share:$HOME/tart-share

Comme la commande tart run garde la main, laissez-la tourner et ouvrez un second terminal pour la suite, en y refaisant l'export ci-dessous depuis le dossier tart, sinon vous appellerez un autre tart.

export PATH="$PWD/dist/windows-preview/tart.app/Contents/MacOS:$PATH"

Au démarrage, la session admin (mot de passe admin) s'ouvre alors toute seule et vous arrivez sur le bureau. Le dossier partagé apparaît sur le lecteur Z:, dans un dossier share. Ouvrez PowerShell en administrateur (et n'oubliez pas que le clavier est en QWERTY) pour installer le pilote, puis déclarer l'agent comme tâche lancée à l'ouverture de session, parce que c'est dans cette session que sont le presse-papiers et le bureau :

pnputil /add-driver Z:\share\viosock\viosock.inf /install
mkdir "C:\Program Files\Tart"
copy Z:\share\tart-guest-agent.exe "C:\Program Files\Tart\"
$a = New-ScheduledTaskAction -Execute "$env:SystemRoot\System32\conhost.exe" -Argument '--headless "C:\Program Files\Tart\tart-guest-agent.exe" --run-agent'
$t = New-ScheduledTaskTrigger -AtLogOn -User $env:USERNAME
$s = New-ScheduledTaskSettingsSet -ExecutionTimeLimit ([TimeSpan]::Zero) -RestartCount 999 -RestartInterval (New-TimeSpan -Minutes 1)
$p = New-ScheduledTaskPrincipal -UserId $env:USERNAME -LogonType Interactive -RunLevel Highest
Register-ScheduledTask -TaskName "Tart Guest Agent" -Action $a -Trigger $t -Settings $s -Principal $p
Start-ScheduledTask -TaskName "Tart Guest Agent"
Get-Service VirtioSocketWSP

Le service VirtioSocketWSP doit alors afficher Running. S'il n'existe pas, c'est que le pilote n'est pas passé et tart exec ne répondra pas. Relisez alors la sortie de pnputil et vérifiez que le dossier viosock contient bien viosock.inf.

Vérifier que le terminal de Windows répond

Retournez ensuite dans le terminal du Mac et entrez cette commande pour connaitre le numéro de version du Windows :

tart exec win11 cmd /c ver
Microsoft Windows [version 10.0.26200.8037]

Informations système dans la VM : Windows 11 Famille, build 26200, sur une "Apple Virtualization Generic Platform" en ARM64

L'intérêt de tout ça c'est surtout d'avoir un Windows jetable. Vous devez arrêtez d'abord la VM de base avec tart exec win11 shutdown /s /t 0 puis pour cloner la VM, faites un : tart clone win11 w1 . C'est instantané, et y'a plus qu'à la démarrer avec un tart run w1 --no-graphics.

Avec --no-graphics ça démarre sans fenêtre et vous pouvez alors lancer ce que vous voulez avec tart exec. Ensuite pour tout stopper, un petit tart stop w1, et un tart delete w1 pour supprimer la VM et voilà...

Ce qui ne marche pas

En tout cas, n'en faites pas votre Windows de tous les jours car il n'y a ni son ni accélération graphique, pas de possibilité de suspendre le Windows et la virtualisation imbriquée se fige dès que Windows veut démarrer WSL2 ou Hyper-V.

La commande Get-Tpm confirme aussi l'absence de TPM. Et selon l'auteur, le disque est le point faible de ce Windows ARM 64 sous tart, en partie parce que tart rempli très vite les SSD avec ses logs. Pensez aussi à changer le mot de passe, puisque le compte est admin avec le mot de passe admin, et que SSH est ouvert sur le réseau interne de tart.

Mais pour tester des logiciels Windows ou scripter des trucs, ça tient bien la route.

Source : Mustafa Akin

Conteneurs Linux - Quand l'isolation ne tient plus

Par : Korben ✨

La société de sécurité Depthfirst a publié un billet que j'ai trouvé intéressant dans lequel ils expliquent en gros que les conteneurs (Docker et compagnie) ne sont plus une barrière de sécurité suffisamment solide. La thèse du papier, c'est qu'il faut désormais partir du principe qu'un attaquant (hacker ou malware) saura sortir d'un conteneur quand il le veut, sans grande difficulté.

En effet, un conteneur comme ceux que font tourner Docker ou Kubernetes, donne à un programme l'impression d'avoir sa propre machine. Sauf qu'en réalité, il n'embarque pas de système d'exploitation. Tous les conteneurs d'un serveur passent par le même noyau Linux qui est celui de l'hôte et dont le rôle est de gérer pour eux la mémoire, le processeur ainsi que le réseau.

Toutefois, beaucoup d'organisateurs de CTF notamment s'y fient les yeux fermés et hébergent plusieurs épreuves sur le même serveur, chacune dans son conteneur, en comptant uniquement sur la sécurité de l'hôte. Mais c'est un faux sentiment de sécurité, j'en veux pour preuve ce bulletin de sécurité d'AWS daté de novembre 2025 où il est expliqué que l'entreprise ne considère plus les conteneurs comme une barrière de sécurité et ne s'en sert donc plus pour isoler ses clients les uns des autres.

Ce qui a changé depuis quelques mois, vous le savez, c'est le prix d'entrée de la recherche de failles puisqu'avec les modèles d'IA de pointe, même un attaquant avec des moyens modestes peut fabriquer sans effort, dès la publication d'une faille, un exploit contre des machines qui ne sont pas encore corrigées, alors qu'avant ça demandait de sérieuses compétences.

source : Depthfirst

Et les chiffres publiés par Depthfirst montrent que tout ça s'accélère puisque 249 CVE ont été publiées pour le noyau Linux en janvier, et en août on en a eu 1 650 !

Depthfirst relève également que sur les 36 CVE divulguées via le kernelCTF de Google, 13 sont réalisables via des interfaces ordinaires comme celles qu'un conteneur reçoit par défaut (dont les sockets locaux). En fait, on en croise sans le savoir dès qu'on passe systemd, Docker ou une base de données locale.

Le 24 juillet dernier, Depthfirst a même décroché une place au kernelCTF avec un exploit 0day (donc avant tout correctif) et aujourd'hui, le PoC est en accès libre sur GitHub. Rassurez-vous, côté noyau Linux, le correctif est sorti le 6 août mais malheureusement, côté Ubuntu la mise à jour au 24 septembre, affichait encore que le noyau de la 26.04 était en "Vulnerable, work in progress" et celui de la 24.04 en "Vulnerable". Bref, trouver des vulns ça va vite. Fixer ces vulns sur TOUTES les releases et les machines, ça prend du temps. Alors qu'avant c'était l'inverse. Bref, tout a été chamboulé et c'est un peu la merde maintenant niveau cybersécurité pour patcher rapidement.

Alors comment se protéger de tout ça ?

Hé bien la solution de Depthfirst va vous mettre en PLS car eux proposent carrément de ne plus partager le noyau. Ils recommandent à la place de migrer les charges non fiables vers des microVM, autrement dit des machines virtuelles légères où chaque charge aura son propre noyau. Le projet Firecracker en fait partie tout comme Kata Containers comme ça, en théorie, si un attaquant casse l'un de ces noyau, il ne compromet que sa propre instance et pas l'hôte dans son entièreté ni ses voisins.

Reste que Firecracker s'appuie sur KVM, la brique de virtualisation du noyau Linux de l'hôte. Et comme vous le savez, KVM a eu ses propres failles. En effet, cet été, la faille Januscape ouvrait en grand la porte de la machine physique à un attaquant pourtant enfermé dans sa VM, à condition bien sûr que l'hôte autorise la virtualisation imbriquée (une VM dans la VM). Alors certes, la surface d'attaque est plus petite mais loin d'être nulle.

Voilà, en attendant, si vous êtes sous Ubuntu 24.04 ou 26.04, surveillez bien la mise à dispo du prochain noyau. Canonical a d'ailleurs annoncé il y a peu, une publication hebdomadaire des noyaux pour tenter de compenser cet emballement.

Source : le billet de recherche de depthfirst

Floci - L'émulateur AWS open source qui tourne en local

Par : Korben ✨

Si vous développez pour AWS, il y a de bonnes chances que LocalStack tourne déjà quelque part dans votre docker-compose ou votre CI. C'est un peu l'outil incontournable pour tester ses buckets S3 et ses fonctions Lambda sans avoir à toucher au vrai cloud. Sauf que depuis mars dernier, ses nouvelles versions exigent un compte LocalStack et un jeton d'authentification, CI comprise, et surtout l'édition Community n'est plus prise en charge.

Ouin !

Et comme si ça ne suffisait pas, l'offre gratuite qui reste interdit totalement l'usage commercial. Donc si vous l'utilisez dans le cadre de votre travail, faudra passer à la caisse. Alors, oui, ne pas respecter la licence ou se figer sur une ancienne image reste possible, mais déjà, ça ne se fait pas, et ensuite, niveau faille de sécu, ce n'est pas top.

Mais c'est là qu'arrive en sauveur Floci, un émulateur AWS local sous licence MIT qui se présente comme un remplaçant direct de LocalStack, sans avoir besoin de se créer un compte ou un jeton et surtout sans offre payante planquée dedans.

Maintenant, le principe reste le même puisque vous pointez dessus l'AWS CLI (Floci écoute sur le port 4566), vos SDK, Terraform, OpenTofu ou le CDK, avec la région de votre choix et des identifiants bidon, et vos commandes habituelles tomberont sur votre machine au lieu de partir chez Amazon.

Le plus simple pour démarrer, c'est sa CLI qu'on peut déployer avec Homebrew (il y a aussi un script pour Linux et un pour Windows) :

brew install floci-io/floci/floci
floci start
eval $(floci env)
aws s3 mb s3://my-bucket

Ensuite, faites un floci start pour lancer l'émulateur dans un conteneur et lui monter le socket Docker de votre machine. Floci s'appuie sur de vrais conteneurs dès que la fidélité l'exige ce qui fait que Lambda tourne dans l'image d'exécution officielle d'AWS, RDS lance un vrai PostgreSQL, MySQL ou MariaDB, ElastiCache un Valkey, et c'est pareil pour ECS, EC2 ou EKS.

J'ai fait l'essai sur mon Mac avec un bucket S3, une table DynamoDB et une petite fonction Lambda en Python, et tout a répondu du premier coup à la CLI AWS. La Lambda a juste mis six secondes à répondre au premier appel, puis moins d'une seconde au suivant.

Pour voir ce qui se passe ensuite, une console web est dispo localhost:4566/_floci/ui, avec vos ressources rangées par service.

La console web de Floci sur localhost, après un essai sur S3, DynamoDB et Lambda

Notez aussi que si vous venez de LocalStack, la bascule se résume simplement dans le nom de l'image puisque Floci traduit tout seul les variables d'environnement de LocalStack, exécute sans modification les scripts d'init rangés dans /etc/localstack/init/ et répond même sur /_localstack/health. Cela veut dire qu'une CI qui attend ce signal ne voit pas la différence et ça c'est super cool pour migrer vite fait bien fait.

Et si vos scripts appellent aws ou boto3, prenez l'image floci/floci:latest-compat, qui embarque les deux.

Par contre, méfiez-vous du volume de données, car LocalStack range tout par défaut dans /var/lib/localstack et Floci dans /app/data. Donc dans le docker compose, pointez bien votre volume sur /app/data sinon, vous perdrez vos fichiers au premier restart du docker.

Après n'oubliez pas non plus que Floci imite le comportement d'AWS, et pas sa sécurité. En effet, par défaut, il n'applique aucune politique IAM, donc si vous voulez vérifier qu'un rôle trop resserré bloque bien une action, il faudra activer la variable FLOCI_SERVICES_IAM_ENFORCEMENT_ENABLED. Et certains services ne sont également que des façades. Par exemple Bedrock Runtime renvoie des réponses factices et Transcribe termine ses tâches aussitôt, sans jamais traiter l'audio, donc oui, votre code peut les appeler, mais le résultat ne sera pas au rendez-vous, ce qui est tout à fait normal.

Pour le reste, les données sont stockées en mémoire par défaut et s'effaceront à l'arrêt, ce qui est pile poil ce qu'on veut en CI. Vous pouvez quand même le paramétrer pour que ça s'écrive sur le disque si vous voulez...

Voilà, à essayer sur une branche de votre CI si vous voulez vous débarrasser de débrancher LocalStack pour de bon !

Source : Floci sur GitHub

Maintenant - Le monitoring qui trouve vos conteneurs tout seul

Par : Korben ✨

"Maintenant", ce n'est pas qu'un adverbe à la con pour apprécier l'instant présent ou faire péter ses ordres comme votre Belle Mère ! C'est également un conteneur à lancer, qui se connecte en lecture seule à un socket Docker pour réaliser en un battement de cil, tout l'inventaire de votre home lab !

Il relève ainsi l'état de chaque conteneur, ses healthchecks, ses boucles de redémarrage, ses logs, et vos projets Compose regroupés comme vous les avez écrits.

Ensuite, tout ce qui vous alerte pour de bon se déclare à la main. Les checks HTTP et TCP se configurent sous la forme de labels sur les conteneurs à surveiller. Par exemple, un maintenant.endpoint.http avec son intervalle et son seuil d'échec, un maintenant.endpoint.tcp pour la base...etc. Pas besoin donc d'aller mettre votre gros nez dans un fichier de config spécifique.

Vos tâches planifiées reçoivent chacune une URL à appeler quand elles finissent comme ça si la sauvegarde de trois heures du matin ne se manifeste pas, vous êtes prévenu. Vos certificats HTTPS sont surveillés et signalés cinq fois avant leur expiration, un mois avant puis de plus en plus près. Il compare aussi l'empreinte de vos images à celle publiée sur le registre, ce qui vous permet ensuite de savoir lesquelles ont pris du retard sans lancer des docker pull à l'aveugle. Ah et il sert une page de statut publique pour vos utilisateurs.

Le tout tient dans un binaire Go qui occupe environ 17 Mo de RAM et qui se repose sur une simple base SQLite.

Par contre, l'édition gratuite (Community) gère une seule machine. Si vous voulez du multi-hôte, il faudra passer par la case payante. Toujours en gratuit, il y a aussi des plafonds... Vous avez le droit uniquement à 10 endpoints, 5 heartbeats, 5 certificats, 3 composants de page de statut et uniquement 7 jours d'historique.

Attention quand même, y'a 2 choses à savoir avant de vous enflammer et de poser ça sur une machine exposée sur le net. Il n'y a aucune authentification intégrée, et de ce que j'ai compris, c'est assumé ! A vous donc de mettre en place un reverse proxy et un Authelia ou un Authentik devant.

Pour situer "Maintenant" par rapport à d'autres solutions que je vous ai déjà présentées, Beszel fait les métriques par conteneur sans aucun plafond gratos, mais pas les checks HTTP. Uptime Kuma lui, fait les checks, mais ses monitors doivent être créés un par un dans l'interface, sauf à lui greffer AutoKuma pour lire les labels. Donc, il n'y a pas vraiment de solution tout-en-un gratuite...

A découvrir ici !

❌