Mejores prácticas para actualizar un servidor previamente no mantenido RHEL5.7

Recientemente se puso bajo mi cuidado un nuevo servidor RedHat EL5.6. Es inmediatamente obvio que, durante los 12 meses anteriores, se ha prestado poca o ninguna atención a ningún tipo de actualizaciones de paquetes.

Por lo general, tengo la mentalidad de si no está roto, no lo arregles. Sin embargo, después de registrar el servidor con RHN, y también de usar el complemento yum-security para verificar las actualizaciones de seguridad, hay un poco más de 1100 actualizaciones de "seguridad" disponibles.

¿Alguien ha tenido una situación similar? Soy reacio a actualizar todo, ya que me gusta saber qué se está actualizando y si tiene el potencial de afectar o no cualquier cosa que se ejecute en la caja (este es un servidor de producción). Sin embargo, también parece que mantenerme en línea con esta práctica requeriría que revise las erratas del paquete 1100 línea por línea. ¿Existe una solución más eficiente?

En términos generales, las actualizaciones de seguridad se consideran algo seguras, particularmente para una distribución con objetivos como RedHat. Su enfoque principal es crear un entorno operativo que sea consistente. Como tal, los mantenedores tienden a elegir versiones de paquetes y quedarse con ellos a largo plazo. Para ver lo que quiero decir vistazo a las versiones de este tipo de paquetes como kernel, python, perl, y httpd. Lo que también hacen es parches de seguridad de los desarrolladores anteriores. Entonces, si se encuentra una vulnerabilidad de seguridad para todas las versiones de Apache httpd 2.2.x, entonces la fundación Apache puede lanzar la versión 2.2.40 con la solución, pero RedHat lanzará el parche localmente y lo lanzará httpd-2.2.3-80con la solución.

También tenga en cuenta que actualmente está hablando de un sistema RHEL5.7, la versión actual es 5.9. Algunos proveedores de software solo admitirán ciertos subarriendos. Recientemente me he encontrado con una pieza de software, por ejemplo, que el proveedor dice que solo funciona en 5.4. Eso no significa que no se ejecutará en 5.9, pero puede significar que no proporcionarán ningún soporte si no funciona.

También existe la preocupación de realizar actualizaciones masivas de un sistema que no ha sido parcheado en tanto tiempo. El mayor problema con el que me he encontrado es en realidad más un problema de administración de la configuración que puede ser exacerbado por grandes actualizaciones. A veces se cambia un archivo de configuración pero el administrador nunca reinicia el servicio. Esto significa que la configuración en el disco nunca se ha probado y que la configuración en ejecución ya no existe. Entonces, si el servicio se reinicia, lo que sucederá una vez que aplique las actualizaciones del kernel, es posible que no se reinicie. O puede actuar diferente una vez que se reinicia.

Mi consejo sería hacer las actualizaciones, pero sé inteligente al respecto.

• Planifíquelo durante una ventana de mantenimiento. Si nada más requerirá reiniciar el servidor, ha habido una serie de actualizaciones del núcleo y tendrá que reiniciar para aplicarlas.
• Asegúrese de realizar una copia de seguridad completa antes de hacer nada. Esto podría ser instantáneas, si se trata de una máquina virtual, desencadenando una copia de seguridad completa en cualquier herramienta, reteniendo /(a otro sistema), tomando una ddimagen de las unidades, lo que sea. Siempre y cuando sea algo de lo que puedas restaurar.
• Planifique cómo aplica las actualizaciones. No quieres simplemente lanzarle un tiro yum update -yy alejarte. Por todas las cosas buenas que hace yum, no ordena cuando aplica actualizaciones de acuerdo con las dependencias. Esto ha causado problemas en el pasado. Yo siempre corro yum clean all && yum update -y yum && yum update -y glibc && yum update. Eso tiende a ocuparse de la mayoría de los posibles problemas de pedidos.

Este también puede ser un buen momento para volver a formatear. Hemos tenido RHEL6 desde hace bastante tiempo. Dependiendo de lo que haga este servidor, puede tener sentido dejar que este se ejecute tal como está mientras se muestra una nueva instancia en paralelo. Luego, una vez que está instalado, puede copiar todos los datos, probar los servicios y realizar el corte. Esto también le dará la oportunidad de saber, desde cero, que el sistema está estandarizado, limpio, bien documentado y todo ese jazz.

No importa lo que hagas, creo que es muy importante que te pongas a la altura de un sistema actual. Solo necesita asegurarse de hacerlo de una manera que le permita confiar en su trabajo y el producto terminado.

En mi experiencia, RHEL no rompe la compatibilidad con versiones anteriores en las actualizaciones del mismo lanzamiento.

eso, sin embargo, no se extenderá a nada que haya sido instalado externamente a rpm.

Puede utilizar rpm -qfpara encontrar los archivos que sospecha que están compilados externos, si devuelve "no es propiedad de ningún paquete", entonces podría tener problemas en su actualización.

Tomaría una imagen del servidor y realizaría la actualización, sin embargo, estoy un poco más preocupado que la mayoría.