Préparation de l'application des mises à jour sur Red Hat Linux

Objectif

Notre objectif est de garantir que la mise à jour du système d'exploitation se déroulera sans problème et sans erreur.

Versions du système d'exploitation et du logiciel

• Système d'exploitation : Red Hat Enterprise Linux 6+

Exigences

Accès privilégié aux systèmes

Difficulté

FACILE

Congrès

• # - nécessite que les commandes linux données soient exécutées avec les privilèges root soit directement en tant qu'utilisateur root, soit en utilisant sudo commande
• $ – commandes linux données à exécuter en tant qu'utilisateur normal non privilégié

Présentation

Maintenir le système à jour est une tâche quotidienne pour un administrateur système, ainsi que pour un utilisateur de bureau. En appliquant le dernier logiciel (stable) disponible sur le système, nous pouvons tirer parti des dernières fonctionnalités, et nous serons mieux protégés contre les problèmes de sécurité et, espérons-le, souffrirons moins de bogues. Pour mettre à jour le système, vous aurez besoin de yum configuré référentiels qui agissent comme source du logiciel mis à jour.

Si vous êtes assis à côté de la machine qui exécute le système d'exploitation à mettre à jour, vous pouvez facilement agir si quelque chose ne va pas pendant la mise à jour, comme vérifier la sortie sur le terminal, ou démarrer sur un système en direct si le système mis à niveau ne revient pas de redémarrer - mais ce n'est pas toujours le cas. Pensez à un centre de données avec des centaines ou des milliers de machines (virtuelles), ou simplement à un PC physique que vous devez mettre à niveau à distance.

Nous pouvons suivre des étapes simples pour préparer le système à la mise à niveau et éventuellement résoudre tout problème susceptible de compromettre la réussite de la mise à jour.

Processus de mise à jour

Lors d'une mise à jour inconditionnelle (c'est-à-dire "tout mettre à jour"), yum récupérera toutes les métadonnées des référentiels disponibles et calculera tous les packages à mettre à niveau par rapport au rpm base de données qui contient toutes les métadonnées sur les packages installés sur le système.

Le processus de mise à jour calcule également toutes les dépendances des packages mis à niveau, peut remplacer les anciens packages et supprimer les anciennes images du noyau en fonction de sa configuration. Le nombre d'images du noyau à conserver est défini dans le /etc/yum.conf fichier de configuration, et vaut 3 par défaut :

installonly_limit=3




Après toutes les modifications nécessaires calculées, yum fournit une liste complète de tous les packages à mettre à niveau, supprimer ou installer pour les dépendances, de la même manière que lors de l'installation ou de la mise à niveau de packages spécifiques.

Dans une session de mise à jour interactive yum fournira un résumé des packages à modifier, ainsi qu'un calcul de la taille des données à télécharger pour la mise à niveau, comme indiqué ci-dessous :

Résumé de la mise à jour interactive de yum

Après avoir examiné les résultats, nous pouvons décider si nous démarrons la mise à jour ou si nous l'annulons. Comme yum mettra à jour tout ce pour quoi il peut trouver des mises à jour, nous voudrons peut-être supprimer les packages inutiles au préalable. Nous pouvons également remarquer un package marqué pour mise à jour avec lequel nous sommes verrouillés en version et qui doit être exclu de la mise à niveau.

Après approbation, yum téléchargera tous les nouveaux packages et les installera/mettra à jour un par un. Une fois terminé, il vérifiera l'intégrité des packages installés / mis à jour, nettoiera les fichiers inutiles. Il fournit également des commentaires pendant le processus, fournissant une ligne de texte pour chaque étape, ainsi qu'un code de sortie indiquant si la mise à niveau a réussi ou si un problème est survenu. Il annulera également le processus de mise à jour si un problème semble critique du point de vue du système cohérent - mais il y a des moments où il est déjà trop tard, donc empêcher les problèmes de mise à jour de se produire est une meilleure approche.

Espace disque

miam cache

D'après le processus décrit ci-dessus, nous pourrions deviner que nous avons besoin d'espace disque pour le processus de mise à jour :

• Les métadonnées de tous les référentiels configurés doivent être stockées jusqu'à la fin du calcul de tous les packages (et de leurs dépendances) à mettre à jour.
• rpm les packages qui constituent la mise à jour elle-même doivent être stockés localement jusqu'à ce qu'ils soient correctement installés.

