Debian : Mises à Jour Automatiques
Un des gros problèmes souvent rencontré dans l’administration d’un système est la mise à jour. Combien de fois peut-on voir sur les forums quelqu’un se plaindre de s’être fait hacker son serveur et, dans le même temps, avouer benoîtement ne pas en avoir passé une seule depuis l’installation ! Les différentes distributions mettent pourtant en place des système de gestion des packages (yum ou apt), mais on n’a pas forcément toujours le temps de régulièrement se connecter sur son ou (surtout) ses serveurs pour s’en occuper.
Pour résoudre ce problème, Debian, mais aussi Ubuntu, proposent un package, unattended-upgrade, permettant d’automatiser les mises à jour. Ce n’est pas la panacée, une mise à jour présente toujours le risque de casser quelque chose et mieux vaut toujours les passer manuellement, mais c’est toujours mieux que de rien faire.
Installer et Activer Unattended-Upgrade
Un simple apt-get suffit.
1 2 3 4 | root@server:~# apt-get install unattended-upgrades Reading package lists... Done Building dependency tree Reading state information... Done |
Voilà, c’est a priori simple, mais, par défaut, unattended-upgrade n’est pas activé. Il faudra donc créer le fichier /etc/apt/apt.conf.d/02periodic. La configuration suivante est un bon point de départ :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 | root@server:~# cat /etc/apt/apt.conf.d/02periodic // Enable the update/upgrade script (0=disable) APT::Periodic::Enable "1"; // Do "apt-get update" automatically every n-days (0=disable) APT::Periodic::Update-Package-Lists "1"; // Do "apt-get upgrade --download-only" every n-days (0=disable) APT::Periodic::Download-Upgradeable-Packages "1"; // Run the "unattended-upgrade" security upgrade script // every n-days (0=disabled) // Requires the package "unattended-upgrades" and will write // a log in /var/log/unattended-upgrades APT::Periodic::Unattended-Upgrade "1"; // Do "apt-get autoclean" every n-days (0=disable) APT::Periodic::AutocleanInterval "7"; // - Send report mail to root // 0: no report (or null string) // 1: progress report (actually any string) // 2: + command outputs (remove -qq, remove 2>/dev/null, add -d) // 3: + trace on APT::Periodic::Verbose "1"; // sleep for a random interval of time (default 30min) APT::Periodic::RandomSleep "1800"; |
Le script que vous venez ainsi de configurer est /etc/cron.daily/apt et il est exécuté (normalement) par défaut tous les jours à 6h25, en tous cas sur mon système :
1 2 | root@ns203445:~# cat /etc/crontab | grep cron.daily 25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ) |
Je n’arrive pas à savoir si le 6h25 est systématique sur tous les systèmes Debian/Ubuntu. Cela semble être le cas et, dans le doute, il est dans l’intérêt de tout le monde, soit de changer l’heure d’exécution, soit de bien activer le paramètre APT::Periodic::RandomSleep "1800"; afin d’éviter de saturer les serveurs hébergeant les repos.
Si vous utilisez Ubuntu, le fonctionnement d’unattended-upgrade est le même à ceci près que le fichier 10periodic se substitue au fichier 02periodic de Debian et est créé à lors de l’installation.
Configurer unattended-upgrades
Pour configurer plus finement le comportement d’unattended-upgrade, il suffit de modifier le fichier /etc/apt/apt.conf.d/50unattended-upgrades. Par défaut, seules les mises à jour de sécurité sont passées :
1 | "origin=Debian,archive=stable,label=Debian-Security"; |
Et honnêtement, ce n’est pas plus mal. De même, je pense que certains packages ne devraient jamais être mis à jour automatiquement et que les reboots automatiques sont une très mauvaise idée :
1 2 3 4 5 6 7 8 9 10 11 | // List of packages to not update Unattended-Upgrade::Package-Blacklist { "grub*"; // "vim"; // "libc6"; // "libc6-dev"; // "libc6-i686"; }; // Automatically reboot *WITHOUT CONFIRMATION* if a // the file /var/run/reboot-required is found after the upgrade Unattended-Upgrade::Automatic-Reboot "false"; |
Maintenant, tout dépend de votre système, de vos besoins et de vos préférences personnelles.
Ajouter des Repository
La configuration jusqu’à maintenant permet de gérer les mises à jour automatiques des packages issus des repository Debian. Mais comment rajouter un repository tiers (third party) comme dotdeb par exemple ?
Cette configuration est gérée au niveau du paramètre Origins-Pattern et il faut d’abord connaître les valeurs origin, archive et label etc. du repository. On les obtient assez simplement :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | root@server:~# apt-cache policy Package files: 100 /var/lib/dpkg/status release a=now 500 http://packages.dotdeb.org/ wheezy-php55/all amd64 Packages release o=packages.dotdeb.org,a=stable,n=wheezy-php55,l=packages.dotdeb.org,c=all origin packages.dotdeb.org 500 http://packages.dotdeb.org/ wheezy/all amd64 Packages release o=packages.dotdeb.org,a=stable,n=wheezy,l=packages.dotdeb.org,c=all origin packages.dotdeb.org 500 http://security.debian.org/ wheezy/updates/main Translation-en 500 http://security.debian.org/ wheezy/updates/main amd64 Packages release v=7.0,o=Debian,a=stable,n=wheezy,l=Debian-Security,c=main origin security.debian.org 500 http://debian.mirrors.ovh.net/debian/ wheezy/main Translation-en 500 http://debian.mirrors.ovh.net/debian/ wheezy/main amd64 Packages release v=7.5,o=Debian,a=stable,n=wheezy,l=Debian,c=main origin debian.mirrors.ovh.net Pinned packages: |
Pour rappel et explication
- o = Release Origin/Vendor (Debian, Ubuntu, Grml, CRAN, ETHZ, Opera Software ASA, LP-PPA-
, “Google, Inc.”, etc.) - v = Release Version (6.0, 12.04, etc.)
- a = Archive/Suite (stable, testing, unstable, etc.)
- n = Code name (wheezy, squeeze, sid, etc.)
- c = Component (main, contrib, non-free, universe, restricted, multiverse, etc.)
- l = Label (Debian-Security, Debian Backports, Google, etc.)
Si l’on souhaite connaître à quel repository appartient un package spécifique :
1 2 3 4 5 6 7 8 9 10 11 | root@ns203445:~# apt-cache policy nginx nginx: Installed: 1.6.0-1~dotdeb.1 Candidate: 1.6.0-1~dotdeb.1 Version table: *** 1.6.0-1~dotdeb.1 0 500 http://packages.dotdeb.org/ wheezy/all amd64 Packages 100 /var/lib/dpkg/status 1.2.1-2.2+wheezy2 0 500 http://debian.mirrors.ovh.net/debian/ wheezy/main amd64 Packages 500 http://security.debian.org/ wheezy/updates/main amd64 Packages |
J’en conclue donc, que si je veux que nginx de dotdeb soit updaté régulièrement, je dois rajouter la ligne suivante au fichier /etc/apt/apt.conf.d/50unattended-upgrades :
1 2 3 4 5 6 7 | Unattended-Upgrade::Origins-Pattern { // "o=Debian,a=stable"; // "o=Debian,a=stable-updates"; // "o=Debian,a=proposed-updates"; "origin=Debian,archive=stable,label=Debian-Security"; "origin=packages.dotdeb.org,archive=stable"; }; |
Bien évidemment, cela mettra à jour tous les packages partageant la même origine et le même label, pas seulement nginx.
Débuguer Unattended-Upgrade
Une fois tout installé et configuré, le problème est de savoir si sa configuration est bonne sans attendre la prochaine mise à jour… On peut dans un premier temps, exécuter unattended-upgrade à la ligne de commande. L’option –dry-run simule une installation et -d est le mode debug pour obtenir plus d’informations.
1 2 3 4 5 6 7 8 9 10 | root@server:~# unattended-upgrade -d --dry-run Initial blacklisted packages: grub* Starting unattended upgrades script Allowed origins are: ['origin=Debian,archive=stable,label=Debian-Security', 'origin=packages.dotdeb.org,label=stable'] pkgs that look like they should be upgraded: Fetched 0 B in 0s (0 B/s) fetch.run() result: 0 blacklist: ['grub*'] InstCount=0 DelCount=0 BrokenCout=0 No packages found that can be upgraded unattended |
Accessoirement, si certains packages ne sont toujours pas mis à jour automatiquement, il faut aller chercher la réponse dans les logs avec par exemple cat /var/log/unattended-upgrades/unattended-upgrades.log | more
Pour Conclure
Unattended-upgrade est un outils extrêmement pratique pour déployer rapidement les mises à jours de sécurité et par extension toutes les mises à jour du système. Plus aucune excuse maintenant pour traîner un système avec des versions ante-diluvienne!
Ceci dit, et encore une fois, soyez prudent surtout si la stabilité du serveur est critique. Mieux vaut alors se limiter aux correctifs de sécurité et passer sur un serveur de test (pré-production) le reste des mises à jour.