Aller au contenu principal

Cours : Gestion des Services et Planification des Tâches sous Linux

Objectifs d'Apprentissage​

À la fin de ce cours, vous serez capable de:

  • Comprendre la différence entre démons et services
  • Maîtriser systemd et systemctl
  • Créer et gérer vos propres services systemd
  • Planifier des tâches avec cron et at
  • Effectuer des sauvegardes avec rsync
  • Gérer la rotation des logs avec logrotate

Partie 1 – Introduction aux Démons et Services

1.1 Définition : Qu'est-ce qu'un démon ?​

Un démon (ou daemon en anglais) est un programme qui tourne en arrière-plan, sans interface graphique, et qui travaille silencieusement pour offrir des services essentiels au système ou aux utilisateurs.

Exemples simples :​

  • sshd : permet les connexions à distance via SSH
  • httpd : serveur web Apache
  • crond : planifie l'exécution de tâches
  • systemd : orchestre tous les autres services au démarrage

1.2 Définition Technique : Nature et Fonction d'un Démon​

Un démon est un processus système indépendant, lancé :

  • soit au démarrage du système
  • soit manuellement par l'administrateur
  • et qui ne s'arrête pas tant qu'il n'est pas explicitement stoppé.

Il est :

  • détaché de tout terminal ou session utilisateur (tty)
  • souvent créé par le processus init (PID 1), désormais systemd dans la majorité des distributions modernes.

1.3 Comment les démons sont-ils créés ?​

3 étapes :​

  1. Lancement initial via un fichier de configuration ou script
  2. Détachement du terminal courant
  3. Exécution en continu, souvent en boucle infinie, jusqu'à arrêt ou crash

Sur les systèmes modernes, systemd s'occupe de cette gestion automatiquement via des unités .service.

1.4 Les noms de démons finissent par d​

C'est une convention de nommage :

  • sshd → Secure Shell Daemon
  • ftpd → FTP Daemon
  • systemd → System Daemon
  • rsyslogd → Remote SYSLOG Daemon

1.5 Liste de démons courants dans Linux​

DémonFonction principale
sshdPermet les connexions SSH
crondGère les tâches planifiées
httpdFournit un service web (Apache)
systemdContrôle les services et le démarrage du système
rsyslogdGère la journalisation système
cupsdGère l'impression
ntpdSynchronise l'heure avec des serveurs NTP

