Vida útil y actualizaciones de versión

Módulo 4: Software y actualizaciones · Tiempo de lectura: 11 minutos

Objetivo de aprendizaje: Después de esta lección podrá consultar la vida útil de su distribución, sabrá qué significa "end of life" para su servidor y podrá planificar y ejecutar con seguridad una actualización a una nueva versión (release-upgrade).

Conceptos clave: versión (release), LTS, soporte estándar, Debian LTS, Ubuntu ESM y Ubuntu Pro, end of life (EOL), /etc/os-release, do-release-upgrade, actualización mínima y completa, repositorios de terceros, snapshot, curl | bash

Cada versión tiene fecha de caducidad

Las actualizaciones automáticas (lección 4.2) solo funcionan mientras su distribución siga publicando actualizaciones para su versión. Cada versión de Debian y Ubuntu recibe actualizaciones de seguridad durante un periodo fijo. Después se acaba: su servidor deja de recibir correcciones, incluso para vulnerabilidades graves. Eso se llama end of life (EOL), el fin de la vida útil.

Puede ver qué versión tiene así:

anna@web1:~$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
...

En Ubuntu aparece, por ejemplo, VERSION="24.04.3 LTS (Noble Numbat)".

Debian

Debian da soporte completo a una versión durante unos tres años. Después, el equipo de Debian LTS se hace cargo durante dos años más, con actualizaciones de seguridad para los paquetes más utilizados. Para las versiones actuales (situación en noviembre de 2026, compruébelo en debian.org/releases):

Así pues, Debian 12 todavía recibe actualizaciones a través de LTS, pero está en su última fase. Un servidor nuevo se instala con Debian 13.

Ubuntu

Ubuntu publica cada dos años, en abril, una versión LTS (Long Term Support), con cinco años de mantenimiento de seguridad estándar. Con una suscripción a Ubuntu Pro (gratuita para uso personal en unas pocas máquinas) se añade ESM (Expanded Security Maintenance), hasta diez años en total.

Entre las versiones LTS aparecen versiones intermedias (como la 25.10) con solo nueve meses de soporte. No están pensadas para un servidor que debe funcionar durante años. Para un servidor, elija siempre una LTS.

Qué significa EOL para usted

Un servidor con una versión que ya no recibe actualizaciones sigue funcionando con normalidad. Precisamente eso es lo traicionero: no nota nada hasta que alguien aprovecha una vulnerabilidad que se ha corregido en todas partes menos en su servidor. Además:

• el software nuevo (una nueva versión de PHP, una nueva versión de Docker) deja de compilarse para su versión;
• los repositorios de terceros también dejan de dar soporte, a menudo antes;
• cuanto más espere, mayor será el salto. Debian no admite saltarse una versión: para pasar de la 11 a la 13 hay que pasar por la 12.

Por eso, anote en su agenda la fecha de EOL de su servidor, con un recordatorio medio año antes.

Dos caminos: actualizar o reconstruir

Hay dos rutas limpias hacia una nueva versión.

1. Actualización in situ (in-place): actualiza el servidor existente a la nueva versión. Es rápido y todo se conserva, pero también se arrastran restos antiguos y ajustes propios.
2. Reconstruir: crea un servidor nuevo con la nueva versión, vuelve a instalar sus servicios (algo práctico con las notas de la lección 10.4 o con Docker Compose, módulo 9), traslada los datos desde su copia de seguridad y cambia el DNS (lección 7.1). Requiere más trabajo, pero queda limpio y además sirve como prueba de su copia de seguridad.

Para un servidor pequeño con unos pocos servicios, una actualización in situ es perfectamente válida. Si tiene mucho trabajo a medida o el servidor ya se ha actualizado varias veces, plantéese reconstruirlo.

Preparar una actualización in situ

Asegúrese de tener estas cinco cosas antes de empezar:

1. Un snapshot en el panel de su proveedor, justo antes de empezar, y además una copia de seguridad reciente fuera del servidor (módulo 8). Un snapshot es su vía rápida de vuelta si la actualización falla a mitad de camino.
2. Una segunda vía de acceso: la consola de su proveedor. Usted trabaja por SSH, y si la configuración de red o el servidor SSH cambian durante la actualización, querrá poder continuar a través de la consola. Las notas de la versión de Debian lo dicen literalmente: asegúrese de antemano de tener otra forma de iniciar sesión.
3. Leer las notas de la versión, sobre todo el capítulo "Issues to be aware of". Para Debian 13 figura, por ejemplo, que /tmp ahora está en memoria de forma predeterminada, que /etc/sysctl.conf ya no se lee (utilice /etc/sysctl.d/) y que /boot debe ser lo bastante grande.
4. Revisar los repositorios de terceros. Los paquetes que no proceden del propio Debian o Ubuntu pueden entrar en conflicto durante la actualización. Compruebe qué repositorios tiene (ls /etc/apt/sources.list.d/) y si el fabricante ya ofrece una versión para la nueva release.
5. Una sesión que sobreviva a una conexión cortada. Inicie la actualización en tmux o screen. Si se cae su conexión a internet, la actualización continúa y usted la retoma con tmux attach.

Debian: los pasos

Según las notas de la versión de Debian 13, para una actualización de la 12 a la 13:

root@web1:~# apt update && apt full-upgrade          # primero actualizar por completo la versión actual
root@web1:~# sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/debian.sources
root@web1:~# apt update
root@web1:~# apt upgrade --without-new-pkgs          # actualización mínima
root@web1:~# apt full-upgrade                        # actualización completa
root@web1:~# reboot

Si todavía utiliza /etc/apt/sources.list, cambie allí el nombre en clave. Los repositorios de terceros se desactivan temporalmente durante la actualización (cambiándoles el nombre a .disabled) y después se vuelven a activar con el nombre en clave de la nueva versión, si el fabricante la ofrece.

Durante la actualización, preste atención a las preguntas sobre archivos de configuración. Si ha modificado usted mismo un archivo, como sshd_config, dpkg le preguntará si desea conservar su versión. Conserve su propia versión si sabe por qué la modificó y compárela después con la nueva versión (.dpkg-dist).

Después del reinicio:

anna@web1:~$ cat /etc/os-release | grep VERSION=
VERSION="13 (trixie)"
anna@web1:~$ systemctl --failed
anna@web1:~$ sudo apt autoremove

systemctl --failed (lección 6.1) debe aparecer vacío. Compruebe también que sus sitios web y contenedores funcionan y que su monitorización (lección 8.3) está en verde.

Ubuntu: do-release-upgrade

Ubuntu tiene un programa propio para ello:

anna@web1:~$ sudo apt update && sudo apt full-upgrade
anna@web1:~$ sudo do-release-upgrade

Hay dos cosas que conviene saber. En primer lugar, Ubuntu solo ofrece la actualización de una LTS a la siguiente después de la primera versión de mantenimiento (point release) (por ejemplo, la 26.04.1, unos meses después de abril). Es intencionado: en los primeros meses se resuelven los problemas más importantes. En segundo lugar, si ejecuta la actualización por SSH, do-release-upgrade le avisará de que, por seguridad, inicia un servidor SSH adicional en un puerto de reserva. Ese puerto tendrá que estar permitido en su firewall (lección 5.2) si lo necesita; normalmente no lo necesitará porque dispone de la consola.

La gran trampa: software de fuera de la distribución

Las actualizaciones fallan casi siempre por software que no procede de la distribución. Tres hábitos marcan la diferencia:

• Nada de curl https://... | bash. Un script de internet que ejecuta directamente como root puede cambiar cualquier cosa en su servidor: añadir repositorios, confiar en claves para todos los repositorios, sobrescribir archivos. No sabe qué ha pasado y, en la siguiente actualización, algo se rompe. Descargue ese script, léalo y, mejor aún, realice los pasos usted mismo.
• Un repositorio adicional solo del propio fabricante, con su propia clave (Signed-By, lección 4.1), y anote en la documentación de su servidor por qué está ahí.
• Nada de archivos .deb sueltos descargados de sitios web si el software también está disponible en la distribución o en el repositorio del fabricante. Esos archivos nunca reciben actualizaciones.

En AlmaLinux y Rocky Linux

Allí, una versión "major" (9, 10) recibe actualizaciones durante unos diez años, y las versiones intermedias (9.6, 9.7) se actualizan sin más con dnf upgrade. Un salto in situ a una nueva versión major es posible con la herramienta ELevate (AlmaLinux), pero muchos administradores prefieren reconstruir el servidor cuando dan el salto a una nueva versión major.

En la práctica

En la pantalla del VPS de WebOké puede crear un snapshot antes de una actualización (como máximo dos a la vez, en el mismo almacenamiento que su VPS) y dispone de la consola como segunda vía de acceso. En otros proveedores los nombres son parecidos: snapshot, consola VNC o web, rescue. Un snapshot no sustituye a una copia de seguridad fuera del servidor; elimínelo cuando todo funcione, porque crece con cada cambio.

Resumen

• Cada versión recibe actualizaciones de seguridad durante un periodo fijo; después llega a su end of life y su servidor deja de recibir correcciones.
• Debian: unos tres años más dos años de LTS; Ubuntu LTS: cinco años más ESM hasta diez años. Para un servidor, elija siempre una LTS y anote la fecha de fin en su agenda.
• Prepare una actualización con un snapshot, una copia de seguridad, la consola, las notas de la versión y una sesión de tmux.
• Debian: repositorios con el nuevo nombre en clave, apt upgrade --without-new-pkgs, apt full-upgrade; Ubuntu: do-release-upgrade, después de la primera versión de mantenimiento.
• El software de fuera de la distribución es la mayor fuente de problemas en las actualizaciones: nada de curl | bash, solo repositorios del fabricante con su propia clave.

Cuestionario

Ejercicio

Ejercicio O4.3: Su plan de actualización. Averigüe qué versión ejecuta su servidor y hasta cuándo recibe actualizaciones de seguridad. Después, elabore un plan de actualización: ¿qué repositorios de terceros tiene?, ¿cómo crea un snapshot y una copia de seguridad?, ¿cómo accede a través de la consola?, ¿qué pasos va a ejecutar?, ¿cómo lo comprueba después? y ¿opta por una actualización in situ o por reconstruir (y por qué)?

Para saber más

• Snapshots y copias de seguridad de su VPS
• Montar una ISO propia o reinstalar su VPS
• Versiones de Debian y periodos de soporte: https://www.debian.org/releases/
• Debian 13, notas de la versión, capítulo 4 (actualización) y 5 (aspectos a tener en cuenta): https://www.debian.org/releases/trixie/release-notes/
• Ubuntu, ciclo de versiones: https://ubuntu.com/about/release-cycle
• Documentación de Ubuntu Server, Upgrade your release: https://ubuntu.com/server/docs/how-to/software/upgrade-your-release/