Depuis quelques jours, je bricole un petit outil de gestion de parc pour NixOS — baptisé Linux MDM — dans l’esprit d’un SCCM ou d’un Intune, mais en misant sur la promesse Nix : une config déclarative et reproductible, sans postes « bricolés à la main » impossibles à reconstruire à l’identique.

Version actuelle : 0.2. L’idée : un hub web (PHP + MariaDB), des profils de logiciels, un magasin DSI, et sur chaque poste une app Centre Logiciels pour le self-service.

C’est quoi un MDM ?

MDM veut dire Mobile Device Management — littéralement « gestion des appareils ». En pratique, c’est la boîte à outils de la DSI pour :

• enrôler des postes (les enregistrer dans le parc),
• pousser (ou faire tirer) une configuration et des logiciels,
• suivre l’inventaire (qui a quoi, quel profil, dernière sync),
• parfois offrir un self-service (l’utilisateur installe des apps validées sans ticket).

Sur Windows / macOS / mobile, on parle souvent d’Intune, Jamf, Workspace ONE, etc. Sur Linux, c’est plus rare et plus artisanal. Linux MDM vise ce rôle pour un parc NixOS : le serveur décrit le « voulu », les postes se synchronisent et appliquent.

Le problème

Gérer des postes Linux « comme Windows » est souvent pénible : paquets qui divergent d’une machine à l’autre, scripts maison, pas de vrai catalogue métier. NixOS attire pour sa config déclarative, mais il manquait une couche métier simple pour une DSI : profils, inventaire, magasin validé, sync automatique.

Ce que fait Linux MDM 0.2

• Profils — paquets nixpkgs + fréquence de sync, publiés en parc.nix
• Machines — inventaire des postes enrôlés, réassignation de profil
• Magasin DSI — catalogue validé + recherche dans +120 000 paquets nixpkgs
• Centre Logiciels — app client autonome (Chromium embarqué) pour installer / retirer et forcer une sync

Déploiement client

Un seul script par profil :

curl -fsSL https://VOTRE-SERVEUR/mdm/generated/install-on-client.sh | sudo bash

Ça enregistre l’appareil, écrit /etc/nixos/mdm.auth, importe le module parc.nix et active le timer systemd nix-builder-mdm-sync. Au cycle suivant (ou sur sync forcée), le poste tire sa config et fait un nixos-rebuild switch.

Centre Logiciels (côté utilisateur)

Sur le bureau : Applications → Centre Logiciels. Fenêtre dédiée, pas besoin d’ouvrir un navigateur système. On y voit les apps du profil, le magasin DSI, et un bouton Synchroniser pour ne pas attendre le prochain timer.

Sous le capot, un agent local (127.0.0.1:17380) + Polkit démarre nix-builder-mdm-sync.service — le hub enregistre le choix, le poste applique.

Stack technique (en vrac)

• Hub : PHP 8 / Apache, MariaDB, UI type MaterialPro, logo Université de Tours
• Clients : NixOS, parc.nix généré, open-vm-tools, SSH, allowUnfree pour vscode / brave / onlyoffice…
• Auth applicative (sessions) côté admin ; token appareil côté client

Et ensuite ?

La 0.2 pose les bases. Prochaines pistes évidentes : meilleure remontée d’état de sync, reporting, durcissement réseau, et peaufiner l’expérience « j’installe → c’est là » (le nixos-rebuild reste le goulot d’étranglement, et c’est assumé).

Si vous jouez avec NixOS en parc / labo / univ, ce genre de couche MDM change vraiment la donne : on garde le declarative, on gagne un vrai workflow DSI.