De vez en cuando inicio sesión en los cuadros de producción web/db/tools y veo el mensaje típico:
Se pueden actualizar 30 paquetes. 16 actualizaciones son actualizaciones de seguridad.
Mi pregunta es, ¿cómo manejan todos ustedes las actualizaciones en sus cajas Ubuntu de producción? ¿Automatizan estas actualizaciones? ¿Les establece tiempo de inactividad? El problema es que nunca se sabe cuándo una actualización va a romper algo, como quizás un archivo de configuración existente, etc.
La otra parte de este problema es que mantenerse al día con los parches es "algo bueno", pero los parches se lanzan casi a diario. ¿Cuántas interrupciones programadas hay que realizar si hay un nuevo parche de seguridad disponible todos los días?
Creo que sería muy útil un hilo sobre respuestas sobre cómo gestionar sus actualizaciones.
Respuesta1
No hay nada especial en parchear Ubuntu frente a Windows, RHEL, CentOS, SuSE, Debian, etc.
El estado mental básico en el que debe estar al diseñar su procedimiento de parche es asumir algovoluntadromper.
Algunas de las pautas básicas que suelo utilizar al diseñar una configuración de parche son:
- Utilice siempre un sistema local para centralizar internamente en su red desde donde se instalan los parches.
Esto puede incluir el uso de WSUS o réplicas de <your_os_here>una máquina de administración de parches interna. Es preferible uno que pueda consultar de forma centralizada y permitirle conocer el estado de los parches instalados en sus máquinas individuales.
- Preparar previamente las instalaciones, cuando sea posible, en las máquinas.
Cuando sea posible, a medida que salgan los parches, haga que el servidor central los copie en las máquinas individuales. En realidad, esto es solo un ahorro de tiempo para que no tenga que esperar a que se descarguen E instalen, solo tiene que iniciar la instalación durante la ventana de parche.
- Obtenga una ventana de interrupción para instalar los parches, es posible que deba reiniciar y es probable que algo se rompa. Asegúrese de que las partes interesadas de esos sistemas sepan que se están implementando parches. Esté preparado para las llamadas de "esto" no funciona.
De acuerdo con mi teoría básica de que los parches rompen cosas, asegúrese de tener una ventana de interrupción para aplicar parches el tiempo suficiente para solucionar problemas críticos y posiblemente revertir el parche. No es necesario que haya gente sentada allí probando los parches. Personalmente, confío en gran medida en mis sistemas de monitoreo para saber que todo está funcionando al nivel mínimo que podemos lograr. Pero también esté preparado para que surjan pequeños problemas molestos cuando la gente se ponga a trabajar. Siempre debes tener a alguien programado para estar allí listo para contestar el teléfono; preferiblemente no el tipo que estuvo despierto hasta las 3 a.m. parchando las cajas.
- automatizar tanto como sea posible
Como todo lo demás en TI, guión, guión y luego guión un poco más. Script para la descarga del paquete, el inicio de la instalación, el mirror. Básicamente, desea convertir las ventanas de parche en una tarea de cuidado de niños que solo necesita un ser humano allí en caso de que algo se rompa.
- Tener varias ventanas cada mes
Esto le brinda la posibilidad de no parchear algunos servidores si por alguna razón no se pueden parchear en "la noche señalada". Si no puede hacerlo en la noche 1, exija que estén libres en la noche 2. También le permite mantener la cantidad de servidores parcheados al mismo tiempo.
Más importante¡Sigue con los parches!Si no lo hace, tendrá que realizar parches muy largos de más de 10 horas sólo para volver al punto en el que se encuentra atrapado. Introducimos aún más puntos en los que las cosas podrían salir mal y hacemos que sea mucho más difícil encontrar qué parche causó el problema.
La otra parte de este problema es que mantenerse al día con los parches es "algo bueno", pero los parches se lanzan casi a diario. ¿Cuántas interrupciones programadas hay que realizar si hay un nuevo parche de seguridad disponible todos los días?
Parchar un servidor una vez al mes o una vez cada dos meses es, en mi humilde opinión, un objetivo muy alcanzable y aceptable. Más que eso, y bueno, constantemente estarás aplicando parches a los servidores, mucho menos y comenzarás a meterte en situaciones en las que tendrás cientos de parches que deben aplicarse por servidor.
¿En cuanto a cuántas ventanas necesitas al mes? Eso depende de tu entorno. ¿Cuantos servidores tienes? ¿Cuál es el tiempo de actividad requerido para sus servidores?
Los entornos más pequeños de 9x5 probablemente puedan salirse con la suya con una ventana de parche al mes. Las tiendas grandes que funcionan 24 horas al día, 7 días a la semana, pueden necesitar dos. Es posible que un servidor muy grande que funciona las 24 horas del día, los 7 días de la semana y los 365 días del año necesite una ventana móvil cada semana para parchear un conjunto diferente de servidores cada semana.
Encuentre una frecuencia que funcione para usted y su entorno.
Una cosa a tener en cuenta es que 100% actualizado es unimposibleobjetivo a alcanzar: no permita que su departamento de seguridad le diga lo contrario. Haz tu mejor esfuerzo, no te quedes atrás.
Respuesta2
Cosas para hacer:
- Hacer una copia de seguridad
- Asegúrese de que sea una copia de seguridad restaurable (aunque estos dos son puntos generales)
- Intente desviar el tráfico lejos del cuadro de producción mientras actualiza.
- Intente tener un método de acceso fuera de banda en caso de que todo salga mal, KVM, consola serie, acceso local o manos remotas.
- Pruebe en un servidor y luego asegúrese de que todo funcione antes de implementar actualizaciones en más servidores.
- Utilice Puppet si puede para asegurarse de que los números de versión sean los mismos en varios servidores. (También puedes usarlo para forzar actualizaciones)
- En un servidor de prueba, compare las versiones de los archivos de configuración con las nuevas (actualización instalada) y asegúrese de que nada vaya a estropear seriamente las cosas. Creo recordar que dpkg preguntó antes de instalar nuevas versiones que difieran de las instaladas actualmente.
Cosas que se deben evitar:
- ¡Haciendo actualizaciones a mitad del día, o a las 09:00 un lunes por la mañana, o a las 5:00 p.m. un viernes por la tarde! (¡gracias @3influence!)
- Actualizar MySQL en servidores de bases de datos realmente grandes (el reinicio puede llevar mucho tiempo)
- Hacer todos sus servidores a la vez (especialmente los kernels)
- Hacer cualquier cosa que pueda cambiar /etc/networks (porque podría perder conectividad)
- Actualizaciones automáticas que podrían hacer lo anterior sin que usted esté allí para verificar que todo esté bien.
Respuesta3
Otro punto que vale la pena destacar: si está acostumbrado a Windows, se sorprenderá de que la mayoría de las actualizaciones de Linux no funcionan.norequieren tiempo de inactividad o reinicio. Algunos lo hacen, como las actualizaciones del kernel. Pero las actualizaciones que requieren reinicio o tiempo de inactividad generalmente se marcan como tales y se pueden manejar en un cronograma separado.
Respuesta4
Nos ocupamos de las actualizaciones de la siguiente manera para los sistemas ubuntu LTS:
- Mantener un conjunto de pruebas de aceptación que verifiquen todas las rutas críticas en nuestro software.
- Instale actualizaciones de seguridad sin supervisión a las 4 a. m. todas las mañanas y ejecute inmediatamente las pruebas de aceptación. Si algo falla, se llama a un ingeniero y tiene tiempo suficiente para arreglar las cosas o retroceder antes de las 9 a.m. Hasta ahora, esto ha sucedido sólo dos veces en cinco años: LTS está bien probado y es estable.
- Redistribuimos automáticamente toda nuestra infraestructura cada semana (en digitalocean) con implementaciones azules/verdes, lo que mantiene todos los paquetes en sus últimas versiones. Si una nueva implementación no supera las pruebas de aceptación, la implementación queda en espera hasta que un ingeniero pueda solucionar el problema.
El siguiente paso lógico para nosotros es eliminar la información de la sesión en memoria para que podamos simplemente volver a implementar la infraestructura todos los días o incluso varias veces al día sin afectar a los clientes y eliminar el paso (2).
Este enfoque requiere poco mantenimiento y evita por completo las ventanas de mantenimiento.