Pour mettre à jour miam? Ou pas?

veuillez pardonner cette question plutôt simple.

Tout d'abord, je ne suis pas un administrateur système et mon expérience avec Linux est quelque peu limitée.

Il y a environ 3-4 mois, j'ai mis en place un serveur CentOS au travail, pour diverses raisons. Nous l'utilisons comme serveur de développement pour les sites Web (auxquels nos clients ont accès), serveur de subversion, et nous hébergeons également un wiki là-bas pour la communication interne, il est donc devenu un outil très important pour nous. (Probablement plus important que ce que nous pensions qu'il serait quand je l'ai installé!)

Il est venu à mon attention que Yum veut mettre à jour environ 250 packages vers les dernières versions du référentiel.

Étant donné que le serveur fonctionne bien pour nous, dois-je prendre le risque de mettre à jour ces packages? Les risques de sécurité l'emportent-ils sur le risque de panne du serveur lorsque je mets tout à jour?

Je dois souligner que même si j'ai des sauvegardes de tout, il faudrait du temps pour tout configurer tel qu'il est maintenant, et je n'ai pas beaucoup de temps libre au travail pour le moment!

Si le conseil est de mettre à jour, existe-t-il des meilleures pratiques qui pourraient être transmises pour rendre le processus aussi sûr que possible?

Merci d'avance pour tout conseil.

MISE À JOUR - Merci pour vos réponses à tous. Si j'avais assez de représentants pour voter pour tout le monde, je le ferais. ;) J'ai décidé de fantôme le disque dur et de le mettre à jour. Malheureusement, mettre la main sur un administrateur système à temps plein ou à temps partiel n'est pas une option pour le moment, je vais donc devoir régler le problème du mieux que je peux!

Solution rapide et sale (c.-à-d. Battlefield Administrator):

1. Mettez votre système hors ligne (j'espère que vous le pouvez) et effectuez une sauvegarde NortonGhost (ou quelque chose de similaire) sur un 2ème disque dur.

2. Démarrez le 2ème disque dur (pour vous assurer que votre sauvegarde fonctionne réellement) et effectuez la mise à jour yum sur CE disque.

3. Si tout fonctionne ... félicitations!

4. Si ça gâche quelque chose ... allez-y et mettez votre lecteur ORIGINAL et trouvez un "Plan B".

MISE À JOUR:

Je pensais juste mentionner que le vrai problème ici est "Dois-je mettre à jour mon système waaaay obsolète et risquer de le gâcher?" ou "Dois-je laisser mon système de travail parfaitement fonctionnel sans correctif et risquer de le faire pirater / compromettre?"

La réponse est ... une fois que votre système est corrigé via les étapes ci-dessus ... essayez de rester au top en le sauvegardant fréquemment ET en le corrigeant fréquemment.

Ensuite, vous aurez le meilleur des deux mondes. ;-)

Oui, mettez à jour.

RHEL (et donc CentOS) font attention à ne pas mettre à jour les versions vers quoi que ce soit d'incompatible, au lieu de cela, ils rétroportent les corrections de bogues et les correctifs de sécurité, de sorte que les modifications réelles apportées aux packages sont minimes et raisonnablement peu susceptibles de causer des problèmes de compatibilité.

Si des fichiers de configuration ont changé, les packages vous parleront d'un fichier .rpmorig ou .rpmnew qui sera créé. Cela dépend de la configuration du RPM lui-même. Vous pouvez rechercher des avertissements à propos de ceux qui sont créés et remettre votre ancienne configuration (" cp foo foo.bak; cp foo.rpmorig foo") ou regarder les fichiers .rpmnew et incorporer toutes les modifications dans votre configuration.

Le problème est moins visible si vous mettez à jour régulièrement.

