¿Con qué frecuencia debo actualizar nuestro servidor Linux?

Soy responsable de administrar tanto nuestro servidor de producción (correo, web, base de datos están en un solo servidor) como nuestro servidor de prueba. Ambos están construidos en Debian. Sin embargo, como soy muy nuevo en la administración del sistema, solo he estado instalando actualizaciones, ya que me encuentro con cosas que deben actualizarse para poder tener nuevas funciones y obtener correcciones de errores. Es un proceso bastante ad hoc en este momento, y me gustaría hacerlo menos.

Entonces, me pregunto cómo las personas que saben lo que están haciendo manejan esto. ¿Con qué frecuencia realiza actualizaciones en sus servidores? ¿El proceso de actualización es diferente entre prueba y producción? ¿Siempre actualiza primero los servidores de prueba? ¿Y realiza una actualización completa de todo el software, o simplemente instala las actualizaciones seleccionadas?

Corro apt-get update -qq; apt-get upgrade -duyq diariamente. Esto buscará actualizaciones, pero no las hará automáticamente.

Luego puedo ejecutar las actualizaciones manualmente mientras estoy mirando y puedo corregir cualquier cosa que pueda salir mal.

Además de las preocupaciones de seguridad de mantener un sistema parcheado, encuentro que si lo dejo demasiado tiempo entre parches, termino con un montón de paquetes que quieren actualizarse, y eso me asusta mucho más que solo actualizar uno o dos cada semana más o menos. Por lo tanto, tiendo a ejecutar mis actualizaciones semanalmente, o si son de alta prioridad, diariamente. Esto tiene la ventaja adicional de saber qué paquete rompió su sistema (es decir, si solo está actualizando un par a la vez)

Siempre actualizo primero los sistemas menos críticos. También tengo un "plan de reversión" en caso de que no pueda arreglar el sistema. (dado que la mayoría de nuestros servidores son virtuales, este plan de reversión generalmente consiste en tomar una instantánea antes de la actualización a la que puedo volver si es necesario)

Dicho esto, creo que una actualización ha roto algo solo una o dos veces en los últimos 4 años, y eso fue en un sistema altamente personalizado, por lo que no tiene que ser DEMASIADO paranoico :)

Además de las respuestas anteriores, un par de cosas más específicamente sobre Debian: debe suscribirse a debian-security-anunciar y debian-anunciar y / o visitar la página de Debian Security .

Suponiendo que esté ejecutando la versión estable de Debian, la mayoría de los parches estarán relacionados con la seguridad o los errores, lo que significa que no habrá demasiados cambios importantes entre las versiones de un paquete dado. De acuerdo con la política de parches de Debian, los parches también deberían haberse estado probando durante algún tiempo antes de que el mantenedor los trasladara a la rama estable. Obviamente, esto no detendrá las roturas al parchar, pero debería evitarlas en la mayoría de los casos.

Sería prudente asegurarse de que su servidor de pruebas se mantenga actualizado y que los paquetes que tengan errores que lo afecten a usted y a sus servidores deben mantenerse actualizados. Todos los paquetes que tienen avisos de seguridad contra ellos deben actualizarse tan pronto como sepa que el parche es estable.

Debian suele ser un sistema operativo muy estable y no debe preocuparse demasiado por las roturas, sin embargo, siempre lea lo que se actualizará antes de actualizarse y esté atento a cualquier cosa que parezca extraña. También uso VCS en mi / etc / dir para asegurarme de que cualquier cambio en el archivo de configuración se pueda ver con un comando 'git diff'.

Hago una prueba en seco (primero) para ver qué se va a actualizar. A veces, las bibliotecas (llamémoslo libfoo para este ejemplo) cambian su API, lo que rompe los programas que escribimos / instalamos nosotros mismos. Si se actualiza alguna biblioteca crítica, tomo la fuente e intento reconstruir nuestras cosas antes de actualizar.

También verifico que no saltemos a una versión intermedia de algún servicio público, es decir, apache, etc. Prefiero quedarme un año atrás y no encontrar roturas al azar, a menos que la actualización sea crítica.

Si usted es un administrador del sistema, debería extraer los canales RSS de sitios como Secunia , lo que debería informarle con anticipación si su distribución va a generar algunos parches.

Nunca, nunca, solo actualice / actualice ciegamente. Desafortunadamente, la tarea de saber qué está roto recae en usted, no en su administrador de paquetes de distribución, especialmente si sus sistemas admiten programadores.

Cuando trabajo, tenemos un proceso bastante extenso que implica el uso de un software llamado PatchLink para notificarnos sobre las actualizaciones más importantes relacionadas con la seguridad, y las aplicamos después de las pruebas, paquete por paquete. Sin embargo, tenemos miles de servidores.

Si solo tiene dos servidores, el proceso debería ser mucho más simple. Aunque no creo que hacer una "actualización / actualización apt-get" sea su mejor opción.

Monitorearía los parches para el software que está ejecutando y tomaría decisiones basadas en las correcciones en esas versiones sobre cuándo actualizar.

Como tiene un servidor de prueba, obviamente, siempre pruebe la actualización antes de aplicarla.

Las actualizaciones manuales son mejores como se menciona aquí en el sentido de que puede ver lo que está sucediendo. Sin embargo, para un gran número de servidores que pueden ser poco prácticos. La ejecución en seco es una práctica estándar, de hecho, la mayoría de los administradores de paquetes le preguntarán antes de continuar.

