À quelle fréquence devrais-je mettre à jour notre serveur Linux?

Je suis responsable de la gestion de notre serveur de production (courrier, Web, bases de données sur un seul serveur) et de notre serveur de test. Les deux sont construits sur Debian. Cependant, comme je suis très novice dans l'administration système, je n'ai fait qu'installer des mises à jour, car je découvre des éléments qui doivent être mis à jour pour pouvoir disposer de nouvelles fonctionnalités et obtenir des correctifs. C'est un joli processus ad hoc en ce moment, et j'aimerais le rendre moins.

Alors je me demande comment les gens qui savent ce qu'ils font gèrent ça? À quelle fréquence effectuez-vous des mises à niveau sur vos serveurs? Le processus de mise à niveau est-il différent entre le test et la production? Mettez-vous toujours à niveau les serveurs de test en premier? Et effectuez-vous une mise à jour complète de tous les logiciels ou installez-vous simplement les mises à jour sélectionnées?

Je lance apt-get update -qq; apt-get upgrade -duyq quotidiennement. Cela vérifiera les mises à jour, mais ne les fera pas automatiquement.

Ensuite, je peux exécuter les mises à niveau manuellement pendant que je regarde et corriger tout ce qui pourrait mal tourner.

Outre les problèmes de sécurité liés à la maintenance d'un système corrigé, je constate que si je le laisse trop longtemps entre deux correctifs, je me retrouve avec toute une série de paquets qui veulent être mis à niveau, ce qui me fait bien plus peur que la simple mise à niveau. deux chaque semaine ou à peu près. Par conséquent, j'ai tendance à exécuter mes mises à niveau chaque semaine ou, si elles sont prioritaires, tous les jours. Cela présente l’avantage supplémentaire de savoir quel paquet a brisé votre système (c’est-à-dire si vous ne mettez à jour que quelques personnes à la fois).

Je mets toujours à niveau les systèmes les moins critiques en premier. J'ai également un "plan de restauration" en place au cas où je ne pourrais pas réparer le système. (Étant donné que la plupart de nos serveurs sont virtuels, ce plan de restauration consiste généralement à prendre un instantané avant la mise à niveau auquel je peux revenir si nécessaire.)

Cela étant dit, je pense qu'une mise à niveau n'a endommagé quelque chose qu'une ou deux fois au cours des 4 dernières années, et que c'était sur un système hautement personnalisé - vous n'avez donc pas à être trop paranoïaque :)

En plus des réponses précédentes - quelques-unes plus spécifiquement de choses Debian: vous devriez vous abonner à debian-security- advert et debian-annonc et / ou consulter la page Sécurité Debian .

En supposant que vous utilisiez la version stable de Debian, la plupart des correctifs seront liés à la sécurité ou à des bogues, ce qui signifie qu’il n’y aura pas trop de changements majeurs entre les versions d’un paquet donné. Selon la stratégie de correctifs de Debian, les correctifs auraient également dû être testés pendant un certain temps avant d'être déplacés vers la branche stable par le responsable. Évidemment, cela n'arrêtera pas les ruptures lors de l'application de correctifs, mais devrait les éviter dans la plupart des cas.

Il serait prudent de vous assurer que votre serveur de test est tenu à jour et que tous les paquets contenant des bogues vous affectant, ainsi que vos serveurs, devraient être tenus à jour. Tous les paquetages contenant des avis de sécurité doivent être mis à jour dès que vous savez que le correctif est stable.

Debian est généralement un système d’exploitation très stable et vous ne devriez pas trop vous inquiéter des casses, mais lisez toujours ce qui va être mis à jour avant de le mettre à jour et gardez un œil sur tout ce qui vous semble étrange. J'utilise VCS sur mon / etc / dir également pour m'assurer que tout changement de fichier de configuration peut être vu avec une commande 'git diff'.