Nous avons beaucoup de systèmes qui sont mis à jour trimestriellement (tous les 3 mois); et très rarement voir des problèmes de mises à jour de packages. (sauf sur les systèmes faisant des choses étranges sur le noyau pour accéder aux LUN à partir d'un SAN)

Bien que oui, il faudrait du temps pour mettre à niveau, Et dans le même manoir, il faudrait du temps pour restaurer si quelque chose tournait mal, Quelle douleur / souffrance ce serait si les données sur ce système étaient supprimées par un exploit / hack?

Pour la plupart, les mises à niveau à partir des référentiels de base CentOS sont sûres à installer, La seule fois où j'ai eu des problèmes de mise à jour avec CentOS, c'est quand je démarre / ou que j'ai besoin d'utiliser un référentiel extérieur (DAG, RPMForge, Ect ect ..)

La meilleure configuration pour ce genre de chose est d'avoir un serveur remplaçable à chaud prêt, afin que vous puissiez tester les mises à jour dessus avant de les déployer sur le serveur en direct.

On dirait que vous avez besoin d'un administrateur système réel pour prendre quelques heures pour examiner votre système, le mettre à jour et vous assurer que tout fonctionne à nouveau. Idéalement, vous voudriez que cette personne vienne le faire pour vous quelques fois par mois. Un serveur n'est pas une chose à installer une fois et à oublier; il a besoin d'un service régulier.

Si ce système est si important, les mises à jour de sécurité deviennent d'autant plus importantes. Considérez les implications si ce système doit être arrêté pour une reconstruction si (quand?) Un paquet obsolète permet un compromis du système. Idéalement, vous auriez un serveur de test configuré de manière similaire que vous pourriez mettre à jour en premier et vérifier si quelque chose se cassait.

Lorsque vous appliquez des mises à jour, vous devez vous assurer de certaines choses:

1. L'heure de mise à jour est annoncée à tous ceux qui utilisent le système
2. Vous avez un plan sur la façon de mettre à jour et de tester chaque application
3. Vous avez un plan pour annuler les mises à jour si (quand?) La mise à jour casse l'application
4. Et les sauvegardes actuelles existent en cas de problème

Un bon administrateur système aurait de l'expérience dans ce genre de travail et devrait de toute façon faire toutes ces choses. Si votre organisation en a, alors c'est peut-être le moment de vider l'administration du système sur eux. Ou si vous êtes nerveux à l'idée de le faire vous-même, envisagez d'embaucher une personne sous contrat pour effectuer ce type d'entretien de routine. Quoi qu'il en soit, les mises à jour doivent avoir lieu, car vous vous ouvrez à une situation bien pire sur toute la ligne.

C'est pourquoi aujourd'hui, je n'exécute presque jamais de système de production sur du vrai matériel. Je les exécute dans des machines virtuelles. Ensuite, pendant un bref temps d'arrêt (5 minutes), j'exécute un instantané à partir d'ESX lui-même, ou si j'utilise une configuration Xen / Solaris / OpenVZ personnalisée, je fais un instantané LVM de l'image du serveur. Je démarre ensuite la sauvegarde d'origine, et maintenant j'ai une copie que je peux faire à ma guise.

Cela dit, commencez par mettre à jour le noyau et apache, puis revenez en arrière à partir de là. Vous n'êtes pas obligé de prendre la liste complète des paquets que Yum rapporte, mais les principaux vecteurs d'attaque devraient être ceux que vous corrigez le plus tôt.

Chaque fois que j'ai eu un système Linux piraté, c'est parce que j'ai laissé apache, openssh ou le noyau lui-même non corrigé.

Je voudrais simplement mettre à jour les packages liés à la sécurité.

J'ai eu cette chose exacte il y a un an environ ... J'ai fait la mise à jour yum sur la boîte CentOS, fonctionnant sur du matériel Dell et il a installé un noyau qui ne démarrerait pas. La boîte n'avait encore rien chargé (sinon j'aurais été plus prudent). J'ai passé beaucoup de temps à jouer avec et il semble qu'il y ait une incompatibilité entre les noyaux CentOS / Linux plus récents et cette boîte Dell. Soyez très prudent avec vos mises à jour. Je recommande toujours la mise à jour car c'est la bonne chose à faire, mais soyez prêt à récupérer à partir d'un système saccagé!