L’adaptation des scripts Shell Bash¶
1. Objectif du cours¶
Surveiller un serveur Web Apache en vérifiant périodiquement le code HTTP retourné, redémarrer automatiquement le service en cas de panne et consigner l’événement. Automatiser l’exécution du script avec cron pour éviter les vérifications manuelles.
2. Notions et définitions essentielles¶
- Code HTTP 200 : requête réussie.
- Code HTTP 404 : ressource non trouvée.
- Code HTTP 500 : erreur interne serveur.
- curl : outil de transfert de données utilisé ici pour obtenir le code HTTP d’une requête.
- bash : interpréteur utilisé pour écrire et exécuter des scripts Shell.
- cron / crontab : mécanisme Linux pour planifier l’exécution périodique de tâches.
- systemctl / service : outils pour contrôler les services (démarrer/arrêter/redémarrer).
3. Fonctionnement et principes¶
Le script exécute une requête HTTP vers le serveur et récupère uniquement le code de statut. Si ce code est différent de 200, le script enregistre un message horodaté dans un fichier de log puis tente de redémarrer le service Apache. Pour automatiser la surveillance, on planifie l’exécution régulière du script via cron. Les messages horodatés utilisent la commande date avec un format jour/heure pour garder un journal clair.
4. Commandes et manipulations¶
Regroupées par procédure, uniquement les commandes présentes dans le document avec leur rôle.
- Vérifier le statut HTTP (récupérer uniquement le code)
-
curl --write-out %{http_code} --silent --output /dev/null
Rôle : obtenir le code HTTP sans afficher le contenu HTML ni la progression. -
Création et exécution du script Bash
-
!/bin/bash¶
Rôle : indiquer l’interpréteur Bash en première ligne du fichier.
- Affectation d’une commande à une variable : var=$(commande)
Rôle : stocker le code HTTP renvoyé par curl dans une variable pour traitement. - echo "message $(date +%F\ %T)" >> /script/serveur.log
Rôle : écrire un message horodaté dans le fichier de log (création si absent). -
systemctl restart httpd
Rôle : redémarrer le service Apache lorsqu’un problème est détecté. -
Planification avec cron
- crontab -e
Rôle : éditer la table des tâches planifiées pour l’utilisateur. - Exemple de ligne de planification : */1 * * * * bash /scripts/verification_serveur.sh
Rôle : exécuter le script toutes les minutes. - Vérification et gestion du service cron : systemctl status cron ; service cron start ; crontab -l
Rôle : vérifier que cron est actif, le démarrer si nécessaire et lister les tâches enregistrées.
5. Sécurité et bonnes pratiques¶
- Vérifier le type de système et la commande adaptée pour redémarrer le service (ex. systemctl vs autre).
- S’assurer des droits d’écriture sur le fichier de log avant d’y rediriger des sorties.
- Limiter les permissions d’exécution du script (principe présenté dans la synthèse).
- Utiliser des chemins absolus pour les commandes et les fichiers (conseil évoqué).
- Vérifier régulièrement le statut du service cron pour garantir l’automatisation.
6. Points essentiels à retenir pour le TSSR¶
- Surveiller le code HTTP permet de détecter une panne applicative sans analyser le contenu HTML.
- Le code 200 = succès ; 404 = ressource manquante ; 500 = erreur interne.
- Capturer la sortie d’une commande avec $() permet de l’utiliser conditionnellement dans un script.
- En cas de code ≠ 200, journaliser l’événement avec date pour traçabilité puis tenter un redémarrage.
- Cron permet d’automatiser l’exécution périodique : comprendre la signification des champs de la crontab.
- S’assurer que cron est actif et que la tâche est bien listée dans la crontab.
- Toujours vérifier et configurer les permissions (fichier de log, exécution du script).
- Utiliser un format date+heure clair pour faciliter l’analyse des logs.
- Adapter la commande de gestion de service au système (vérifier systemctl ou alternative).
- Tester l’exécution manuelle du script avant de la mettre en production via cron.
7. Tableau récapitulatif¶
| Élément | Signification / But |
|---|---|
| Code 200 | Requête réussie — pas d’action nécessaire |
| Code 404 | Ressource non trouvée — indication d’erreur côté contenu |
| Code 500 | Erreur interne serveur — alerte critique |
| Cron | Planifier l’exécution périodique du script |
| Log (serveur.log) | Conserver trace horodatée des redémarrages |
| $() dans script | Capturer la sortie d’une commande pour traitement |
8. Vérifications pratiques¶
- Exécuter manuellement le script et observer l’affichage du code HTTP pour valider la capture du statut.
- Contrôler le fichier de log pour vérifier qu’un message horodaté a bien été ajouté après une détection d’erreur.
- Vérifier que cron est actif et lancé sur la machine (état du service cron).
- Consulter la crontab de l’utilisateur pour confirmer la présence de la ligne planifiant le script.
9. Flashcards Anki¶
Que signifie le code 200 pour une requête web ? :: Requête réussie
Que signifie le code 404 pour une requête web ? :: Ressource non trouvée
Que signifie le code 500 pour une requête web ? :: Erreur interne du serveur
Quel outil utiliser pour obtenir le code HTTP d’une requête ? :: curl
Quelle option de curl permet d’obtenir uniquement le code HTTP sans afficher le contenu ? :: --write-out %{http_code} combiné avec --silent et --output /dev/null
Comment indiquer l’interpréteur Bash en première ligne d’un script ? :: #!/bin/bash
Comment capturer la sortie d’une commande dans une variable dans un script ? :: Avec la syntaxe $(commande)
Quelle commande permet de redémarrer le service Apache telle que présentée ? :: systemctl restart httpd
Que fait la ligne */1 * * * * bash /scripts/verification_serveur.sh dans cron ? :: Exécute le script toutes les minutes
Quelle commande affiche les tâches enregistrées dans la crontab ? :: crontab -l