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.
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.
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.
Descarga la lista de versiones disponibles en los repositorios.
No instala ni cambia nada. Es rápido y es inofensivo: puedes ejecutarlo cuando quieras.
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.
upgrade sin un update previo instala
contra un catálogo viejo: se pierde lo publicado desde la última consulta.
Por eso se escriben encadenados.
# 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 autoremoveListing... 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.
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.
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.
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ó.
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.
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.
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-.
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.
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».
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 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 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.
Responde antes de voltear.
Ejecutas sudo apt update todas las semanas y nada más. ¿Está el servidor al día?
update el servidor tiene exactamente el mismo software que
antes.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?
/var/run/reboot-required.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