Por qué la actualización no es urgente, y cuándo se vuelve razonable
Ubuntu 26.04 LTS se publicó el 23 de abril de 2026. Como en cada LTS, Canonical solo abre el salto desde la LTS anterior con la primera versión puntual: 26.04.1 se anunció el 27 de agosto de 2026, pero la oferta de actualización se retuvo unas semanas más, el tiempo de retroportar correcciones a regresiones de rust-coreutils. El equipo de publicación anunció la apertura el 29 de septiembre de 2026, con un despliegue progresivo en escritorio y do-release-upgrade disponible en cualquier momento en servidores.
Digámoslo con franqueza: nada apremia. Ubuntu 24.04 LTS recibe sus parches de seguridad estándar hasta mayo de 2029, y hasta mayo de 2034 con Ubuntu Pro. Un VPS 24.04 actualizado no es un VPS expuesto. 26.04, por su parte, se mantiene hasta mayo de 2031.
La actualización se vuelve razonable cuando se cumplen tres condiciones: sus repositorios de terceros (Docker, PHP, Node, agentes de supervisión) publican para resolute, un clon del VPS ha superado la actualización con su pila real y dispone de una ventana de mantenimiento acordada con el cliente. Para una agencia, el buen momento suele ser cuando se estandariza una flota: una sola base que documentar en lugar de dos.
Lo que esta guía le permite hacer
- Decidir entre actualizar in situ o un VPS nuevo — con criterios medibles, no por costumbre.
- Contar con una red de seguridad real — una copia ya restaurada una vez, no una instantánea nunca probada.
- Sobrevivir a un corte de SSH — gracias a la sesión
screenque la herramienta abre por sí misma y al demonio de respaldo en el puerto 1022. - Saber dónde está el punto de no retorno — y, por tanto, qué debe cubrir su copia de seguridad antes de alcanzarlo.
- Anticipar lo que se rompe —
sudo-rs,rust-coreutils, PHP, MySQL, OpenSSH,docker-composev1, repositorios de terceros. - Volver a activar los repositorios de terceros — con el nombre de versión correcto, sin reintroducir
apt-key. - Repetir el procedimiento en una flota — cada paso se verifica con un comando, así que se puede reproducir.
Actualizar in situ o reinstalar un VPS nuevo
La actualización in situ conserva la dirección IP, las claves de host SSH, las cuentas y la configuración. Falla sobre todo donde el servidor se ha alejado de una instalación estándar. La reinstalación en un VPS nuevo cuesta una migración, pero deja el servidor antiguo intacto hasta el cambio de DNS: es el único escenario que ofrece una vuelta atrás real.
Decida con cuatro preguntas. ¿Cuántos repositorios de terceros y PPA están activos? Más allá de dos o tres, cada uno es una incógnita que la herramienta desactiva durante la actualización. ¿Su copia de seguridad se ha restaurado alguna vez? Si no, la actualización in situ es una apuesta. ¿Cuánta interrupción tolera el cliente? Según la documentación de Ubuntu, la actualización lleva varias horas, y la máquina se reinicia al final. ¿El servidor está descrito en código (Ansible, cloud-init, Compose)? Si es así, un VPS nuevo se reconstruye rápido y la reinstalación pasa a ser la opción más segura.
Regla práctica: servidor documentado y pila en contenedores, reinstale; servidor histórico con pocos repositorios de terceros y una copia probada, actualice in situ, tras un ensayo en un clon.
Requisitos antes de ejecutar nada
El VPS debe ejecutar una 24.04 totalmente actualizada: do-release-upgrade se niega en caso contrario, con un mensaje explícito. Cuente con una ventana de varias horas, una persona presente para responder a las preguntas de la herramienta y una consola fuera de banda (consola web o VNC del proveedor) por si SSH no vuelve. El puerto 1022/tcp debe poder abrirse temporalmente en el cortafuegos.
La herramienta calcula por sí misma el espacio en disco necesario y se detiene si falta: compruebe df -h / y df -h /boot antes, y vacíe la caché de APT si hace falta. En el lado de las aplicaciones, necesita una copia de los datos fuera del VPS y una instantánea de la máquina completa proporcionada por la plataforma.
Una precisión por honestidad: los cambios que se enumeran más abajo proceden de las notas de versión oficiales de 26.04 y de la documentación de los paquetes afectados. No se han observado en un ensayo completo por nuestra parte sobre una pila Docker, Nginx y PHP-FPM. Precisamente por eso el procedimiento pasa por un clon.
El procedimiento, paso a paso
Inventariar lo que viene de fuera de la distribución
Liste las fuentes APT de terceros con
ls /etc/apt/sources.list.d/y localice los paquetes ajenos al archivo de Ubuntu conapt list --installed 2>/dev/null | grep -v ubuntu. Anote la versión de PHP (php -v), la presencia del antiguo binario de Compose (which docker-compose && docker-compose version) y el contenido de/etc/sudoers.d/. Esta lista es su plan de pruebas.Hacer una copia y restaurarla una vez
Una instantánea del VPS en la plataforma solo es una red de seguridad si ya se ha restaurado una vez. Haga la instantánea, restáurela en una máquina de prueba y compruebe que los servicios arrancan. Compleméntela con una copia de las aplicaciones fuera del servidor (bases de datos, volúmenes,
/etc): nuestra guía copias de seguridad con Restic en un VPS detalla la configuración.Actualizar primero un clon
Cree un VPS de prueba a partir de la instantánea (desde 99 DH/mes) y ejecute todo el procedimiento en él. Anote cada pregunta de la herramienta, cada servicio que falla, cada repositorio desactivado. La actualización de producción ya no debería dar sorpresas.
Actualizar 24.04 por completo
La documentación de Ubuntu Server prescribe
sudo apt updatey despuéssudo apt dist-upgrade -o APT::Get::Always-Include-Phased-Updates=true. Si existe el archivo/run/reboot-required, reinicie antes de continuar. Compruebe por último que/etc/update-manager/release-upgradescontienePrompt=lts.Preparar el acceso de respaldo
Ejecutada por SSH, la actualización avisa de que iniciará un demonio SSH adicional en el puerto 1022, sin abrirlo en el cortafuegos. Ábralo usted mismo:
sudo ufw allow 1022/tcp. Mantenga abierta la consola web del proveedor en otra pestaña.Lanzar la actualización
Ejecute
sudo do-release-upgrade, sin-d: esa opción sirve para versiones de desarrollo y ya no es necesaria desde la apertura de la ruta LTS. La herramienta se relanza sola dentro de una sesiónscreenllamadaubuntu-release-upgrade-screen-window. Si se cae su conexión, vuelva a conectarse y retómela consudo screen -d -r ubuntu-release-upgrade-screen-window. Los registros están en/var/log/dist-upgrade/.Responder a las preguntas sin automatismos
La herramienta anuncia los repositorios de terceros desactivados y después el número de paquetes que instalará, actualizará y eliminará. Lea la lista de eliminaciones. Para cada archivo de configuración modificado localmente (
sshd_config,php.ini,nginx.conf), conserve su versión por defecto y compare después con el archivo.dpkg-dist.Cruzar el punto de no retorno con conocimiento de causa
La documentación de Ubuntu es clara: una vez terminada la descarga, el proceso ya no se puede cancelar. Los paquetes se reemplazan y la distribución no prevé ninguna vuelta a 24.04. A partir de ahí, su única vuelta atrás es restaurar la instantánea del paso 2.
Reiniciar y comprobar
El sistema solo se considera actualizado tras el reinicio propuesto al final del procedimiento. Compruebe después
cat /etc/os-release,uname -r,systemctl --failedy los registros de sus servicios. Cierre el puerto de respaldo consudo ufw delete allow 1022/tcp.Reactivar los repositorios de terceros y después Docker
Reescriba cada fuente de terceros con el nombre de versión
resolute. Docker documenta una fuente en formato.sourcescuya líneaSuiteslee el nombre desde/etc/os-release. Para PHP, el PPA de Ondřej Surý remite ahora apackages.sury.org/php/para Resolute. Compruebe después sus pilas con nuestra guía migración a Docker v29 en un VPS.
24.04 y 26.04: lo que cambia bajo sus aplicaciones
Desplace la tabla
| Componente | Ubuntu 24.04 LTS | Ubuntu 26.04 LTS |
|---|---|---|
| Núcleo (GA) | 6.8 | 7.0 |
| PHP (archivo de Ubuntu) | 8.3 | 8.5 |
| Python 3 | 3.12 | 3.14 |
| OpenSSL | serie 3.0 | serie 3.5 |
| OpenSSH | 9.6p1 | 10.2p1, claves DSA retiradas |
| MySQL | 8.0 | 8.4 LTS, `mysql_native_password` bloqueado por defecto |
| sudo y coreutils | sudo en C, GNU coreutils | `sudo-rs` y `rust-coreutils` por defecto; `cp`, `mv`, `rm` siguen siendo GNU |
| Compose | paquete `docker-compose` v1 (1.29.2) | paquete v1 ausente; `docker-compose-v2` (2.40.3) |
Lo que se rompe: lo que dicen las notas de versión
El cambio más visible es sudo-rs, que pasa a ser el proveedor por defecto. La implementación original sigue instalada con el nombre sudo.ws. Ajustes como requiretty, timestamp_type o mailto en un archivo sudoers pueden provocar un error de ajuste desconocido, el registro de entradas y salidas no existe y sudo-ldap se ha retirado. Volver al sudo antiguo pasa por sudo update-alternatives --set sudo /usr/bin/sudo.ws, algo que el anuncio de Ubuntu desaconseja sin prohibirlo.
Las utilidades básicas proceden de rust-coreutils, salvo cp, mv y rm. Las notas de versión aún enumeran CVE abiertas en este paquete y un defecto de herencia de ACL con mkdir -p. El paquete coreutils-from-gnu restablece las versiones GNU si un script de copia o de despliegue depende de ellas.
Para un servidor web, tenga en cuenta también que apt-key se ha retirado, que el módulo libapache2-mod-php pierde el JIT de PHP por un endurecimiento de systemd (se recomienda PHP-FPM) y que el soporte de cgroup v1 desaparece con systemd 259.
Los cambios que hay que probar en el clon
- sudo — ejecute
sudo visudo -cy vuelva a lanzar sus scripts que llaman asudosin terminal. - Scripts de shell — ejecute sus copias y despliegues tal cual; una diferencia de
rust-coreutilsaparece en opciones poco habituales dedate,lsostat. - PHP 8.5 — compruebe las extensiones cargadas con
php -my la compatibilidad de sus CMS; el paso desde 8.3 se salta una versión mayor intermedia. - MySQL 8.4 — las cuentas con
mysql_native_passwordestán bloqueadas por defecto; localícelas antes de la actualización. - SSH — las claves DSA ya no se aceptan, y OpenSSH avisa ahora cuando el intercambio de claves no es poscuántico.
- Compose v1 — el paquete
docker-composev1 ya no existe en 26.04; todo script que llame adocker-composecon guion debe pasar adocker compose. - Sincronización horaria — chrony sustituye a systemd-timesyncd en las instalaciones nuevas; en un servidor actualizado el cambio es manual y opcional.
- Repositorios de terceros — cada fuente desactivada debe reescribirse para
resolute, y su clave gestionarse fuera deapt-key.
Cerrar lo que la actualización abrió
Tras el reinicio, compruebe que el demonio de respaldo ha desaparecido (sudo ss -tlnp | grep 1022 no debe devolver nada) y que la regla del cortafuegos se ha retirado. Compare /etc/ssh/sshd_config con sshd_config.dpkg-dist si existe y valide la configuración con sudo sshd -t antes de reiniciar el servicio. Nuestra checklist de bastionado Linux sirve después de control completo.
Resolución de problemas: los mensajes que puede encontrar
«Please install all available updates for your release before upgrading.» El sistema no está totalmente actualizado: vuelva a ejecutar el comando apt dist-upgrade del paso 4, incluida la opción de actualizaciones escalonadas.
«You have not rebooted after updating a package which requires a reboot.» Un núcleo o una biblioteca espera un reinicio. Reinicie y vuelva a lanzar la actualización.
«No new release found.» Compruebe Prompt=lts en /etc/update-manager/release-upgrades. Con Prompt=never, la herramienta lo indica explícitamente y se niega.
«Required apt sources are missing» La herramienta ya no encuentra una fuente de Ubuntu utilizable, a menudo por un espejo propio. Acepte continuar con las fuentes por defecto o corrija la fuente principal antes de volver a lanzarla.
Lista de paquetes ajenos imposible de desplazar. Las notas de versión señalan este defecto en las actualizaciones desde 24.04: cancele, purgue los paquetes ajenos innecesarios y vuelva a lanzarla.
Se cae la conexión SSH. Vuelva a conectarse por el puerto 22 o 1022 y retome la sesión con sudo screen -d -r ubuntu-release-upgrade-screen-window.
Una actualización por VPS, un método para toda la flota
Pasar de 24.04 a 26.04 no es una urgencia: es un proyecto que planificar antes de mayo de 2029, a su ritmo y al de sus clientes. Lo que marca la diferencia no es el comando, que cabe en una línea, sino lo que lo rodea: un inventario, una copia ya restaurada, un ensayo en un clon, una ventana acordada y una vuelta atrás que sabe ejecutar.
Para una agencia, el interés está en convertir este procedimiento en una rutina. Anote los cambios encontrados en el primer clon y se convertirán en el plan de pruebas de los VPS siguientes. Toda la flota termina en una sola base, documentada una sola vez, mantenida hasta mayo de 2031. Esta guía describe el procedimiento; la actualización de versión queda a su cargo, y ServOrbit no la ejecuta en su VPS.
