Cette épreuve clôt le socle : on vous confie un service web déjà publié en HTTPS, vous le documentez, vous prouvez qu'il fonctionne, vous retrouvez la cause d'un incident que personne ne vous a décrit, puis vous restaurez sa sauvegarde. Elle s'adresse à celui qui a suivi les leçons du socle, de Publier un service web à Diagnostiquer un service web par couches. Comptez une heure et demie. Elle suppose aussi de savoir lire l'état d'un service systemd sur Debian 13, d'en modifier l'unité puis de la recharger, et d'éditer le fichier de configuration d'un service système comme un résolveur DNS local. Aucune leçon du socle ne l'enseigne : ces gestes sont ceux de systemctl : lister, démarrer et diagnostiquer les services Linux, à lire avant de vous lancer si vous ne les pratiquez pas.
Sur le banc, les fichiers de configuration en place vous donnent le plus
souvent la syntaxe attendue, et la réparation consiste alors à les
corriger. Une exception vaut d'être connue avant d'y être : l'incident peut
avoir retiré une ligne entière, et le fichier restant ne vous en montre
alors aucun exemple. C'est le cas de la ligne qui associe un nom à une
adresse chez le résolveur ; le manuel unbound.conf(5) la décrit, donc
essayez man 5 unbound.conf sur la machine, et à défaut la documentation en
ligne d'Unbound.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »L'épreuve n'enseigne aucun geste nouveau : elle vous apprend à mobiliser seul ceux du socle sur un service que vous n'avez pas monté, sans savoir d'avance où se cache la panne. Vous saurez :
- Décrire un service publié tel qu'il est réellement, pas tel qu'on le croit
- Réceptionner une publication depuis un client indépendant
- Diagnostiquer une panne inconnue et justifier votre raisonnement
- Réparer par une modification minimale
- Restaurer une sauvegarde et en prouver la fiabilité
Le besoin
Section intitulée « Le besoin »Le service epreuve.test répond sur la machine edge.lab, en TLS, derrière
un routeur qui relaie vers un backend protégé. Le backend est
l'application située derrière le routeur ; il porte une valeur métier et sa
sauvegarde. Tout est en place avant votre arrivée : on vous confie un service
en fonctionnement, pas une machine vierge.
Peu après sa mise en service, un incident a été introduit. Rien ne vous dit
quelle couche il touche : en cours de route, le service ne se comportera pas
comme le dossier que vous aurez écrit le prétend. La machine poste.lab joue le
client indépendant, celui qui regarde le service de l'extérieur, sans les
accès de l'opérateur.
Les contraintes
Section intitulée « Les contraintes »Chaque exigence se prouve par un état observable, pas par une affirmation. Un document dit ce que vous croyez ; une réponse obtenue dit ce que le service fait. Quatre exigences sont à tenir, dans cet ordre.
| # | Exigence | Ce qui sera observé |
|---|---|---|
| 1 | Un dossier d'architecture décrit le service | le dossier existe et nomme epreuve.test |
| 2 | Le service fonctionne, vu de poste.lab | une réponse correcte à des données que vous n'avez pas choisies, et /admin refusé |
| 3 | L'incident est diagnostiqué puis réparé | la couche et le composant en cause nommés, puis le service répond de nouveau |
| 4 | La sauvegarde se restaure en confiance | la configuration et les données retrouvées, le service répondant sous TLS strict |
Avant d'exécuter restaurer.sh, le contrôle supprime la configuration et
les données actives du service : le script doit tout reconstituer depuis la
sauvegarde, et un travail que vous n'y auriez pas consigné est perdu.
Ce que vous devez livrer
Section intitulée « Ce que vous devez livrer »Trois livrables, déposés dans /home/student/ sur edge.lab, en plus de
l'état final du service. Le dossier dossier.md décrit l'architecture réelle : noms,
flux, identités et responsabilités. Le fichier incident.yaml porte trois
champs, couche, composant et explication ; le dernier dit
comment vous êtes arrivé au diagnostic, hypothèses écartées comprises. Le
script restaurer.sh rejoue la restauration.
La couche s'écrit avec l'une de ces cinq valeurs : dns, transport,
tls, route ou backend, qui correspondent, dans l'ordre du socle, au nom,
au port, à TLS, au routage et à l'application. Le composant nomme la
seule pièce fautive. Citer toutes les pièces à la fois n'est pas un
diagnostic : les pistes écartées ont leur place dans l'explication, pas
dans le composant.
Comment vous auto-évaluer
Section intitulée « Comment vous auto-évaluer »Le contrôle automatisé note des faits comparés à l'état réel de la machine ; la pertinence de vos écrits est lue par un relecteur. Cette distinction est volontaire : une machine ne juge pas un document, et un texte long qui emploie les bons mots n'est pas pour autant cohérent.
Ce que le contrôle mesure :
- le dossier existe, n'est pas vide, et nomme
epreuve.test; - depuis
poste.lab, le service répond avec une donnée tirée au moment de l'essai, la vraie valeur métier, sous vérification TLS stricte, et/adminreste refusé (403) ; une requête qui n'indique pas l'autorité de test doit échouer, donc cette autorité ne doit pas devenir de confiance pour tout le poste ; - le champ
couchedésigne la couche réellement cassée, le champcomposantnomme le composant fautif sans citer de couche sans rapport, etexplicationest renseigné ; - le service répond trois fois de suite après la réparation ;
- après restauration, la configuration et les données sont celles de la
sauvegarde, le service répond,
/adminreste refusé et la vérification TLS reste stricte.
Ce qui est lu et non noté : la couverture de votre dossier et la qualité de votre raisonnement. Un contrôle au vert ne remplace pas cette relecture, et relire toutes les leçons ne prouve pas non plus que vous savez faire : seule la réponse du service le prouve. Une exigence ratée n'appelle pas une solution toute faite, car aucun corrigé ne figure dans les guides. Revenez à la leçon qui enseigne le geste manquant, puis recommencez dans un état propre.
Mettre en pratique : passer l'épreuve
Section intitulée « Mettre en pratique : passer l'épreuve »L'épreuve se déroule dans le lab. Elle dure environ 90 minutes et ne fournit aucun indice. Lancez-la quand vous avez le temps de la finir d'une traite.
À retenir
Section intitulée « À retenir »Une épreuve du socle prouve un état et un raisonnement.
- Un dossier décrit le service réel, et un schéma seul ne démontre pas son comportement.
- Une recette se passe depuis un client indépendant, vérification TLS intacte.
- Un diagnostic nomme la couche et le composant, hypothèses écartées à l'appui.
- Une sauvegarde ne vaut que restaurée, avec sa configuration, ses données et sa confiance.
- Avoir lu toutes les pages ne valide pas la compétence : seul le service qui répond le prouve.