Servidores Linux

Paquetes y actualizaciones

Lección 4 de 8 · 13 min

En Linux el software no se descarga de páginas

Instalar un programa en un servidor no se parece en nada a bajar un instalador. Existe un repositorio: un catálogo firmado de paquetes que mantiene la distribución, y de ahí sale todo.

Eso cambia dos cosas importantes. Instalas escribiendo el nombre, sin buscar en ningún sitio. Y las actualizaciones de todo lo instalado llegan por el mismo canal, en vez de que cada programa avise por su cuenta.

Los paquetes vienen firmados y se comprueba la firma antes de instalarlos. Por eso descargar un .deb suelto de una página cualquiera es exactamente el hábito que este sistema existe para evitar.

El malentendido que deja servidores sin actualizar

Aquí está la confusión más cara de esta lección, y la comete muchísima gente que lleva años administrando servidores:

apt update no actualiza nada. Lo único que hace es refrescar el catálogo: preguntar a los repositorios qué versiones hay disponibles hoy. Después de ejecutarlo, tu servidor tiene exactamente el mismo software que antes.

Los dos comandos, y qué hace cada uno

apt update - preguntar

Descarga la lista de versiones disponibles en los repositorios.

No instala ni cambia nada. Es rápido y es inofensivo: puedes ejecutarlo cuando quieras.

apt upgrade - instalar

Instala de verdad las versiones nuevas de lo que ya tienes.

Este es el que aplica las correcciones de seguridad. Sin él, el otro no sirve de nada.

Siempre en ese orden

upgrade sin un update previo instala contra un catálogo viejo: se pierde lo publicado desde la última consulta.

Por eso se escriben encadenados.

La secuencia de mantenimiento
# Refrescar el catalogo y luego aplicar lo que haya
sudo apt update && sudo apt upgrade

# Ver que hay pendiente ANTES de instalarlo
apt list --upgradable

# Instalar un programa
sudo apt install nginx

# Quitarlo, incluida su configuracion
sudo apt purge nginx

# Limpiar dependencias que ya no usa nadie
sudo apt autoremove
Resultado
Listing... Done
openssh-server/noble-security 1:9.6p1-3ubuntu13.5 amd64 [upgradable from: 1:9.6p1-3ubuntu13.4]
libssl3t64/noble-security 3.0.13-0ubuntu3.4 amd64 [upgradable from: 3.0.13-0ubuntu3.3]

Fíjate en la palabra -security del ejemplo: indica que esa actualización viene del canal de seguridad, no de mejoras normales. Son las que no se aplazan.

remove, purge y autoremove

Tres formas de quitar, y la diferencia importa: remove borra el programa pero deja su configuración -pensando en que lo reinstales-, y purge se lleva también la configuración.

autoremove es otra cosa: limpia las dependencias que se instalaron para acompañar a algo que ya no está. Conviene leer la lista que propone antes de aceptar.

Las actualizaciones automáticas: no hay que instalarlas

Aquí hay que corregir algo que repiten casi todos los tutoriales. La documentación oficial de Ubuntu Server dice que el paquete unattended-upgrades viene «installed by default», y que «right after installation, automatic installation of security updates will be enabled».

Es decir: tu servidor Ubuntu ya está aplicando actualizaciones de seguridad solo, una vez al día, desde el primer arranque. No hay que activarlo.

Y sin embargo hay servidores Ubuntu sin actualizar. ¿Por qué? Porque lo automático cubre solo el canal de seguridad, porque alguien pudo desactivarlo, y sobre todo porque una actualización de núcleo o de una biblioteca en uso no surte efecto hasta que se reinicia lo que la usa.

El paquete instala la corrección; el servicio viejo sigue corriendo en memoria con la versión vulnerable. Por eso la tarea real no es «activar las automáticas», sino comprobar que están activas y atender lo que queda pendiente de reinicio.

Comprobar que está haciendo su trabajo

  1. Ver si está activado

    cat /etc/apt/apt.conf.d/20auto-upgrades

    Ese archivo es el interruptor. Los valores son días: 1 significa activo a diario y 0 significa desactivado. Si ves ceros, alguien lo apagó.

  2. Ver qué instaló, y cuándo

    sudo tail -30 /var/log/unattended-upgrades/unattended-upgrades.log

    Es la prueba de que funciona. Un registro que lleva semanas sin líneas es una señal, no una buena noticia.

  3. Ver si hace falta reiniciar

    Si existe el archivo /var/run/reboot-required, hay una actualización -normalmente del núcleo- esperando un reinicio para surtir efecto.

    cat /var/run/reboot-required lo dice en una línea.

  4. Ajustar el comportamiento, si hace falta

    El otro archivo, /etc/apt/apt.conf.d/50unattended-upgrades, decide qué canales se aplican, si se envía correo y si se permite reiniciar solo a una hora concreta.

    Se edita con sudo nano, y con una copia previa.

Un servidor de producción no se reinicia a la ligera, pero tampoco puede pasar un año sin reiniciarse: significa que arrastra correcciones de núcleo sin aplicar. Lo sano es una ventana de mantenimiento planeada, avisada y con la copia comprobada -que es la lección 8-.

Lo que te va a salir en pantalla

Could not get lock - otro proceso está usando apt

Casi siempre son las actualizaciones automáticas trabajando en ese momento. Es normal.

Se espera un minuto y se reintenta. No se borra el archivo de bloqueo por las bravas: si de verdad hay una instalación a medias, se corta y deja paquetes rotos.

La pantalla morada que pregunta por servicios a reiniciar

Aparece cuando una biblioteca actualizada la están usando servicios en marcha. Te pregunta cuáles reiniciar.

Aceptar la lista propuesta es lo correcto: si no se reinician, siguen usando la versión vieja en memoria. Es justo el caso de «actualizado pero no protegido».

¿Y si me preguntan por el archivo de configuración?

Cuando tú modificaste un archivo de /etc y el paquete trae una versión nueva, apt pregunta cuál conservar.

Lo prudente es mantener la tuya y luego comparar con la nueva. Aceptar la del paquete a ciegas borra tu configuración -y ahí es donde se pierde la del SSH o la del servidor web-.

upgrade frente a full-upgrade

upgrade es conservador: no quita nada para actualizar. full-upgrade puede desinstalar paquetes si eso hace falta para resolver el cambio.

En un servidor en producción se usa upgrade, y full-upgrade solo leyendo con calma lo que propone quitar.

apt frente a apt-get

apt es el moderno, pensado para escribirlo a mano: salida más clara y barra de progreso.

apt-get es el antiguo y tiene una ventaja concreta: su comportamiento es estable, así que es el que se usa dentro de guiones automáticos.

Las cinco que hay que tener claras

Responde antes de voltear.

Compruébalo tú mismo

Ejecutas sudo apt update todas las semanas y nada más. ¿Está el servidor al día?

Te dicen que hay que instalar unattended-upgrades en un Ubuntu Server recién montado. ¿Es cierto?

Se aplicó una corrección de seguridad de una biblioteca, pero el servicio que la usa no se reinició. ¿Está protegido?

Lo que sigue

Acabas de ver que un servicio hay que reiniciarlo para que un cambio surta efecto. La siguiente lección es exactamente eso: manejar servicios con systemd, leer sus registros y seguir el procedimiento para averiguar por qué uno no arranca -que es el trabajo real de administrar un servidor-.

Siguiente: Servicios con systemd

Continuar ← Archivos, permisos y sudo