TSSR module 3 : administration systèmes et services

Jour 29 · 01/12 — HTTP, HTTPS : requêtes, codes de statut, TLS

Objectif : lire une requête et une réponse HTTP, et reconnaître les codes de statut courants.

Théorie 1/2 : requêtes et réponses

Tim Berners-Lee a inventé le Web au CERN en 1989-1991 : des pages en HTML, des adresses (URL) et un protocole, HTTP. Le client envoie une requête : une méthode (GET pour lire, POST pour envoyer, aussi PUT, DELETE, HEAD), un chemin, des en-têtes (Host, User-Agent…). Le serveur renvoie une réponse : un code de statut, des en-têtes, un corps. Les codes par famille :

• 2xx succès : 200 OK ;
• 3xx redirection : 301 déplacé définitivement, 302 temporairement ;
• 4xx erreur du client : 401 authentification requise, 403 interdit, 404 introuvable ;
• 5xx erreur du serveur : 500 erreur interne, 502 mauvaise passerelle (le proxy n'a pas eu de réponse valable du serveur derrière lui), 503 indisponible.

Théorie 2/2 : HTTPS et TLS

HTTPS, c'est HTTP dans un tunnel TLS, sur le port 443 au lieu de 80. TLS chiffre l'échange et prouve l'identité du serveur par un certificat, signé par une autorité de certification que le navigateur connaît. TLS a succédé à SSL ; la version actuelle, TLS 1.3, date de 2018 (RFC 8446). Depuis Let's Encrypt (2015), les certificats sont gratuits et automatiques.

Pratique (30 min)

curl -I https://www.debian.org            # en-têtes seulement : 200 ?
curl -I http://www.debian.org             # 301 vers https ? Lisez l'en-tête Location
curl -I https://www.debian.org/page-qui-nexiste-pas   # 404
curl -v https://www.debian.org -o /dev/null  # la négociation TLS, puis la requête

Dans la sortie de curl -v, repérez la version de TLS, l'émetteur du certificat et sa date d'expiration. Faites le même essai sur deux autres sites et notez les codes obtenus.

Synthèse (10 min)

Récitez les cinq familles de codes avec un exemple chacune. Expliquez en une phrase ce qu'apporte TLS.

Jour 30 · 02/12 — SSH contre Telnet, clés publiques et privées

Objectif : se connecter en SSH de la VM Windows à la VM Debian, d'abord par mot de passe, puis par clé.

Théorie 1/2 : pourquoi SSH

Telnet (RFC 854, 1983, port 23) ouvre une console à distance, mais tout passe en clair, mot de passe compris : n'importe qui sur le chemin peut le lire. SSH, créé par Tatu Ylönen en 1995 après une attaque par écoute de mots de passe dans son université, chiffre la session (port 22). OpenSSH, issu du projet OpenBSD en 1999, est l'implémentation la plus répandue ; Windows 10 et 11 intègrent son client.

Théorie 2/2 : les clés

Une paire de clés se compose d'une clé privée, qui ne quitte jamais votre machine, et d'une clé publique, que vous déposez sur le serveur dans ~/.ssh/authorized_keys. À la connexion, le serveur pose un défi que seule la clé privée peut signer : aucun secret ne traverse le réseau. Protégez la clé privée par une phrase de passe. À la première connexion, SSH affiche l'empreinte du serveur : vérifiez-la, puis elle est gardée dans known_hosts.

Pratique (30 min)

1. Dans la VM Debian : systemctl status ssh (installé au jour 6 ; sinon sudo apt install openssh-server). Relevez son adresse : ip a.
2. Dans la VM Windows, PowerShell : ssh <utilisateur>@<ip-debian>. Acceptez l'empreinte, entrez le mot de passe, tapez hostname, puis exit.
3. Toujours sous Windows : ssh-keygen -t ed25519 (acceptez l'emplacement, donnez une phrase de passe).
4. Copiez la clé publique : type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh <utilisateur>@<ip-debian> "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys".
5. Reconnectez-vous : la phrase de passe de la clé est demandée, plus le mot de passe du compte.

Synthèse (10 min)

Trois lignes : le défaut de Telnet, le rôle de chaque clé, à quoi sert l'empreinte. Refaites la connexion sans notes.

Jour 31 · 03/12 — Messagerie : SMTP, POP3, IMAP et leurs ports

Objectif : dessiner le trajet d'un e-mail et attribuer chaque protocole à son étape.

Théorie (20 min)

• SMTP (RFC 821 en 1982, aujourd'hui RFC 5321) envoie : du logiciel de messagerie vers son serveur, puis de serveur à serveur. Ports : 25 entre serveurs, 587 pour la soumission par un client authentifié (STARTTLS), 465 pour la soumission chiffrée d'emblée.
• POP3 (port 110, ou 995 chiffré) relève : il télécharge les messages, et par défaut les retire du serveur. Pratique pour un seul appareil.
• IMAP (port 143, ou 993 chiffré) consulte : les messages et les dossiers restent sur le serveur, synchronisés entre tous les appareils. C'est le choix courant aujourd'hui.

Le trajet : le client d'Alice soumet le message à son serveur en SMTP ; ce serveur cherche l'enregistrement MX du domaine du destinataire dans le DNS, puis le livre en SMTP au serveur de Bruno ; Bruno le lit en IMAP ou POP3. SPF, DKIM et DMARC, publiés dans le DNS, servent à prouver qu'un serveur a le droit d'envoyer pour un domaine.

Pratique (30 min)

1. Dessinez le trajet d'un e-mail d'Alice (domaine A) à Bruno (domaine B) : quatre acteurs (deux clients, deux serveurs), le DNS, chaque flèche avec son protocole et son port.
2. Vérifiez la partie DNS en vrai : dig debian.org MX +short, puis dig debian.org TXT +short et cherchez un enregistrement SPF (v=spf1 ; tous les domaines n'en publient pas).
3. Dans votre propre logiciel de messagerie, retrouvez les serveurs et ports configurés et notez-les.

Synthèse (10 min)

Récitez les trois protocoles, leur rôle et leurs ports, clair et chiffré.

Jour 32 · 04/12 — Serveur web : Apache ou Nginx

Objectif : servir une page personnelle depuis la VM Debian et l'ouvrir depuis Windows.

Théorie (20 min)

Un serveur web écoute sur les ports 80 et 443 et renvoie des fichiers, ou transmet la requête à une application. Les deux plus répandus sont libres : Apache HTTP Server (1995, configuration par fichiers et modules, .htaccess par répertoire) et nginx (Igor Sysoev, 2004, conçu pour beaucoup de connexions simultanées avec peu de mémoire, très utilisé comme proxy inverse). Sous Debian, nginx sert par défaut le répertoire /var/www/html ; la configuration est dans /etc/nginx/, un fichier par site dans sites-available, activé par un lien dans sites-enabled.

Pratique (30 min)

1. nginx est installé depuis le jour 9 ; sinon sudo apt install nginx.
2. Écrivez votre page :

   sudo tee /var/www/html/index.html >/dev/null <<'EOF'
   <!doctype html>
   <html lang="fr"><meta charset="utf-8"><title>Labo TSSR</title>
   <h1>Ma VM Debian sert cette page</h1>
   </html>
   EOF

3. Testez en local : curl -I http://localhost (200 ?) et curl http://localhost.
4. Depuis la VM Windows, ouvrez http://<ip-debian>/ dans le navigateur.
5. Lisez les journaux : sudo tail -n 5 /var/log/nginx/access.log. Vous y voyez la visite de Windows.

Synthèse (10 min)

Trois lignes : où est la page, où est la configuration, où sont les journaux. Remplacez la page par une autre sans notes.

Jour 33 · 05/12 — Annuaire : notions d'Active Directory

Objectif : comprendre domaine, contrôleur, unités d'organisation et stratégies de groupe, et dessiner un annuaire fictif.

Théorie 1/2 : l'annuaire

Dans une entreprise, on ne crée pas les comptes poste par poste : un annuaire centralise les utilisateurs, les groupes et les machines. Active Directory (AD), arrivé avec Windows 2000 Server, est l'annuaire de Microsoft, interrogé par le protocole LDAP et authentifié par Kerberos. Il dépend du DNS pour que les postes trouvent leurs contrôleurs.

• Domaine : le périmètre d'administration, nommé comme un domaine DNS (labo.example).
• Contrôleur de domaine (DC) : le serveur qui héberge l'annuaire et authentifie. On en met au moins deux.
• Forêt et arbre : un ensemble de domaines qui se font confiance.

Théorie 2/2 : OU et GPO

Une unité d'organisation (OU) est un dossier de l'annuaire : on y range comptes et ordinateurs, souvent par site ou par service. On y délègue l'administration, et on y lie des stratégies de groupe (GPO) : des réglages appliqués automatiquement aux comptes et machines de l'OU (fond d'écran, lecteur réseau, règles de mot de passe, installation de logiciel). Les GPO s'appliquent dans l'ordre local, site, domaine, OU (« LSDOU ») : la dernière appliquée l'emporte en cas de conflit. Une bonne pratique : les droits se donnent à des groupes, jamais directement aux comptes.

Pratique (30 min)

1. Inventez une PME de 30 personnes sur deux sites : Lyon et Nantes, services Direction, Compta, Atelier.
2. Dessinez l'arborescence AD du domaine pme.example : une OU par site, des sous-OU Utilisateurs et Ordinateurs par service, une OU Groupes.
3. Placez cinq comptes fictifs, trois groupes (GG_Compta…), deux GPO (lecteur réseau de la compta, verrouillage d'écran après 10 minutes) et indiquez où chacune est liée.
4. Pour aller plus loin plus tard : Windows Server existe aussi en version d'évaluation gratuite, pour monter un vrai contrôleur au jour 56.

Synthèse (10 min)

Définissez de mémoire domaine, DC, OU et GPO en une ligne chacun, et l'ordre LSDOU.

Jour 34 · 06/12 — Partage de fichiers : SMB et montage réseau

Objectif : partager un dossier de la VM Debian et le monter comme lecteur réseau sous Windows.

Théorie (20 min)

SMB (Server Message Block), créé chez IBM dans les années 1980 puis développé par Microsoft, est le protocole de partage de fichiers et d'imprimantes de Windows, sur le port TCP 445. SMBv1 est obsolète et dangereux (le rançongiciel WannaCry l'a exploité en 2017) : on utilise SMB 2 ou 3. Samba, écrit par Andrew Tridgell à partir de 1992, implémente SMB sous Linux. Côté Windows, un partage se note \\serveur\partage (chemin UNC) et se monte sur une lettre de lecteur. Deux couches de droits s'appliquent : ceux du partage et ceux du système de fichiers ; le plus restrictif gagne. Sous Linux, l'équivalent historique est NFS.

Pratique (30 min)

1. Dans la VM Debian : sudo apt install samba.
2. Créez le dossier et un compte Samba (le mot de passe Samba est distinct de celui du système) :

   sudo mkdir -p /srv/partage/commun
   sudo chown alice:compta /srv/partage/commun
   sudo chmod 770 /srv/partage/commun
   sudo smbpasswd -a alice

3. À la fin de /etc/samba/smb.conf :

   [commun]
      path = /srv/partage/commun
      valid users = @compta
      read only = no

4. testparm pour vérifier, puis sudo systemctl restart smbd.
5. Sous Windows : Explorateur → Ce PC → Connecter un lecteur réseau, dossier \\<ip-debian>\commun, identifiants d'alice. Ou en commande : net use Z: \\<ip-debian>\commun /user:alice.
6. Créez un fichier depuis Windows, vérifiez qu'il apparaît dans /srv/partage/commun avec ls -l.

Synthèse (10 min)

Trois lignes : SMB, Samba et le chemin UNC ; les deux couches de droits ; pourquoi pas SMBv1.

Jour 35 · 07/12 — Impression réseau et files d'attente

Objectif : comprendre le chemin d'une impression et gérer une file d'attente.

Théorie (20 min)

Une impression passe par un spouleur : le travail est mis en file d'attente, puis envoyé à l'imprimante quand elle est libre. Sous Windows, c'est le service Spouleur d'impression (vu au jour 5) ; sous Linux et macOS, c'est CUPS. Deux organisations :

• chaque poste imprime directement vers l'imprimante, par son adresse IP ;
• un serveur d'impression partage les imprimantes : une seule file, des pilotes déployés depuis le serveur, une GPO pour les installer sur les postes.

Protocoles courants : port RAW 9100 (le travail est envoyé tel quel), IPP (port 631, utilisé par CUPS et par les imprimantes récentes, base de l'impression sans pilote), LPD (port 515, ancien). Le dépannage le plus fréquent : un travail bloqué qui retient toute la file. On le supprime ; s'il résiste, on arrête le spouleur, on vide sa file, on le redémarre.

Pratique (30 min)

1. Dans la VM Debian : sudo apt install cups printer-driver-cups-pdf. CUPS crée une imprimante PDF virtuelle.
2. lpstat -p -d : repérez l'imprimante. Imprimez un fichier : lp -d PDF /etc/hostname (le nom exact vient de lpstat). Le PDF arrive dans le dossier PDF de votre répertoire personnel.
3. Mettez l'imprimante en pause (sudo cupsdisable PDF), envoyez deux travaux, regardez la file avec lpstat -o, supprimez-en un avec cancel, réactivez (sudo cupsenable PDF).
4. Sous Windows : Paramètres → Imprimantes et scanners → « Microsoft Print to PDF » ; imprimez une page, ouvrez la file, mettez un travail en pause puis supprimez-le.

Synthèse (10 min)

Trois lignes : ce que fait un spouleur, direct contre serveur d'impression, la procédure pour une file bloquée.

Jour 36 · 08/12 — Sauvegarde : complète, incrémentale, différentielle, PRA

Objectif : choisir une stratégie de sauvegarde et écrire un plan pour une petite entreprise.

Théorie 1/2 : les trois types

• Complète : tout, à chaque fois. Restauration simple, mais longue et volumineuse.
• Incrémentale : ce qui a changé depuis la dernière sauvegarde, quelle qu'elle soit. Rapide et légère ; pour restaurer, il faut la complète puis toutes les incrémentales dans l'ordre.
• Différentielle : ce qui a changé depuis la dernière complète. Grossit chaque jour ; pour restaurer, la complète plus la dernière différentielle suffisent.

Théorie 2/2 : RPO, RTO, PRA

Deux chiffres fixent une stratégie : le RPO (perte de données maximale acceptable, par exemple une journée) et le RTO (durée maximale d'interruption acceptable, par exemple quatre heures). Le PRA (plan de reprise d'activité) décrit comment repartir après un sinistre ; le PCA (plan de continuité) vise à ne pas s'arrêter du tout. Une sauvegarde qu'on n'a jamais restaurée n'est qu'un espoir : on teste la restauration régulièrement. La règle 3-2-1 du jour 12 s'applique, avec une copie hors ligne ou immuable contre les rançongiciels.

Pratique (30 min)

Plan de sauvegarde pour un cabinet de 10 personnes (un serveur de fichiers, une base de comptabilité, des postes) :

1. Inventaire : quoi sauvegarder, quel volume, quelle criticité.
2. RPO et RTO pour chaque donnée.
3. Calendrier : quels types, quels jours, quelle rétention (combien de versions on garde).
4. Supports et emplacements, en appliquant 3-2-1.
5. Test de restauration : quoi, quand, par qui, comment on le prouve.

Synthèse (10 min)

Trois lignes : incrémentale contre différentielle, RPO contre RTO, pourquoi tester la restauration.

Jour 37 · 09/12 — Supervision : SNMP, journaux, métriques

Objectif : savoir ce qu'on surveille, avec quoi, et lire les journaux d'un système Linux.

Théorie (20 min)

Superviser, c'est voir une panne avant les utilisateurs. Trois sources :

• Les métriques : des chiffres dans le temps (processeur, mémoire, disque, bande passante, temps de réponse), avec des seuils d'alerte.
• Les journaux (logs) : des événements horodatés. Sous Linux, journald (systemd) et les fichiers de /var/log ; le protocole syslog les centralise sur un serveur. Sous Windows, l'Observateur d'événements (eventvwr.msc).
• SNMP (Simple Network Management Protocol, RFC 1157 en 1990 ; ports UDP 161 pour les requêtes, 162 pour les alertes « traps ») : le superviseur interroge les équipements réseau, qui exposent leurs valeurs dans une base appelée MIB. Les versions 1 et 2c s'authentifient par une simple « communauté » en clair ; SNMPv3 ajoute authentification et chiffrement.

Outils libres courants : Zabbix, Nagios et ses dérivés, Prometheus avec Grafana pour les tableaux de bord.

Pratique (30 min)

journalctl -b                  # depuis le dernier démarrage
journalctl -p err -b           # seulement les erreurs
journalctl -u ssh --since today
sudo journalctl -f             # en direct (Ctrl+C pour sortir)
df -h ; free -h ; uptime       # trois métriques de base

Pendant que journalctl -f tourne, connectez-vous en SSH depuis Windows avec un mauvais mot de passe : regardez l'échec s'inscrire. Notez la ligne exacte : c'est ce qu'un outil comme fail2ban surveille.

Synthèse (10 min)

Trois lignes : métriques contre journaux, ce que fait SNMP, trois options de journalctl.

Jour 38 · 10/12 — Scripting bash 1 : variables, conditions, boucles

Objectif : écrire un script qui vérifie si une liste de machines répond.

Théorie 1/2 : variables et conditions

Bash (Brian Fox, 1989, pour le projet GNU) est le shell par défaut de nombreuses distributions. Un script est un fichier texte qui commence par #!/bin/bash, rendu exécutable par chmod +x.

• Variable : hote="debian.org" (sans espace autour de =), lue par "$hote". Toujours entre guillemets doubles.
• Arguments : $1, $2… ; leur nombre, $#.
• Code de retour : chaque commande renvoie 0 si elle réussit, autre chose sinon ; $? le contient.
• Condition : if commande; then … else … fi, ou un test : if [ "$#" -eq 0 ]; then ….

Théorie 2/2 : les boucles

for h in a b c; do … done parcourt une liste ; while read -r ligne; do … done < fichier lit un fichier ligne à ligne. Avant de lancer un script, bash -n script.sh vérifie sa syntaxe ; l'outil shellcheck (paquet du même nom) signale les erreurs courantes.

Pratique (30 min)

#!/bin/bash
# check-hosts.sh: tell which hosts answer a ping.
if [ "$#" -eq 0 ]; then
  echo "usage: $0 host..." >&2
  exit 2
fi
for h in "$@"; do
  if ping -c 1 -W 2 "$h" >/dev/null 2>&1; then
    echo "OK    $h"
  else
    echo "DOWN  $h"
  fi
done

1. Tapez ce script (ne le collez pas) dans ~/check-hosts.sh, chmod +x ~/check-hosts.sh.
2. Lancez ./check-hosts.sh debian.org 192.0.2.1 localhost : 192.0.2.1, adresse de documentation, ne répondra pas.
3. Améliorez-le : comptez les machines DOWN et terminez par exit 1 s'il y en a au moins une.

Synthèse (10 min)

Réécrivez le script de mémoire, puis passez-le à bash -n.

Jour 39 · 11/12 — Scripting bash 2 : automatiser, cron

Objectif : écrire cinq petits scripts utiles, dont une sauvegarde planifiée par cron.

Théorie (20 min)

cron lance des commandes à heure fixe. crontab -e édite la table de l'utilisateur ; chaque ligne a cinq champs de temps puis la commande :

# minute heure jour-du-mois mois jour-de-la-semaine  commande
30 2 * * *   /usr/local/bin/backup-dir.sh   # chaque nuit à 2 h 30
*/15 * * * * /usr/local/bin/check-hosts.sh debian.org

Sous cron, l'environnement est réduit : utilisez des chemins absolus et redirigez la sortie vers un journal. Sur une machine systemd, les timers sont l'alternative moderne. Les sauvegardes s'appuient sur tar (archive, -z pour compresser) ou rsync (copie incrémentale).

Pratique (30 min)

1. Le script de sauvegarde :

   #!/bin/bash
   # backup-dir.sh: archive a directory into a dated tarball, keep the last 7.
   set -eu
   src=${1:?usage: backup-dir.sh directory}
   dest=/var/backups/labo
   mkdir -p "$dest"
   tar -czf "$dest/$(basename "$src")-$(date +%F-%H%M).tar.gz" -C "$(dirname "$src")" "$(basename "$src")"
   ls -1t "$dest"/*.tar.gz | tail -n +8 | xargs -r rm --

2. Installez-le : sudo install -m 755 backup-dir.sh /usr/local/bin/, testez-le à la main sur /srv/partage/commun, puis listez /var/backups/labo.
3. Planifiez-le dans la crontab de root (sudo crontab -e) toutes les 5 minutes pour le test, vérifiez qu'une archive apparaît, puis remettez-le à une fois par nuit.
4. Restaurez une archive dans /tmp (tar -xzf … -C /tmp) : une sauvegarde se prouve par une restauration.
5. Quatre autres scripts courts, à écrire seul : l'espace disque libre avec une alerte sous 20 % ; la liste des comptes humains (UID ≥ 1000 dans /etc/passwd) ; les cinq plus gros fichiers d'un dossier ; le nombre de connexions SSH refusées aujourd'hui (à partir du jour 37).

Synthèse (10 min)

Écrivez de mémoire la ligne cron « chaque nuit à 2 h 30 » et la commande tar de création d'une archive compressée.

Jour 40 · 12/12 — PowerShell : les équivalents des commandes bash

Objectif : retrouver sous Windows, en PowerShell, ce que vous savez faire en bash.

Théorie (20 min)

PowerShell, conçu par Jeffrey Snover chez Microsoft et publié en 2006, a une idée centrale : les commandes, appelées cmdlets, échangent des objets, pas du texte. On filtre donc par propriété au lieu de découper des lignes. Les noms suivent le modèle Verbe-Nom : Get-Process, Stop-Service. PowerShell est libre et multiplateforme depuis 2016 (PowerShell 7 aujourd'hui) ; Windows fournit aussi l'ancien Windows PowerShell 5.1.

Pratique (30 min)

Get-Process | Sort-Object CPU -Descending | Select-Object -First 5
Get-Service | Where-Object Status -eq 'Running' | Measure-Object
Get-Service Spooler
Restart-Service Spooler          # dans une console administrateur
Get-ChildItem C:\Windows -File | Sort-Object Length -Descending | Select-Object -First 5 Name, Length
Test-Connection debian.org -Count 2
Get-NetIPAddress -AddressFamily IPv4
Get-Help Get-Service -Examples

Puis réécrivez en PowerShell le script check-hosts.sh du jour 38 avec foreach et Test-Connection -Quiet. Si l'exécution de scripts est bloquée, lisez Get-Help about_Execution_Policies avant de changer quoi que ce soit.

Synthèse (10 min)

Recopiez le tableau de correspondance de mémoire.

Jour 41 · 13/12 — Cloud et conteneurs : IaaS, PaaS, SaaS, Docker

Objectif : situer les trois modèles de cloud et comprendre ce qu'est un conteneur.

Théorie 1/2 : les trois modèles

Le NIST a fixé en 2011 la définition de référence du cloud (publication SP 800-145). Elle distingue trois modèles de service, selon ce que le fournisseur gère pour vous :

• IaaS (infrastructure) : on loue des machines virtuelles, du stockage, du réseau ; vous gérez le système et ce qu'il y a dessus.
• PaaS (plateforme) : on dépose son application, le fournisseur gère les serveurs et le système.
• SaaS (logiciel) : on utilise une application prête, par le navigateur ; vous ne gérez que vos données et vos comptes.

La même publication distingue les modes de déploiement : cloud public, privé, hybride, communautaire.

Théorie 2/2 : les conteneurs

Une VM embarque tout un système d'exploitation sur un matériel virtuel. Un conteneur partage le noyau de l'hôte et n'isole que l'application et ses dépendances (grâce aux namespaces et aux cgroups du noyau Linux) : il démarre en une seconde et pèse beaucoup moins. Docker, présenté en 2013, l'a rendu simple : une image est un modèle en lecture seule, un conteneur en est une instance qui tourne, un Dockerfile décrit comment construire l'image, un registre (Docker Hub) les distribue.

Pratique (30 min)

1. Dessinez les trois modèles en trois colonnes de couches (réseau, stockage, serveurs, virtualisation, système, environnement d'exécution, application, données) et coloriez ce que gère le client dans chacun.
2. Dessinez une VM et un conteneur côte à côte : où est le noyau ?
3. Première lecture sur Docker : la page « Get started » de la documentation officielle (docs.docker.com). Notez les définitions d'image, de conteneur et de registre dans vos mots.
4. Facultatif, si la VM a de la place : installez Docker en suivant la procédure officielle pour Debian, puis sudo docker run --rm hello-world.

Synthèse (10 min)

Trois lignes : IaaS, PaaS et SaaS avec un exemple chacun ; VM contre conteneur ; image contre conteneur.

Jour 42 · 14/12 — Bilan du module 3 : le mini-projet

Objectif : une VM Debian qui sert une page web accessible depuis Windows par son adresse IP, documentée en dix lignes.

Théorie (20 min) : documenter

Une installation non documentée est à refaire de mémoire le jour de la panne. Une bonne documentation courte dit : ce que fait le système, où il est (adresse, nom), comment il est installé (paquets, fichiers modifiés), comment vérifier qu'il marche, comment le redémarrer, où sont ses journaux, ce qui reste à faire. Elle est écrite pour quelqu'un d'autre : votre collègue, ou vous dans six mois.

Pratique (30 min)

1. Restaurez l'instantané propre de la VM Debian (jour 13), ou repartez d'une VM neuve.
2. Sans notes : adresse vérifiée, nginx installé et activé au démarrage, page personnelle déposée, test curl en local.
3. Depuis Windows : ping <ip-debian>, puis la page dans le navigateur, puis curl.exe -I http://<ip-debian>/.
4. Rédigez la documentation en dix lignes : rôle, adresse, système, paquets, fichier de la page, commande de test, redémarrage, journaux, accès SSH, limites.

Synthèse (10 min)

Relisez votre documentation comme si vous la découvriez : manque-t-il une étape pour refaire le projet ? Ajoutez-la.