Meilleures pratiques pour la mise à jour d'un serveur RHEL5.7 non géré auparavant

Un nouveau serveur RedHat EL5.6 a été récemment placé sous ma responsabilité. Il est immédiatement évident que, au cours des 12 derniers mois, peu ou pas d'attention a été accordée à toute sorte de mises à jour de packages.

En règle générale, je pense que si ce n'est pas le cas, ne le réparez pas. Cependant, après avoir enregistré le serveur auprès de RHN et également utilisé le plug-in yum-security pour vérifier les mises à jour de sécurité, il y a un peu plus de 1100 mises à jour de «sécurité» disponibles.

Quelqu'un a-t-il eu une situation similaire? Je suis réticent à simplement tout mettre à jour, car j'aime savoir ce qui est mis à jour et s'il peut ou non avoir un impact sur tout ce qui fonctionne sur la boîte (c'est un serveur de production). Cependant, il semble également que le maintien de cette pratique m'oblige à parcourir les errata du package 1100 ligne par ligne. Existe-t-il une solution plus efficace?

De manière générale, les mises à jour de sécurité sont considérées comme quelque peu sûres, en particulier pour une distribution avec des objectifs comme RedHat. Leur objectif principal est de créer un environnement d'exploitation cohérent. En tant que tels, les responsables ont tendance à choisir des versions de packages et à les conserver sur le long terme. Pour voir ce que je veux dire regarder les versions de ces paquets comme kernel, python, perlet httpd. Ce qu'ils font également, c'est rétroporter les correctifs de sécurité des développeurs en amont. Donc, si une vulnérabilité de sécurité est trouvée pour toutes les versions d'Apache httpd 2.2.x, la fondation Apache peut publier la version 2.2.40 avec le correctif, mais RedHat déploiera le correctif localement et le publiera httpd-2.2.3-80avec le correctif.

Gardez également à l'esprit que vous parlez actuellement d'un système RHEL5.7, la version actuelle est la 5.9. Certains éditeurs de logiciels ne prennent en charge que certaines sous-versions. J'ai récemment rencontré un logiciel, par exemple, qui, selon le fournisseur, ne fonctionne que sur la version 5.4. Cela ne signifie pas qu'il ne fonctionnera pas sur 5.9, mais cela peut signifier qu'ils ne fourniront aucun support si cela ne fonctionne pas .

La mise à jour en masse d'un système qui n'a pas été corrigé depuis si longtemps pose également des problèmes. Le plus gros problème que j'ai rencontré est en fait davantage un problème de gestion de la configuration qui peut simplement être exacerbé par de grosses mises à jour. Parfois, un fichier de configuration est modifié mais l'administrateur ne redémarre jamais le service. Cela signifie que la configuration sur le disque n'a jamais été testée et que la configuration en cours peut ne plus exister. Donc, si le service est redémarré, ce qui se produira une fois que vous aurez appliqué les mises à jour du noyau, il se peut qu'il ne redémarre pas réellement. Ou il peut agir différemment une fois qu'il a redémarré.

Mon conseil serait de faire les mises à jour, mais soyez intelligent.

• Planifiez-le pendant une fenêtre de maintenance. Si rien d'autre ne nécessite un redémarrage du serveur, il y a eu un certain nombre de mises à jour du noyau et vous devrez redémarrer pour les appliquer.
• Assurez-vous de faire une sauvegarde complète avant de faire quoi que ce soit. Cela pourrait être un instantané, s'il s'agit d'une machine virtuelle, déclencher une sauvegarde complète sur quel que soit votre outil, préparer /(vers un autre système), prendre une ddimage des disques, peu importe. Tant que c'est quelque chose que vous pouvez restaurer à partir de.
• Planifiez la façon dont vous appliquez les mises à jour. Vous ne voulez pas simplement vous lancer yum update -ydessus et vous éloigner. Pour toutes les bonnes choses que fait yum, il ne commande pas lorsqu'il applique des mises à jour en fonction des dépendances. Cela a causé des problèmes dans le passé. Je cours toujours yum clean all && yum update -y yum && yum update -y glibc && yum update. Cela a tendance à résoudre la plupart des problèmes de commande potentiels.

Cela peut également être un bon moment pour replatform. Nous avons RHEL6 depuis un bon moment maintenant. Selon ce que fait ce serveur, il peut être judicieux de laisser celui-ci s'exécuter tel quel pendant que vous affichez une nouvelle instance en parallèle. Ensuite, une fois installé, vous pouvez copier toutes les données, tester les services et effectuer la découpe. Cela vous donnera également la chance de savoir, de fond en comble, que le système est standardisé, propre, bien documenté et tout ce jazz.

Peu importe ce que vous faites, je pense qu'il est assez important que vous vous familiarisiez avec un système actuel. Il vous suffit de vous assurer de le faire d'une manière qui vous permette de faire confiance à votre travail et au produit fini.

D'après mon expérience, RHEL ne rompt pas la compatibilité descendante dans les mises à jour de la même version.

cela, cependant, ne s'étendra pas à tout ce qui a été installé en externe à rpm.

Vous pouvez utiliser rpm -qfpour trouver les fichiers que vous pensez être compilés en externe, s'il renvoie "n'appartenant à aucun package", vous pourriez avoir des problèmes avec votre mise à niveau.

Je prendrais une image du serveur et ferais la mise à niveau, je suis un peu plus diabolique que la plupart cependant.