Meilleures pratiques pour maintenir à jour les packages UNIX?

• Comment gardez-vous vos serveurs à jour?
• Lorsque vous utilisez un gestionnaire de packages comme Aptitude , conservez-vous un historique de mise à niveau / d'installation, et si oui, comment procédez-vous?
• Lors de l'installation ou de la mise à niveau de packages sur plusieurs serveurs, existe-t-il des moyens d'accélérer le processus autant que possible?

Sur les systèmes Linux / Debian, cron-apt est un outil très pratique qui peut gérer l'automatisation d'apt via cron.

Je l'utilise apt-get updatetous les jours et m'envoie un e-mail si de nouvelles mises à jour doivent être installées.

Voici une introduction courte et bien faite sur cet outil .

Concernant votre troisième question: je gère toujours un référentiel local. Même si ce n'est que pour une seule machine, cela fait gagner du temps au cas où je devrais réinstaller (j'utilise généralement quelque chose comme aptitude autoclean), et pour deux machines, cela rapporte presque toujours.

Pour les clusters que j'administre, je ne garde généralement pas de journaux explicites: je laisse le gestionnaire de paquets le faire pour moi. Cependant, pour ces machines (par opposition aux ordinateurs de bureau), je n'utilise pas les installations automatiques, j'ai donc mes notes sur ce que j'avais l'intention d'installer sur toutes les machines.

Semblable à cron-apt, j'utilise apticron .

J'utilise apt-history pour l'histoire. Je ne sais pas pourquoi cet outil utile n'est pas inclus par défaut, c'est le premier package que je déploie avec marionnette .

Je lance / usr / bin / apt-get update -qq; / usr / bin / apt-get dist-upgrade -duyq en tant que tâche cron tous les soirs. Dans la matinée, je suis informé des packages à mettre à niveau et les fichiers ont déjà été téléchargés sur la machine.

Ensuite, je prends généralement un instantané de la machine (la plupart de nos serveurs sont virtuels), fais une mise à niveau distante apt-get , vérifie les nagios et vérifie que tout fonctionne toujours, et supprime l'instantané.

Enfin, je garde une liste courante de toutes les modifications apportées à chaque serveur sur un wiki , afin de suivre les problèmes qui surviennent plus tard.

En ce qui concerne la limitation des téléchargements redondants, je comprends que vous pouvez configurer un proxy web de mise en cache (squid?) Entre vos serveurs et Internet qui mettra en cache les fichiers .deb lors de leur premier accès. C'est peut-être plus simple que de configurer un référentiel de packages local - et a l'avantage supplémentaire d'accélérer la navigation Web générale.

apt-cacher est pratique pour la mise en cache des packages, il mettra en cache la première fois qu'ils sont nécessaires plutôt que de compléter un miroir complet de l'ensemble du référentiel, économisant ainsi le disque et la bande passante. C'est également pratique car il diffuse la première demande d'un package directement au demandeur tout en le mettant en cache en même temps, il n'y a donc pas de délai supplémentaire.

L'exécution d'un référentiel local est le meilleur moyen de gérer exactement ce qui se trouve sur vos serveurs locaux. Il vous permet également de déployer facilement des rétroportages personnalisés ou des packages locaux personnalisés. J'ai été connu pour créer des «méta packages» locaux qui ne sont qu'un énorme nombre de dépendances pour faciliter une installation locale. (par exemple, 'apt-get install local-mailserver'). Cela a pour effet secondaire de vous permettre également de «version» de vos changements de configuration. (Pour une gestion de configuration plus compliquée, vous aurez besoin de quelque chose comme Puppet)

Pour nos boîtes Windows, nous avons un serveur WSUS local et une fenêtre standard pour appliquer les correctifs mensuels. Pour les systèmes Linux (RHEL), nous avons un serveur satellite RHN sur le campus auquel ils sont tous joints. Cela fournit un joli tableau de bord de chaque système joint que vous administrez, ainsi que les mises à jour non appliquées pour chaque système. Pour ceux qui sont en marionnette, nous poussons un script qui applique automatiquement les correctifs pendant une fenêtre normale et envoie une notification par e-mail avec les résultats.

Vous pouvez avoir un référentiel local et configurer tous les serveurs pour qu'il pointe vers lui pour les mises à jour. Non seulement vous obtenez la vitesse des téléchargements locaux, mais vous pouvez également contrôler les mises à jour officielles que vous souhaitez installer sur votre infrastructure afin d'éviter tout problème de compatibilité.

Du côté de Windows, j'ai utilisé Windows Server Update Services avec des résultats très satisfaisants.

Lorsque vous utilisez un gestionnaire de packages comme Aptitude, conservez-vous un historique de mise à niveau / d'installation, et si oui, comment procédez-vous?

apt conserve un journal dans / var / log / apt / et dpkg utilise /var/log/dpkg.log. dpkg en particulier est assez analysable.

Sur OpenSuSE Linux, SLES et Novell OES (tous les produits basés sur SuSE), nous avons un script qui exécute zypper et recherche les packages qui doivent être mis à jour. Lorsqu'il en trouve un, il soumet un ticket à JIRA et l'attribue aux administrateurs système. Lorsque nous installons les mises à jour, nous fermons le ticket, ce qui laisse une piste d'audit qui nous indique quand il a été installé et par qui. Cela peut être réconcilié / confirmé avec les journaux zypper et sudo, qui sont centralisés sur un serveur syslogging.