Linux : administration système, préparation au LFCS

Les étapes

1. Étape 1
   Débutant

   Linux : inventorier un serveur (services, ports, journaux)

   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 de courant. 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. Le guide ne vous donne pas les réponses : il vous donne les questions et les outils, et vous cherchez sur la machine avant d'ouvrir la solution. Vous apprendrez à lire l'arborescence pour séparer ce qu'un paquet a installé de ce qu'un humain a posé à la main, à demander à systemd à qui appartient un processus, et à mettre un nom sur chaque port en écoute. En chemin, vous tomberez sur ce que tout serveur hérité cache : des données métier qu'aucune sauvegarde standard ne prendrait, un programme que personne ne surveille, et un script qui marche à la main mais échouerait en service. Vous ne corrigez rien, vous documentez. Votre inventaire est relu sur la machine à la fin du lab, et il compte pour votre classement. Un vrai serveur, avec ses services en production et ses journaux. Le terminal s'ouvre dans votre navigateur : ni clé SSH, ni installation.

   • Aucun avis
   • Débutant
   • 1 h 45 min
   • 500 crédits
   • 1er atelier offert
2. Étape 2
   Débutant

   Linux : utilisateurs, groupes et permissions

   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é trois conditions pour valider l'exercice : des comptes nominatifs, un accès aux pièces comptables limité aux personnes concernées, et la traçabilité des actions d'administration. 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 commencerez par l'audit, et il réserve une surprise : un ancien salarié a gardé les pleins pouvoirs. Puis vous traduirez le besoin métier en groupes, vous construirez un partage où chaque nouveau fichier reste modifiable par toute l'équipe (groupe, setgid, umask), et vous accorderez par sudo une commande précise au lieu du pouvoir root. Le serveur est en service, et l'ordre des gestes compte autant que les gestes : construire, prouver sous l'identité de chaque arrivant, et seulement ensuite fermer les anciens accès. Le guide vous fait prédire le résultat avant chaque commande, parce que c'est l'écart entre ce que vous attendiez et ce que vous voyez qui fait comprendre les permissions Unix. À la fin, l'état de la machine est vérifié et compte pour votre classement. Sandbox prête, terminal dans le navigateur, aucune clé à gérer.

   • Aucun avis
   • Débutant
   • 2 h 30 min
   • 750 crédits
   • 1er atelier offert
3. Étape 3
   Général

   Linux : corriger une faille avec apt et dnf (Debian, RHEL)

   Une faille critique vient d'être publiée sur GnuTLS, la bibliothèque de chiffrement présente sur tout votre parc, et elle doit être corrigée sous 24 heures. Sauf que l'éditeur de l'ERP vous a écrit ce matin : son connecteur n'est certifié qu'avec la version de curl actuellement installée. Toute montée de version de curl arrête la facturation. Il faut donc corriger la faille sans laisser curl bouger, sur les deux moitiés du parc, et pouvoir le justifier devant l'auditeur. Un parc homogène n'existe que dans les formations. Ici vous travaillez les deux familles en parallèle, un serveur de la famille RHEL et un conteneur Debian 12 resté à sa version de 2023, et vous apprenez à traduire chaque opération de l'une vers l'autre : dpkg et rpm pour savoir, apt et dnf pour changer. Premier piège, celui qui fait échouer la plupart des débutants : le paquet ne porte ni le nom de la commande, ni le même nom d'une distribution à l'autre. Vous regarderez ce qu'une mise à jour emporterait avant de la lancer, vous corrigerez le strict nécessaire et vous le prouverez par la version installée, pas par l'absence d'erreur. Puis vous gèlerez curl des deux côtés, vous essaierez de forcer le verrou, et vous documenterez la dette que ce gel crée, avec sa date de levée. C'est ce dernier point qu'on vous reprochera s'il manque. À la fin, la machine et votre fiche sont vérifiées, et le résultat compte pour votre classement. Terminal dans le navigateur, aucune installation.

   • Aucun avis
   • Intermédiaire
   • 2 h 50 min
   • 1 000 crédits
   • 1er atelier offert
