Administrar actualizaciones en cientos de servidores Debian


20

¿Cuáles cree que son las mejores prácticas para mantener docenas (si no cientos) de servidores Debian actualizados? Teniendo en cuenta que:

  • Hay grupos de servidores (es decir, servidores web idénticos, servidores DB, ...)
  • Puede haber varios problemas de Debian (lenny, etch)
  • No es aceptable ejecutar un bucle en todos los servidores y hacer apt-get update && upgrade (porque es lo que estoy haciendo en este momento :)) ¡Debería ser mejor que esto!

Actualmente, cuando finalmente termino todas las actualizaciones, se publica una nueva actualización de seguridad, y tengo que volver a hacerlo.

Gracias de antemano comunidad serverfault!


1
Tenga un servidor local para almacenar los paquetes más recientes y úselo como un repositorio apto, esto le ahorrará ancho de banda y tiempo, use su repositorio local para distribuir actualizaciones a los servidores locales. Ah, y usa aptitude en lugar de apt-get.
Karolis T.

3
Sí para espejo y no para aptitud. Sin beneficio en estos días. Ni siquiera tiene superpoderes de vaca.
David Pashley

Respuestas:


12

Uso apt-dater para gestionar la actualización de todos mis cuadros de Debian. Parece hacer el truco lo suficientemente bien. Sin embargo, no he tratado de escalarlo a cientos de hosts.


1
Producto interesante, aunque nunca había oído hablar de él.
wzzrd

Es muy bueno ! Promovería esta respuesta si apt-dater no tuviera un paquete local para instalar en cada host ... y no entiendo por qué es necesario.
Falken

¡Después de probar, esta herramienta es increíble! Pero funciona para docenas de servidores, no cientos. Cuando se manejan muchas máquinas, todo se vuelve escamoso y lento ... lástima.
Falken

1
Promuevo esta respuesta porque finalmente logré usarla, ¡pero otras soluciones también son bastante buenas, dependiendo de sus preferencias / entorno!
Falken

2
Fue el agente ssh predeterminado en ubuntu lo que lo hizo todo mal. Simplemente lo eliminé y usé el sencillo "ssh-add". ¡Toda la lentitud se desvaneció!
Falken


3

Estábamos probando el uso de Puppet para actualizar las correcciones de seguridad en paquetes no esenciales. Ejecutamos apticron para enviar por correo electrónico una lista de actualizaciones para cada servidor, luego ejecutamos diariamente un script que fusionó estas actualizaciones en un archivo de manifiesto títere que proporcionó el paquete y la versión para cada distribución. Esto actualizaría un montón de archivos en los servidores individuales y comenzaría un script de actualización cuando un paquete necesitara actualizarse. Esto funcionó razonablemente bien, pero no lo hemos probado tanto como me gustaría. Este esquema evitó la limitación de Puppet de no tener el mismo recurso definido en varios lugares.

Tampoco me sentía cómodo haciendo actualizaciones automáticas de cosas como MySQL o PostgreSQL, donde una actualización aleatoria cerraría un servicio, posiblemente en la mitad del día. Estos aún requerirían actualizaciones manuales.

Spacewalk y Debmarshall parecen alternativas adecuadas para nuestro esquema de títeres.


No hay comentarios sobre la respuesta, solo un grito tardío de "feliz día 10K".
Evan Anderson

1

Aparentemente, Spacewalk ahora tiene soporte preliminar para Debian. Eso, junto, tal vez, con Puppet, sería mi punto de partida. Estoy bastante seguro de que el tipo que desarrolla el soporte de Debian para Spacewalk lo amará por trabajar con él para llevar el soporte de Debian a un nivel superior.


1

En cuanto a los sistemas de configuración basados ​​en extracción como Puppet, también hay bcfg2 y cfengine. Uno u otro de ellos podría satisfacer bien sus necesidades. Estoy implementando bcfg2 en mi laboratorio ahora mismo.


1

Una solución puede ser dada por func


Yo no haría func. Es una forma inmadura de usar en la producción, aunque admito que es prometedor.
wzzrd

