J’ai toujours été emmerdé par le sujet des mises à jour système que ce soit sur les environnements WINDOWS ou LINUX. Faut-il les passer en automatique ou manuellement ? Que faire si jamais une mise à jour est foireuse, est ce compatible avec les applications métiers, est ce que je réponds à la correction de vulnérabilité ect ?

Je pense que la liste pourrait être longue…

Pour ma part je ne suis pas un grand partisan de l’application des mises à jour automatique. Les raisons ? Avoir subi des aléas système avec WINDOWS et des aléas d’application tierce sous LINUX.

Le temps passé à diagnostiquer, refuser et désinstaller la, les mises à jour (quand c’est possible et que le SE à décider de boot jusqu’au bout) ou alors de réparer le système (restauration de la sauvegarde précédente pour le système, application de fix nébuleux pour ne pas dire opaque) couplé au temps d’interruption de service que subit les utilisateurs cela peut vite s’avérer un casse-tête et une source de stress…

L’un des meilleurs exemples qui me vient en tête :

Souviens toi, souviens toi du 15 Octobre 2021, de la conspiration de MICROSOFT et de VMWare car la mise à jour du pilote pvscsi à débugger jamais je ne pourrai me résoudre…

Erwan GUILLEMARD (sur la base de V for Vendetta 2005)