La actualización periódica suele ser la mejor, aunque puede ser un poco un acto de equilibrio. Las actualizaciones frecuentes significan menos de una vez y menos de fallar a la vez. Si las cosas salen mal, hay menos candidatos para inspeccionar. Los paquetes también son un poco mejores para actualizar en pasos más pequeños, ya que generalmente cuando las actualizaciones del programador están mirando desde la última versión a la siguiente, si puede prestar atención más allá de la última versión puede variar, aunque esto tiende a importar principalmente para software que evoluciona rápidamente.

No todas las actualizaciones no son disruptivas. Querrás tener cuidado con esto. Algunos reiniciarán los servicios y provocarán un tiempo de inactividad.

En una configuración ideal, puede tener lo siguiente:

• Un medio de cambiar servidores aparentemente (A / B o tick tock). Esto significa que actualiza uno mientras está en el banco, luego simplemente cambia el tráfico del actual al nuevo. Esto puede ser más complicado para servicios como bases de datos.
• La capacidad de probar actualizaciones. Debe tener servidores de prueba que sean prácticamente clones de producción (pero sin conectarse a ningún servicio de producción). Estos le permitirán probar primero las actualizaciones.
• Una buena estrategia de respaldo, incremental es ideal. Nunca sabes. Siempre es mejor prevenir que curar.
• Tenga en cuenta qué horas tienen más actividad y qué nivel de tiempo de inactividad es tolerable.
• Sepa cómo deshacer una actualización o un paquete específico.
• Tenga sus propios espejos de paquetes para que las actualizaciones sean consistentes y predecibles en todos los servidores. Este es el primer paso hacia un sistema desatendido decente en el que pueda confiar. Significa que puede actualizar el espejo, ejecutar la actualización en una o más máquinas de prueba y, si eso es bueno, dejar que se apague automáticamente. Pasé un tiempo excelente gestionando acertadamente alrededor de 800 máquinas EPOS.
• Un buen nivel de consistencia para que pueda saber que si algo funciona aquí, funcionará allí.

Algunos de estos pueden ser excesivos en diversos grados para configuraciones pequeñas, pero deben tenerse en cuenta.

En términos generales, las actualizaciones suelen ser relativamente indoloras para las distribuciones de servidores. Esto se debe a que casi siempre solo se adhieren a correcciones de errores y actualizaciones de seguridad. Sin embargo, puede tener problemas si la gente ha hecho cosas extrañas al sistema o si agrega fuentes de paquetes adicionales.

Aunque es moderadamente raro, ocasionalmente cometen errores y rompen la compatibilidad entre versiones de paquetes menores.

Me gusta cron-apt para automatizar este proceso, pero como @dinomite señaló en otra pregunta con respecto a las actualizaciones, configurarlo específicamente para automatizar las actualizaciones relacionadas con la seguridad es una idea muy inteligente: luego puede actualizar manualmente lo que necesita. Había estado usando cron-apt para todas las actualizaciones, pero en realidad cambié esto en función de su respuesta. Si te gusta, probablemente deberías votar su respuesta en lugar de esta.

En Debian, instalo cron-apt y edito su archivo de configuración para enviarme un correo electrónico si hay algún cambio. de esta manera me notifican si hay actualizaciones para mis sistemas y hago las actualizaciones a mano

En la misma línea que cron-apt, debería echar un vistazo al paquete de actualizaciones desatendidas http://packages.debian.org/lenny/unattended-upgrades .

Es muy fácil de configurar y le permitirá descargar y aplicar actualizaciones de seguridad automáticamente, pero dejará otras actualizaciones para la actualización manual (o, a su discreción, ¡actualice todo!

La Guía oficial de Ubuntu Server tiene una sección razonablemente detallada que cubre el uso del paquete de actualizaciones desatendidas https://help.ubuntu.com/9.04/serverguide/C/automatic-updates.html

Nota: dependiendo de su nivel de precaución / paranoia, primero puede hacer una actualización progresiva en un grupo de servidores de prueba, luego, si no hay problemas, permita que se actualicen sus cajas de producción, aunque personalmente no he encontrado ningún problema con las actualizaciones de seguridad causando estragos hasta ahora (toco madera) ...

También hay una opción de configuración para enviarle los resultados de cada actualización de seguridad, una vez que se aplica. Además, si hubo algún cuadro de diálogo o mensajes interactivos que se presentaron durante la actualización, los que necesitarán ajustes manuales por parte de un administrador de sistemas, también los mencionará.

Personalmente apago las actualizaciones automáticas y no realizo regularmente ningún tipo de actualización de paquetes en servidores en mis entornos, a menos que: (a) haya un importante aviso CERT para uno de los paquetes en mi sistema; (b) Necesito actualizar paquetes individuales por razones específicas; (c) El sistema operativo o los paquetes están llegando al final del ciclo, ya no serán compatibles y debemos seguir teniendo soporte. Mi razonamiento es que la actualización sin saber qué se está cambiando o por qué deja demasiado espacio para que algo se rompa. Llevo 14 años haciendo cosas como esta y funciona bien.

Además de las cosas que se mencionan, debe usar algún tipo de herramienta de monitoreo (Nagios o lo que sea que flote en su bote) para alertarlo sobre las actualizaciones.

En cuanto a la frecuencia: ¡Tan pronto como haya una actualización disponible!