Je fais un essai (d'abord) pour voir ce qui va être mis à jour. Parfois, les bibliothèques (appelons-le libfoo pour cet exemple) changent d’API, ce qui rompt les programmes que nous avons écrits / installés nous-mêmes. Si une bibliothèque critique est mise à jour, je récupère le code source et essaie de reconstituer nos fichiers avant de le mettre à jour.

Je vérifie également que nous ne passons pas à une version intermédiaire de certains services publics, c.-à-d. Apache, etc. Je préférerais rester un an en arrière et ne pas rencontrer de casse aléatoire, à moins que la mise à jour ne soit critique.

Si vous êtes administrateur système, vous devriez extraire les flux RSS de sites tels que Secunia , ce qui vous permettra de savoir longtemps à l’avance si votre distribution va installer des correctifs.

Ne jamais, jamais, juste aveuglément mettre à jour / mettre à jour. Malheureusement, la tâche de savoir ce qui est cassé incombe à vous, et non à votre gestionnaire de paquets distro, surtout si vos systèmes prennent en charge les programmeurs.

Là où je travaille, nous avons un processus assez long qui implique l’utilisation d’un logiciel appelé PatchLink pour nous informer des mises à jour les plus importantes en matière de sécurité, et nous les appliquons après les tests, package par package. Nous avons des milliers de serveurs cependant.

Si vous n'avez que deux serveurs, le processus devrait être beaucoup plus simple. Bien que je ne pense pas que faire une "apt-get update / upgrade" soit votre meilleur pari.

Je surveillerais les correctifs du logiciel que vous exécutez et prendrais des décisions en fonction des correctifs de ces versions en ce qui concerne le moment de la mise à niveau.

Puisque vous avez un serveur de test, il est évident que vous devez toujours tester la mise à jour avant de l’appliquer.

Les mises à jour manuelles sont préférables, comme mentionné ici, dans le sens où vous pouvez voir ce qui se passe. Cependant, pour un très grand nombre de serveurs, cela pourrait devenir impraticable. La marche à sec est une pratique courante. En fait, la plupart des gestionnaires de colis vous le demanderont avant de poursuivre.

La mise à jour régulière tend à être préférable, bien que cela puisse être un peu un exercice d'équilibre. Les mises à jour fréquentes signifient moins en une fois et moins de problèmes en une fois. Si les choses tournent mal, il y a moins de candidats à inspecter. Les paquets sont aussi légèrement meilleurs pour la mise à jour par petites étapes, comme généralement lorsque le programmeur met à jour, il souhaite passer de la dernière version à la suivante. principalement pour les logiciels en évolution rapide.

Toutes les mises à jour ne sont pas perturbatrices. Vous voudrez faire attention à cela. Certains redémarreront des services entraînant des temps d'arrêt.

Dans une configuration idéale, vous pourriez avoir les éléments suivants:

• Un moyen de changer de serveur en douceur (A / B ou tick tock). Cela signifie que vous en mettez à jour un pendant qu'il est sur le banc, puis permutez simplement le trafic du trafic actuel vers le nouveau. Cela peut être plus compliqué pour des services tels que des bases de données.
• La possibilité de tester les mises à jour. Vous devez avoir des serveurs de test qui sont pratiquement des clones de production (mais sans connexion à aucun service de production). Cela vous permettrait de tester les mises à jour en premier.
• Une bonne stratégie de sauvegarde, incrémentielle est idéale. On ne sait jamais. Il vaut toujours mieux prévenir que guérir.
• Sachez quelles heures sont les plus actives et quel niveau d'indisponibilité est tolérable.
• Savoir comment annuler une mise à jour ou un package spécifique.
• Disposez de vos propres miroirs de package pour que les mises à jour soient cohérentes et prévisibles sur tous les serveurs. C’est la première étape vers un système sans surveillance décent auquel vous pouvez faire confiance. Cela signifie que vous pouvez mettre à jour le miroir, exécuter la mise à jour sur une ou plusieurs machines de test, puis, si c'est bon, le laisser disparaître automatiquement. J'ai passé un excellent moment à gérer avec succès environ 800 machines EPOS.
• Un bon niveau de cohérence pour que vous sachiez que si quelque chose va marcher ici, ça va marcher là-bas.

Certaines d’entre elles peuvent être surexploitées à des degrés divers pour de petites configurations, mais il convient de les garder à l’esprit.

De manière générale, les mises à jour sont généralement relativement simples pour les distributions de serveurs. En effet, ils ne s’attachent presque toujours qu’aux correctifs de bogues et aux mises à jour de sécurité. Vous pouvez cependant avoir des problèmes si des personnes ont modifié le système ou si vous ajoutez des sources de paquetages supplémentaires.

Bien que ce soit assez rare, ils commettent parfois des erreurs et cassent la compatibilité entre les versions de paquetages mineurs.

J'aime bien pouvoir automatiser ce processus, mais comme l'a souligné @dinomite sur une autre question concernant les mises à jour, le configurer spécifiquement pour automatiser les mises à jour liées à la sécurité est une idée très intelligente - vous pouvez ensuite mettre à jour manuellement ce dont vous avez besoin. J'avais utilisé cron-apt pour toutes les mises à jour, mais en fait, cela a été modifié en fonction de sa réponse. Si cela vous convient, vous devriez probablement voter sur sa réponse plutôt que sur celle-ci.

Sur debian, j'installe cron-apt et édite son fichier de configuration pour m'envoyer un mail en cas de changement. De cette façon, je suis informé s'il y a des mises à jour pour mes systèmes et fais les mises à jour à la main

Dans le même ordre d'idées que cron-apt, vous devriez jeter un coup d'œil au paquet sans surveillance - mises à jour http://packages.debian.org/lenny/unattended-upgrades .

Il est très facile à configurer et vous permettra de télécharger et d'appliquer automatiquement les mises à jour de sécurité, tout en laissant d'autres mises à jour pour une mise à niveau manuelle (ou, à votre discrétion, tout mettre à niveau!).

Le Guide officiel du serveur Ubuntu contient une section assez détaillée couvrant l’utilisation du paquet de mises à jour sans surveillance https://help.ubuntu.com/9.04/serverguide/C/automatic-updates.html

Remarque: en fonction de votre niveau de prudence / de paranoïa, vous pouvez commencer par effectuer une mise à niveau progressive sur un groupe de serveurs de test. Ensuite, s'il n'y a pas de problèmes, laissez vos modules de production se mettre à jour, bien que je n'ai personnellement rencontré aucun problème avec les mises à jour de sécurité. ravages jusqu'à présent (toucher du bois) ...

Il existe également une option de configuration pour vous envoyer par courrier électronique les résultats de chaque mise à jour de sécurité, une fois celle-ci appliquée. De plus, si des invites de dialogue ou interactives ont été présentées lors de la mise à jour, celles-ci nécessiteront un ajustement manuel par un administrateur système, elles seront également mentionnées.

Personnellement, je désactive les mises à jour automatiques et n’effectue régulièrement aucune mise à jour des packages sur les serveurs de mes environnements, sauf si: (a) il existe un avis CERT important pour l’un des packages de mon système; (b) je dois mettre à jour des paquets individuels pour des raisons spécifiques; (c) Les systèmes d'exploitation ou les packages arrivent en fin de cycle, ils ne seront plus pris en charge et nous devons continuer à le faire. Mon raisonnement est que mettre à niveau sans savoir ce qui est en train d'être changé ou pourquoi laisse trop de place à quelque chose qui cloche. Je fais ce genre de choses depuis 14 ans et ça marche bien.

Outre les éléments mentionnés, vous devez utiliser un outil de surveillance (Nagios ou tout ce qui flotte sur votre bateau) pour vous alerter des mises à jour.

En ce qui concerne la fréquence: Dès qu'une mise à jour est disponible!