Actualizaciones desatendidas con unattended-upgrades

En una flota de ordenadores de escritorio bien mantenida es de esperar que se hayan aplicado todas las actualizaciones para que el software esté al día.

El caso más sencillo son las actualizaciones de herramientas que se han instalado en formato flatpak (o snap) ya que estos sistemas actualizan el software de manera atómica y permiten instalar una nueva versión de la aplicación sin sobreescribir la antigua.

Cada formato tiene su propio sistema de actualización:

• En el caso de los paquetes snap el servicio snapd se encarga de comprobar si hay actualizaciones y las aplica automáticamente.
• En el caso de los paquetes flatpak el comando flatpak -y update —que en el centro ejecuta Vasilisa— aplica las actualizaciones.

Actualizar las herramientas instaladas en formato flatpak o snap no provoca ningún problema aún cuando ocurra un corte eléctrico durante la actualización. Y por eso distribuciones como Fedora Silverblue o Ubuntu for the Internet of Things buscan simplificar las actualizaciones montando una distribución inmutable sobre la que se instalan paquetes flatpak o snap. Otras distribuciones de GNU/Linux como el Sistema GNU Guix consiguen actualizaciones atómicas gracias al gestor de paquetes GNU Guix que también guarda cada paquete en el almacén sin que una nueva versión sobreescriba a la antigua.

Pero con los paquetes .deb la cosa no es tan sencilla. Un administrador siempre puede ejecutar apt update para actualizar la BBDD con los paquetes que se encuentran en ese momento en los repositorios y ejecutar apt upgrade para actualizar los paquetes. En ese momento comenzará la descarga de los paquetes y después se realizará su instalación. Pero durante la instalación de los paquetes se estará modificando el sistema de archivos eliminando la versión antigua e instalando la versión nueva de cada paquete. Y a ningún administrador le gustará siquiera pensar en que este proceso se pueda interrumpir de forma abrupta por un corte eléctrico.

Las herramientas apt y dpkg hacen un gran trabajo con la gestión de los paquetes pero no proporcionan operaciones atómicas. Sin embargo en el centro este curso se utiliza Ubuntu 20.04 instalado sobre OpenZFS y cada vez que apt gestiona el software instalado se toma un snapshot del sistema de manera que, en el caso de que algo haya salido mal, se puede volver al estado anterior.

Con esta medida de seguridad ya resulta razonable activar las instalaciones automáticas en toda la flota de escritorios del centro, incluso en los portátiles que se pueden quedar sin batería durante una actualización e interrumpir el proceso de manera inesperada.

El paquete unattended-upgrades

El paquete unattended-upgrades proporciona actualizaciones desatendidas en las distribuciones Debian y Ubuntu. El elemento central del paquete es el script unattended-upgrade que no es pequeño precisamente. Su función es instalar las actualizaciones de manera desatendida, es decir, sin intervención del usuario.

Una de sus principales características es que por defecto la instalación de los paquetes se divide en pequeños pasos que se pueden interrumpir. Así si el usuario inicia la detención del equipo únicamente hay que esperar hasta que se completa el paso en curso.

La activación de este script depende del timer /usr/lib/systemd/system/apt-daily-upgrade.timer que activa el servicio correspondiente un tiempo aleatorio entre 0 y 60 minutos después del arranque siempre que el equipo esté conectado a la alimentación.

Y aquí viene el principal problema con los portátiles del centro —que se cargan en un carro y se utilizan siempre sin alimentador—, y es que en estos equipos nunca se lanza el servicio y nunca se instalan las actualizaciones aunque se haya cambiando la configuración en /etc/apt/apt.conf.d/50unattended-upgradespara permitir actualizaciones utilizando la batería.

Otro problema está relacionado con el tiempo de espera aleatorio entre el arranque y el momento en el que se lanzan las actualizaciones. En ocasiones Ansible coincide con el proceso de actualización automática y las operaciones que utilizan el falla pues solo un proceso puede estar instalando/desinstalado/actualizando paquetes en un momento determinado.

En nuestro caso las solución consiste en que /opt/vasilisa lanceunattended-upgrade en cada arranque antes de hacer la petición a Sirin que puede provocar la ejecución de un playbook.

La configuración de unattended-upgrades

Estas actualizaciones se controlan mediante el fichero /etc/apt/apt.conf.d/20auto-upgrades que permite definir si de manera automática:

1. Se actualiza la lista de paquetes
2. Se realiza la actualización desatendida

En un sistema con las dos opciones activadas se puede ver:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Cómo se realizan estas actualizaciones se puede configurar en el fichero /etc/apt/apt.conf.d/50unattended-upgrades.

Lo primero que se configuran son los orígenes para las actualizaciones automáticas:

// Automatically upgrade packages from these (origin:archive) pairs
//
// Note that in Ubuntu security updates may pull in new dependencies
// from non-security sources (e.g. chromium). By allowing the release
// pocket these get automatically pulled in.
Unattended-Upgrade::Allowed-Origins {
	"${distro_id}:${distro_codename}";
	"${distro_id}:${distro_codename}-security";
	// Extended Security Maintenance; doesn't necessarily exist for
	// every release and this system may not have it installed, but if
	// available, the policy for updates is such that unattended-upgrades
	// should also install from here by default.
	"${distro_id}ESMApps:${distro_codename}-apps-security";
	"${distro_id}ESM:${distro_codename}-infra-security";
	"${distro_id}:${distro_codename}-updates";
//	"${distro_id}:${distro_codename}-proposed";
//	"${distro_id}:${distro_codename}-backports";
};

Los orígenes activos por defecto no incluyen "${distro_id}:${distro_codename}-updates" pero en el centro tenemos una tarea de Ansible que activa este origen.