¿Es importante reiniciar Linux después de una actualización del kernel?

Tengo algunos servidores web de producción Fedora y Debian que alojan nuestros sitios, así como cuentas de shell de usuario (utilizadas para el trabajo de git vcs, algunas sesiones de pantalla + irssi, etc.).

Ocasionalmente, una nueva actualización del kernel se reducirá en yum/ apt-get, y me preguntaba si la mayoría de las correcciones son lo suficientemente graves como para justificar un reinicio, o si puedo aplicar las correcciones sin reiniciar.

Nuestro servidor de desarrollo principal actualmente tiene 213 días de tiempo de actividad, y no estaba seguro de si era inseguro ejecutar un núcleo tan antiguo.

No hay nada realmente especial en tener un tiempo de actividad prolongado. Generalmente es mejor tener un sistema seguro. Todos los sistemas necesitan actualizaciones en algún momento. Probablemente ya esté aplicando actualizaciones, ¿programa interrupciones cuando las aplica? Probablemente deberías por si algo sale mal. Un reinicio no debería ser tanto tiempo realmente.

Si su sistema es tan sensible a las interrupciones, probablemente debería estar pensando en algún tipo de configuración de agrupación para actualizar un solo miembro del clúster sin derribar todo.

Si no está seguro acerca de una actualización en particular, probablemente sea más seguro programar un reinicio y aplicarlo (preferiblemente después de probarlo en otro sistema similar).

Si está interesado en saber si la actualización es importante, tómese el tiempo de leer el aviso de seguridad y siga los enlaces a CVE o las publicaciones / listas / blogs que describen el problema. Esto debería ayudarlo a decidir si la actualización se aplica directamente en su caso.

Incluso si no cree que se aplique, debería considerar actualizar su sistema eventualmente. La seguridad es un enfoque en capas. Debe suponer en algún momento que esas otras capas pueden fallar. Además, es posible que olvide que tiene un sistema vulnerable porque omitió una actualización cuando cambia la configuración en algún momento posterior.

De todos modos, si desea ignorar o esperar un momento en la actualización de los sistemas basados ​​en Debian, puede poner el paquete en espera. Personalmente, me gusta poner en espera todos los paquetes del kernel por si acaso.

Método CLI para establecer una retención en un paquete en sistemas basados ​​en Debian.

dpkg --get-selections | grep 'linux-image' | sed -e 's/install/hold/' | sudo dpkg --set-selections

La mayoría de las actualizaciones no requieren reiniciar, pero las actualizaciones de Kernel sí (realmente no puede reemplazar el kernel en ejecución sin reiniciar).

Una cosa que he descubierto es que si su servidor ha estado funcionando durante mucho tiempo sin reiniciar, es más probable que desee realizar comprobaciones de disco (fsck) cuando reinicie, y esto puede aumentar significativamente el tiempo que lleva volver. arriba y corriendo de nuevo. Lo mejor es anticipar esto y planificarlo.

También descubrí que los cambios de configuración a veces pueden pasarse por alto y no se notarán hasta que se reinicie (como agregar nuevas direcciones IP / reglas de iptables, etc.) Esto también aumenta el "riesgo de tiempo de inactividad" cuando se reinicia con poca frecuencia.

Es mejor planificar un tiempo de inactividad al reiniciar, o si esta no es una opción deseable, configure sus servidores en clústeres para que se puedan reiniciar si es necesario.

Si solo necesita actualizaciones de seguridad y no un núcleo completamente nuevo, es posible que le interese Ksplice , ya que le permite parchear ciertas actualizaciones del núcleo en un núcleo en ejecución.

No hay una respuesta simple a esto, algunas actualizaciones del kernel no están realmente relacionadas con la seguridad, y algunas pueden solucionar problemas de seguridad que no lo afectan, mientras que otras pueden afectarlo.

El mejor enfoque de la OMI es suscribirse a las listas de correo de seguridad relevantes como el anuncio de seguridad de ubuntu para que pueda ver cuándo salen los parches de seguridad y cómo podrían afectarlo.

También consideraría apticron o similar para obtener los detalles y registros de cambios de cualquier otra actualización de paquete.

Esta es una función de la actualización, si corrige un priv. escalada que resulta en acceso de root, entonces es posible que desee aplicarlo.

En el caso de que no reinicies, debes asegurarte de que el nuevo kernel no sea el predeterminado para iniciarse en el arranque.

Lo último que desea es que se use un kernel no probado para la producción después de un reinicio no planificado.

Como mencionó mibus, si instala el núcleo y no reinicia, asegúrese de que no sea el predeterminado. No sabe si o en qué estado volverá su servidor, así que asegúrese de que esté probado.

Dicho esto, creo que es bueno acostumbrarse a reiniciar las máquinas de forma regular cuando sea posible. Muchas fallas de hardware y software se manifestarán solo en un reinicio y es mejor averiguarlas cuando esté planeando un reinicio en lugar de durante una interrupción no planificada.

Tenga en cuenta que algunas de las actualizaciones del núcleo de Debian requieren (bueno, muy recomendable) que reinicie lo antes posible después de aplicarlas.

Este es el caso cuando la diferencia no es suficiente para garantizar un cambio de directorio de módulos, pero los módulos pueden diferir.

Debian le advertirá cuando instale dichos paquetes de kernel.