> ## Documentation Index > Fetch the complete documentation index at: https://blog.onetsolutions.net/llms.txt > Use this file to discover all available pages before exploring further. # Mises à jour de sécurité automatiques sur un VPS Linux > Mises à jour de sécurité automatiques sur votre VPS Linux : unattended-upgrades, dnf-automatic, redémarrage planifié et rapports e-mail. Guide OnetSolutions. *Publié le 13 novembre 2026* Activer les mises à jour de sécurité automatiques sur un VPS Linux prend dix minutes. Ne pas le faire coûte des jours d'exposition. Les derniers avis du blog le montrent. Pour [php2shell](https://blog.onetsolutions.net/fr/php2shell-cve-2026-109618.md), les attaques ont commencé le matin même de la publication des correctifs. Pour la faille [Apache HTTP/2](https://blog.onetsolutions.net/fr/apache-http2-cve-2026-119618.md), le correctif existe : seul compte le moment où il arrive sur votre serveur. Pour [Copy Fail](https://blog.onetsolutions.net/fr/copy-fail-cve-2026-31431.md), le noyau corrigé ne protège qu'après un redémarrage. Le risque n'est pas la faille. C'est le délai entre le correctif publié et le correctif appliqué. Ce guide le ramène à quelques heures, sur Debian, Ubuntu, AlmaLinux et Rocky Linux. ## Quel outil pour quelle distribution Versions des paquets dans les dépôts officiels, relevées le 13 novembre 2026 : | Distribution | Outil | Version du paquet | | - | - | - | | Debian 12 (Bookworm) | `unattended-upgrades` | 2.9.1+nmu3 | | Debian 13 (Trixie) | `unattended-upgrades` | 2.12 | | Ubuntu 22.04 LTS | `unattended-upgrades` | 2.8ubuntu1 | | Ubuntu 24.04 LTS | `unattended-upgrades` | 2.9.1+nmu4ubuntu1 | | Ubuntu 26.04 LTS | `unattended-upgrades` | 2.12ubuntu9 | | AlmaLinux 9, Rocky Linux 9 | `dnf-automatic` (dnf 4) | 4.14.0 | | AlmaLinux 10, Rocky Linux 10 | `dnf-automatic` (dnf 4) | 4.20.0 | AlmaLinux 10 et Rocky Linux 10 restent sur dnf 4 : la configuration ci-dessous vaut pour les deux générations. | | `unattended-upgrades` (Debian, Ubuntu) | `dnf-automatic` (AlmaLinux, Rocky) | | - | - | - | | Sécurité seulement | Liste `Origins-Pattern` / `Allowed-Origins` | `upgrade_type = security` | | Redémarrage | `Automatic-Reboot`, si `/var/run/reboot-required` existe | `reboot = when-needed` ou `when-changed` | | Heure du redémarrage | `Automatic-Reboot-Time` | Heure du minuteur + délai de `reboot_command` | | Rapport par e-mail | `Mail`, `MailReport` | `emit_via = email`, section `[email]` | | Simulation | `unattended-upgrade --dry-run` | `dnf upgrade --security --assumeno` | | Minuteur systemd | `apt-daily.timer`, `apt-daily-upgrade.timer` | `dnf-automatic.timer` | ## Avant d'activer le redémarrage : un snapshot Un redémarrage automatique, c'est un redémarrage que vous ne surveillez pas. Prenez un [snapshot](https://help.onetsolutions.net/fr/vps/snapshot) depuis la console avant de l'activer. Si le premier redémarrage se passe mal, vous revenez à un état connu en un clic. Les [sauvegardes](https://help.onetsolutions.net/fr/vps/backup) restent votre protection de fond : un snapshot est un point de retour, pas une sauvegarde. ## Activer unattended-upgrades sur Debian et Ubuntu ### Installer et activer Ubuntu installe `unattended-upgrades` par défaut. Sur Debian, installez-le. Dans les deux cas, la commande ne casse rien : ```bash theme={null} sudo apt update sudo apt install unattended-upgrades ``` L'activation tient dans `/etc/apt/apt.conf.d/20auto-upgrades`. Chaque valeur est un nombre de jours : `1` pour tous les jours, `0` pour désactiver. ```bash theme={null} sudo tee /etc/apt/apt.conf.d/20auto-upgrades >/dev/null <<'EOF' APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Unattended-Upgrade "1"; EOF ``` ### Limiter aux mises à jour de sécurité C'est déjà le comportement par défaut, à une nuance près selon la distribution. * **Ubuntu** : la liste `Allowed-Origins` prend la version de base, la poche `-security` et les dépôts ESM s'ils sont présents. `-updates`, `-proposed` et `-backports` sont commentés. * **Debian** : la liste `Origins-Pattern` prend `Debian-Security` et l'archive de votre version (celle qui reçoit les publications intermédiaires de la version stable). Les backports et `-updates` sont commentés. Ne modifiez pas `50unattended-upgrades` : le wiki Debian recommande de placer vos réglages dans un fichier à part, `52unattended-upgrades-local`, lu après lui. Sur Debian, si vous voulez strictement les avis de sécurité, videz la liste puis redéclarez-la. Une liste APT ne se remplace pas, elle s'efface avec `#clear` : ```bash theme={null} sudo tee /etc/apt/apt.conf.d/52unattended-upgrades-local >/dev/null <<'EOF' // Debian : uniquement l'archive de sécurité #clear Unattended-Upgrade::Origins-Pattern; Unattended-Upgrade::Origins-Pattern { "origin=Debian,codename=${distro_codename},label=Debian-Security"; "origin=Debian,codename=${distro_codename}-security,label=Debian-Security"; }; EOF ``` > [!NOTE] > > Le fichier fourni par Ubuntu le rappelle : un correctif de sécurité peut dépendre d'un paquet de l'archive principale. C'est pour cela que celle-ci figure dans les listes par défaut. Avec le filtre strict, un tel correctif reste en attente : la simulation plus bas vous le montre. Pour voir les origines réellement configurées sur votre serveur : ```bash theme={null} apt-cache policy | grep release ``` ### Choisir le redémarrage automatique Un noyau, une bibliothèque C ou systemd corrigés ne protègent qu'après un redémarrage. Quand un paquet l'exige, il crée `/var/run/reboot-required`. `unattended-upgrades` ne redémarre que si ce fichier existe et si vous l'avez autorisé. | Situation | Réglage | | - | - | | VPS seul, une coupure de quelques minutes la nuit est acceptable | `Automatic-Reboot "true"` et `Automatic-Reboot-Time "03:30"` | | Vous voulez choisir vous-même le moment | `Automatic-Reboot "false"` et un rapport par e-mail | | Plusieurs VPS qui assurent le même service | Redémarrage automatique, avec une heure différente sur chaque serveur | Ajoutez les réglages au fichier local (créez-le s'il n'existe pas encore) : ```bash theme={null} sudo tee -a /etc/apt/apt.conf.d/52unattended-upgrades-local >/dev/null <<'EOF' // Redémarre seulement si /var/run/reboot-required existe Unattended-Upgrade::Automatic-Reboot "true"; // Redémarre même si quelqu'un est connecté en SSH Unattended-Upgrade::Automatic-Reboot-WithUsers "true"; // Heure locale du redémarrage, passée à shutdown Unattended-Upgrade::Automatic-Reboot-Time "03:30"; EOF ``` `Automatic-Reboot-Time` accepte aussi `now` (la valeur par défaut) ou `+m`, un délai en minutes. L'installation elle-même part de `apt-daily-upgrade.timer`, réglé par défaut à 6 h avec un délai aléatoire d'une heure. Pour qu'elle précède le redémarrage de la même nuit, avancez-la : ```bash theme={null} sudo systemctl edit apt-daily-upgrade.timer ``` ```ini theme={null} [Timer] # La ligne vide efface l'horaire d'origine OnCalendar= OnCalendar=*-*-* 02:00 ``` ```bash theme={null} sudo systemctl restart apt-daily-upgrade.timer ``` Gardez le délai aléatoire : le wiki Debian le recommande pour éviter que tous les serveurs interrogent les miroirs à la même seconde. ### Recevoir un rapport par e-mail ```bash theme={null} sudo tee -a /etc/apt/apt.conf.d/52unattended-upgrades-local >/dev/null <<'EOF' Unattended-Upgrade::Mail "admin@example.com"; // always, only-on-error, on-change (défaut) Unattended-Upgrade::MailReport "on-change"; EOF ``` L'envoi passe par la commande `mail` : il faut un paquet qui la fournit, comme `bsd-mailx`, et un serveur de messagerie local capable d'envoyer vers l'extérieur. ```bash theme={null} sudo apt install bsd-mailx echo "test" | mail -s "Test depuis $(hostname)" admin@example.com ``` Si ce test n'arrive pas, le rapport n'arrivera pas non plus. Notre guide [SPF, DKIM, DMARC et reverse DNS](https://blog.onetsolutions.net/fr/spf-dkim-dmarc-reverse-dns-serveur-mail-vps.md) couvre la délivrabilité. ### Vérifier : simulation, minuteurs et journaux ```bash theme={null} # Simulation complète, rien n'est installé sudo unattended-upgrade -v --dry-run # Prochaines exécutions des deux minuteurs systemctl list-timers apt-daily.timer apt-daily-upgrade.timer # Ce qui s'est passé lors des dernières exécutions sudo journalctl -u apt-daily-upgrade.service --since "7 days ago" sudo tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log # Un redémarrage est-il en attente ? test -f /var/run/reboot-required && echo "Redémarrage requis" || echo "Aucun redémarrage requis" ``` **Bon résultat :** la simulation liste les paquets de sécurité en attente sans erreur, et `list-timers` affiche une prochaine exécution dans les 24 heures. ## Configurer dnf-automatic sur AlmaLinux et Rocky Linux ### Installer ```bash theme={null} sudo dnf install dnf-automatic ``` ### Sécurité seulement, redémarrage et e-mail Tout se règle dans `/etc/dnf/automatic.conf`. Modifiez ces lignes dans leurs sections respectives : ```ini theme={null} [commands] # Uniquement les mises à jour accompagnées d'un avis de sécurité upgrade_type = security download_updates = yes apply_updates = yes # never (défaut), when-changed (après toute mise à jour) # ou when-needed (seulement si nécessaire : noyau, systemd...) reboot = when-needed # Valeur par défaut : redémarrage 5 minutes après la mise à jour reboot_command = "shutdown -r +5 'Rebooting after applying package updates'" [emitters] emit_via = stdio,email [email] email_from = root@vps.example.com email_to = admin@example.com email_host = localhost ``` Avec `stdio`, le rapport part aussi dans le journal systemd. Avec `email`, `dnf-automatic` envoie lui-même le message au serveur SMTP indiqué par `email_host` : un serveur de messagerie local, Postfix par exemple, doit l'accepter. ### Choisir l'heure et activer Le redémarrage suit l'installation de cinq minutes. Choisir l'heure du redémarrage revient donc à choisir l'heure du minuteur, réglé par défaut à 6 h avec un délai aléatoire d'une heure : ```bash theme={null} sudo systemctl edit dnf-automatic.timer ``` ```ini theme={null} [Timer] OnCalendar= OnCalendar=*-*-* 03:00 ``` ```bash theme={null} sudo systemctl enable --now dnf-automatic.timer ``` Le paquet fournit aussi `dnf-automatic-install.timer`, qui installe quel que soit `apply_updates`, et `dnf-automatic-notifyonly.timer`, qui ne fait que prévenir. N'en activez qu'un. ### Vérifier ```bash theme={null} # Avis de sécurité en attente sudo dnf updateinfo list --security # Simulation : affiche la transaction puis répond non sudo dnf upgrade --security --assumeno # Prochaine exécution du minuteur systemctl list-timers 'dnf-automatic*' # Rapports des dernières exécutions sudo journalctl -u dnf-automatic.service --since "7 days ago" # Code 1 : un redémarrage est nécessaire (fourni par dnf-plugins-core) sudo dnf needs-restarting -r ``` > [!WARNING] > > `sudo systemctl start dnf-automatic.service` lance une exécution réelle : avec la configuration ci-dessus, il installe les correctifs et peut redémarrer le VPS cinq minutes plus tard. Utilisez la simulation pour tester. ## Si le VPS ne redémarre pas C'est rare, et tout se rattrape depuis la console. | Situation | Action | | - | - | | Le VPS ne répond plus en SSH après le redémarrage | Ouvrez la [console KVM](https://help.onetsolutions.net/fr/vps/kvm-console) : vous voyez où le démarrage s'arrête | | Le nouveau noyau ne démarre pas | Depuis la console KVM, choisissez le noyau précédent dans le menu GRUB | | Système de fichiers ou configuration à réparer | Démarrez en [mode rescue](https://help.onetsolutions.net/fr/vps/rescue-mode) : notre [guide du mode rescue](https://blog.onetsolutions.net/fr/mode-rescue-vps-reparer-serveur-qui-ne-demarre-plus.md) détaille la réparation | | Vous voulez simplement revenir en arrière | Restaurez le [snapshot](https://help.onetsolutions.net/fr/vps/snapshot) pris avant l'activation | ## Pièges courants **Les services tournent encore sur l'ancien code.** Un paquet mis à jour ne remplace pas le processus en mémoire. Sur Ubuntu 24.04 et suivantes, `unattended-upgrades` appelle `needrestart`, qui redémarre les services concernés. Ailleurs, listez les processus qui utilisent des fichiers remplacés avec `sudo dnf needs-restarting` sur AlmaLinux et Rocky, et redémarrez les services concernés. Notre [routine d'audit nginx](https://blog.onetsolutions.net/fr/auditer-et-durcir-nginx-sur-un-vps.md) montre comment repérer un processus plus ancien que sa mise à jour. **Les dépôts tiers ne sont pas couverts.** Les origines par défaut ne visent que les dépôts de la distribution. PHP installé depuis un dépôt externe, Docker, nginx.org : leurs correctifs ne passent pas par ce mécanisme. Ajoutez leur origine à `Origins-Pattern` après l'avoir lue dans `apt-cache policy`, ou suivez leurs avis vous-même. **Un paquet gelé reste gelé.** Un paquet marqué avec `apt-mark hold`, ou listé dans `Package-Blacklist`, n'est jamais mis à jour automatiquement. Vérifiez avec `apt-mark showhold`. **Une mise à jour manuelle attend son tour.** Pendant qu'`unattended-upgrades` travaille, il tient le verrou de `dpkg`. Un `apt upgrade` lancé au même moment attend : ne supprimez pas le verrou. **Les conteneurs ne suivent pas l'hôte.** Les images Docker embarquent leurs propres paquets. Elles se mettent à jour en reconstruisant ou en tirant une nouvelle image, pas par l'hôte. **Le rapport ne part pas.** Pas de commande `mail`, pas de serveur de messagerie local, ou un message rejeté par le destinataire : envoyez un e-mail de test avant de compter sur les rapports. ## Pour aller plus loin * [Snapshots](https://help.onetsolutions.net/fr/vps/snapshot) : créer un point de retour avant de modifier le système * [Sauvegardes](https://help.onetsolutions.net/fr/vps/backup) : la protection de fond de vos données * [Console KVM](https://help.onetsolutions.net/fr/vps/kvm-console) et [mode rescue](https://help.onetsolutions.net/fr/vps/rescue-mode) : reprendre la main sur un VPS qui ne répond plus * [Clés SSH](https://help.onetsolutions.net/fr/vps/ssh-keys) : l'autre réglage de sécurité à faire dès l'installation * [Systèmes d'exploitation](https://help.onetsolutions.net/fr/vps/operating-system) : les versions disponibles et leurs dates de fin de support * [Sécurité renforcée sur un VPS Linux](https://blog.onetsolutions.net/fr/securite-renforcee-sur-un-vps-linux-conseils-et-outils-pour-proteger-vos-donnees-sensibles.md), pour les couches suivantes Une question sur un serveur hébergé chez nous ? [Notre équipe est disponible](https://help.onetsolutions.net/fr/console/support) depuis votre espace client. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.