Automatiser ses mises à jours de serveur avec dnf automatic

Dans le contexte actuel, avoir ses serveurs à jours est une nécessité. Cependant, quand on dispose d'une dizaine voir centaines de machines, cela peut vite devenir compliqué.

Grâce à dnf-automatic, vous allez pouvoir automatiser le téléchargement et la mise à jour des packages RPM sur des distributions fondé sur RHEL  (RHEL, Rocky Linux, Alma Linux...)

dnf-automatic est un petit plugin dnf, permettant, comme son nom l'indique, l'automatiser les mises à jour des packages RPM

Installation 

Pour l'installer, rien de plus simple :

# dnf install dnf-automatic

Configuration

Une fois le package installé, nous pouvons passer à sa configuration. Pour ce faire, nous allons éditer le fichier automatic.conf:

# vi /etc/dnf/automatic.conf

Type de mise à jour

Si vous souhaitez seulement appliquer les mises à jour de sécurités, passez la valeur à security

[commands]
#  What kind of upgrade to perform:
# default                            = all available upgrades
# security                           = only the security upgrades
upgrade_type = default
random_sleep = 0

Paramètres download_updates et apply_updates

• Laisser download_updates à true, pour que dnf-automatic, télécharge automatiquement les packages
• L'option apply_updates va mettre à jour les paquets de manière automatique.
• Comme son nom l'indique, l'option, reboot, va redémarrer le serveur après les mises à jour. Je vous recommande VIVEMENT de laisser la valeur à never et de faire des redémarrages manuels afin de vous assurer du bon fonctionnement de vos serveurs.

# Whether updates should be downloaded when they are available, by
# dnf-automatic.timer. notifyonly.timer, download.tizmer and
# install.timer override this setting.
download_updates = yes
# Whether updates should be applied when they are available, by
# dnf-automatic.timer. notifyonly.timer, download.timer and
# install.timer override this setting.
apply_updates = yes
# When the system should reboot following upgrades:
# never                              = don't reboot after upgrades
# when-changed                       = reboot after any changes
# when-needed                        = reboot when necessary to apply changes
reboot = never

Section emitters

[emitters]
# How to send messages.  Valid options are stdio, email and motd.  If
# emit_via includes stdio, messages will be sent to stdout; this is useful
# to have cron send the messages.  If emit_via includes email, this
# program will send email itself according to the configured options.
# If emit_via includes motd, /etc/motd file will have the messages. if
# emit_via includes command_email, then messages will be send via a shell
# command compatible with sendmail.
# Default is email,stdio.
# If emit_via is None or left blank, no messages will be sent.
emit_via = stdio
[email]
# The address to send email messages from.
email_from = root@srv.toto.fr
# List of addresses to send messages to.
email_to = root
# Name of the host to connect to to send email messages.
email_host = localhost

Et, pour finir, activation du timer systemd

# systemctl enable --now dnf-automatic.timer

Par défaut, le timer se lancera quotidiennement à 6:00 du matin. Si vous souhaitez changer l'heure, il vous suffit d'éditer le timer

# systemctl edit dnf-automatic.timer

### Editing /etc/systemd/system/dnf-automatic.timer.d/override.conf
### Anything between here and the comment below will become the new contents of the file
[Timer]
OnCalendar=*-*-* 4:10
### Lines below this comment will be discarded
### /usr/lib/systemd/system/dnf-automatic.timer
[...]

Conclusion

En 10 ans d'utilisation, il m'est seulement arrivé deux désagréments il y a quelques années.

• Serveur java (package OpenJDK)  / Tomcat (Binaire provenant du site Apache) (en 2015_) :

À la suite d'une mise à jour du package OpenJDK, le serveur Tomcat utilisant la variable d'environnement JAVA_HOME pointait sur le lien symbolique /usr/lib/jvm/jre. Cependant, l'ancienne destination de ce lien symbolique, n'existait plus, causant un plantage du serveur Tomcat. À la suite de ce problème, nous avons forcé le redémarrage du service Tomcat après le passage du service yum-cron (CentOS 7).

• Configuration dépréciée dans le fichier gitlab.rb (en 2018) :

Un paramètre, déprécié dans le fichier de configuration de GitLab, avait causé un plantage du service suite à sa mise à jour. 

Dans l'urgence, j'ai dû restaurer l'ancienne sauvegarde de la VM, avant de trouver la root cause.

Si vous êtes encore frileux à l'idée d'activer les mises à jour automatique, vous pouvez simplement activer l'envoie de notifications via dnf-automatic-notifyonly et dnf-automatic-download  

Pour en savoir plus sur ces fonctionnalités, consultez la documentation officielle.