EduLibre repose sur cinq machines aux rôles strictement séparés, un domaine interne, et un ordre de construction qui n'est pas négociable. Voici l'architecture globale et les raisons de ce découpage.
Une passerelle qui porte les services réseau, trois serveurs spécialisés, et un parc de postes déployés automatiquement.
Les cinq briques
- La passerelle — deux interfaces réseau : une vers l'extérieur, une vers le réseau pédagogique. Elle route, traduit les adresses, sert le DNS autoritaire du domaine interne et distribue les adresses en DHCP. C'est le point de sortie unique.
- Le serveur d'annuaire — OpenLDAP : utilisateurs, groupes, appartenances, avec des identifiants numériques stables. C'est la brique de voûte : tout le reste s'y adosse.
- Le serveur de fichiers — NFS : profils utilisateurs, espaces de classe, quotas, avec des permissions issues exclusivement de l'annuaire.
- Le serveur de management — PXE pour installer les postes, dépôt d'images, et contrôleur Ansible pour les configurer. Le cerveau du déploiement.
- Les postes — Ubuntu Desktop, installés par le réseau puis rendus exploitables par Ansible.
Un poste de test est monté en amont, installé manuellement, pour valider la chaîne d'automatisation avant de l'industrialiser — décision de méthode qui évite de déboguer deux choses à la fois.
Un domaine interne, et pourquoi c'est structurant
Tout le lab vit dans une zone DNS interne servie par la passerelle. Chaque machine y a un nom pleinement qualifié, et c'est ce nom qui est utilisé partout — dans les configurations, dans les certificats, dans les scripts.
Ce détail apparemment cosmétique conditionne la suite : l'annuaire s'annonce sous son nom, son certificat est émis pour ce nom, les clients le contactent par ce nom. Une infrastructure où l'on écrit des adresses IP dans les fichiers de configuration devient impossible à faire évoluer — changer une machine oblige alors à retrouver toutes les occurrences.
La séparation des rôles : un choix, pas une contrainte
On pourrait tout mettre sur une machine. Le découpage retenu se justifie brique par brique :
- les services réseau restent hors des serveurs applicatifs — si le DNS tombait avec l'annuaire, plus rien ne serait diagnosticable ;
- l'annuaire est isolé parce qu'il est critique : tout le monde en dépend, et on veut pouvoir le redémarrer sans arrêter le stockage ;
- le serveur de fichiers a des besoins propres — entrées/sorties, espace disque, quotas — sans rapport avec ceux d'un annuaire ;
- le management est à part parce qu'il porte le déploiement : il doit rester disponible même quand on casse un poste, et c'est aussi la machine qui détient les clés d'accès au parc.
Cette séparation a un autre effet, moins technique : elle rend les responsabilités lisibles. Un incident se localise immédiatement.
L'ordre de construction
- Le réseau d'abord — la passerelle, son routage, son DNS, son DHCP. Rien ne se construit sans résolution de noms fiable.
- L'identité ensuite — l'annuaire, avec ses conventions de nommage et ses identifiants figés une fois pour toutes.
- Le stockage — le serveur de fichiers, adossé à l'annuaire pour les droits.
- L'orchestration — PXE et Ansible, qui n'ont de sens que si les trois briques précédentes répondent.
- Les postes enfin, d'abord un seul, en test.
Cet ordre suit les dépendances réelles. On ne peut pas configurer un client d'annuaire sans annuaire, ni monter un partage sans identifiants cohérents, ni automatiser une installation sans DHCP. Les tentatives de raccourci se paient en heures de débogage.
Les conventions figées dès le départ
La documentation parle de « conventions figées », et c'est le point le plus important de tout le projet :
- le plan d'adressage — serveurs en adresses fixes basses, plage DHCP séparée, passerelle en haut de plage ;
- les noms de machines et leur correspondance avec les noms DNS ;
- les identifiants numériques des groupes et des utilisateurs, décidés avant la création du premier compte ;
- l'emplacement des partages, sous une racine unique.
Ces décisions coûtent une heure au début. Les changer plus tard coûte une réinstallation — parce qu'un identifiant numérique modifié, ce sont des fichiers dont plus personne n'est propriétaire.
Ce que l'architecture prépare
Le lab n'est pas une fin : l'architecture est dimensionnée pour accueillir la suite — un service d'authentification unique pour les applications web, un durcissement progressif des postes, des politiques de navigateur, l'inventaire des machines dans l'annuaire. C'est aussi pour cela que la structure de l'annuaire prévoit dès le départ une branche pour les postes.
La série EduLibre
De la décision à l'industrialisation du parc :
- 1. Pourquoi un socle libre pour un parc informatique
- 2. L'architecture globale, brique par brique — vous y êtes
- 3. La passerelle : routage, NAT, DNS et DHCP
- 4. L'annuaire LDAP, brique de voûte
- 5. NFS : profils, classes et quotas
- 6. PXE et Ansible : le parc en zero-touch