Compétences du Bloc B1 : B1.1 — Gérer le patrimoine informatique · B1.5 — Mettre à disposition des utilisateurs un service informatique
L’organisation et le contexte
Le projet de masterisation mené à l’IP2I (laboratoire de recherche en physique, CNRS / Université Lyon 1) couvrait d’abord les postes de travail. Mais le service informatique administre aussi des serveurs, pour lesquels les besoins diffèrent : dans le monde de la recherche et de l’IN2P3, c’est la famille Red Hat qui fait référence, et le laboratoire s’appuie sur AlmaLinux 9, distribution communautaire compatible. Il fallait donc étendre l’infrastructure de déploiement à ce second cas d’usage.
Le besoin technique
Contrairement aux postes de travail, où le clonage d’une image de référence est pertinent, un serveur se prête mal à cette approche : chaque serveur a une identité propre et doit être installé « au propre », avec les dernières versions des paquets, dans une configuration minimale et reproductible. Le besoin était donc une installation réseau entièrement automatisée : de la mise sous tension de la machine à un serveur joignable en SSH, sans répondre à une seule question de l’installeur. Une contrainte d’architecture s’ajoutait : les machines du réseau de déploiement (VLAN 30) n’ont volontairement aucun accès direct à Internet, alors que l’installation doit télécharger ses paquets depuis les dépôts officiels.
La solution mise en œuvre
La réponse s’appuie sur Kickstart, le mécanisme d’installation automatisée natif de la famille Red Hat : un fichier de réponses unique décrit toute l’installation (partitionnement, fuseau horaire, mot de passe, paquets, configuration réseau), et l’installeur Anaconda le déroule sans intervention. L’image de démarrage minimale est servie par le serveur Foreman, et les paquets sont téléchargés depuis les dépôts officiels au travers d’un proxy installé sur le serveur : c’est lui qui offre aux machines du réseau isolé une sortie Internet contrôlée, limitée à ce seul usage et aux seules machines du réseau de déploiement.
Le fichier de réponses ne se contente pas d’installer le système : il livre un serveur déjà conforme aux standards du service. Dès la fin de l’installation, la machine redémarre configurée, joignable, et prête à être administrée à distance — le technicien n’a littéralement qu’à la déclarer dans Foreman et à la démarrer en réseau.
La dimension sécurité
C’est le volet le plus abouti de ce projet. Chaque serveur installé sort durci : la connexion de l’administrateur à distance n’est possible que par clé SSH — toute tentative par mot de passe est refusée, le mot de passe restant utilisable uniquement sur la console physique ou l’hyperviseur. La clé du serveur d’administration est déposée automatiquement pendant l’installation, avec les permissions strictes exigées par SSH. L’accès Internet des machines en cours d’installation est canalisé par le proxy, jamais direct. Enfin, j’ai préparé la distribution centralisée des clés publiques de toute l’équipe informatique : le mécanisme est déjà intégré au fichier de réponses et conçu pour être tolérant — tant que le fichier de clés n’est pas publié, l’installation se déroule sans la moindre erreur ; le jour où il le sera, tous les nouveaux serveurs recevront automatiquement les clés de l’équipe, sans modifier quoi que ce soit à la procédure.
Ma plus-value personnelle
Ma contribution la plus significative sur ce volet est justement cette conception « prête pour demain ». Plutôt que de figer la procédure sur l’état actuel du réseau (qui ne permet pas encore au serveur de déploiement d’atteindre le stockage partagé où l’équipe centralise ses clés), j’ai écrit un mécanisme conditionnel et silencieux : il tente de récupérer le fichier des clés, l’utilise s’il existe, et s’efface proprement sinon. C’est une manière de penser l’automatisation que ce stage m’a apprise : un script robuste doit prévoir l’absence de ses dépendances. J’ai aussi documenté en détail le rôle de chaque directive du fichier de réponses — y compris les choix de sécurité et leurs conséquences pratiques — pour que la procédure serve de référence à l’équipe. Ce volet complète la couverture du parc : postes de travail par clonage, serveurs par installation automatisée, effacement certifié en fin de vie — l’ensemble du cycle de vie du matériel passe désormais par la même infrastructure.
La procédure technique détaillée pas à pas, avec captures d’écran et commandes complètes, est disponible en téléchargement au format PDF ci-dessous.