Aller au contenu

TP – Sauvegarder, versionner et restaurer une configuration

BTS SIO SISR 1re année – Bloc 1 – S11

Note

But. Situation : un serveur web de SimIO SARL va être modifié. Tu dois pouvoir revenir à la configuration d'hier en quelques minutes si la modification tourne mal.

Comment ce TP fonctionne. Avant de manipuler, tu écris ce que tu anticipes (« J'anticipe »). Puis tu testes et tu notes ce que tu constates. Tu comprends ce que fait chaque commande (« Je comprends »). Un bilan de compétences clôt la séance. Le TP se fait sur une machine virtuelle réelle (Debian) ; la dernière partie, facultative, utilise un simulateur pour les équipements réseau.

Durée estimée : 2 h. Travail en binôme.

Contraintes

  • Machine virtuelle Debian avec accès à Internet (ou paquets déjà installés) et un compte avec sudo.
  • Toute modification de configuration est précédée d'une sauvegarde et suivie d'un test.
  • Chaque modification est tracée (message de validation Git ou ligne de journal).

Étape 0 : préparer la machine (10 min)

sudo apt update
sudo apt install -y apache2 git curl
systemctl is-active apache2
curl -sI http://localhost | head -n 3

Je comprends. systemctl is-active apache2 répond active si le service tourne. curl -sI demande seulement les en-têtes de la réponse (-I), sans bruit (-s).

Note ce que te répond curl pour la ligne Server: : ______________________

Étape 1 : établir une référence et la sauvegarder (25 min)

J'anticipe. Pourquoi fait-on une sauvegarde avant de modifier, et pas après ?

Éléments de réponse

Parce que la sauvegarde d'avant est la référence (baseline) vers laquelle on revient si la modification échoue. Une sauvegarde faite après la modification contiendrait déjà l'erreur.

Installe le script de l'annexe :

sudo nano /usr/local/bin/sauvegarde-configs.sh      # coller le script de l'annexe
sudo chmod 750 /usr/local/bin/sauvegarde-configs.sh
sudo /usr/local/bin/sauvegarde-configs.sh
sudo ls -l /var/backups/configs
sudo cat /var/backups/configs/sauvegarde.log

Vérifie l'empreinte et le contenu de l'archive :

cd /var/backups/configs
sudo sha256sum -c configs-*.sha256
sudo tar -tzf "$(ls configs-*.tar.gz | head -n 1)" | head

Je comprends. sha256sum -c recalcule l'empreinte et la compare à celle notée à la création : OK signifie que l'archive est intacte. tar -tzf liste le contenu sans l'extraire.

Combien de fichiers l'archive contient-elle ? ______ Quelle est sa taille ? ______

Étape 2 : versionner la configuration avec Git (25 min)

On copie la configuration dans un dossier de travail (on ne versionne pas directement /etc pour ce TP) et on l'enregistre avec Git.

mkdir -p ~/configs/apache2
sudo rsync -a /etc/apache2/ ~/configs/apache2/
sudo chown -R "$USER": ~/configs
cd ~/configs
git init
git config user.name  "Ton Nom"
git config user.email "ton.nom@exemple.local"
git add .
git commit -m "Baseline : configuration Apache d'origine"
git log --oneline

Je comprends. rsync -a copie en conservant droits et dates. git commit fige cet état avec un message : c'est la baseline versionnée. git log --oneline liste les versions, une par ligne.

Étape 3 : modifier, tester, tracer (25 min)

Objectif de la modification : ne plus révéler la version précise d'Apache dans les en-têtes (bonne pratique de durcissement).

J'anticipe. Que devrait afficher curl -sI http://localhost | grep Server après la modification ? Quelle commande te dit si la syntaxe est valide avant de recharger ?

Éléments de réponse

Server: Apache (sans numéro de version ni système) au lieu de Server: Apache/2.4.x (Debian). La syntaxe se vérifie avec sudo apache2ctl configtest : elle doit répondre Syntax OK.

sudo sed -i 's/^ServerTokens .*/ServerTokens Prod/' /etc/apache2/conf-available/security.conf
sudo apache2ctl configtest
sudo systemctl reload apache2
curl -sI http://localhost | grep -i '^Server'

Enregistre la modification dans Git et compare :

sudo rsync -a /etc/apache2/ ~/configs/apache2/
sudo chown -R "$USER": ~/configs
cd ~/configs
git diff
git add -A
git commit -m "Durcissement : ServerTokens Prod (ticket interne n°1)"
git log --oneline

Je comprends. git diff montre exactement ce qui a changé (ligne retirée, ligne ajoutée). Le message de validation dit pourquoi : c'est ce que demande le journal des modifications de l'annexe.

Note le résultat de curl : ______________________

Étape 4 : provoquer une panne et revenir en arrière (25 min)

J'anticipe. On introduit une faute de frappe dans la configuration, puis on recharge sans tester. Que peut-il se passer ? Et si on teste d'abord ?

Éléments de réponse

Sans test, un reload avec une configuration invalide est en général refusé (le service garde l'ancienne configuration en mémoire) ; un restart en revanche arrêterait le service et il ne redémarrerait plus. Avec apache2ctl configtest avant, on détecte l'erreur sans interruption : c'est pourquoi on teste toujours avant de recharger.

echo "ServerTokensss Prod" | sudo tee -a /etc/apache2/conf-available/security.conf
sudo apache2ctl configtest

La commande doit signaler une erreur de syntaxe. Reviens à la dernière version saine :

cd ~/configs
git log --oneline
sudo rsync -a --no-owner --no-group --delete ~/configs/apache2/ /etc/apache2/
sudo apache2ctl configtest
sudo systemctl reload apache2
curl -sI http://localhost | grep -i '^Server'

Je comprends. Les fichiers de ~/configs/apache2 n'ont pas reçu la faute (on n'a pas recopié l'état cassé) : ils sont la dernière version saine. rsync --delete recopie cet état et supprime ce qui n'existe pas dans la source : /etc/apache2 redevient identique à la version versionnée. Les options --no-owner --no-group évitent de donner les fichiers à ton compte : ils restent la propriété de root.

Vérifie que le retour arrière est complet :

diff -r /etc/apache2 ~/configs/apache2 && echo "identique"

Étape 5 : automatiser et tester la restauration (25 min)

Planifie la sauvegarde chaque nuit à 2 h 30, en tant que root :

sudo crontab -e
# ajouter la ligne :
30 2 * * * /usr/local/bin/sauvegarde-configs.sh
sudo crontab -l

Je comprends. 30 2 * * * se lit : minute 30, heure 2, tous les jours du mois, tous les mois, tous les jours de la semaine. Une tâche planifiée qui n'a jamais été testée est une tâche qui ne marche probablement pas : lance donc le script à la main une seconde fois, puis restaure dans un dossier à part :

sudo /usr/local/bin/sauvegarde-configs.sh
mkdir -p /tmp/restauration
sudo tar -xzf "$(sudo ls -t /var/backups/configs/configs-*.tar.gz | head -n 1)" -C /tmp/restauration
sudo diff -r /tmp/restauration/etc/apache2 /etc/apache2 && echo "restauration identique"

Warning

Une sauvegarde non testée n'existe pas. C'est la restauration d'essai (et non la création de l'archive) qui prouve que tu peux revenir en arrière.

Étape 6 : tracer dans un journal des modifications (10 min)

Remplis, pour la modification de l'étape 3, le journal des modifications : version, date, auteur, raison, référence du ticket.

Partie facultative : équipement réseau Cisco (20 min)

Dans le simulateur ou Packet Tracer (manipulation d'équipement, pas une réalisation à présenter seule) :

  1. Modifie le nom d'un commutateur : hostname SW-TEST.
  2. Affiche la configuration courante : show running-config.
  3. Affiche la configuration de démarrage : show startup-config.
  4. Compare : le nom diffère-t-il ? Pourquoi ?
  5. Enregistre : copy running-config startup-config, puis redémarre l'équipement (reload) et vérifie.

Je comprends. La running-config est en mémoire vive (perdue au redémarrage), la startup-config est en mémoire non volatile (conservée). Tant qu'on n'a pas fait copy running-config startup-config, la modification n'est pas sauvegardée.

Retour en entreprise

Si ta situation le permet : observe comment ton entreprise sauvegarde les configurations de ses équipements (où, à quelle fréquence, qui le vérifie) et demande quand a eu lieu le dernier test de restauration. Note la réponse (voir Transfert en entreprise).

Bilan de la séance

Remplis ce bilan seul, honnêtement : il sert à décider ce qu'il faut reprendre. Niveau : Non maîtrisé, Maîtrise partielle, Bonne maîtrise ou Excellente maîtrise (le vocabulaire des grilles nationales d'évaluation) ; Non évalué si tu n'as pas travaillé la compétence aujourd'hui.

Compétence du référentiel Ce que j'ai fait dans cette séance Niveau
B1.1 – Gérer le patrimoine informatique
B1.5 – Mettre à disposition des utilisateurs un service informatique
B1.2 – Répondre aux incidents et aux demandes d'assistance et d'évolution

Note

Les codes sont ceux du référentiel (l'arrêté numérote des activités : les codes « B… » sont un usage courant).

Je sais faire, sans aide :

  • Définir la gestion des configurations, la CMDB et la ligne de base ;
  • Nommer et horodater des fichiers de configuration ;
  • Distinguer configuration courante et configuration de démarrage d'un équipement Cisco ;
  • Comparer deux versions d'une configuration ;
  • Automatiser une sauvegarde simple et l'essayer (restauration) ;
  • Versionner une configuration avec Git (aperçu).

Ce que je dois reprendre : ______________________

Ma question à poser à l'enseignant : ______________________