Automatiser le processus de mise à jour Apt sur Debian

I. Présentation

Dans ce tutoriel, nous allons voir comment automatiser le processus de mise à jour d'une machine Linux sous Debian ou Ubuntu. En effet, à partir d'un certain nombre d'instances de VM (ou de machines physiques), il est assez fastidieux de taper ne serait-ce qu'une fois par mois : "apt update && apt upgrade" sur toutes vos machines. L'objectif de cet article est de se la jouer fainéant, mais surtout futé en automatisant le processus.

"Je choisis une personne paresseuse pour un travail difficile, car une personne paresseuse va trouver un moyen facile de le faire." - Bill Gates 

II. Automatiser le processus de mise à jour avec un script bash

Nous allons créer un petit script bash pour réaliser notre automatisation. Afin de garder une trace de chaque exécution, je vais rediriger le contenu de stderr (en cas de retour d'une erreur lors de l'exécution du script) et stdout (en cas de succès).

Plus d'informations concernant la redirection des flux standard sous Linux.

Suivez les étapes ci-dessous, les commentaires sont là pour vous guider.

# Création du fichier
touch /home/user/script.sh 

# Edition du script
nano /home/user/script.sh

# Contenu du script "script.sh"
#!/bin/bash
echo ">>------------------------------------------------$(date)---------------------------------------------<<" >> /var/log/update_upgrade.log
echo ">>------------------errors------------------------------$(date)---------------errors------------------------------<<" >> /var/log/update_upgrade.err
export DEBIAN_FRONTEND=noninteractive
apt-get update && apt-get upgrade -y >> /var/log/update_upgrade.log 2>> /var/log/update_upgrade.err

# On donne les droits d'exécution sur le script
chmod u+x /home/user/script.sh 

# On édite la crontab 
crontab -e 

# Adaptez l'heure de la cron en fonction de l'heure à laquelle vous souhaitez faire votre test. 
06 17 * * * /home/user/script.sh

# Affichez les logs 
cat /var/log/update_upgrade.*

Je vais détailler quelques éléments du script ci-dessous :

- "DEBIAN_FRONTEND=noninteractive" : Nous allons activer ce mode par le biais de l'instanciation d'une variable DEBIAN_FRONTEND.  Utilisez ce mode lorsque vous n'avez besoin d'aucune interaction lors de l'installation ou de la mise à niveau du système via apt. Il accepte la réponse par défaut pour toutes les questions. Il peut envoyer un message d'erreur à l'utilisateur root, mais c'est tout. Une interface parfaite pour les installations automatiques. On peut utiliser ce mode dans des fichiers Dockerfile, des scripts shell, etc.

- ">> /var/log/update_upgrade.log" : Redirige la sortie standard du couple de commandes vers le fichier update_upgrade.log, afin d'avoir une trace de ce qu'il s'est passé.

- "2>> /var/log/update_upgrade.err" : Redirige la ou les erreurs en cas d'échec du couple de commandes vers le fichier update_upgrade.err. Normalement, ce fichier devrait toujours être vide. Le cas contraire indiquerait que vous avez un problème lors de l'exécution des deux commandes (il faudrait le cas échéant, déprogrammer la tâche cron, puis investiguer manuellement). Cas concret : si vous avez une coupure internet pile au moment du lancement du processus, apt vous renverra une erreur.

Il est à noter que les upgrades de tous les paquets se feront automatiquement sur Debian/Ubuntu, sauf les upgrades du noyau Linux, qui sont exclus par défaut, lorsque apt upgrade est automatisé. Pour faire ce genre de mise à jour, il faudrait manuellement taper la commande. 

Note 1 : Si au sein de votre parc informatique, vous avez un très grand nombre de machines Debian/Ubuntu (plus d'une centaine) par exemple, il serait peut-être judicieux de créer votre propre reposiotry local. Je vous laisse le soin de consulter ces deux articles si le sujet vous intéresse :

Ubuntu : comment créer son propre repository local ?  

Debian : comment créer son propre repository local ?

Note 2 : lors de la première exécution du script, il se peut que vous obteniez les messages (warnings) suivant :

cat /var/log/update_upgrade.err

Après quelques recherches, cette erreur intervient lors de la première exécution du script. Mais par la suite, vous ne devriez pas la rencontrer de nouveau.

En effet d'après ce que j'en ai déduit, le processus dpkg parent d'apt s'inquiète que la modification du mode frontend ait été changée, et nous le signale simplement. En aucun cas, ces messages qui pourraient s'apparenter à des "erreurs fatales" ne sont bloquants pour la mise à jour des dépôts distants et l'installation de nouveaux paquets, donc pas de stress ! 🙂

III. Automatiser le processus de suppression des paquets obsolètes  ?

Hum... Selon moi ce n'est pas une bonne idée, car certaines applications (anciennes ou non) peuvent reposer sur d'anciens packages. Je ne vous recommande pas d'effectuer cette automatisation au risque de perturber certains services de vos serveurs et d'occasionner un dysfonctionnement.

Selon moi, la commande "apt autoremove" doit être exécutée manuellement et avec une attention toute particulière, afin de bien évaluer l'impact de la suppression des paquets détectés comme obsolète/plus utile.

IV. Conclusion et idées d'optimisations

L'automatisation c'est génial ! Mais, gardez en tête qu'il faut de temps à autre jeter un œil au fichier de log, afin de vérifier que les automatisations fonctionnent comme vous le souhaitez.

Pour cela, je vous conseille de vous créer un fichier Excel ou équivalent avec la création d'un planning de tâche cron. C'est ce que j'utilise actuellement, et cela me permet de "prendre de la hauteur" sur l'ensemble de mes automatisations, et de ne pas être perdu parmi les nombreuses tâches cron qui s'exécute (à savoir des dizaines...).

Afin de ne pas vérifier tous les fichiers de logs apt un par un sur tous vos serveurs, il pourrait être judicieux d'implémenter un serveur RSYSLOG afin de centraliser la gestion de vos logs de mises à jour. Comme je suis sympa, je vous donne le morceau de configuration a ajouter dans la configuration rsyslog côté client (pas besoin de mettre quoi que ce soit dans la configuration côté serveur rsyslog).

Ajoutez ce bout de code à la fin du fichier /etc/rsyslog.conf de la machine qui transfert ses logs, et adaptez le en conséquence.

# ...
$ModLoad imfile
$InputFileName /var/log/update_upgrade.log
$InputFileTag tag_app_log:
$InputFileStateFile app_log1
$InputFileSeverity info
$InputFileFacility apt-update-upgrade
$InputRunFileMonitor
apt-update-upgrade @ip-du-serveur-rsyslog:514

# Si-vous utilisez TCP pour le transfert des logs au lieu d'UDP, veilliez à mettre deux @@ au lieu d'un.

A vous de jouer !

Geoffrey Sauvageot-Berland Ingénieur Cybersécurité

Ingénieur diplômé par l’état en Informatique et Cybersécurité. Généraliste, à l'origine administrateur systèmes et réseaux, j’occupe actuellement un poste d’auditeur en sécurité offensive. J’apprécie également la programmation/automatisation. Fondateur du blog : "Le Guide du SecOps", anciennement "Le Guide du SysOps"

See Full Bio