Comment Nixorium est né dans une salle informatique.
Nixorium est né dans une salle informatique de lycée en Italie, avec des élèves de terminale. La salle compte 30 PC d’élèves et un contrôleur, mais les clients n’accèdent pas à Internet tant qu’un utilisateur ne s’est pas authentifié sur le réseau de l’établissement.
- Élèves
- Terminale, lycée en Italie
- Postes
- 30 PC d’élèves
- Contrôleur
- 1 (31 machines au total)
Trente postes, tout à la main
Dans l’établissement, un PC ne sortait sur Internet qu’une fois quelqu’un connecté dessus avec un compte de l’établissement. Un poste tout juste installé, ou simplement allumé sans que personne ne s’y soit connecté, ne pouvait donc rien télécharger, ni logiciel ni mise à jour. Résultat : à chaque installation ou mise à jour, il fallait passer sur chacun des trente PC, se connecter, lancer l’opération à la main, puis recommencer sur le suivant. Impossible de gérer quoi que ce soit de façon centralisée.
La solution a été de mettre un contrôleur dans la salle : un PC qui prépare les systèmes et les diffuse aux autres postes par le réseau local. Installation, mises à jour ou remise en état, tout part désormais du contrôleur pour l’ensemble des PC, sans avoir à se connecter sur chacun. Pendant les cours, les élèves continuent d’utiliser Internet avec l’authentification de l’établissement.
Clonezilla, puis Ansible, ont précédé NixOS.
La salle avait d’abord été gérée avec Clonezilla, puis avec Ansible. Nix a changé la façon de travailler : décrire les systèmes voulus, puis déployer cette configuration autant de fois que nécessaire.
Par la suite, pour les personnalisations que le menu ne proposait pas, la modification de la configuration à la main a de plus en plus souvent laissé place à une demande adressée à une intelligence artificielle. De cette habitude est né Assistant, le service facultatif du menu d’administration, dont les propositions sont vérifiées avant tout enregistrement. Découvrir Assistant →
Préparation locale et démarrage réseau.
Le démarrage UEFI PXE permet d’installer les postes sans démarrer chacun sur une clé USB. Il sert à l’installation ; les PC installés démarrent sur leur propre disque. Un cache binaire local fournit les logiciels préparés, et le contrôleur déploie ensuite les changements par le réseau.
Une adresse DHCP donne accès au réseau scolaire, à côté d’une adresse statique pour la gestion locale.
Outils familiers. Stockage durable.
Les élèves utilisent surtout VS Code, Chromium, Docker et Git. GNOME a été choisi car ils le connaissaient déjà.
Les travaux de programmation passent par Git. Les élèves choisissent leur serveur, et presque tous utilisent GitHub. Les autres documents vont dans Google Drive, avec leurs comptes scolaires.
Dossier remis à zéro et historique local.
Le dossier élève revient au modèle propre à chaque démarrage, tandis que des instantanés locaux gardent les états précédents pour récupérer des fichiers. Seul l’espace de l’élève est remis à zéro, pas tout le système.
Un système entièrement éphémère avec certains états persistants a été envisagé. Pour cette salle, remettre le dossier à zéro et garder des instantanés était plus simple à exploiter.
Environ une heure pour réinstaller la salle.
Réinstaller la salle prend environ une heure. Surtout, la maintenance est devenue plus prévisible : une configuration déclarée, des machines identiques et une méthode reproductible pour reconstruire un poste.
C’est l’expérience d’une seule salle.
Cette durée d’environ une heure est un constat, pas une mesure de performance : le matériel et les conditions de mesure n’ont pas été notés. GitHub et Google Drive sont des choix de la classe, pas des intégrations du produit. Pour le fonctionnement et la compatibilité actuels, consultez les guides opérationnels.
Nixorium est développé et maintenu par un enseignant.
Commencez par un contrôleur, puis un client.
Vérifiez les prérequis, commencez par un contrôleur, puis validez un client représentatif avant de passer à toute la salle.