Ces données, appelées yum cache n'est nécessaire que pendant la mise à jour, mais peut occuper un espace disque important. L'emplacement par défaut de ce cache est dans le /var/cache/yum annuaire. Inutile de dire que s'il n'y a pas assez d'espace pour stocker toutes les données nécessaires, le processus de mise à jour échouera. Certains téléchargements inachevés seront abandonnés, mais tout l'espace ne sera peut-être pas libéré, ce qui finira par faire échouer la mise à jour du système et avoir son volume contenant /var/cache presque plein.

De nombreuses installations stockent leur /var répertoire sur un volume dédié à la journalisation, car l'emplacement par défaut des fichiers journaux est /var/log sur la plupart des distributions, et la plupart des applications qui se comportent bien cesseront de fonctionner ou même planteront si elles ne peuvent pas écrire leurs fichiers journaux. Donc, remplir le volume sur lequel ils écrivent est une mauvaise chose .

Plus il y a de paquets à mettre à jour et plus nous avons de référentiels, plus la mise à jour occupera temporairement d'espace. Calculer cet espace d'une mise à jour à l'autre est difficile, mais peut être testé avec la solution de simulation décrite plus loin si nous avons une machine de test avec le contenu logiciel exact. Pour un exemple en temps réel, la mise à jour de RHEL 7.1 à 7.5 (installation de bureau avec Gnome) peut prendre 4 Go d'espace cache, mais l'installation de quelques correctifs sur un système qui n'est qu'un ou deux mois obsolète ne prendra que quelques Mo.

Pour vérifier combien d'espace nous avons, nous pouvons utiliser le df commande :

# df -h /var/
Filesystem              Size  Used Avail Use% Mounted on
/dev/mapper/vg_sys-var  6.0G  1.7G  4.4G  28% /var




Dans l'exemple ci-dessus, nous avons 4,4 Go d'espace libre, ce qui sera suffisant étant donné que le serveur a été mis à jour il y a seulement quelques mois. Pour libérer de l'espace, une étape triviale serait de vider le yum cache déjà stocké (peut-être lors de la dernière mise à jour). Pour vérifier combien d'espace le cache occupe en ce moment, nous pouvons utiliser du :

# du -mcd 1 /var/cache/yum
1103    /var/cache/yum/x86_64
1103    /var/cache/yum
1103    total




Les nombres ci-dessus sont en Mo, donc le yum cache dans cet exemple, occupe environ 1 Go d'espace disque et occupe la majeure partie de l'espace sur /var volume.

Vider le cache

Nous pouvons vider tout le cache avec la commande suivante :

yum clean all

Mais comme yum nous avertit dans la sortie de la commande ci-dessus sur les versions RHEL 7, il peut y avoir des données orphelines provenant de référentiels supprimés ou désactivés, ce qui se produira très probablement après des mises à niveau mineures, auquel cas nous pouvons effacer les données à la main en toute sécurité :

