«Mise à jour yum» automatisée pour sécuriser le serveur - avantages et inconvénients?

J'envisage d'ajouter un cronjob fonctionnant yum -qy updaterégulièrement sur certaines machines qui ne bénéficient pas d'une maintenance régulière. L'objectif serait de maintenir les machines à jour en ce qui concerne les correctifs de sécurité qui seraient sinon appliqués trop tard. J'utilise uniquement les référentiels de base CentOS.

Des questions:

• D'après votre expérience - dans quelle mesure cette approche serait-elle «sûre»? Dois-je m'attendre à des échecs de mises à jour de temps en temps? À quelle fréquence cette approche nécessiterait-elle des redémarrages?
• Avantages / inconvénients ou autres problèmes avec cette approche?
• Comment gardez-vous vos machines à jour grâce à l'automatisation?

Ça dépend

D'après mon expérience avec CentOS, c'est assez sûr car vous n'utilisez que les référentiels de base CentOS.

Si vous vous attendez à des mises à jour échouées de temps en temps ... oui ... au même niveau que vous devriez vous attendre à un disque dur défaillant ou à un processeur défaillant de temps en temps. Vous ne pouvez jamais avoir trop de sauvegardes. :-)

La bonne chose à propos des mises à jour automatisées est que vous obtenez des correctifs (et donc plus de sécurité) plus rapidement que de le faire manuellement.

Les correctifs manuels semblent toujours être repoussés ou considérés comme "à faible priorité" pour tant d'autres choses, donc si vous allez passer en mode manuel, PLANIFIEZ LE TEMPS SUR VOTRE CALENDRIER pour le faire.

J'ai configuré de nombreuses machines pour faire des mises à jour automatiques (via le travail cron) et j'ai rarement eu un problème. En fait, je ne me souviens pas avoir eu de problème avec les référentiels BASE. Chaque problème auquel je peux penser (du haut de ma tête, selon mon expérience) a toujours été une situation de tiers.

Cela étant dit ... J'ai plusieurs machines pour lesquelles je fais manuellement les mises à jour. Des choses comme les serveurs de bases de données et d'autres systèmes extrêmement critiques j'aime avoir une approche "pratique".

La façon dont je l'ai compris personnellement était comme ça ... Je pense au scénario "et si" et ensuite j'essaye de penser au temps qu'il faudrait pour reconstruire ou restaurer à partir d'une sauvegarde et ce qui (le cas échéant) serait perdu .

Dans le cas de plusieurs serveurs Web ... ou de serveurs dont le contenu ne change pas beaucoup ... Je vais de l'avant et je fais une mise à jour automatique car le temps de reconstruction / restauration est minime.

Dans le cas des serveurs de bases de données critiques, etc ... Je planifie du temps une fois par semaine pour les examiner et les corriger manuellement ... car le temps nécessaire pour reconstruire / restaurer prend plus de temps.

Selon les serveurs que VOUS avez sur votre réseau et la façon dont votre plan de sauvegarde / restauration est mis en œuvre, vos décisions peuvent être différentes.

J'espère que cela t'aides.

Pro : votre serveur est toujours au dernier niveau de correctif, généralement même contre les exploits de 0 jour.

Inconvénients : tout code exécuté sur votre serveur qui utilise des fonctionnalités supprimées dans les versions ultérieures, tous les fichiers de configuration qui changent la syntaxe et toutes les nouvelles "fonctionnalités" de sécurité qui empêchent l'exécution de code qui peuvent être exploitées peuvent provoquer des ruptures s'exécutant sur ce serveur sans vous le savoir jusqu'à ce que quelqu'un vous appelle avec un problème.

Meilleure pratique: demandez au serveur de vous envoyer un e-mail lorsqu'il doit être mis à jour. Sauvegarder ou savoir comment annuler les mises à jour.

En plus de ce que la plupart des gens ont dit ici, je vous recommande fortement de vous inscrire à la liste de diffusion centos, ils publient toujours des e-mails sur les correctifs et leurs priorités juste avant de les pousser vers les référentiels. Il est utile de savoir à l'avance quels packages doivent être mis à niveau.

Ma configuration permet à yum de mettre à jour automatiquement le système une fois par jour, je fais en sorte que yum m'envoie un mail avec les packages installés ou mis à jour juste après. Je reçois également du courrier en cas de conflit et j'ai besoin d'une intervention manuelle (toutes les 4 heures).

Jusqu'à présent, tout se passe bien (depuis plus de 4 ans maintenant), la seule fois où j'ai été pris au dépourvu, c'est quand yum a mis à jour le noyau régulier (j'ai virtualisé mon serveur) et a changé le grub et a poussé le noyau régulier par défaut, 2 semaines plus tard pendant la maintenance, mon système a été redémarré et tous mes serveurs virtuels ont disparu pendant quelques minutes jusqu'à ce que je doive intervenir manuellement.

A part ça, je n'ai pas vraiment eu de problèmes.

tant que vous n'avez pas de packages personnalisés et que vous utilisez uniquement les référentiels de base de CentOS, cela devrait être assez sûr.

aussi, un meilleur moyen d'y parvenir serait d'utiliser yum-updatesd avec do_update = yesset.

Je suppose que tant que vous avez des sauvegardes automatisées, ce ne sera pas trop un souci, tant que vous pouvez vivre avec un temps d'arrêt du serveur.

Je n'ai pas essayé ça; Je ne voudrais pas personnellement parce qu'il y a un risque important de casser quelque chose ou d'avoir un problème obscur inhabituel en raison d'un correctif en amont. C'est encore pire s'il s'agit d'un serveur qui attire rarement l'attention, donc si quelque chose ne va pas, vous ne le savez peut-être pas.

Si vous pouvez vivre avec le serveur en question en panne pendant une période de temps si / quand quelque chose se casse, et vous avez un plan de réponse pour restaurer le système à l'état précédent ainsi qu'un système pour vous envoyer des mises à jour via des journaux ou des e-mails signaler quand et ce qui a été mis à jour (afin que vous sachiez qu'il n'est pas bloqué ou en attente d'une réponse à quelque chose qui nécessite une intervention), alors vous pouvez l'essayer. Si c'est un serveur critique ou quelque chose d'important ... je ne voudrais pas le risquer.

Mes serveurs ne vous appartiennent pas :-)