Leer un script de parcheo y lo que su registro no dice

apt-get -y upgrade instala sin preguntar las actualizaciones pendientes, y la opción -y responde «sí» a todo. Antes de eso, el script ejecuta apt-mark hold con una lista de paquetes: es la orden que le dice a apt que ese paquete no debe actualizarse. Se usa para proteger una aplicación que depende de una versión concreta, y es razonable, pero tiene un coste que debe quedar escrito.

Abre parchea-semanal.sh y localiza el apt-mark hold.

Una retención escrita en un script se repite cada semana sin que nadie la vuelva a decidir. Por eso la lista de retenidos es un documento de gestión: cada línea debería traer el motivo, la fecha y quién la pidió. Para el analista, un paquete retenido durante meses es una excepción no formalizada, y sus hallazgos no se pueden contar como «en proceso».

El registro del script trae un bloque por servidor, que empieza con una línea == host ==. Los mensajes de apt que empiezan con E: son errores. Un error frecuente en servidores con actualizaciones automáticas es que otro proceso tenga ocupado el gestor de paquetes: el segundo intento falla y no instala nada.

Abre parcheo-2026-10-06.log y busca el bloque con errores del gestor de paquetes (un servidor distinto del que no respondió por red).

El informe de parcheo toma su cifra de la última línea del registro. Esa línea sale de grep -c '^==', que cuenta las líneas que empiezan con ==, es decir, los equipos que el bucle intentó. Además, la línea del apt-get termina con || true, que hace que el comando se considere siempre exitoso, y el script acaba con exit 0. Con esas tres piezas, el script no puede reportar un fallo aunque lo haya habido.

Una actualización de bibliotecas o del núcleo no protege hasta que el servicio o el sistema se reinicia. El script comprueba la existencia del archivo /var/run/reboot-required y deja una línea en el registro cuando existe. Contar esas líneas da la lista de trabajo del siguiente paso, y es un dato que el informe no trae.