4. Étape 4
   Général

   Linux : disque plein et extension d'un volume LVM

   3 h 12 du matin. L'astreinte sonne : plus aucune facture ne part, le volume /srv/factures est à 100 %. Il faut rétablir le service cette nuit, sans redémarrer le serveur, sans rendre /etc/fstab invalide, et sans supprimer quoi que ce soit qui ait une valeur comptable. Au matin, la direction posera une seule question : pourquoi personne n'a été prévenu avant la panne ? « Disque plein » recouvre trois pannes différentes, et elles ne se soignent pas pareil. Le guide vous fait diagnostiquer avant de toucher : vous prédisez ce que df et du vont répondre, et leur désaccord vous mène à un fichier supprimé la veille mais toujours tenu ouvert par un service, qui occupe encore des centaines de mégaoctets. Vous rendez cet espace sans effacer un seul fichier, puis vous étendez le volume logique et son système de fichiers à chaud, sans démonter et sans interrompre la facturation. 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 l'usage réel de la mémoire, plutôt que d'obéir à une règle toute faite. Puis poser ce qui manquait vraiment : une mesure du remplissage, planifiée par un timer systemd, et une alarme CloudWatch avec un seuil qui laisse le temps d'agir en journée. À la fin, l'état de la machine et l'alarme sont vérifiés, et le résultat compte pour votre classement. Un serveur réel, en conditions d'incident.

   • Aucun avis
   • Intermédiaire
   • 3 h 15 min
   • 1 500 crédits
5. Étape 5
   Général

   Réseau Linux : routage et pare-feu nftables

   L'entreprise a changé d'opérateur Internet il y a deux jours. Depuis, les clients n'arrivent plus à suivre leurs conteneurs en ligne, alors qu'au bureau le portail s'affiche parfaitement. L'opérateur a répondu à votre ticket en une heure : le problème ne se situe pas chez lui. La direction vous donne la matinée pour rendre le portail aux clients, et pour répondre par écrit à une seule question : qui avait raison ? Vous commencez par délimiter la panne au lieu de chercher au hasard : le même test depuis le bureau et depuis Internet écarte la moitié des suspects. Puis une capture de paquets tranche le débat avec l'opérateur, preuve à l'appui. Vous descendez ensuite couche par couche : l'adresse, la route, les voisins, et une passerelle qui n'existe plus depuis le changement de box. Vous apprenez à reconnaître, à la seule forme de l'erreur, un service qui n'écoute pas d'un pare-feu qui filtre, et vous prenez le pare-feu sur le fait dans le journal du noyau. Le lab va là où s'arrêtent les tutoriels. Comprendre pourquoi une règle fausse depuis le premier jour a fonctionné pendant des années. Ouvrir exactement un port dans nftables, sans ouvrir l'administration à Internet ni fermer le bureau. Puis rendre chaque correction durable, et le prouver sans redémarrer, avant de rédiger le rapport d'incident que liront la direction et l'opérateur. Le bureau, la box de l'opérateur et un client sur Internet sont simulés sur la machine : vous pouvez casser la route et le pare-feu sans perdre votre terminal. À la fin, l'état du serveur et votre rapport sont vérifiés, et le résultat compte pour votre classement.

   • Aucun avis
   • Intermédiaire
   • 2 h 50 min
   • 1 500 crédits
6. Étape 6
   Avancé

   Linux : services systemd, timers et règles udev

   La douane écrit pour la troisième fois : plus aucune déclaration n'est arrivée au guichet unique depuis trois jours, et des conteneurs sont bloqués au port. Le même matin, le chef de quai signale que l'étiqueteuse n'imprime plus rien depuis que le poste a été rebranché. Au lab 1, vous aviez rangé le script de collecte dans la colonne des risques : lancé au démarrage par cron, détaché par nohup, sa sortie jetée dans /dev/null. Le risque s'est réalisé. Vous commencez par l'enquête : le journal qui s'arrête sans un mot, l'onduleur qui révèle que seules les coupures de courant relançaient la collecte, puis le script lancé à la main qui meurt sous vos yeux au premier refus du guichet. Avant de toucher à quoi que ce soit, vous mettez la configuration sous Git. Vous confiez ensuite la collecte à systemd : une unité qui la relance sans s'épuiser, sous son propre compte, avec une mémoire bornée et un journal où plus rien ne se perd. Le récapitulatif de nuit, que cron oubliait les nuits de coupure, devient un timer qui rattrape les passages manqués. Reste la douchette. Le noyau numérote les appareils dans l'ordre où ils arrivent, et le logiciel d'étiquetage écoute désormais le clavier. Vous lisez ce que le noyau et udev savent d'un appareil, vous croisez les modules qui le pilotent, et vous écrivez la règle udev qui le nomme par ce qu'il est, pas par son rang d'arrivée. Pour finir, un collègue « simplifie » la configuration un vendredi soir, et Git vous dit en dix secondes ce qui a changé. Le guichet des douanes et le matériel du quai sont simulés sur la machine, et se comportent comme les vrais. À la fin, l'état du serveur et votre historique Git sont vérifiés, et le résultat compte pour votre classement.

   • Aucun avis
   • Intermédiaire
   • 3 h
   • 1 500 crédits
