¿Mejores prácticas para mantener actualizados los paquetes de UNIX?

• ¿Cómo mantiene actualizados sus servidores?
• Cuando utiliza un administrador de paquetes como Aptitude , ¿mantiene un historial de actualización / instalación y, de ser así, cómo lo hace?
• Al instalar o actualizar paquetes en varios servidores, ¿hay alguna forma de acelerar el proceso tanto como sea posible?

En sistemas basados ​​en Linux / Debian, cron-apt es una herramienta muy útil que puede gestionar la automatización de apt a través de cron.

Lo estoy usando apt-get updatetodos los días y me envía un correo electrónico si hay que instalar nuevas actualizaciones.

Aquí hay una introducción breve y bien hecha sobre esa herramienta .

Con respecto a su tercera pregunta: siempre ejecuto un repositorio local. Incluso si es solo para una máquina, ahorra tiempo en caso de que necesite reinstalar (generalmente uso algo como aptitude autoclean), y para dos máquinas, casi siempre vale la pena.

Para los clústeres que administro, generalmente no mantengo registros explícitos: dejo que el administrador de paquetes lo haga por mí. Sin embargo, para esas máquinas (a diferencia de las computadoras de escritorio), no uso instalaciones automáticas, así que tengo mis notas sobre lo que pretendía instalar en todas las máquinas.

Similar a cron-apt, yo uso apticron .

Yo uso apt-history para la historia. No tengo idea de por qué esta útil herramienta no está incluida de manera predeterminada, es el primer paquete que implemento con Puppet .

Corro / usr / bin / apt-get update -qq; / usr / bin / apt-get dist-upgrade -duyq como una tarea programada cada noche. Por la mañana tengo una notificación de qué paquetes necesitan actualizarse, y los archivos ya se han descargado en la máquina.

Luego, generalmente tomo una instantánea de la máquina (la mayoría de nuestros servidores son virtuales), hago una actualización de apt-get dist , compruebo nagios y me aseguro de que todo siga funcionando y elimino la instantánea.

Finalmente, mantengo una lista actualizada de todos los cambios realizados en cada servidor en una wiki , para rastrear cualquier problema que surja más adelante.

En cuanto a limitar las descargas redundantes, entiendo que puede configurar un proxy web de almacenamiento en caché (squid?) Entre sus servidores e Internet que almacenará en caché los archivos .deb la primera vez que se acceda a ellos. Quizás esto es más simple que configurar un repositorio de paquetes local, y tiene el beneficio adicional de acelerar la navegación web general.

apt-cacher es útil para almacenar en caché los paquetes, se almacenará en caché la primera vez que se necesiten en lugar de completar un espejo completo de todo el repositorio, ahorrando así disco y ancho de banda. También es útil ya que transmite la primera solicitud de un paquete directamente al solicitante mientras lo almacena en caché al mismo tiempo para que no haya demoras adicionales.

Ejecutar un repositorio local es la mejor manera de administrar exactamente lo que hay en sus servidores locales. También le permite implementar fácilmente backports personalizados o paquetes locales personalizados. Se sabe que hago 'metapaquetes' locales que son solo una gran cantidad de dependencias para facilitar una instalación local. (por ejemplo, 'apt-get install local-mailserver'). Esto tiene el efecto secundario de permitirle 'versionar' sus cambios de configuración. (Para una administración de configuración más complicada, necesitará algo como Puppet)

Para nuestros cuadros de Windows tenemos un servidor WSUS local y una ventana estándar para aplicar los parches mensuales. Para los sistemas Linux (RHEL) tenemos un servidor satelital RHN en el campus al que están todos unidos. Eso proporciona un buen panel de control de cada sistema unido que administra, así como las actualizaciones no aplicadas para cada sistema. Para aquellos que están en títeres, sacamos un script que aplica automáticamente parches durante una ventana normal y envía una notificación por correo electrónico con los resultados.

Puede tener un repositorio local y configurar todos los servidores para que apunten a él para actualizaciones. No solo obtiene la velocidad de las descargas locales, también puede controlar qué actualizaciones oficiales desea instalar en su infraestructura para evitar problemas de compatibilidad.

En el lado de Windows, he usado Windows Server Update Services con resultados muy satisfactorios.

Cuando utiliza un administrador de paquetes como Aptitude, ¿mantiene un historial de actualización / instalación y, de ser así, cómo lo hace?

apt mantiene un registro en / var / log / apt /, y dpkg usa /var/log/dpkg.log. dpkg en particular es bastante analizable.

En OpenSuSE Linux, SLES y Novell OES (todos los productos basados ​​en SuSE), tenemos un script que ejecuta zypper y busca paquetes que deben actualizarse. Cuando encuentra uno, envía un ticket a JIRA y lo asigna a los administradores del sistema. Cuando instalamos las actualizaciones, cerramos el ticket, lo que deja una pista de auditoría que nos dice cuándo fue instalado y quién lo hizo. Esto puede conciliarse / confirmarse con los registros zypper y sudo, que están centralizados en un servidor de syslogging.