rm -rf /var/cache/yum/*

Nous pouvons obtenir plus d'espace pour la mise à jour en effaçant d'autres données stockées sur le volume, comme la compression/la suppression d'anciens fichiers journaux, le déplacement de fichiers volumineux vers d'autres volumes ou l'extension de la taille du volume.

Déplacer le cache

Pour travailler avec les possibilités de yum , si nous manquons vraiment d'espace disque, que nous ne pouvons plus rien effacer et que nous ne pouvons pas ajouter plus d'espace au volume, nous pouvons déplacer l'emplacement du yum cache vers un autre volume avec plus d'espace libre. Nous pouvons configurer l'emplacement du cache dans le yum.conf fichier de configuration mentionné ci-dessus. Considérez le paramètre par défaut :

cachedir=/var/cache/yum/$basearch/$releasever

En changeant le chemin avant $basearch la prochaine opération yum fonctionnera avec la même structure de répertoires, mais sur un chemin différent - espérons-le avec plus d'espace libre pour la mise à niveau. Nous pouvons également déplacer le cache vers un autre volume en déplaçant tout le répertoire :

mv /var/cache/yum /extended_data_volume/




Et en créant un lien symbolique à l'emplacement d'origine qui pointe vers le nouveau lieu :

ln -s /extended_data_volume/yum /var/cache/yum




Il est sage de savoir que la mise à jour n'échouera pas sur une erreur triviale telle qu'un espace disque insuffisant. Sur un grand système, les administrateurs système déploient des outils de surveillance comme Nagios qui peuvent signaler un espace disque insuffisant sur toutes les machines, ce qui rend cette étape beaucoup moins longue et sujette aux erreurs.

Erreurs de réseau

S'il existe des problèmes de connectivité entre les référentiels et la machine effectuant la mise à jour, la mise à jour peut échouer. Cela ne peut se produire qu'au niveau des métadonnées ou de l'étape de téléchargement des nouveaux RPM, et ne cassera pas le système. Vous pouvez recommencer le processus de mise à jour lorsque le problème de réseau est résolu.

D'autre part, si la mise à jour est initialisée à partir d'une session interactive, en cas de panne du réseau, la connexion peut se rompre, laissant la machine de mise à jour sans administrateur pour répondre aux questions yum peut demander. Si l'étape d'installation/de mise à jour du package a déjà commencé, elle se poursuivra sans surveillance et peut échouer ou se terminer si elle le ferait autrement. Après la reconnexion, le processus peut être suivi dans le /var/log/yum.log .

Yum dry run

Outre l'espace disque insuffisant et les problèmes de réseau, la mise à jour peut échouer dans de nombreux cas sur des dépendances de packages non résolues. Ceux-ci doivent être résolus avec des outils capables de calculer et de gérer les dépendances des packages, mais il serait utile de savoir qu'il y aura des problèmes avant la mise à jour proprement dite (et donc de ne pas perdre le temps d'arrêt toujours trop court du système). Pour obtenir ces précieuses informations, nous pouvons exécuter le processus de mise à jour comme il exécuterait la mise à jour proprement dite, mais s'arrêter avant que le téléchargement, l'installation ou la mise à jour du package n'ait eu lieu.

Autour de Redhat 6.6, une nouvelle option a été introduite qui causera yum pour supposer "Non" à chaque question qui se pose pendant la mise à jour - y compris l'approbation avant l'étape de manipulation réelle du package, et par conséquent aucune interaction réelle n'est nécessaire exécuter un essai :

yum update --assumeno

Cela peut être l'outil idéal pour fournir un essai à blanc de la mise à jour à venir, y compris les packages à mettre à niveau et les erreurs éventuelles. Considérez le simple bash suivant script :

#!/bin/bash
yum update --assumeno &> $(hostname).yum.dryrun.$(date '+%Y-%m-%d').out
exit $?




Le script ci-dessus peut être exécuté automatiquement et fournira un rapport textuel de la simulation, ainsi qu'un code de sortie global indiquant tout problème. La sortie n'a pas besoin d'être enregistrée sur le système de fichiers local. La cible de la redirection de sortie peut être un système de fichiers réseau, ou le rapport peut être publié sur un serveur de rapport central, peut être collecté par d'autres scripts ou applications. Les rapports peuvent être publiés et distribués aux autres services informatiques pour approbation, de cette façon toutes les personnes impliquées peuvent voir exactement quels packages seront mis à jour et vers quelle version.

La simulation peut être programmée pour s'exécuter sur une période donnée (peut-être la nuit pour avoir moins d'impact sur les performances du système) avec cron , ou exécuté à partir d'une source centrale avec une configuration de marionnette. Le code de sortie peut également être stocké et traité par surveillance ou facter , pour agréger les résultats possibles de la prochaine mise à jour avant de continuer.

Conclusion

Même avec un ou quelques ordinateurs, nous devrions recueillir des informations avant de lancer une mise à jour de l'ensemble du système d'exploitation, juste pour être du bon côté. Un jour, il y aura un problème, et c'est beaucoup moins stressant si vous pouvez le résoudre avant qu'il n'ait un impact sur le travail réel d'une machine donnée. À plus grande échelle, il n'est tout simplement pas possible de s'asseoir à côté de chaque serveur ou bureau et de le soutenir de votre présence dans l'espoir que cela aidera la mise à jour à fonctionner parfaitement.

En connaissant les étapes du processus de mise à jour, les pièges, ainsi que la solution à ceux-ci sont essentiels pour des mises à jour réussies. Commencer la prochaine étape de mise à jour de toute votre infrastructure avec la certitude qu'il n'y aura pas de problèmes, c'est le faire avec style.