Je fais de le drama ! Le dysfonctionnement a été corrigé dans la matinée pour l’ensemble des serveurs concernées. Toutefois ça a été long et fastidieux. (cf

Afin d’éviter ce cas de figure, je me suis posé la question que préconise les éditeurs, les distributeurs de SE ?

Dans la logique il conviendrait d’avoir un miroir de son environnement de production en préproduction. Cela demande d’avoir les ressources de stockage et calcul nécessaire, d’avoir une réplication des données à J-1. Bref, c’est beaucoup de contrainte humaine, financière et matérielle pour des PMEs.

Il existe selon moi trois alternatives sans consommer trop de ressources :

1. Ne pas mettre à jour ces environnements (ça solde rapidement le problème)
2. Avoir un environnement de préproduction minimaliste avec les SEs les plus présent et au moins un de chaque. Appliquer les mises à jour en amont et si tout est correct appliquer les changements en production
3. Appliquer les mises à jour sur l’environnement de production en lissant ces dernières dans le temps. Application des mises à jour sur un AD la deuxième semaine du mois puis la troisième semaine pour les autres serveurs d’authentifications par exemple.

Sans m’étendre sur le scénario numéro un qui est pour moi celui le plus présent malheureusement (même si ce n’est pas empirique). J’ai tendance à préférer le cas de figure numéro 3. Il a des inconvénients, avantages et je trouve pour ma part une efficience à l’administrer au quotidien.

Cependant, pour les environnements critiques ou métiers à fort impact je préfére l’option 2. C’est le cas des environnements LINUX pour lesquelles je garde un historique des actions effectuées ainsi qu’une application dans un environnement de préproduction/test au préalable.

J’ajoute ceinture, bretelle et parachute avec une sauvegarde de la veille, dump des bdds et snapshot à froid si possible. Nous ne sommes jamais trop sûr, sait on jamais…

Prérequis

• SE: RHEL, Debian, Ubuntu
• Apps: Mutt, cyrus-sasl-plain
• Autres: Sauvegarde fonctionnelle et/ou sauvegarde des fichiers de configurations au préalable

Update Notifications

Installation et configuration de MUTT

Concernant cette partie, je vous invite à parcourir la section déjà documentée dans l’article Apps – MUTT.

Configuration et installation du Script

J’ai pour habitude de positionner mes scripts à la racine du système dans un répertoire à part avec des droits spécifiques. L’objectif étant de toujours garantir un niveau de sécurité suffisant et d’éviter une escalade potentiel des droits.

$ sudo mkdir /script
$ sudo mkdir /script/SS_023_LINUX_UpdatesNotifications

SS_023_ t’es allé la cherché loin ta p****n de convention de nommage !

Effectivement, au premier abord, le nom peut paraitre compliqué, je vous explique. Et non, nous n’effleurerons pas le point G (Godwin) dans cet article. J’ai nommé mes projets suivant une convention personnelle depuis un grand nombre d’année déjà.

• GS : GraphicalScript
• SS : SystemScript
• XX : Le numéro du projet suivi du nom du projet

Editez le fichier ou copiez le fichier suivant : SS_023_D_LINUX_UpdatesNotification.sh

A ce jour le fichier en version D est construit de la manière suivante :

• Les constantes
• Une fonction vérifiant l’OS
• Une fonction vérifiant les mises à jour
• Une fonction d’envoi de mail
• Une fonction pour forger le mail en html

Dans un premier temps, par fainéantise un simple mail en texte brut me suffisait amplement. Puis il a fallu mettre en service tout ça et rendre lisible le rapport. C’est pourquoi il y a dans le script la possibilité de générer le rapport au format HTML ou TXT.

« T’es mignon, mais sans le script on ne peut pas aller bien loin… Ce n’est pas dans l’esprit communautaire ce que tu fais nanani nana »

Ouvrons une parenthèse et faisons une mise au point,

Oui j’en ai bien conscience, je n’ai tout simplement pas envie non plus de donner les fruits de mon travail et réflexion facilement. Il y a plusieurs raisons pour lesquelles je ne délivre pas mes scripts.

• Il est nécessaire d’assurer le support et la correction des bugs. Cela demande du temps et la communauté pour l’avoir plusieurs fois constaté sur d’autres forums on put se montrer malveillante et désobligeante bien que cela ne soit pas une généralité.
• Cela repose sur une personne et donc il y a un risque quant à la durée de vie et du fonctionnement de ma solution (MCO et MCS). J’ai peut-être réinventé la roue, mais c’est ma roue avec ces petits défauts et je ne peux et ne veux pas être tenu pour responsable de tous dysfonctionnements éventuels sur vos SIs.
• Un peu de pudeur singulière quand au code. Certains pourraient dire que c’est codé avec les pieds, que ça peut être mieux fait, factorisé ect. Je crois et c’est ce que j’ai retenu d’un de mes collègues, c’est que l’on peut toujours faire mieux que les autres et que chaque solution est optimisable. Toutefois, mes « outils » reflètent mon paradigme. Si ce dernier ne me convient pas intrinsèquement je n’en parle pas et né présente pas mes « travaux ».
• Je ne compte pas vendre les solutions car je pense que ces dernières doivent rester dans l’esprit du libre. Je suis prêt à donner mes outils mais pas de mon temps. Echanger sur le sujet reste un grand plaisir. Assurer le support et faire « à la place de » nécessite sonnant et trébuchant (communément appelé Prestation de Services).

Fermons la parenthèse.

Revenons à nos moutons. Le script mis en place, il est nécessaire de définir les droits.

Un simple 700 suffit sur le fichier.

$ sudo chmod 700 /script/SS_023_LINUX_UpdatesNotifications/SS_023_D_LINUX_UpdatesNotifications.sh

Néanmoins, les permissions restent root:root et ça c’est pas ouf. C’est comme allez aux p****s sans capotes. Ça peut le faire mais il subsiste un risque. Après chacun fait ce qui lui chante.

Malheureusement je n’ai pas à ce jour « procéduré » de manière correct l’exécution d’une tâche planifiée avec un utilisateur autre que root sans générer de trou dans la raquette niveau sécurité.

En gros soit c’est sécu mais ça ne fonctionne pas, soit ça fonctionne mais faut pas trop regarder côté sécu.

Configuration du cron

Comme pour Microsoft avec son mensuel Tuesday Update, j’aime quant à moi réaliser un rapport hebdomadaire le mercredi à 03:00 PM.

Et puis entre nous, le mercredi aprem c’est la journée télétravail, tout le monde fait semblant de taffer, la France est au 4/5eme, on se fait ch**r et nous ne sommes pas Vendredi soir pour faire une mise en production. Il faut bien s’occuper un peu !

# vim /etc/crontab

Ce qui nous donne dans notre BAL :

Nothing to do – No updates availables	MCO to do – Updates availables

Conclusion

J’ai peut-être réinventé la roue et je suis certains qu’un paquet répond déjà à mon besoin dans un repo.

Cependant, si une solution existe dans les gestionnaires de paquet il est fort probable que ces dernières ne répondent pas à mon besoin personnel dans sa globalité.

Je vois donc dans ma solution « maison » les avantages et inconvénients suivants :

Mon objectif étant maintenant selon mon temps libre et la criticité des « Inconvénients » de faire de ces derniers des avantages. Jusqu’à réduire au plus possible le nombre de point énuméré.

M’affranchir de MUTT et de faire mon propre service de relai de messagerie par exemple.

Pour répondre au point de l’altération et ou non du script et d’aborder la non répudiation et véracité du script, ce dernier a été déjà été traité et sera abordé dans un autre article.

Pour d’avantage d’information sur le script vous pouvez me contacter, ça serait avec un grand plaisir que je vous répondrai.

Le mot de la fin :

Je DISM mon kernel LINUX, dnf update mon MSSQL et fax le résultat à Philippe RISOLI

Erwan GUILLEMARD

Sources

• Mutt