Actualizar automáticamente un servidor

updateÚltimamente he estado leyendo sobre cómo y cuando actualizar un servidor Linux (Fedora/CentOS/Red Hat en mi caso), de cara a aplicar los últimos parches de seguridad y mantener el sistema actualizado. Resulta que no soy el único que se pregunta sobre si hay algún tipo de guía, recomendaciones, o mejores prácticas para updatear sistemas.

Después de leer y leer, y ver las numerosas razones tanto a favor como en contra de los updates automáticos, la siguiente frase en la documentación oficial de Fedora resume cuándo habilitar las actualizaciones automáticas, por lo general:

If the machine is a critical server, for which unplanned downtime of a service on the machine can not be tolerated, then you should not use automatic updates. Otherwise, you may choose to use them.”

Es decir, por norma general sería una buena idea habilitar las actualizaciones automáticas en todo servidor que no sea crítico, siempre y cuando tengamos la posibilidad de deshacer los updates instalados, o revertir los cambios, en caso de error.

Así pues, podríamos seguir la siguiente estrategia, de cara a los updates:

  1. Identificar los servidores críticos, para dejarlos fuera del plan de updates automáticos. Imagino que lo ideal es que los servidores críticos tengan un entorno de QA que nos sirva, además, para updatear y testear antes de pasar a updatear a mano el servidor en producción. Eso sí, los servidores críticos se podrían configurar para que nos envíe un mail diario con los updates a aplicar, a modo informativo.
  2. Para el resto de servidores, asegurarse de tener un plan para revertir los updates o recuperar el sistema en caso de fallo. Por ejemplo, puedes probar yum history undo para deshacer una actualización, o hacer un snapshot del servidor antes de aplicar los updates si se trata de una máquina virtual y tienes esa opción. Es recomendable hacer un backup de tus ficheros de configuración antes de aplicar los updates (recuerda que en /etc se encuentran la mayoría de ficheros de configuración locales).
  3. Decidir la periodicidad de los updates automáticos (si estamos aquí, seguramente nos interese actualizar a diario).
  4. Repasar los repositorios instalados en cada servidor, para únicamente habilitar aquellos repositorios de los que nos fiemos (por ejemplo, los repositorios oficiales).
  5. Configurar los updates automáticos. Hay varias formas de hacerlo. Por ejemplo:
    • En CentOS 5, mediante “yum-updatesd” [+ info]
    • En CentOS 6, mediante “yum-cron” [+info] [+info]
    • En cualquier servidor tipo Red Hat, símplemente con un crontab que ejecute “/usr/bin/yum -y update“. Puedes configurar tu propio script para que por ejemplo, mire si hay actualizaciones, y en función de eso, haga un backup de los ficheros de configuración, actualice, reinicie procesos actualizados, y finalmente envíe un mail con el resultado.
  6. Seguir a @unaaldia de Hispasec, o similar, para estar informado de las últimas vulnerabilidades.

NOTA: Hay que tener en cuenta que si se instala un update del kernel, el update no se aplicará hasta reiniciar el server. Igualmente, los updates que afecten a demonios que estén corriendo en la máquina no se aplicarán hasta que se reinicien, así que hasta entonces, a pesar de haber actualizado, el servidor no estará seguro.

Ejemplo de configuración con yum-cron en CentOS 6

En este ejemplo, trabajaremos con un CentOS 6.4. Lo primero, verificar los repositorios habilitados:

[root@myServer]# yum repolist enabled
repo id repo name status
base CentOS-6 - Base 6.367
extras CentOS-6 - Extras 14
updates CentOS-6 - Updates 617

A continuación, confirmar que tenemos la opción de “deshacer” con yum:

[root@myServer]# yum history list

Ahora que sabemos que tenemos la opción de deshacer updates, y que únicamente tenemos habilitados los repositorios oficiales, pasaremos a instalar y configurar yum-cron:

[root@myServer]# yum install yum-cron.noarch
[root@myServer]# vi /etc/sysconfig/yum-cron

Como parámetros de configuración, destacan las siguientes combinaciones de CHECK_ONLY y DOWNLOAD ONLY [fuente]:

# Default - check for updates, download, and apply
CHECK_ONLY=no
DOWNLOAD_ONLY=no

# Download the updates and email a report
CHECK_ONLY=no
DOWNLOAD_ONLY=yes

# Don't download the updates, just email a report
CHECK_ONLY=yes
DOWNLOAD_ONLY=no

Otro parámetro interesante es YUM_PARAMETER, que nos permitirá indicar paquetes que no querremos incluir en los updates automáticos, como por ejemplo los paquetes de kernel, o los paquetes php si hemos de trabajar con una versión concreta. Lo bueno, es que indicando la exclusión en el fichero de configuración del yum-cron, esta exclusión no afectará a los updates manuales realizados con yum [fuente]:

YUM_PARAMETER="-x kernel*"

Finalmente, tenemos la opción de configurar una dirección de correo donde recibir por ejemplo, el listado de updates disponibles si hemos configurado yum-cron con la opción CHECK_ONLY=yes:

MAILTO="adrian.perez@midominio.com"

Con ésto ya tendríamos configurados los updates automáticos cada día. No haría falta hacer nada más, pues yum-cron automáticamente se habrá configurado en el cron.daily (NOTA: ten en cuenta que el cron.daily, si no has tocado nada, puede variar la hora en la que ejecuta las tareas, encontrándose su configuración en /etc/anacrontab).

¿Y tú? ¿Cómo haces los updates de tus servidores? Si tienes decenas de servidores, ¿automatizas los updates? ¿Algún consejo o sugerencia?

Special thanks to:

https://twitter.com/vblazquezf

Fuentes:

http://serverfault.com/questions/308600/good-practice-for-managing-package-updates-for-lots-of-centos-servers
http://unix.stackexchange.com/questions/37439/should-you-run-automatic-updates
http://serverfault.com/questions/9490/how-often-should-i-update-our-linux-server
https://fedoraproject.org/wiki/AutoUpdates
http://www.centos.org/docs/5/html/yum/sn-updating-your-system.html
http://samdoran.com/2013/05/17/automatic-updates-in-rhel-6-and-cent-os-6/

4 opiniones en “Actualizar automáticamente un servidor”

  1. Voy a lanzarme, supongo que hará grupos en ansible por importancia, entorno, tipo de servidor, etc, y luego según el grupo puede hacer updates automáticos (condicionados a ciertos paquetes o no) e incluso para ciertos grupos tratarlo todo de manera manual (estudiar posibles implicaciones pasar un tiempo en máquina de pre, etc), incorporando en todo caso toda parafernalia extra necesaria respecto a sistemas de vuelta atrás.

    En cualquier caso creo que se sale un poco del tema del artículo, aunque creo que el punto está en que desde ansible puedes realizar la automatización sin pasar por por ejemplo el cron de cada máquina (centralización)… Pero bueno es que para eso es ansible, si tienes 3-4 servidores lo harás a mano si tienes 100 deberías usar algún sistema de automatización y en cualquier caso esta info te ayudaría igualmente…

    1. Muchas gracias Jesús por compartirlo! Tengo pendiente darle un vistazo a Ansible, ya que como dices, si llevas muchos servers y tienes la suerte de contar con diferentes entornos bien controlados (llámale de, qa, pre, staging, etc) siempre puedes aplicar los updates por grupos, como dices, en un entorno no productivo para después aplicarlo en prod una vez asegurado su funcionamiento.

      ¡Gracias de nuevo!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *