Cómo gestionar las actualizaciones en un servidor Ubuntu 23 fuera de soporte

Introducción

Mantener un servidor con Ubuntu 23 fuera de soporte exige actuar con más prudencia de la habitual. El sistema puede seguir arrancando, Nginx puede continuar sirviendo páginas y las bases de datos pueden funcionar con aparente normalidad, pero la distribución ya no recibe el mantenimiento ordinario que corresponde a una versión compatible. El principal problema no es que el servidor deje de funcionar de un día para otro, sino que aumenta la distancia entre el software instalado y las correcciones de seguridad, dependencias y procedimientos de actualización disponibles.

Las versiones intermedias de Ubuntu tienen un ciclo de mantenimiento corto. Ubuntu 23.04, cuyo nombre en clave es Lunar Lobster, y Ubuntu 23.10, denominado Mantic Minotaur, pertenecen a esa familia de versiones no LTS. Cuando una versión llega al final de su vida útil, sus repositorios se retiran de los servidores ordinarios y pasan al archivo histórico. A partir de ese momento, ejecutar apt update puede devolver errores 404 aunque la conexión a Internet funcione correctamente.

Este artículo explica cómo recuperar temporalmente el funcionamiento de APT, revisar los repositorios sin desestabilizar un servidor en producción, instalar paquetes concretos con control y preparar la migración hacia una versión Ubuntu LTS compatible. El objetivo no es presentar el uso de una versión sin soporte como una solución permanente, sino gestionar el periodo de transición con el menor riesgo posible.

Índice

Qué significa que Ubuntu 23 esté fuera de soporte

Una versión fuera de soporte, también llamada EOL por End of Life, ya no recibe actualizaciones ordinarias de seguridad ni mantenimiento desde los repositorios activos de Ubuntu. El sistema operativo no se desactiva, pero queda congelado en el estado alcanzado al finalizar su ciclo de vida.

Conviene distinguir tres situaciones:

• Versión compatible: recibe actualizaciones desde los repositorios normales.
• Versión LTS fuera del soporte estándar pero cubierta por mantenimiento ampliado: puede disponer de servicios adicionales de seguridad según la versión y la modalidad contratada.
• Versión intermedia EOL: deja de recibir mantenimiento y sus paquetes se trasladan normalmente al archivo histórico.

Ubuntu 23.04 y Ubuntu 23.10 fueron versiones intermedias. No deben confundirse con Ubuntu 22.04 LTS o Ubuntu 24.04 LTS, cuyo ciclo de vida está pensado para entornos que necesitan estabilidad durante varios años.

En un servidor web, permanecer indefinidamente en una versión EOL puede afectar al kernel, OpenSSL, bibliotecas del sistema, PHP, servidores de bases de datos, herramientas de copia de seguridad y utilidades administrativas. Aunque una aplicación concreta siga funcionando, la plataforma completa deja de avanzar.

Cómo comprobar la versión y el estado del servidor

Antes de cambiar repositorios, hay que confirmar qué versión está instalada. No conviene deducirla por la antigüedad del servidor ni por una referencia encontrada en un panel de control.

cat /etc/os-release
lsb_release -a
uname -a

La primera orden muestra el nombre de la distribución y su código interno. En Ubuntu 23.04 aparecerá normalmente lunar; en Ubuntu 23.10, mantic.

También es recomendable registrar el estado de los servicios críticos:

systemctl --failed
systemctl is-active nginx
systemctl is-active apache2
systemctl is-active mariadb
systemctl is-active mysql
systemctl is-active php8.1-fpm

No todos esos servicios estarán instalados. El objetivo es comprobar los que correspondan a la máquina real y conservar una referencia previa. En un servidor WordPress, por ejemplo, interesan especialmente el servidor web, PHP-FPM, la base de datos, el sistema de certificados y las tareas programadas.

Para documentar paquetes y versiones:

dpkg-query -W -f='${binary:Package}\t${Version}\n' > /root/paquetes-antes-de-actualizar.txt
apt-mark showhold > /root/paquetes-bloqueados.txt

Esta información no sustituye una copia de seguridad, pero facilita el diagnóstico si una actualización introduce cambios inesperados.

Crear un punto de retorno antes de modificar APT

Modificar /etc/apt/sources.list no suele afectar inmediatamente a Nginx, MariaDB o PHP. Sin embargo, una actualización posterior sí puede sustituir paquetes, reiniciar servicios o cambiar dependencias. Por eso debe existir un punto de retorno verificable.

Copiar la configuración de repositorios

cp -a /etc/apt/sources.list /etc/apt/sources.list.bak
cp -a /etc/apt/sources.list.d /etc/apt/sources.list.d.bak

Guardar configuraciones de servicios

tar -czf /root/configuracion-servidor-antes-apt.tar.gz \
/etc/nginx \
/etc/apache2 \
/etc/php \
/etc/mysql \
/etc/letsencrypt \
/etc/systemd/system 2>/dev/null

El comando debe adaptarse a los servicios instalados. Si alguna ruta no existe, puede omitirse.

Respaldar datos y bases de datos

Una copia de /etc no contiene necesariamente los datos de las aplicaciones. Hay que respaldar también las bases de datos, los ficheros web, las claves, los certificados y los directorios donde se almacenen documentos o exportaciones.

Para una base de datos MariaDB o MySQL, la estrategia puede incluir una exportación lógica:

mysqldump --single-transaction --routines --events --all-databases \
> /root/bases-de-datos-antes-actualizacion.sql

En servidores importantes, es preferible combinar la copia lógica con una instantánea del proveedor, del hipervisor o del volumen. La copia solo es útil si se conoce el procedimiento de restauración y se ha comprobado que el fichero generado no está vacío.

La gestión de copias de seguridad debe formar parte del mantenimiento ordinario, no limitarse al día de una actualización crítica.

Auditar los repositorios configurados

APT puede leer fuentes desde dos ubicaciones principales:

• /etc/apt/sources.list
• /etc/apt/sources.list.d/

Antes de editar nada, conviene obtener una vista conjunta:

grep -R --line-number --no-messages \
-E '^[[:space:]]*(deb|deb-src)[[:space:]]' \
/etc/apt/sources.list \
/etc/apt/sources.list.d/

Esta revisión permite detectar mezclas habituales:

• Repositorios de Ubuntu que todavía apuntan a archive.ubuntu.com.
• Entradas de seguridad que apuntan a security.ubuntu.com.
• Fuentes deb-src que continúan activas aunque no se necesite descargar código fuente.
• Repositorios de terceros, como NodeSource, Docker, bases de datos, paneles de administración o herramientas de monitorización.
• Entradas duplicadas o correspondientes a otra versión de Ubuntu.

Un error 404 durante apt update no implica necesariamente que todos los repositorios estén mal. APT consulta cada fuente por separado. Puede haber una fuente válida y otra obsoleta en la misma ejecución.

Usar old-releases.ubuntu.com correctamente

Cuando una versión Ubuntu alcanza el final de su vida útil, sus repositorios dejan de estar disponibles en los servidores activos y pasan al archivo histórico. Para recuperar temporalmente la capacidad de consultar los paquetes de esa versión, normalmente hay que sustituir el dominio, pero conservar el nombre en clave de la distribución.

En Ubuntu 23.04, por ejemplo, no se debe cambiar lunar por el código de una versión más nueva dentro del mismo sources.list. Mezclar paquetes de distintas versiones no equivale a realizar una actualización de distribución y puede dejar el sistema en un estado incoherente.

Ejemplo para Ubuntu 23.04 Lunar

deb http://old-releases.ubuntu.com/ubuntu lunar main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu lunar-updates main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu lunar-security main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu lunar-backports main restricted universe multiverse

Ejemplo para Ubuntu 23.10 Mantic

deb http://old-releases.ubuntu.com/ubuntu mantic main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu mantic-updates main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu mantic-security main restricted universe multiverse
deb http://old-releases.ubuntu.com/ubuntu mantic-backports main restricted universe multiverse

Las líneas deb-src solo son necesarias cuando se quiere descargar el código fuente de los paquetes. En muchos servidores de producción pueden dejarse comentadas para simplificar la resolución de errores:

sed -i 's/^[[:space:]]*deb-src/#deb-src/' /etc/apt/sources.list

Después hay que comprobar el resultado antes de ejecutar APT:

grep -E '^[[:space:]]*deb[[:space:]]' /etc/apt/sources.list
apt update

Que apt update termine sin errores significa que APT puede leer los índices configurados. No significa que la versión haya vuelto a tener soporte ni que hayan aparecido correcciones de seguridad nuevas. old-releases.ubuntu.com es un archivo, no un canal de mantenimiento activo.

Gestionar repositorios de terceros

Un servidor EOL puede tener repositorios externos que continúan funcionando porque no dependen del ciclo de Ubuntu o porque publican paquetes bajo una distribución genérica como nodistro. Esto no convierte al sistema completo en compatible.

Hay que revisar cada fichero de /etc/apt/sources.list.d/ y responder a tres preguntas:

1. ¿El repositorio declara compatibilidad con la plataforma instalada?
2. ¿La clave de firma sigue siendo válida?
3. ¿El paquete puede instalarse sin sustituir bibliotecas críticas del sistema?

Para listar las fuentes:

