Nouveautés 2026
État au
Marionnet a été repris en profondeur en 2026. Voici, en neuf points, ce qui change pour l’enseignant, pour l’étudiant et pour l’administrateur des salles de TP. Chaque carte mène à sa section ; les détails techniques y sont repliés et s’ouvrent d’un clic.
Une installation par le gestionnaire de paquets
Marionnet s’installe maintenant comme les autres logiciels de votre distribution, c’est-à-dire
par son gestionnaire de paquets : un dépôt apt signé pour Debian, Ubuntu et leurs dérivées,
et un dépôt dnf signé, que zypper lit aussi, pour Fedora, Rocky Linux, AlmaLinux et
openSUSE. Sur les autres distributions, l’installeur marionnet-install.sh télécharge et met
en place une archive précompilée.
Les images des systèmes invités et les noyaux se téléchargent à part, parce qu’ils pèsent
plusieurs gibioctets : la commande marionnet-get-images les présente dans le terminal, sous
la forme d’une liste à cocher.
Les systèmes testés, et la limite de Rocky Linux et AlmaLinux 10
Cette version a été installée, dans un conteneur de chacun de ces systèmes, puis testée sur Ubuntu 20.04 à 26.04, Debian 11 à 13, Rocky Linux et AlmaLinux 9 et 10, Fedora 42 et openSUSE Leap 16.0. Le guide complet donne le nombre de cas testés pour chacun.
Rocky Linux et AlmaLinux 10 ne fournissent plus de bibliothèques 32 bits : le noyau 32 bits ne s’y installe donc pas, et avec lui les routeurs, dont l’image est en 32 bits. Une image de routeur en 64 bits est prévue.
Vérifier la clef qui signe les dépôts
La signature protège surtout les mises à jour, puisqu’une machine déjà installée vérifie chaque paquet avec la clef qu’elle garde sur son disque. Pour la toute première installation, en revanche, il faut comparer l’empreinte de la clef avec une source qui ne soit pas ce site : le dépôt git du projet, un polycopié, ou une machine où Marionnet est déjà installé.
4A65 3434 0BF9 7733 E74C 9DFC 12E4 6000 225F 0E56
Une salle de TP sans accès à Internet
On recopie une fois le répertoire de publication du site sur un serveur local, et chaque poste y prend ses images et ses noyaux : l’installeur accepte un répertoire local là où il attend une adresse.
Le guide d’installation rapide donne les commandes à copier ; le guide complet explique chacune d’elles.
$ echo 'deb [signed-by=/etc/apt/keyrings/marionnet.asc] https://www.marionnet.org/download/apt/ ./' \ | sudo tee /etc/apt/sources.list.d/marionnet.list $ sudo apt update $ sudo apt install marionnet $ marionnet-get-images
Le démon root a disparu
Jusqu’ici, Marionnet ne fonctionnait pleinement qu’accompagné d’un second programme,
marionnet-daemon, qu’il fallait installer à part et faire tourner en permanence comme
service, sous le compte root, même quand personne n’utilisait Marionnet. Il créait à la
demande les interfaces réseau de l’hôte dont les machines virtuelles ont besoin (les taps),
et il acceptait les requêtes de n’importe quel compte de la machine.
Ce démon n’existe plus, et c’est aussi ce qui permet à Marionnet de s’installer comme un logiciel ordinaire. Pour les administrateurs des salles de TP, c’est un service root de moins sur chaque poste.
Ce qui le remplace : une règle sudoers, accordée bloc par bloc
Les quelques opérations privilégiées passent désormais par sudo. Chacune est confiée à un petit script qui vérifie ses arguments avant d’agir, et la règle sudoers ne nomme que ces scripts. Elle est découpée en trois blocs : un socle, nécessaire à tout le reste, puis un bloc pour le NAT bridge et un pour le LAN bridge (voir la section suivante).
L’administrateur accorde chaque bloc à un compte, à plusieurs, ou à toute une salle par un groupe, et il peut aussi en interdire un définitivement. Si un bloc n’a pas été accordé à l’avance, Marionnet demande à l’utilisateur son propre mot de passe sudo au moment où il démarre le pont.
La section 7 du guide complet décrit chaque bloc et ce qu’il permet de faire à la machine.
Accéder au réseau réel : Gateway, NAT bridge, LAN bridge
L’accès au réseau réel se fait désormais par un équipement que l’on pose sur le schéma du réseau, comme un hub ou un switch. Le bouton « planète » de la palette en propose trois :
- Gateway, le composant historique, présent depuis 2011, qui ne demande aucun privilège,
mais ne reproduit qu’une partie de la pile TCP/IP : un
pingn’y passe pas, par exemple ; - NAT bridge, nouveau, qui en est le successeur naturel : il crée sur l’hôte un réseau privé réservé aux machines virtuelles, où toute la pile TCP/IP passe, avec DHCP, DNS et, si on le souhaite, IPv6 ;
- LAN bridge, qui place les machines virtuelles directement sur le réseau local de l’hôte.
Le NAT bridge et le LAN bridge modifient le réseau de l’hôte : l’administrateur les autorise par la règle sudoers décrite dans la section précédente.
Le Gateway, et ses limites
Le Gateway est un petit programme de l’hôte, qui tourne sous le compte de l’utilisateur ;
c’est pourquoi il ne demande aucun privilège. Il simule l’essentiel de la pile TCP/IP pour
les machines virtuelles, mais pas sa totalité : le protocole ICMP, en IPv4 comme en IPv6,
n’y est pas simulé, si bien qu’un ping vers l’extérieur échoue. Le NAT bridge n’a pas
cette limite, puisque les paquets y traversent la vraie pile de l’hôte ; c’est aussi, du
point de vue de l’utilisateur, le plus proche du Gateway.
Le NAT bridge en détail
Il crée sur l’hôte un pont privé, c’est-à-dire un petit réseau réservé aux machines virtuelles, qui sort vers Internet par traduction d’adresses (NAT). Un serveur DHCP et DNS y distribue les adresses et résout les noms. On peut y ajouter IPv6, avec un préfixe local, des annonces de routeur et du NAT66. Le NAT bridge intègre un switch, de 1 à 16 ports, auquel on relie directement les machines. Chaque NAT bridge posé sur le schéma forme un réseau distinct.
Le LAN bridge en détail
Chaque machine virtuelle apparaît sur le réseau local avec sa propre adresse MAC. Marionnet construit lui-même le pont, qu’il fallait auparavant configurer à la main sur l’hôte. Une carte Wi-Fi ne s’y prête pas, parce qu’un point d’accès n’accepte pas plusieurs adresses MAC derrière une même connexion.
Un switch qui accepte tous les câbles
Comme la plupart des switchs actuels, un switch de Marionnet peut désormais détecter le câblage de lui-même : cochée dans sa fiche, l’option Auto MDI-X fait fonctionner sur tous ses ports un câble droit comme un câble croisé. Elle est décochée par défaut, pour que le choix du bon câble reste un exercice, et les anciens projets gardent leur comportement.
La configuration de démarrage d’un switch, écrite dans le langage de commandes de VDE (pour créer des VLAN, par exemple), ne s’exécute plus à l’aveugle : chaque réponse du switch est consignée dans un journal, où une commande refusée se lit avec la raison du refus.
Ce qu’un switch dit de lui-même, pendant qu’il tourne
Par l’interface de pilotage, la commande switch-info interroge un switch en marche et
rend ses quatre tables : ses ports, les adresses MAC qu’il a apprises, ses VLAN et l’état
de l’arbre couvrant (FSTP, le fast spanning tree de VDE). La commande log rend le journal de sa configuration de
démarrage, même une fois le switch arrêté. Un corrigé de TP peut ainsi vérifier qu’un
port est bien dans le VLAN demandé.
Piloter Marionnet par script, ou par une IA
Lancé avec l’option --control-socket, Marionnet ouvre sa fenêtre comme d’habitude, et la
souris y reste utilisable. Il ouvre aussi une interface de pilotage, par laquelle il accepte
en même temps des commandes envoyées depuis un terminal par mrnctl : créer des machines, les câbler, leur donner une adresse, les démarrer, lire ce
qui s’y passe, enregistrer le projet. Un enseignant peut ainsi construire un TP par un script
plutôt qu’à la souris, et le vérifier avant de le distribuer.
Corriger un TP par un fichier d’assertions
L’enseignant écrit le corrigé une seule fois, sous la forme d’un fichier d’assertions (une
par ligne), que la commande mrn-verify rejoue sur le projet de chaque étudiant, ouvert
dans Marionnet. Toutes les copies sont donc jugées par les mêmes tests.
Un guide écrit pour un agent d’IA
Chaque réponse de Marionnet étant une ligne JSON, un agent d’IA capable de lancer des commandes peut piloter Marionnet. Marionnet lui fournit un skill, c’est-à-dire une procédure écrite pour lui, qui l’aide à concevoir un TP avec l’enseignant, à le jouer, puis à noter les séances des étudiants.
En anglais pour l’instant : le guide de l’enseignant, de la préparation d’un TP à la note ; le pilotage par script ; la procédure suivie par un agent d’IA.
Des projets enregistrés en texte
Un projet Marionnet (fichier .mar) est une archive compressée qui décrit le réseau virtuel.
Jusqu’ici, son contenu était écrit dans un format binaire propre au programme, illisible en
dehors de Marionnet. Il est désormais écrit en texte : du JSON pour la description du réseau
(machines, routeurs, switchs, câbles) et des scripts ordinaires pour les configurations de
démarrage. Un projet se lit donc, se compare à un autre avec diff et se garde dans un
gestionnaire de versions comme git : un TP dont une adresse a changé donne une ligne
modifiée.
Ce que cela change pour un enseignant assisté par une IA
Un agent d’IA qui assiste l’enseignant peut ouvrir un projet et y lire le réseau d’un TP sans lancer Marionnet : expliquer un sujet transmis par un collègue, comparer la copie d’un étudiant au corrigé, retrouver ce qui a changé d’une année sur l’autre. La comparaison a un sens, parce qu’un projet qui n’a pas été modifié est réécrit à l’identique. L’agent lit, mais n’écrit pas : Marionnet reste le seul programme qui produit un projet, et l’agent le modifie par l’interface de pilotage (section précédente).
Les anciens projets, et une précaution avant de les enregistrer
Marionnet lit toujours les formats qu’il a écrits autrefois. En revanche, un ancien projet enregistré par cette version passe au nouveau format, et une version antérieure de Marionnet ne saura plus l’ouvrir. Si certains postes n’ont pas encore été mis à jour, gardez une copie du fichier avant de l’enregistrer.
En anglais pour l’instant : le format de projet v3.
Le mode examen enregistre la séance
Lancé par marionnet --exam, Marionnet conserve pour chaque machine et chaque routeur un
rapport sur l’état final du système (interfaces, routes, pare-feu, services…), l’historique
horodaté des commandes tapées, la console du système invité et l’enregistrement du terminal, où
figurent les commandes avec leurs résultats. Ces documents sont rangés dans le projet, onglet
Documents, quand la machine s’arrête proprement.
Sur quels documents une note peut s’appuyer
Le rapport et l’historique sont écrits dans la machine virtuelle, donc dans un système que l’étudiant administre et peut modifier. La console et le terminal, en revanche, sont écrits par Marionnet sur l’hôte, hors de sa portée : c’est sur eux qu’une note peut s’appuyer.
Ce que le mode examen refuse
Puisque les documents ne sont rangés qu’à l’arrêt propre d’une machine, le mode examen refuse les gestes qui sauteraient cette étape, comme le bouton « Tout débrancher ». Quitter Marionnet ou fermer le projet arrête au contraire toutes les machines proprement, attend qu’elles soient éteintes, puis enregistre le projet.
En anglais pour l’instant : le mode examen.
12 traductions complètes
Écrite en anglais (en), l’interface de Marionnet est traduite en allemand (de), espagnol (es), espéranto (eo), français (fr), grec (el), italien (it), portugais (pt), portugais du Brésil (pt_BR), roumain (ro), russe (ru), slovaque (sk) et turc (tr). Les 12 traductions sont complètes : chacune couvre les 442 messages de l’interface, dialogues et textes d’aide des nouveaux composants compris.
Des bénévoles avaient amorcé une dizaine de ces traductions au fil des années. Elles ont été complétées avec soin en 2026, avec l’aide de l’IA, qui a aussi écrit les traductions qui manquaient : la terminologie a d’abord été fixée, puis appliquée catalogue par catalogue.
Des noyaux et des systèmes invités récents
Marionnet est livré avec un noyau Linux 6.12, en 64 et en 32 bits, et une image Debian 13 (trixie) pour les machines. L’image Debian 7 (wheezy) et la petite image guignol, qui sert aussi aux routeurs, restent publiées ; elles utilisent le noyau 32 bits.
Quand un ancien projet nomme un noyau ou une distribution qui ne sont plus publiés, Marionnet les remplace au moment de l’ouvrir, puis récapitule dans une fenêtre ce qu’il a adapté.
Ce qui est remplacé, et l’exception des disques enregistrés
Les noyaux 2.6 et 3.2, qui ne démarrent plus sur les hôtes récents, sont remplacés par le 6.12, et une distribution abandonnée, comme Mandriva, par Debian 13. Une machine dont l’état du disque a été enregistré dans le projet fait exception, car cet état ne vaut que pour son image d’origine : si celle-ci a disparu, la machine est écartée du projet ouvert, et la fenêtre le signale.
Pourquoi le noyau tourne aussi sur les anciennes distributions
Un noyau UML (User Mode Linux) est un programme ordinaire de l’hôte, qui dépend donc de sa bibliothèque C. Il a été compilé de façon à tourner aussi sur les plus anciennes distributions que Marionnet prend en charge.
Une interface cachée sans patch du noyau
Chaque machine virtuelle a une interface de service, eth42, qui la relie à l’hôte pour
afficher ses applications graphiques. Un patch du noyau, écrit par Luca Saiu puis mis à jour
par Jonathan Roudière, la rendait invisible à l’étudiant : c’était la « ghostification ». Elle est
désormais rangée dans un espace de noms réseau (network namespace) caché de la
machine : l’étudiant ne la voit plus avec ip a, et le noyau publié n’a plus besoin de ce
patch. Le masquage est pédagogique : l’administrateur de la machine pourrait la
retrouver, ce que le patch empêchait.
La section 5 du guide complet explique comment choisir et installer les images, et où elles se rangent.