¿Deberías ejecutar actualizaciones automáticas?

Estoy ejecutando servidores web de producción de Centos. Quiero saber cuál es la mejor práctica para ejecutar actualizaciones. ¿Debo automatizar esto con yum-cron o yum-updatesd? ¿O existe el peligro de que las actualizaciones rompan los sitios, por lo que sería mejor actualizar en un servidor de prueba y luego ejecutar actualizaciones manualmente semanalmente?

La mayoría de los servidores están utilizando solo los repositorios oficiales, pero algunos tienen el repositorio atómico para módulos PHP que de otro modo no están disponibles. ¿Qué es lo mejor en este caso? ¿Puedo configurar yum para usar solo Atomic para los módulos PHP? No quiero que todo se actualice a las cosas de vanguardia en Atomic, confiaría más bien en Centos (o realmente Red Hat) para mantener mis servidores estables y seguros.

Hay ventajas y desventajas en ambos sentidos, y realmente necesita trabajar a través de la arquitectura de su sistema para saber cuál es el mejor para usted. Independientemente de la ruta que tome, debe comprender por qué eligió ese método y cuáles son las desventajas para poder compensarlos.

Aquí hay algunas cosas a considerar:

• Las actualizaciones de seguridad siempre deben aplicarse de una forma u otra, y más temprano que tarde. Si su servidor no está aplicando actualizaciones de seguridad de manera oportuna por cualquier razón, arregle sus hábitos de administrador de sistemas.

• Las actualizaciones de distribución suelen ser buenas, especialmente si provienen de fuentes oficiales. Si se siente incómodo al aplicarlos, tal vez no esté utilizando la mejor distribución para sus necesidades. Deberías usar una distribución que coincida con tu metodología. En otras palabras, uno en el que pueda confiar para que las actualizaciones sean lo mejor para usted. Si se mueven demasiado rápido o hacen cambios de software que rompen tus cosas, probablemente deberías estar usando una distribución diferente.

• Las actualizaciones pueden romper tus cosas. Un cambio a un software más nuevo podría romper su código si utilizó funciones obsoletas o simplemente escribió cosas malas. Debe considerar una arquitectura de sistema que le permita probar su producto en las actualizaciones antes de ejecutarlas en los sistemas de producción.

• Si usa las funciones de actualización automática, siempre debe tener una forma de retroceder a las configuraciones de trabajo conocidas. Las instantáneas completas del sistema pueden salvarle la vida si alguna actualización rompe su producto en un sistema de producción.

Esta no es una lista exhaustiva, solo algunas cosas para que pienses. Al final, esta no es una decisión que nadie más pueda tomar por ti. Eres el administrador Conoce tus sistemas. Conoce tu distribución.

Estoy 100% de acuerdo con lo que Caleb ya dijo. Algunas muescas más específicas de CentOS de mi parte:

La distribución se basa en RedHat y sus parches. Esos parches se probaron muy bien y en los últimos 4 años, donde hemos estado usando CentOS 5 con más de 50 servidores, nunca ha habido un parche malo.

PERO: aunque aplicamos todos los parches a diario automáticamente a los servidores que ejecutan solo cosas de distribución, arrancamos los servidores de producción (después de la actualización de glibc o kernel) solo después de que nuestros sistemas de prueba se ejecuten en esa configuración un par de días.

Para otros repositorios, los duplicamos en un directorio provisional. Estos parches se aplican primero a los servidores de prueba. Si se demuestra que nada se rompe, activamos el directorio de ensayo y lo copiamos a un repositorio de producción.

El parcheo automático tiene el efecto secundario de que los componentes parcheados a menudo se reinician, por lo que si los configuró incorrectamente después del inicio, el reinicio fallará.