Administrer un parc Linux en production

Les étapes

1. Étape 1
   DébutantNouveau

   Inventorier un serveur Linux inconnu : services, ports et données

   Le prestataire qui gérait le serveur ERP est parti il y a trois semaines, sans rien transmettre. Personne ne sait ce qui tourne dessus, ni ce qui redémarrerait tout seul après une coupure. La direction ne vous demande pas de réparer : elle veut un inventaire écrit, pour que le prochain incident ne se règle pas à l'aveugle. Vous partez d'un shell et de rien d'autre. C'est la situation par laquelle presque tout administrateur système commence, et celle qu'aucun cours ne prépare : reprendre une machine que personne ne connaît. Vous apprendrez à retrouver configuration, données et journaux d'un service inconnu en vous appuyant sur la norme FHS, à distinguer ce que systemd relance de ce qu'on a lancé à la main un jour et oublié, et à mettre un nom sur chaque port en écoute. Trois réflexes qui resserviront à chaque incident. La sandbox est un vrai serveur, avec un service en production, ses journaux et ses surprises. Le terminal s'ouvre dans votre navigateur : ni clé SSH, ni installation. Vous repartez avec une fiche d'inventaire exploitable par quelqu'un qui n'a jamais vu la machine — exactement le document qu'on vous demandera de produire à votre prise de poste.

   • Aucun avis
   • Débutant
   • 1 h 30 min
   • 500 crédits
2. Étape 2
   DébutantNouveau

   Gérer comptes, groupes et permissions Linux pour une équipe

   Deux exploitants et une comptable arrivent lundi. Aujourd'hui tout le monde se connecte avec le même compte admin, dont le mot de passe est noté sur un post-it. Le commissaire aux comptes a posé une condition pour valider l'exercice : des comptes nominatifs, et un accès aux pièces comptables limité à qui en a réellement besoin. Vous avez le week-end. La gestion des droits est ce qu'on confie le plus tôt à un administrateur débutant, et ce qui se fait le plus souvent de travers — un chmod 777 qui règle le problème du jour et ouvre celui de l'année. Vous traduirez un besoin métier en groupes plutôt qu'en permissions individuelles, vous poserez un partage où les fichiers créés restent lisibles par l'équipe (setgid, umask), et vous accorderez par sudo une commande précise au lieu du pouvoir root. Le lab se termine par deux vérifications que peu de tutoriels font faire : vous vous reconnectez sous l'identité de chaque utilisateur pour constater ce qu'il peut vraiment faire, puis vous retrouvez le même principe de moindre privilège un étage plus haut, dans le rôle IAM de la machine. Sandbox prête, terminal dans le navigateur, aucune clé à gérer.

   • Aucun avis
   • Débutant
   • 2 h
   • 750 crédits
3. Étape 3
   GénéralNouveau

   Corriger une faille avec apt et dnf sur un parc Debian et RHEL

   Une faille critique vient d'être publiée sur une bibliothèque présente sur tout le parc. La moitié des serveurs est sous Debian, l'autre sous RHEL, et le fournisseur de l'ERP a prévenu : la dernière version d'un des paquets casse son application. Il faut corriger la faille aujourd'hui, sans arrêter la facturation, et pouvoir justifier chaque décision devant l'auditeur. Un parc homogène n'existe que dans les formations. Ici vous travaillez les deux familles en parallèle et vous apprenez à traduire chaque opération de l'une vers l'autre (apt ↔ dnf, dpkg ↔ rpm) : c'est ce qui sépare quelqu'un qui connaît une distribution de quelqu'un qui sait administrer un parc. Vous vérifierez qu'une version corrigée est réellement installée et pas seulement téléchargée, vous gèlerez le paquet qui casse la facturation, et surtout vous documenterez la dette que ce gel crée. Ce dernier point ne s'apprend nulle part et c'est celui qu'on vous reprochera : une remédiation qui ne laisse pas de trace opposable n'a pas eu lieu. Deux serveurs réels dans la sandbox, un de chaque famille, terminal dans le navigateur.

   • Aucun avis
   • Intermédiaire
   • 2 h 30 min
   • 1 000 crédits
4. Étape 4
   GénéralNouveau

   Diagnostiquer un disque plein et étendre un volume LVM à chaud

   3 h 12 du matin. L'astreinte sonne : plus aucune facture ne part. La partition /var est à 100 %. Il faut rétablir le service cette nuit, sans redémarrer le serveur, et sans supprimer quoi que ce soit qui aurait une valeur comptable. Au matin, la direction voudra savoir pourquoi personne n'a été prévenu avant la panne. « Disque plein » recouvre trois pannes différentes, et l'une des plus fréquentes ne se voit pas avec df : un fichier supprimé mais toujours ouvert par un processus continue d'occuper la place. Vous apprendrez à les distinguer, puis à étendre un volume logique et son système de fichiers à chaud, sans démonter et sans interrompre le service. C'est le geste qui sauve une nuit d'astreinte. Le lab va ensuite là où s'arrêtent les tutoriels : décider si le swap est un remède ou un symptôme, en lisant la charge d'E/S et l'usage mémoire plutôt qu'en appliquant une règle toute faite ; puis poser l'alarme CloudWatch qui aurait évité l'appel de 3 h. Trois heures de pratique sur un serveur réel, en conditions d'incident.

   • Aucun avis
   • Intermédiaire
   • 3 h
   • 1 500 crédits