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-80
con 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 dd
imagen 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 -y
y 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.