func es utilizado por cobbler, no es inmaduro en mi humilde opinión. cobbler es un gran usuario de especialistas en RH y esas tecnologías se incluirán en la próxima versión de RHEL. Tal vez no esté lista para la producción "formalmente", pero está bastante cerca de serlo.
drAlberT

0

No estoy seguro de qué tipo de solución espera. Probablemente sepa acerca de los trabajos cron, pero no actualizaría los sistemas a ciegas ya que se necesitan intervenciones humanas (y es por eso que le pagan por hacer esto, ¿verdad?)

Si tuviera sistemas completamente idénticos, podría considerar usar algo como rsync para introducir las diferencias, pero descubrir qué archivos no rsync podría ser difícil, y no lo haría mientras los servicios se estén ejecutando. Al menos, los scripts de actualización están configurados para administrar el reinicio de los servicios y la fusión de las diferencias de los archivos de configuración.

Tal vez si explica cuál es el problema con los comandos apt-get podríamos ver lo que desea evitar.

Si el problema es el ancho de banda y el tiempo de descarga, tal vez debería configurar una casilla para que actúe como su depósito local de Debian. Hay guías de Debian sobre cómo hacer eso.

Aquí hay algunos consejos sobre cómo minimizar la cantidad de cosas que necesita actualizar.

Cuando instales Debian, no instales Desktop a menos que realmente necesites usar X en esa consola. La mayoría de los servidores no necesitan X instalado. Esto puede disminuir la cantidad de paquetes en el sistema de manera significativa, y luego no necesita actualizar tantos paquetes.

Compruebe que sources.list incluye solo los repositorios que realmente necesita. Si ha experimentado con algún repositorio y se olvidó de eso, podría estar trayendo actualizaciones que no necesita o no desea.

Si ha tenido problemas para realizar actualizaciones a ciegas en un servidor de producción, tenga cuidado de consultar las guías de actualización de Debian cuando haya una actualización importante (4.0 a 5.0). Esto pasará muy bien si sigue las instrucciones de actualización. No es tan fácil como ejecutar apt-get dist-upgrade y alejarse. A veces, en las instrucciones, incluso hay indicadores sobre cuándo ejecutar aptitude en lugar de apt-get: hay pequeñas diferencias en ellos.



-1

ClusterSSH. Inicie sesión en todos los servidores y les dará exactamente los mismos comandos, para que también pueda reaccionar a los cuadros de diálogo. Si un servidor recibe una pregunta adicional, simplemente haga clic en ese y será el único que responda.

Lo he usado para actualizar 25 servidores web de etch a lenny. Trabajado como un encanto.

http://sourceforge.net/projects/clusterssh/


El agente SSH realmente muere si intentas hacer cosas raras como conectarte a ~ 50 máquinas a la vez. De lo contrario, me gusta ClusterSSH, aunque necesita otro nivel de agrupación.
LapTop006

-1

Cluster ssh es una buena sugerencia.

debmarshal aún no es parte de debian, ni siquiera estoy seguro de que sea un paquete, parece ser un sistema completamente diferente con un repositorio especializado. Como dijo el orador, esto es actualmente hostil para el usuario, no fácil de usar.

Spacewalk parece ser un clon de Redhat Network, al menos en la interfaz web. He tenido malos resultados al usar Redhat Network para actualizar sistemas. Una vez se colgó, sin razón aparente, y causó la interrupción del servicio. Hice una actualización yum inmediatamente después y funcionó bien, así que solo puedo suponer que el problema fue de algo que vomitó en el lado de RHN. La otra cosa que no me gusta de las actualizaciones de RHN es que no sabes cuándo ocurrirá la actualización, para ver si hay problemas.


-1 Falso: las actualizaciones de RHN no son automáticas a menos que las haga automáticas. Aparte de eso: como alguien que usa RHN a diario, aún no lo he visto.
wzzrd

No dije que RHN era automático. Pero si configura las actualizaciones de RHN, no se sabe cuándo sucederán, por lo que se siente lo mismo. Su aparente suerte no deshace mi experiencia real al fallar y dejar a los usuarios sin servicio. Incluso la actualización de yum puede fallar. Cualquiera que piense que puede actualizarse y retirarse no está teniendo cuidado o simplemente no está preocupado porque no es un servidor de producción (producción = hay clientes que dependen de los servicios).
labradort
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.