7. Étape 7
   Avancé

   Linux : centraliser les comptes avec LDAP, SSSD et PAM

   Le commissaire aux comptes est revenu. Au lab 2, vous aviez verrouillé le compte de ktraore, l'agent de quai parti depuis des mois. Son rapport préliminaire tient en une phrase : ktraore est verrouillé sur srv-erp, mais actif sur srv-quai, avec les droits d'administration, et l'auditeur s'y est connecté avec un mot de passe trouvé dans les notes de l'ancien prestataire. Le groupe a un annuaire central depuis l'an dernier, que personne n'a fini de raccorder. La contre-visite a lieu vendredi. Vous commencez par cartographier le parc : un même salarié qui porte deux numéros différents d'un serveur à l'autre, et un compte local qui hérite en silence des groupes de l'annuaire. Vous apprenez à lire un annuaire LDAP, ses branches, ses entrées et ses filtres, en chiffrant la connexion et en vous présentant avec un compte qui ne peut que lire. Puis vous désactivez l'ancien salarié dans l'annuaire, et vous découvrez que la révocation centrale ne vaut rien tant qu'un compte local porte le même nom. Le lab va là où s'arrêtent les tutoriels. Raccorder un serveur avec SSSD, NSS et PAM, et comprendre pourquoi SSSD refuse de démarrer avec un fichier lisible par tous. Migrer les comptes locaux vers l'annuaire sans qu'aucun fichier ne change de main, en sachant pourquoi un chown lancé sur tout le disque volerait leurs fichiers aux comptes d'un conteneur. Constater qu'un ordre mal choisi rouvre la porte qu'on croyait fermée. Couper l'annuaire, voir qui peut encore entrer grâce au cache, et tester le compte de secours avant d'en avoir besoin. Enfin, écrire la procédure de départ que l'auditeur lira vendredi. L'annuaire est un vrai OpenLDAP, et le serveur du quai un conteneur avec son propre SSSD : vous travaillez sur un petit parc, depuis un seul terminal. À la fin, de vraies tentatives de connexion vérifient vos révocations, comme le fera l'auditeur, et le résultat compte pour votre classement.

   • Aucun avis
   • Avancé
   • 3 h 15 min
   • 1 500 crédits
8. Étape 8
   Avancé

   Linux : SELinux et dépannage d'un serveur qui ne démarre plus

   L'audit de sécurité tient en deux constats. Sur srv-portail, le serveur qui sert aux clients le portail de suivi des conteneurs, SELinux ne protège plus rien depuis que le prestataire l'a mis en mode permissif, « parce que le portail ne démarrait pas avec ». Et personne n'a jamais testé un redémarrage : depuis la coupure de courant de cette nuit, srv-archives, qui garde les déclarations en douane, ne démarre plus. Vous lisez d'abord l'état de SELinux, les contextes des processus et des fichiers, et le journal d'audit, où le mode permissif a noté chaque refus sans en appliquer aucun. Vous passez en mode contraint pour voir le portail tomber, puis vous écartez les trois fausses corrections qui font repartir le portail en ouvrant bien plus que le besoin : couper SELinux, le booléen que propose audit2why, et le module qu'écrit audit2allow. La vraie correction tient en deux étiquettes : le port 8090 et le dossier du portail, par semanage et restorecon. SELinux passe en mode contraint, maintenant et au démarrage, sans perte de service. AppArmor, le module de Debian et d'Ubuntu, est situé en regard. Puis le second serveur : en mode d'urgence, root verrouillé, impossible d'y entrer. Vous lisez sa console, trouvez le montage qui échoue, arrêtez le serveur, vérifiez son disque, le montez depuis l'extérieur comme depuis une instance de secours, corrigez la faute de frappe de son fstab et la testez par un montage d'essai. Enfin la preuve : vous découvrez pourquoi le serveur, pourtant « activé », ne redémarrait pas seul, et vous redémarrez la machine pour de vrai. Un compte rendu écrit clôt l'audit. Dernier lab du parcours : il couvre les deux derniers chapitres de LFS207, les modules de sécurité Linux et le secours d'un système.

   • Aucun avis
   • Avancé
   • 3 h
   • 1 500 crédits

The Linux Foundation, LFCS et le badge associé sont des marques de The Linux Foundation. Linux est une marque déposée de Linus Torvalds. MonPremierLab n’est pas affilié à la Linux Foundation.