Horney Patches

Uno de los debates que tiempo ha han dedicado mis mejores broncas en algunos de los más perdidos bares es el tema de confundir el Uptime del servidor con el Uptime del Servicio. Existes seres que cuentan el tiempo que lleva su servidor sin reiniciarse como el que cuenta los intereses de la cuenta naranja de ING y luego se defienden como gato panza arriba cuando les preguntas por los parches. Las respuestas pueden ser de lo más peculiares que yo las he ido catalogando:

A) Servidor Chuck Norrix: Son los que usan esta distribución de Linux al más puro estilo Ranger y están por encima del bien y del mal. La respuesta suele ser:

¿Parches? Mi server es un hax0r y no tiene bugs y no necesita parches…

B) IT Pro Sherlock Holmes: Son los que ante la pregunta de por qué su servidor lleva 400 días de uptime responden:

¿Parches? Me los reviso uno a uno y sólo he instalado los que aplican a mi entorno. Y como mi equipo no tiene ni kernel, pues no le he tenido que aplicar ninguna.

¿Qué tienes majo, un Furby server?

C) El servidor en escabeche: Los servidores son como las anchoas, se conservan sin tocarlos, por lo que los servidores NO se parchean. Eso, y si puedes ponlos de cara a Internet y sin contraseñas, que tengo unos amigos locos por visitar tú servidor. Os dejo un mail de un sufrido lector de este blog:


Fijaros el trabajo que duro es. PRIMERO: Haz el parche y comunica a todo el mundo que hay un parche nuevo. SEGUNDO: Comunica a todo el mundo que no lo instale. Trabajar en Spectra es duro.
El mail lo deja claro..."Nosotros te lo instalamos, pero que sepas que... SE TE VA A JODER EL UPTIME sólo por 57 actualizaciones críticas de mierda".

D) Horney Patches: No, eso de reiniciar tras aplicar un parche es un atraso desde que existen las estrategias de parcheo en caliente.
Nosotros parcheamos on fly…

Es este último tipo de respuesta el que más me preocupa. Vaya por delante que generalmente la peña que da una de estas tres respuestas suele estar excusando una negligencia supina que se ha basado en no aplicar ninguna solución de parcheo y que lo único que busca es salir airoso del rincón donde se encuentra atrapado. La verdad es que sí tiene parches, no se ha revisado todos los parches de todos los productos que están corriendo en su servidor uno a uno y, por supuesto, no parchea en caliente.

Parchear en caliente es una solución delicada. Los sistemas MS Windows, desde Windows Server 2003 SP1, realizan, automáticamente, parcheos en caliente si está habilitada la opción de hotpatching. Para ello, los parches en caliente (que no cachondos) de los sistemas Windows llevan asociado el hotpatch, con los cambios que se deben realizar a la imagen cargada en memoria, y el coldfile, con el nuevo fichero que debe suplantarse.

Sin embargo, esto no siempre se puede realizar por lo que están catalogadas algunas limitaciones conocidas y algunos problemas de compatibilidad (que se habrán descubierto "por las malas"). Hay que tener en cuenta que el número de software instalado en un equipo es difícil de cuantificar y siempre queda la opción de que pueda darse alguna incompatibilidad que te fastidie "tu uptime".

Si el utilizar estrategias de parcheo en caliente con el software del sistema es complejo, el aplicarlo con componentes ejecutándose con altos privilegios que no vienen preparados para hotpatching es aun más temerario. La idea es que existen herramientas para que tú te crees el parche adecuado para esos componentes, es decir, el hotpach y el coldbinary utilizando herramientas externas. Esto, si estamos hablando de un servidor tan crítico que no puede ser reiniciado es una temeridad por si se produce cualquier fallo: tanto de incompatibilidad o como de cagada humana.

En resumen, si tu servicio es tan crítico que no se puede detener, entonces monta una estructura multiserver que para eso existen los clusters, los sistemas de réplica o las arquitecturas distribuidas. Si no es tan crítico el servicio, aplica los parches en la mejor franja horaria y reinicia cuando el fabricante te lo diga. Y si la has cagado a lo grande y el servicio no puede ser parado y has diseñado una arquitectura mono-servidor, entonces, y sólo entonces aplica la opción B) (por si tienes suerte) y la D) (para ver si salimos de esta).

Saludos Malignos!