La section Linux ne se limite pas à des guides à lire. La validation repose sur la preuve par la pratique : chaque compétence peut être démontrée via un lab, un challenge ou un capstone, avec un scoring automatique qui confirme que la manipulation a réellement fonctionné.
Comment fonctionne la validation
Section intitulée « Comment fonctionne la validation »Chaque bloc de compétences (00 à 07) est adossé à des labs reproductibles
dans le dépôt compagnon linux-training, pilotés par la CLI dsoxlab.
La validation suit une progression :
- Lab unitaire : une compétence, un exercice, une validation automatique.
- Challenge : un lab sans aide, pour tester l'autonomie.
- Capstone : un scénario intégré qui combine plusieurs blocs.
- Exercices de certification : alignés sur RHCSA ou LFCS.
- Examen blanc : simulation complète en temps limité.
Types de validation
Section intitulée « Types de validation »Labs unitaires
Un lab par compétence. Chaque lab contient un scénario, des tests automatisés
et un système de scoring via la CLI dsoxlab.
Capstones
Scénarios intégrés qui combinent plusieurs blocs de compétences sur un cas réaliste. Le candidat doit diagnostiquer, configurer et valider un système complet.
Exercices RHCSA
Exercices LFCS
Exercices alignés sur les 5 domaines officiels de la LFCS : commandes, système, réseau, stockage, sécurité.
Les trois niveaux, et la fin de chacun
Section intitulée « Les trois niveaux, et la fin de chacun »Un niveau sans ligne d'arrivée n'est pas un niveau, c'est une étagère. Le parcours compte plus de 200 leçons : ce qui manquait n'était pas du contenu, c'était de pouvoir dire « j'ai fini celui-là ». Les trois épreuves ci-dessous existent déjà, elles portent simplement un nom depuis aujourd'hui.
| Niveau | Ce que vous pouvez affirmer | L'épreuve qui le prouve |
|---|---|---|
| L1, utiliser | Je travaille seul sur une machine Linux sans la casser | drill-essential-commands : 5 tâches, 20 minutes, aucun indice |
| L2, administrer | Je mets un serveur en service et j'assure sa persistance | capstone-mise-en-production : 9 livrables, et la machine redémarre |
| L3, exploiter | Je prends une machine inconnue ou en panne, je comprends son état et je rétablis le service | capstone-serveur-casse : une panne cachée parmi six |
Ces trois épreuves ne sont pas des cours. Ce sont des mesures, et elles se lisent dans cet ordre : se servir d'une machine, en livrer une, en récupérer une. Les certifications se greffent par-dessus, elles ne remplacent pas cette progression.
L'épreuve du niveau L1 ouvre la série : cinq tâches, vingt minutes, aucun indice. Elle ne demande rien d'exotique, seulement de se servir d'une machine sans hésiter, ce qui est exactement ce qu'on n'apprend qu'en le faisant.
L'épreuve du niveau L2 se lance ici, parce que c'est la page où vous venez mesurer où vous en êtes. Une VM neuve, une mission complète, neuf livrables, et aucune commande dictée. Le dernier test redémarre la machine avant de regarder une seconde fois : ce qui ne survit pas au redémarrage vaut zéro.
Examens blancs
Section intitulée « Examens blancs »L'examen blanc RHCSA est disponible : le capstone rhcsa-mock-exam
reproduit les conditions de l'EX200 avec 20 tâches performance-based
réparties sur 2 VMs, pour une durée d'environ 180 minutes. Préparez le
contexte avec le hub RHCSA,
puis lancez-le :
dsoxlab run rhcsa-mock-examL'examen blanc LFCS est disponible lui aussi : lfcs-mock-exam couvre les
5 domaines officiels en 17 tâches sur une VM Ubuntu 24.04, notées sur
100 points, avec 70 pour réussir.
dsoxlab run lfcs-mock-examLe capstone de mise en production, où la machine redémarre
Section intitulée « Le capstone de mise en production, où la machine redémarre »Un apprenant qui ne passe aucune certification mérite lui aussi une épreuve
finale. capstone-mise-en-production la lui donne : une VM neuve, une
application livrée dans /opt/livraison, et une mission, la mettre en service.
dsoxlab run capstone-mise-en-productionNeuf livrables sont notés : stockage sur volume logique monté par fstab,
compte de service sans shell, service actif et enabled, SELinux enforcing
avec port étiqueté et contexte durable, pare-feu ouvert en permanent, page
obtenue depuis le client, journal persistant, sshd sans mot de passe ni
root, sauvegarde planifiée ayant déjà produit une archive.
Le dixième test redémarre vraiment la machine, puis redemande la page. Ce
n'est pas une formalité : les quatre façons de livrer un serveur qui marche le
jour de la recette et pas le lendemain ne se voient qu'au reboot. Un montage
absent de fstab, un service jamais passé en enabled, une règle de pare-feu
posée sans --permanent, une étiquette SELinux posée par chcon au lieu de
semanage. Si la page revient, les quatre sont bons.
Le capstone de dépannage, où le symptôme ne dit rien
Section intitulée « Le capstone de dépannage, où le symptôme ne dit rien »Les deux examens blancs évaluent une certification. Le capstone
capstone-serveur-casse évalue autre chose, le dépannage, et il comble un
manque : tous les labs de panne de la section annoncent leur domaine dans leur
titre. « Réparer un problème SELinux » a déjà donné la moitié du diagnostic.
Ici, vous ne recevez qu'un symptôme, « le site interne ne répond plus ». Le lab a monté un site qui fonctionnait, l'a prouvé, puis a cassé une seule chose tirée au sort parmi six, sans la nommer : service arrêté, mauvais port, pare-feu refermé, contexte SELinux, permissions du docroot, écoute limitée à la boucle locale.
dsoxlab run capstone-serveur-casseLe verdict se prend depuis le client, sur une seconde VM : un curl localhost peut répondre 200 alors que personne n'accède au service. Et
3 des 7 tests sont des garde-fous : passer SELinux en permissive, arrêter
le pare-feu ou ouvrir le docroot à tous font répondre le site et coûtent
30 des 100 points. Un serveur qui répond parce qu'il n'est plus protégé
n'est pas réparé.
Dépôt compagnon
Section intitulée « Dépôt compagnon »Le dépôt linux-dsoxlab-training
regroupe tous les labs, leurs environnements et le moteur de scoring.
La CLI dsoxlab orchestre le cycle complet : lister les labs, lancer un
environnement, valider le travail et suivre sa progression bloc par bloc.
Labs disponibles par bloc
Section intitulée « Labs disponibles par bloc »Le tableau recense les labs jouables aujourd'hui, avec l'identifiant à
passer à dsoxlab run. Les domaines marqués en construction sont déjà
couverts par les guides du site mais n'ont pas encore de lab associé : ils
arrivent au fil du chantier.
| Domaine | Environnement | Labs disponibles |
|---|---|---|
| Fondamentaux : découvrir Linux | Shell | l1-01-discover-linux-map, l1-02-choose-distro, l1-03-prepare-vm, l1-04-first-terminal, l1-05-read-a-command, l1-06-get-help |
| Fondamentaux : se repérer dans les fichiers | Shell | l1-07-linux-filesystem, l1-08-navigate-filesystem, l1-09-paths-absolute-relative |
| Système, processus, services | - | En construction |
| Stockage, filesystems | VM | l2-04-swap-management, l2-luks-encryption, l2-raid-mdadm |
| Réseau, accès distants | - | En construction |
| Identités, permissions, sécurité | - | En construction |
| Dépannage | VM | depanner-service-crash-loop |
| Examen blanc RHCSA (capstone) | 2 VMs | rhcsa-mock-exam |
| Examen blanc LFCS (capstone) | 1 VM | lfcs-mock-exam |
| Dépannage à l'aveugle (capstone) | 2 VMs | capstone-serveur-casse |
| Mise en production (capstone) | 2 VMs | capstone-mise-en-production |
Chaque lab existant est aussi référencé depuis le guide correspondant de la section Linux : le guide donne le contexte, le lab fournit la preuve d'exécution.