1.6 Démons vs Services​

  • Un démon est un processus, un service est une abstraction logique.
  • Un service peut être un démon, mais pas toujours (ex : tmp.mount n'est pas un processus mais une unité).
ÉlémentDémonService
NatureProcessus en arrière-planUnité gérée par systemd
Visible ?Non, sauf via ps, systemctlVisible avec systemctl
Exemplesshdsshd.service

Un service c'est systemd simplement​

CritèreDémonService (systemd)
DéfinitionProgramme qui tourne en arrière-planUnité gérée par systemd pour lancer et gérer un programme
LancementAutomatique ou manuel (souvent au démarrage)Géré avec systemctl (start, stop, enable, etc.)
Tourne en arrière-plan ?OuiPas toujours (ex : un script court peut être un service)
Géré par systemctl ?Non, sauf si intégré comme serviceOui
Nécessite un fichier .serviceNonOui (ex : /etc/systemd/system/mon_service.service)
Peut exister sans systemdOui (anciens systèmes, scripts manuels)Non (service = unité systemd)
Exemplessshd, cron, script infini en arrière-plannginx.service, docker.service, mon_script.service

À retenir :​

  • Un démon est un programme.
  • Un service est une façon de gérer ce programme avec systemd.

1.7 Contrôle des démons​

Sous systemd, tous les démons sont contrôlés via systemctl, avec les commandes suivantes :

ActionCommande
Démarrersudo systemctl start sshd
Arrêtersudo systemctl stop sshd
Redémarrersudo systemctl restart sshd
Voir le statutsudo systemctl status sshd
Activer au bootsudo systemctl enable sshd
Désactiver au bootsudo systemctl disable sshd

1.8 En Résumé – Points Clés à Retenir​

  • Un démon est un processus sans interface, qui fournit un service.
  • Il est souvent démarré au boot, géré par systemd.
  • Pour voir, activer, désactiver ou relancer un démon, on utilise systemctl.
  • Tous les services système modernes sont désormais des unités gérées par systemd.

Partie 2 – Introduction à systemd et systemctl

2.1 Qu'est-ce que systemd ?​

systemd est le système d'initialisation par défaut de la majorité des distributions Linux modernes (Ubuntu, Fedora, Debian, CentOS, etc.). Il remplace l'ancien système SysVinit et sert à :

  • Initialiser le système au démarrage (montage des disques, démarrage des services, etc.)
  • Gérer tous les services système de manière centralisée
  • Offrir des outils intégrés tels que systemctl, journalctl, systemd-analyze, systemd-nspawn, etc.

Avantages de systemd :​

  • Démarrage plus rapide grâce à une initialisation parallèle
  • Redémarrage automatique des services en cas de défaillance
  • Gestion avancée des dépendances entre services
  • Centralisation de la journalisation

2.2 Le rôle de systemctl​

systemctl est l'outil principal en ligne de commande pour interagir avec systemd.

Il permet de :

  • Démarrer, arrêter ou redémarrer un service
  • Activer ou désactiver un service au démarrage
  • Obtenir le statut d'un service
  • Afficher l'ensemble des services actifs ou inactifs

2.3 Commandes fondamentales avec systemctl​

ActionCommande
Démarrer un servicesudo systemctl start nom_du_service
Arrêter un servicesudo systemctl stop nom_du_service
Redémarrage d'un servicesudo systemctl restart nom_du_service
Recharger la configurationsudo systemctl reload nom_du_service
Vérifier le statutsystemctl status nom_du_service
Activer un service au démarragesudo systemctl enable nom_du_service
Désactiver un service au démarragesudo systemctl disable nom_du_service

Remplacez nom_du_service par le nom réel du service concerné (ex : sshd, nginx, apache2, etc.).

2.4 Visualisation des services​

Afficher tous les services actifs :

systemctl list-units --type=service --state=running

Afficher tous les services (actifs ou non) :

systemctl list-units --type=service

2.5 Utilisation de journalctl pour consulter les logs​

systemd intègre un système de logs centralisé : journald. Vous pouvez consulter les journaux avec la commande journalctl.

ObjectifCommande
Voir tous les logsjournalctl
Voir les logs d'un service spécifiquejournalctl -u nom_du_service
Voir les logs depuis le dernier bootjournalctl -b
Suivre les logs en temps réeljournalctl -f
Voir les logs de la dernière heurejournalctl --since "1 hour ago"

2.6 Les unités (units) dans systemd​

Une unité est un objet que systemd peut gérer. Chaque unité correspond à un fichier avec une extension spécifique.

Type d'unitéExtensionExemple
Service.servicenginx.service
Montage.mounthome.mount
Socket.socketcups.socket
Cible.targetmulti-user.target
Minuterie.timerlogrotate.timer

2.7 Les cibles (targets) de systemd​

Une cible représente un état global du système, équivalent aux anciens niveaux d'exécution (runlevels).

Nom de la cibleDescription
rescue.targetMode de récupération (accès root uniquement)
multi-user.targetMode multi-utilisateur sans interface graphique
graphical.targetMode avec interface graphique
default.targetCible par défaut lors du démarrage

Changer la cible courante :

sudo systemctl isolate multi-user.target

2.8 Analyse des performances de démarrage​

Mesurer le temps total de démarrage :

systemd-analyze

Lister les services classés par temps de chargement :

systemd-analyze blame

Voir la chaîne des dépendances critiques :

systemd-analyze critical-chain

2.9 Gérer les redémarrages automatiques​

Pour forcer le redémarrage automatique d'un service après un échec, modifiez ou créez une unité .service avec :

[Service]
ExecStart=/chemin/vers/script
Restart=always
RestartSec=5

Cela redémarre le service 5 secondes après chaque échec.

2.10 Résumé​

  • systemd est le gestionnaire d'unités moderne des systèmes Linux
  • systemctl est l'interface en ligne de commande pour interagir avec systemd
  • Les services, cibles, sockets, et autres ressources sont appelés unités
  • journalctl permet de consulter les logs système
  • Les outils comme systemd-analyze permettent d'analyser les performances au démarrage

Partie 3 – Créer et Gérer ses Propres Services avec systemd

3.1 Objectif de cette partie​

Comprendre comment :

  • Créer une unité de service personnalisée
  • Intégrer un script système dans systemd
  • Tester, activer, désactiver et relancer ce service

3.2 Structure d'un fichier .service​

Les fichiers de service se trouvent généralement dans :

  • /etc/systemd/system/ (unités personnalisées et persistantes)
  • /lib/systemd/system/ (unités installées par les paquets)

Exemple de fichier webapp.service :​

[Unit]
Description=Service personnalisé pour lancer une application web
After=network.target

[Service]
ExecStart=/usr/local/bin/webapp
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Explication des sections :​

  • [Unit] : dépendances du service, description
  • [Service] : commande à exécuter, politique de redémarrage
  • [Install] : cible d'activation (ici, niveau multi-utilisateur)

3.3 Étapes de création d'un service systemd personnalisé​

Étape 1 – Écrire ou localiser le script à exécuter​

Exemple :

sudo nano /usr/local/bin/webapp

Contenu du script :

#!/bin/bash
while true; do
  echo "Application en cours d'exécution" >> /var/log/webapp.log
  sleep 30
done

Rendre le script exécutable :

sudo chmod +x /usr/local/bin/webapp

Étape 2 – Créer l'unité de service​

sudo nano /etc/systemd/system/webapp.service

Copiez le contenu suivant :

[Unit]
Description=Web Application Custom Service
After=network.target

[Service]
ExecStart=/usr/local/bin/webapp
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

Étape 3 – Activer et démarrer le service​

Recharger systemd pour prendre en compte le nouveau fichier :

sudo systemctl daemon-reload

Activer le service au démarrage :

sudo systemctl enable webapp

Démarrer le service :

sudo systemctl start webapp

Étape 4 – Vérifier le bon fonctionnement​

Afficher l'état du service :

systemctl status webapp

Vérifier les journaux :

journalctl -u webapp

3.4 Modifier un service déjà en place​

Si vous modifiez le fichier .service :

  1. Sauvegardez
  2. Rechargez la configuration :
sudo systemctl daemon-reload
  1. Redémarrez le service :
sudo systemctl restart webapp

3.5 Supprimer un service personnalisé​

Désactiver le service :

sudo systemctl disable webapp

Arrêter le service :

sudo systemctl stop webapp

Supprimer le fichier d'unité :

sudo rm /etc/systemd/system/webapp.service

Recharger systemd :

sudo systemctl daemon-reload

3.6 Cas pratique : Redémarrage automatique d'un script planté​

Dans le bloc [Service], utilisez :

Restart=always
RestartSec=5

Cela permet :

  • Un redémarrage automatique après échec
  • Une attente de 5 secondes entre chaque redémarrage

3.7 Cas pratique : Service temporaire non persistant​

Créer un service que l'on souhaite exécuter uniquement une fois, sans l'enregistrer pour les démarrages futurs :

sudo systemctl start /etc/systemd/system/webapp.service

Sans enable, le service ne sera pas lancé au prochain redémarrage.

3.8 Résumé​

  • Les services personnalisés systemd sont définis dans des fichiers .service
  • Ils permettent d'intégrer n'importe quel script au système
  • L'utilisation des commandes daemon-reload, enable, start, status est essentielle
  • Un bon service inclut une politique de redémarrage robuste
  • La structure [Unit], [Service], [Install] est obligatoire
Annexe de partie 3 – On ne peut pas « tuer » un service avec kill ou lsof

Cette annexe démontre qu’on ne peut pas arrêter durablement un service géré par systemd en utilisant kill, kill -9 ou en s’attaquant au processus (ex. via lsof / ss). systemd le relance tant que la politique Restart=always est en vigueur. La seule façon propre de l’arrêter est systemctl stop (et éventuellement disable ou mask).

Vérifier que le service tourne et écrit dans le log​

cat /var/log/webapp.log
cat /var/log/webapp.log | wc -l

Voir le PID du service​

sudo systemctl status webapp

Tu vas voir une ligne du genre : Main PID: 1234 (webapp).

Tuer le processus avec kill (SIGTERM)​

sudo kill 1234

Puis revérifier :

sudo systemctl status webapp

Tu vas observer que le service repasse active (running) avec un nouveau PID : systemd l’a relancé.

Plus agressif : kill -9 (SIGKILL)​

sudo kill -9 <NOUVEAU_PID>
sudo systemctl status webapp

Même résultat : systemd redémarre encore le processus, car Restart=always.

Preuve en direct​

Dans un terminal, suivre les logs du service :

sudo journalctl -u webapp -f

Tu verras les redémarrages successifs après chaque kill ou kill -9.

La solution : arrêter via systemd​

sudo systemctl stop webapp
sudo systemctl status webapp

Pour éviter que le service ne reparte au prochain démarrage ou ne soit relancé par systemd :

  • Option A (simple) – Désactiver au démarrage
sudo systemctl disable webapp
  • Option B (forte) – Masquer le service (impossible à démarrer)
sudo systemctl mask webapp

Après mask, même systemctl start webapp ne pourra plus le démarrer tant que tu n’as pas fait sudo systemctl unmask webapp.

Rappel : signaux et outils​

ActionCommande / outil
Terminaison « propre » (SIGTERM)kill -15 <PID> ou kill <PID>
Forcer l’arrêt (SIGKILL)kill -9 <PID>
Voir qui utilise des ports / fichierssudo lsof -i, sudo lsof -i :80
Voir ports TCP/UDP en écoutesudo ss -ltnp, sudo ss -lunp, sudo ss -ltnp | grep -i ...

Ces outils servent à diagnostiquer (quel processus écoute sur un port, etc.) ; pour arrêter un service, il faut passer par systemctl stop.

Annexe de partie 3 (2) – Même exercice avec le service webapp (scénario type examen)

Cette annexe reprend la même démonstration qu’en Annexe 1, mais en utilisant uniquement le service webapp créé à l’étape 3 de ce chapitre (script qui écrit dans /var/log/webapp.log), sans nginx ni Wiki.js. Elle peut servir de base pour un examen du type Services systemd et gestion des processus.

Prérequis : le service webapp a été créé, activé et démarré comme dans les sections 3.2 et 3.3 (script /usr/local/bin/webapp, unité /etc/systemd/system/webapp.service, Restart=always).

Étape 1 – Vérification du service et du log​

Vérifier que le service tourne et écrit dans le log :

cat /var/log/webapp.log
cat /var/log/webapp.log | wc -l
sudo systemctl status webapp

Dans la sortie de systemctl status webapp, noter la ligne Main PID: XXXX (webapp).

Étape 2 – Tentative d’arrêt manuel (kill)​

Remplacer <PID> par le Main PID affiché :

sudo kill -15 <PID>
# ou simplement : sudo kill <PID>

Puis revérifier :

sudo systemctl status webapp

Observation : le service repasse active (running) avec un nouveau PID ; systemd l’a relancé à cause de Restart=always.

Étape 3 – Tentative plus agressive (kill -9)​

Utiliser le nouveau PID affiché par systemctl status webapp :

sudo kill -9 <NOUVEAU_PID>
sudo systemctl status webapp

Observation : même résultat — systemd redémarre encore le processus.

Étape 4 – Preuve en direct (journalctl)​

Dans un terminal, suivre les logs du service pour voir les redémarrages après chaque kill :

sudo journalctl -u webapp -f

Étape 5 – Identification du service (si on partait du processus)​

Si on avait seulement un PID ou un port, on pourrait identifier le service ainsi :

systemctl list-units --type=service --state=running | grep -i webapp
ps aux | grep webapp
ls -l /etc/systemd/system/ | grep webapp

Pour un service écoutant sur un port (ex. 3000), on utiliserait aussi :

sudo lsof -i -P -n | grep 3000
sudo ss -ltnp | grep 3000

Ici, webapp n’écoute pas sur un port ; il remplit uniquement /var/log/webapp.log.

Étape 6 – Solution : arrêt et désactivation via systemd​

Arrêt immédiat :

sudo systemctl stop webapp
sudo systemctl status webapp

Désactivation au démarrage (le service ne repartira plus au prochain boot) :

sudo systemctl disable webapp

Option plus forte — masquer le service (impossible à démarrer tant qu’il est masqué) :

sudo systemctl mask webapp

Pour annuler le masquage plus tard : sudo systemctl unmask webapp.

Outils complémentaires (bonus) – Investigation et diagnostic​

Ces commandes permettent d’approfondir l’investigation sur les services et les ports. Elles sont utiles en examen ou en dépannage.

1. systemd-cgls — Arbre des groupes de contrôle (cgroups)​

Affiche la hiérarchie des cgroups gérés par systemd : chaque service (dont webapp) vit dans un sous-arbre. Utile pour voir comment systemd regroupe les processus.

systemd-cgls

Pour ne voir que la partie concernant notre service :

systemd-cgls | grep -A 5 webapp

À quoi ça sert ? Comprendre que systemd isole et suit chaque unité dans un cgroup ; cela explique pourquoi un simple kill du processus ne « désinscrit » pas le service — systemd surveille l’unité et la relance selon Restart=always.

2. ss -lptn — Ports TCP en écoute et processus​

Liste les sockets TCP en écoute avec le PID et le programme associé (-l écoute, -p processus, -t TCP, -n ports en numérique).

sudo ss -lptn

Exemple de sortie (extrait) :

LISTEN  0  128  *:80    *:*  users:(("nginx",pid=1234,fd=6))
LISTEN  0  128  *:3000  *:*  users:(("node",pid=5678,fd=21))

Dans notre contexte : le service webapp de l’étape 3 n’écoute sur aucun port (il écrit seulement dans /var/log/webapp.log). Si tu créais plus tard un service qui écoute sur le port 3000 (par ex. une API ou un proxy), tu le verrais ici. C’est l’équivalent moderne de netstat -lptn, plus rapide.

3. fuser -k 3000/tcp — Tuer les processus qui utilisent un port​

fuser indique quels processus utilisent un fichier ou un port. L’option -k envoie SIGKILL à ces processus.

Exemple pour le port 3000 (à utiliser si un service écoute sur ce port) :

sudo fuser -k 3000/tcp

Comportement pédagogique : si un service systemd (par ex. un futur « webapp-api ») écoutait sur le port 3000 avec Restart=always, après fuser -k 3000/tcp le processus serait tué, mais systemd le relancerait et le port serait à nouveau occupé. Pour libérer durablement le port, il faut systemctl stop <service> (et éventuellement disable).

Sans -k, on affiche seulement les PID sans tuer : sudo fuser -v 3000/tcp.

4. journalctl -u webapp — Journaux du service (équivalent de journalctl -u wikijs.service)​

Affiche tous les messages journald pour l’unité webapp (démarrages, arrêts, redémarrages, erreurs).

journalctl -u webapp

Variantes utiles :

CommandeEffet
journalctl -u webappTous les logs du service
journalctl -u webapp -fSuivre les logs en temps réel (comme tail -f)
journalctl -u webapp -n 50Les 50 dernières lignes
journalctl -u webapp --since "1 hour ago"Logs de la dernière heure

À quoi ça sert ? Voir la preuve que systemd relance le service après un kill ou un fuser -k, et diagnostiquer les erreurs au démarrage.

Synthèse (type examen)​

ActionCommandeEfficace ?
Arrêter le processus avec un signalkill -15 <PID> ou kill -9 <PID>Non — systemd relance le service
Arrêter le service proprementsudo systemctl stop webappOui
Éviter le redémarrage au bootsudo systemctl disable webappOui
Empêcher tout démarrage (même manuel)sudo systemctl mask webappOui

À retenir : avec un service systemd configuré en Restart=always, kill et kill -9 ne suffisent pas ; il faut utiliser systemctl stop, puis disable (et éventuellement mask) pour une désactivation définitive.

Partie 4 – Planification de Tâches avec cron

4.1 Introduction​

cron est un outil qui permet de programmer des tâches répétitives sous Linux. Le démon crond s'exécute en arrière-plan et lit les fichiers crontab pour exécuter les commandes à une date/heure précises.

4.2 Structure d'une tâche cron​

*     *     *     *     *   commande à exécuter
-     -     -     -     -
|     |     |     |     |
|     |     |     |     +----- jour de la semaine (0 à 6, dimanche = 0)
|     |     |     +----------- mois (1 à 12)
|     |     +----------------- jour du mois (1 à 31)
|     +----------------------- heure (0 à 23)
+---------------------------- minute (0 à 59)

4.3 Astuce pour s'entraîner rapidement​

Modifier la crontab pour l'utilisateur courant :

crontab -e

Afficher les tâches cron existantes :

crontab -l

4.4 Exercice 1 – Sauvegarde de /etc tous les dimanches à 3h​

Objectif :​

Créer un script qui archive /etc dans /var/backups.

Étapes :​

  1. Créer un dossier d'exercice :
mkdir ~/cron_tp && cd ~/cron_tp
  1. Créer un fichier backup.sh :
nano backup.sh

Contenu :

#!/bin/bash
tar -czf /var/backups/etc-backup-$(date +%Y%m%d).tar.gz /etc
  1. Rendre le script exécutable :
chmod +x backup.sh
  1. Créer le dossier de destination si besoin :
sudo mkdir -p /var/backups
  1. Ajouter à la crontab :
crontab -e

Ajouter la ligne suivante :

0 3 * * 0 /home/utilisateur/cron_tp/backup.sh

Remplacez utilisateur par votre nom d'utilisateur Linux.

4.5 Exercice 2 – Amuse-toi avec du texte​

Objectif :​

Écrire « Bonjour ! Nous sommes le [date] » toutes les 5 minutes dans un fichier.

Commande dans la crontab :​

*/5 * * * * echo "Bonjour ! Nous sommes le $(date)" >> /tmp/bonjour.txt

Vérifiez ensuite :

tail /tmp/bonjour.txt

4.6 Exercice 3 – Créer une page web dynamique qui change toutes les minutes​

Objectif :​

Télécharger différentes pages web toutes les minutes et les afficher dans le dossier web.

Étapes :​

  1. Créer un fichier mypage.sh :
nano ~/cron_tp/mypage.sh

Contenu :

#!/bin/bash
urls=("www.yahoo.com" "www.cmaisonneuve.qc.ca" "www.crosemont.qc.ca" "www.netflix.com")

index_file="/home/$USER/index.txt"
backup_dir="/var/www/html"

index=0
if [[ -f "$index_file" ]]; then
  read -r index < "$index_file"
fi

url=${urls[$((index % ${#urls[@]}))]}
wget -qO "$backup_dir/index.html" --timeout=10 "$url"

next_index=$(( (index + 1) % ${#urls[@]} ))
echo "$next_index" > "$index_file"
  1. Rendre le script exécutable :
chmod +x ~/cron_tp/mypage.sh
  1. Lancer la tâche toutes les minutes :
crontab -e

Ajouter :

* * * * * /home/utilisateur/cron_tp/mypage.sh
  1. Tester en accédant à :
http://localhost/index.html

Chaque minute, la page changera automatiquement.

4.7 Exercice 4 – Observer les processus et les utilisateurs​

Objectif :​

Observer qui est connecté et quels processus tournent entre 9h et 17h.

Ajouter à la crontab :​

# Toutes les heures entre 9h et 17h : processus
0 9-17 * * 1-5 ps aux >> /var/log/processus.txt

# Toutes les 5 minutes entre 9h et 17h : utilisateurs connectés
*/5 9-17 * * 1-5 who >> /var/log/qui.txt

Visualiser ensuite :

tail /var/log/processus.txt
tail /var/log/qui.txt

4.8 Astuce : tester ses tâches cron en direct​

Pour s'assurer que tout fonctionne :

  1. Mettre une tâche chaque minute :
* * * * * echo "Tâche test à $(date)" >> ~/cron.log
  1. Lancer :
tail -f ~/cron.log

Attendez une minute : la ligne s'affichera automatiquement.

4.9 Résumé​

  • cron permet d'exécuter des scripts à des moments précis, automatiquement.
  • Un script cron doit être exécutable et spécifier un chemin absolu.
  • Vous pouvez observer les résultats avec tail, ou créer des fichiers .log pour vérifier vos essais.
  • Ce système permet de faire des sauvegardes, des tests automatisés, ou de mettre à jour dynamiquement des services.

Partie 5 – Tâches Ponctuelles avec at

5.1 Qu'est-ce que at ?​

Le programme at permet de programmer une tâche unique à exécuter plus tard, une seule fois (contrairement à cron, qui est répétitif).

C'est parfait pour :

  • Planifier un redémarrage du système
  • Lancer un script de traitement différé
  • Automatiser une opération sensible à un moment précis

5.2 Vérification et installation du service atd​

Avant toute chose, assurez-vous que le démon atd est actif :

sudo systemctl start atd
sudo systemctl enable atd
sudo systemctl status atd

Si at n'est pas installé :

sudo apt install at   # Debian/Ubuntu
sudo yum install at   # CentOS/RHEL

5.3 Syntaxe de base​

at <heure ou moment>

Exemples :

at now + 1 minute
at 17:00
at 09:30 tomorrow
at now + 2 days

Une fois dans l'éditeur at>, tapez la commande à exécuter, puis terminez par Ctrl + D.

5.4 Exercice 1 – Planifier un message différé​

Objectif :​

Afficher un message sur votre terminal dans 1 minute.

  1. Lancez la commande :
at now + 1 minute
  1. Dans le prompt at>, tapez :
echo "Ceci est un message planifié avec at"
  1. Terminez avec :
Ctrl + D
  1. Attendez une minute et vérifiez que le message s'affiche.

5.5 Exercice 2 – Script différé sur un autre terminal​

Objectif :​

Afficher un message sur un autre terminal (ex: /dev/pts/0).

  1. Créez un script traitement.sh :
nano ~/cron_tp/traitement.sh

Contenu :

#!/bin/bash
echo "Message différé sur le terminal /dev/pts/0" > /dev/pts/0
  1. Rendre le script exécutable :
chmod +x ~/cron_tp/traitement.sh
  1. Planifier le script :
at now + 2 minutes -f ~/cron_tp/traitement.sh

Ouvrez le terminal pts/0 en parallèle et observez.

5.6 Gestion des tâches at​

ActionCommande
Voir les tâches planifiéesatq ou at -l
Supprimer une tâche (ID = 5 par ex.)atrm 5 ou at -d 5
Voir le contenu de la tâche ID 5at -c 5

5.7 Contrôle d'accès à at​

FichierFonction
/etc/at.allowSeuls les utilisateurs listés ici peuvent utiliser at
/etc/at.denyTous les utilisateurs sauf ceux listés ici peuvent utiliser at

Priorité :

  • Si at.allow existe, seuls les utilisateurs dans ce fichier ont le droit.
  • Sinon, at.deny s'applique.

Exemple : interdire toto​

echo toto >> /etc/at.deny

5.8 Exercice 3 – Planifier un redémarrage vendredi à 17h​

Objectif :​

Automatiser un redémarrage à une date précise.

  1. Tapez :
at 17:00 Fri
  1. Dans le prompt at>, entrez :
sudo /sbin/shutdown -r now
  1. Terminez avec Ctrl + D

Note : Pour tester sans redémarrage, utilisez echo "Redémarrage prévu" à la place.

5.9 Exercice 4 – Script automatique dans 2 jours​

  1. Créez un script simple :
echo "echo Traitement terminé dans 2 jours" > ~/cron_tp/futur.sh
chmod +x ~/cron_tp/futur.sh
  1. Planifiez-le :
at now + 2 days -f ~/cron_tp/futur.sh

5.10 Résumé​

  • at est utile pour des tâches ponctuelles, uniques, différées.
  • Il est complémentaire de cron, qui est cyclique.
  • Vous pouvez observer immédiatement l'effet avec echo, ou construire des scripts différés.

Partie 6 – Sauvegardes Avancées et Planifiées avec rsync

6.1 Pourquoi utiliser rsync ?​

rsync est un outil de synchronisation puissant qui permet de copier des fichiers :

  • localement ou entre deux machines
  • de manière optimisée (il ne copie que les fichiers modifiés)
  • avec compression, filtrage, sauvegarde et journalisation

Il est idéal pour :

  • des sauvegardes régulières
  • des migrations de serveurs
  • des copies différentielles rapides

6.2 Syntaxe de base​

rsync [options] source destination

Exemple simple :

rsync -av /home/user/documents /mnt/backup/

Options fréquentes :

  • -a : archive (préserve les permissions, liens, dates)
  • -v : verbose (affiche ce qui est copié)
  • --delete : supprime les fichiers absents de la source
  • --bwlimit=KBps : limite la bande passante utilisée

6.3 Exercice 1 – Sauvegarde locale avec limitation de bande passante​

Objectif :​

Sauvegarder le dossier /home dans /mnt/backup tous les soirs à 20h, sans saturer la bande passante.

Étapes :​

  1. Créer le script :
mkdir -p ~/cron_tp
nano ~/cron_tp/sync_home.sh

Contenu :

#!/bin/bash
rsync -av --delete --bwlimit=200 /home/ /mnt/backup/
  1. Rendre le script exécutable :
chmod +x ~/cron_tp/sync_home.sh
  1. Ajouter dans crontab :
crontab -e

Ajouter :

0 20 * * * /home/utilisateur/cron_tp/sync_home.sh

(Remplacez utilisateur par votre nom réel)

6.4 Exercice 2 – Synchronisation à distance​

Objectif :​

Synchroniser /var/www vers un autre serveur via SSH.

  1. Commande directe (à tester manuellement avant automatisation) :
rsync -avz -e ssh /var/www user@remote_host:/backup/www
  1. Script automatisé :
nano ~/cron_tp/rsync_remote.sh

Contenu :

#!/bin/bash
rsync -az -e ssh /var/www user@192.168.0.100:/backup/www
  1. Crontab (exécution quotidienne à 01h) :
0 1 * * * /home/utilisateur/cron_tp/rsync_remote.sh

Pré-requis :

  • accès SSH sans mot de passe (clé publique/privée configurée)
  • droits en écriture sur /backup/www sur la machine distante

6.5 Exercice 3 – Sauvegarde uniquement la nuit​

Objectif :​

Limiter l'exécution de rsync aux heures non ouvrables (19h à 7h). Arrêter tout processus rsync en journée.

Étapes :​

  1. Script de lancement rsync :
crontab -e

Ajouter :

0 19 * * * /home/utilisateur/cron_tp/sync_home.sh
  1. Script d'arrêt de sécurité :
0 7 * * * pkill rsync

Cela garantit que :

  • rsync commence à 19h
  • S'il est encore actif à 7h, il est tué

6.6 Exercice 4 – Sauvegarde avec journalisation​

  1. Script :
nano ~/cron_tp/rsync_logged.sh

Contenu :

#!/bin/bash
date >> /var/log/rsync_backup.log
rsync -av --delete /home /mnt/backup >> /var/log/rsync_backup.log 2>&1
  1. Planification quotidienne :
0 22 * * * /home/utilisateur/cron_tp/rsync_logged.sh
  1. Lecture du journal :
tail -n 20 /var/log/rsync_backup.log

6.7 Résumé​

  • rsync est un outil rapide, intelligent, et contrôlable
  • Il peut être limité en bande passante avec --bwlimit
  • Il peut être automatisé avec cron
  • Il peut être restreint à certaines plages horaires
  • Il permet une journalisation complète pour audit et suivi

Partie 7 – Gestion des Logs et Rotation avec logrotate

7.1 Pourquoi utiliser logrotate ?​

Les journaux systèmes (dans /var/log/) augmentent continuellement avec le temps :

  • Ils peuvent saturer le disque
  • Deviennent lourds à consulter
  • Peuvent réduire les performances si mal gérés

logrotate permet de :

  • Faire une rotation automatique des logs
  • Supprimer ou compresser les anciens fichiers
  • Conserver un historique limité dans le temps
  • Exécuter une commande après la rotation (ex : redémarrer un service)

7.2 Fonctionnement général​

logrotate est généralement exécuté quotidiennement par cron, via :

/etc/cron.daily/logrotate

Il lit la configuration globale :

/etc/logrotate.conf

Et les configurations spécifiques :

/etc/logrotate.d/

7.3 Syntaxe d'un fichier de configuration​

Exemple :​

/var/log/webapp.log {
    weekly
    rotate 4
    compress
    missingok
    notifempty
    postrotate
        systemctl restart webapp
    endscript
}

Explications :​

  • weekly : rotation chaque semaine
  • rotate 4 : conserver 4 anciens fichiers
  • compress : compresser les anciens logs
  • missingok : ne pas afficher d'erreur si le fichier est manquant
  • notifempty : ne pas tourner le fichier s'il est vide
  • postrotate : exécuter une commande après la rotation

7.4 Exercice 1 – Rotation d'un journal personnalisé​

Objectif :​

Faire la rotation de /var/log/rsync_backup.log chaque semaine, garder 4 versions compressées.

  1. Créer le fichier /etc/logrotate.d/rsync_backup :
sudo nano /etc/logrotate.d/rsync_backup
  1. Contenu :
/var/log/rsync_backup.log {
    weekly
    rotate 4
    compress
    missingok
    notifempty
}
  1. Tester la configuration :
sudo logrotate /etc/logrotate.conf --debug
  1. Forcer la rotation pour test :
sudo logrotate /etc/logrotate.conf --force
  1. Vérifier :
ls -lh /var/log/rsync_backup*

7.5 Exercice 2 – Rotation avec redémarrage de service​

Objectif :​

Faire la rotation de /var/log/webapp.log et redémarrer le service webapp.

  1. Créer le fichier :
sudo nano /etc/logrotate.d/webapp
  1. Contenu :
/var/log/webapp.log {
    weekly
    rotate 2
    compress
    missingok
    notifempty
    postrotate
        systemctl restart webapp
    endscript
}
  1. Forcer une rotation pour tester :
sudo logrotate -f /etc/logrotate.conf

7.6 Exercice 3 – Rotation et envoi par courriel (simulation)​

Objectif :​

Envoyer les 100 dernières lignes du fichier /var/log/syslog chaque nuit à minuit.

  1. Ajouter dans la crontab :
crontab -e

Contenu :

0 0 * * * tail -n 100 /var/log/syslog | mail -s "Derniers logs système" votreadresse@email.com
  1. Pour tester l'envoi localement :
mail

Prérequis : le système doit avoir un agent de mail installé (mailutils, sendmail, postfix...).

7.7 Exercice 4 – Rotation personnalisée d'un fichier simulé​

  1. Créez un faux journal :
echo "ligne test" >> /tmp/test.log
  1. Créez le fichier /etc/logrotate.d/testlog :
sudo nano /etc/logrotate.d/testlog

Contenu :

/tmp/test.log {
    daily
    rotate 3
    compress
    missingok
    notifempty
}
  1. Forcez la rotation :
sudo logrotate -f /etc/logrotate.conf
  1. Observez les fichiers :
ls -lh /tmp/test.log*

7.8 Résumé​

  • logrotate gère la taille, la fréquence, la conservation et la compression des logs
  • Il s'intègre parfaitement avec cron (via /etc/cron.daily/logrotate)
  • Il peut redémarrer des services ou envoyer des mails
  • Les fichiers de configuration personnalisés vont dans /etc/logrotate.d/

Partie 8 – Quiz Final et Évaluation Pratique

8.1 Objectif pédagogique​

Valider que l'apprenant sait :

  • Créer, activer et surveiller un service systemd personnalisé
  • Planifier des tâches répétitives et ponctuelles avec cron et at
  • Synchroniser des dossiers avec rsync et limiter la bande passante
  • Gérer la rotation des journaux avec logrotate
  • Utiliser les bons outils de surveillance (systemctl, journalctl, logrotate, etc.)

8.2 Partie A – Lecture et analyse de crontab (5 points)​

Expliquez ce que fait chaque ligne suivante :

  1. 0 3 * * 0 /usr/local/bin/backup.sh
  2. */10 9-17 * * 1-5 who >> /var/log/connected.log
  3. @reboot systemctl restart nginx
  4. 0 19 * * * /home/user/sync.sh
  5. 0 7 * * * pkill rsync

8.3 Partie B – Création de service systemd (15 points)​

Vous devez créer un service appelé weather_logger qui :

  • Exécute un script /usr/local/bin/weather.sh
  • Écrit la température dans /var/log/weather.log toutes les 5 minutes (via cron)
  • Le service doit se relancer automatiquement en cas d'échec
  • Fournir le fichier weather_logger.service
  • Activer et démarrer le service
  • Vérifier son statut et ses logs

8.4 Partie C – Planification différée avec at (5 points)​

  1. Créez un script /home/user/alert.sh qui envoie un message "Test de sécurité terminé" dans un fichier /tmp/alerte.log.
  2. Programmez ce script pour qu'il s'exécute dans 2 heures exactement à partir de maintenant.

8.5 Partie D – Synchronisation rsync (10 points)​

Créez un script sync_project.sh qui :

  • Sauvegarde le dossier /home/user/projects/ vers /mnt/sauvegardes/
  • Supprime les fichiers obsolètes (--delete)
  • Limite la bande passante à 150 KB/s
  • Enregistre les actions dans /var/log/sync.log

Planifiez ce script pour qu'il s'exécute tous les soirs à 22h.

8.6 Partie E – Rotation de logs avec logrotate (10 points)​

  1. Créez un fichier de configuration /etc/logrotate.d/weather pour le fichier /var/log/weather.log

  2. Exigences :

    • Rotation hebdomadaire
    • 3 fichiers conservés
    • Compression activée
    • Rotation même si vide
    • Redémarrage du service weather_logger après la rotation

8.7 Partie F – Étude de cas finale : scénario complet (15 points)​

Contexte : Vous gérez un serveur Linux sur lequel tourne une application personnalisée (/usr/local/bin/monitor.py).

Objectifs :

  1. Créer un service monitor.service qui exécute ce script au démarrage du système.
  2. Planifier une sauvegarde du répertoire /opt/monitoring tous les jours à 1h dans /mnt/monitor_backup avec rsync, limitée à 250 KB/s.
  3. Créer un fichier /etc/logrotate.d/monitoring.log pour /var/log/monitoring.log, avec rotation tous les 2 jours, conservation de 5 logs compressés.
  4. Envoyer les 100 dernières lignes de /var/log/syslog par mail chaque matin à 6h à admin@example.com.

8.8 Barème (sur 60 points)​

PartiePoints
A – Analyse de crontab5
B – Service systemd15
C – Planification avec at5
D – Script rsync10
E – logrotate personnalisé10
F – Cas complet15

8.9 Consignes finales​

  • Tous les scripts doivent être exécutable (chmod +x)

  • Les chemins doivent être absolus

  • Vous devez montrer la sortie de :

    • systemctl status
    • journalctl -u
    • ls -lh dans les répertoires de logs et sauvegardes

Chapitre créé le: Décembre 2024