find /etc/apt/sources.list.d -maxdepth 1 -type f -print
grep -R --line-number -E '^[[:space:]]*deb[[:space:]]' \
/etc/apt/sources.list.d/

No se debe eliminar un repositorio simplemente porque aparezca junto a un error de Ubuntu. Primero hay que identificar qué URL devuelve el fallo. Del mismo modo, no conviene añadir un repositorio nuevo y ejecutar automáticamente una actualización general sin examinar el plan de cambios.

Cuando se instala software como Node.js desde NodeSource, Docker desde su repositorio oficial o una versión específica de una base de datos, resulta útil comprobar el origen elegido por APT:

apt-cache policy nodejs
apt-cache policy docker-ce
apt-cache policy mariadb-server

La salida muestra las versiones candidatas y el repositorio del que proceden. Es una comprobación sencilla que evita creer que se está instalando el paquete de Ubuntu cuando realmente procede de un tercero, o al revés.

Actualizar paquetes sin romper producción

En un servidor fuera de soporte, el objetivo inmediato debería ser recuperar el control, no ejecutar todos los cambios disponibles de forma impulsiva. El procedimiento debe separar la actualización de índices, la simulación y la instalación real.

1. Actualizar únicamente los índices

apt update

Este comando no instala paquetes. Descarga la información de los repositorios y revela errores de conexión, firmas, rutas o versiones.

2. Ver qué paquetes pueden actualizarse

apt list --upgradable

3. Simular la actualización

apt-get -s upgrade
apt-get -s dist-upgrade

La opción -s realiza una simulación. Hay que prestar atención a paquetes eliminados, cambios de kernel, sustitución de PHP, bibliotecas criptográficas, servidores de bases de datos y servicios que puedan reiniciarse.

4. Evitar autoremove sin revisión

APT puede mostrar paquetes instalados automáticamente que ya no considera necesarios. No conviene ejecutar apt autoremove por reflejo en un servidor antiguo. Algunos paquetes pueden seguir siendo utilizados por herramientas instaladas manualmente, servicios poco documentados o aplicaciones que no declaran bien sus dependencias.

Primero debe simularse:

apt-get -s autoremove

Si aparecen kernels, bibliotecas de red, componentes de PHP, paquetes de bases de datos o herramientas administrativas que todavía se usan, hay que detenerse y revisar.

5. Verificar servicios después de cada bloque

systemctl --failed
nginx -t
apachectl configtest
php -v
mysqladmin ping
curl -I http://127.0.0.1

Solo deben ejecutarse las pruebas correspondientes a los servicios instalados. Para una web HTTPS también conviene comprobar el acceso por el nombre de dominio y revisar los registros del servidor web.

En la sección de administración de sistemas puedes ampliar procedimientos de diagnóstico, mantenimiento y operación segura de servidores Linux.

Instalar un paquete concreto de forma controlada

A veces el servidor EOL se mantiene temporalmente porque una migración completa requiere planificación, pero surge la necesidad de instalar una herramienta concreta. En ese caso, es mejor reducir el alcance del cambio.

Antes de instalar:

apt update
apt-cache policy nombre-del-paquete
apt-get -s install nombre-del-paquete

La simulación permite comprobar si APT pretende instalar un único paquete o arrastrar una cadena amplia de dependencias.

Para Node.js, por ejemplo:

apt-cache policy nodejs
apt-get -s install nodejs

Después de validar el origen y el plan:

apt install nodejs
node -v
npm -v
which node
which npm

El criterio importante no es solo que el programa responda con una versión, sino que se sepa qué repositorio lo suministró, qué dependencias se instalaron y qué espacio adicional ocupa.

Si la instalación propone eliminar servicios importantes o sustituir paquetes esenciales, hay que cancelar y analizar. La opción automática -y es cómoda, pero reduce la oportunidad de detectar un plan de cambios peligroso. En servidores delicados, conviene usarla solo después de una simulación o cuando el procedimiento ya se ha validado en una máquina equivalente.

Errores frecuentes y cómo interpretarlos

Error 404 en archive.ubuntu.com

Suele indicar que la distribución EOL ya no está publicada en el repositorio ordinario. Hay que comprobar el código de versión y migrar las entradas de Ubuntu al archivo histórico, sin mezclar nombres en clave.

Una fuente funciona y otra falla

Es posible que un repositorio externo responda correctamente mientras los repositorios de Ubuntu devuelven errores. Cada entrada debe diagnosticarse de forma independiente.

APT dice que todos los paquetes están actualizados

En una versión EOL, ese mensaje solo significa que no hay versiones más recientes dentro de los repositorios archivados configurados. No demuestra que el sistema esté protegido frente a vulnerabilidades descubiertas posteriormente.

Paquetes “ya no necesarios”

El mensaje informativo no obliga a ejecutar autoremove. Antes hay que simular la eliminación y confirmar que los paquetes no son utilizados por aplicaciones o herramientas instaladas fuera del gestor de paquetes.

Repositorios mezclados

Combinar lunar, mantic, jammy o noble en una misma base de APT puede causar conflictos difíciles de recuperar. Una actualización de versión debe seguir una ruta compatible y un procedimiento específico; no consiste en reemplazar a mano el nombre en clave por el de la versión deseada.

Certbot falla al renovar

Un fallo de Certbot no siempre está relacionado con APT. Si se utiliza el modo standalone, el cliente necesita ocupar temporalmente el puerto 80. Si Nginx o Apache ya lo usan, la renovación puede fallar. Hay que revisar el método de validación, el temporizador, los registros y la configuración del servidor web antes de atribuir el problema a la versión de Ubuntu.

Preparar la migración a una versión LTS

Recuperar APT mediante old-releases.ubuntu.com compra tiempo operativo, pero no resuelve el riesgo estructural. La solución sostenible consiste en migrar a una versión soportada, preferiblemente LTS para un servidor que necesita estabilidad.

Elegir entre actualización y servidor nuevo

Hay dos estrategias principales:

• Actualizar el sistema existente: conserva configuraciones y rutas, pero arrastra decisiones antiguas, paquetes manuales y posibles incompatibilidades.
• Crear un servidor nuevo y migrar servicios: requiere reconstruir la plataforma, pero permite probar, documentar y volver atrás cambiando DNS o balanceo.

En servidores de producción, una migración paralela suele ofrecer un punto de retorno más claro. El nuevo servidor puede prepararse con una versión LTS, instalar las mismas aplicaciones, copiar datos, validar rendimiento y realizar el cambio final en una ventana controlada.

Inventario previo

Antes de migrar hay que registrar:

• Dominios, certificados y renovaciones automáticas.
• Virtual hosts de Nginx o Apache.
• Versiones de PHP y extensiones activas.
• Bases de datos, usuarios, privilegios y eventos programados.
• Tareas de cron y temporizadores de systemd.
• Repositorios externos y claves.
• Reglas de firewall, puertos y restricciones de red.
• Rutas de copias de seguridad, exportaciones y ficheros temporales.
• Usuarios del sistema, permisos y propietarios.
• Servicios que arrancan automáticamente.

Probar antes del cambio definitivo

Una migración no debe considerarse completada solo porque la página principal carga. Hay que probar formularios, tareas programadas, envío de correo, generación de ficheros, subida de contenidos, copias de seguridad, renovación de certificados, administración de WordPress y restauración de bases de datos.

También conviene comparar:

systemctl --failed
ss -lntup
df -h
free -h
php -m
nginx -T
crontab -l

La sección de Linux puede servir como base para documentar comandos, procedimientos y comprobaciones repetibles durante la migración.

Lista de comprobación operativa

1. Confirmar la versión con /etc/os-release.
2. Identificar el nombre en clave: lunar o mantic.
3. Comprobar el estado de servicios y guardar un inventario de paquetes.
4. Crear copias de configuración, datos y bases de datos.
5. Respaldar sources.list y sources.list.d.
6. Revisar todas las líneas deb y deb-src.
7. Cambiar únicamente los dominios de Ubuntu EOL a old-releases.ubuntu.com.
8. No sustituir manualmente el nombre en clave por el de otra versión.
9. Ejecutar apt update y resolver cada error por separado.
10. Comprobar el origen de los paquetes con apt-cache policy.
11. Simular instalaciones y actualizaciones antes de aplicarlas.
12. No ejecutar autoremove sin revisar la simulación.
13. Verificar servicios después de cada cambio.
14. Documentar todo lo instalado o modificado.
15. Programar la migración a una versión LTS soportada.

Preguntas frecuentes

Conclusión

Gestionar actualizaciones en un servidor Ubuntu 23 fuera de soporte consiste, ante todo, en evitar decisiones automáticas. El traslado de los repositorios a old-releases.ubuntu.com puede recuperar temporalmente el funcionamiento de APT, pero no restablece el mantenimiento de seguridad.

La operación segura combina inventario, copias de respaldo, auditoría de repositorios, simulación de cambios, verificación de servicios y documentación. Instalar un paquete concreto puede ser razonable si el origen y las dependencias están controlados, pero no debe confundirse con una solución global.

El objetivo final debe ser abandonar la versión EOL mediante una actualización compatible o, preferiblemente en muchos entornos de producción, mediante la construcción de un servidor nuevo con Ubuntu LTS y una migración probada. Cuanto más tiempo permanezca expuesto un servidor sin soporte, mayor será la deuda técnica y más difícil resultará garantizar su seguridad.