Qué termina en mayo-junio de 2027
Ubuntu 22.04 LTS salió en abril de 2022. Su mantenimiento de seguridad estándar termina en mayo de 2027 según la página ubuntu.com/about/release-cycle, y endoflife.date da el 1 de junio de 2027 para el mismo hito. Escriba «mayo-junio de 2027» en sus planificaciones y apunte al comienzo de la ventana, no a su último día.
Pasada esa fecha, un fallo corregido por Canonical ya no se corrige para usted, salvo suscripción a Ubuntu Pro, que prolonga el mantenimiento de seguridad hasta 2032 (el mes exacto varía según la fuente: abril para endoflife.date, mayo para ubuntu.com, de ahí que se indique solo el año). El coste real de la migración no es la licencia, es el tiempo: una ventana de intervención, un clon de prueba y una validación sitio por sitio.
Para un parque de servidores, el plazo se lee en tres columnas: cuántos servidores siguen en 22.04, cuáles llevan cPanel y cuáles son simples VPS de aplicaciones. Cada columna tiene su procedimiento. El calendario completo de fines de vida de 2027 está en nuestro calendario de fines de vida 2027: aquí solo tratamos esa línea.
Qué le permite hacer esta guía
- Fechar el plazo sin equivocarse — mayo de 2027 para Canonical, 1 de junio de 2027 para endoflife.date: se planifica antes de la ventana.
- Decidir cliente por cliente — actualización in situ, ELevate o servidor nuevo, con criterios medibles y no por costumbre.
- Saber qué impone cPanel — obsolescencia en la versión 132, retirada en la versión 136, y por qué
do-release-upgradeno se lanza a mano en un servidor cPanel. - Disponer de una red de seguridad real — una imagen del servidor ya restaurada una vez, no una promesa de copia.
- Anticipar las roturas — repositorios de terceros desactivados, PHP, nginx, SSH, paquetes retirados durante la actualización.
- Conservar una marcha atrás — un punto de no retorno con nombre y una restauración planificada antes de pulsar Intro.
cPanel & WHM: 22.04 obsoleto en la 132, retirado en la 136
La página «deprecation plan» de la documentación de cPanel clasifica Ubuntu 22.04 LTS entre las funciones obsoletas y luego retiradas: obsolescencia en la versión 132, retirada en la versión 136, con la indicación «Use ELevate to upgrade to Ubuntu 24.04 LTS». La página no da ninguna fecha de lanzamiento para esas versiones y no adelantamos ninguna: siga el calendario de versiones de cPanel en lugar de una fecha leída en un sitio de terceros. Tampoco dice si una actualización in situ al margen de ELevate es compatible.
Por el lado de ELevate, la consigna es clara: la herramienta envuelve do-release-upgrade porque lanzar la herramienta de la distribución directamente sobre una instalación de cPanel la deja inservible. En un servidor cPanel, la documentación de cPanel indica ELevate; la otra vía es un servidor nuevo con 24.04 al que se transfieren las cuentas. Un VPS de aplicaciones sin panel sigue el procedimiento estándar de Ubuntu.
Actualizar in situ o servidor nuevo: el criterio de decisión
La actualización in situ conserva la dirección IP, las cuentas y la configuración. Falla donde el servidor se ha alejado de una instalación estándar. El servidor nuevo cuesta una transferencia de cuentas, pero deja intacta la máquina antigua hasta el cambio de DNS: es el único escenario en el que la marcha atrás consiste simplemente en no cambiar.
Decida con cuatro preguntas. ¿Su copia cubre todo el sistema? Las copias de cuentas de cPanel solo protegen los datos que gestiona cPanel, no los programas ni los ajustes del sistema: tras un fallo habría que reinstalar el sistema operativo y cPanel, y luego restaurar las cuentas. ¿Cuánta interrupción acepta el cliente? ELevate puede superar los 30 minutos y reinicia el servidor varias veces. ¿Cuántas personalizaciones viven fuera de los paquetes (repositorios de terceros, PHP compilado a mano, scripts)? Cada una es una incógnita durante la actualización. Por último, ¿está el servidor descrito en código, con Ansible u otra herramienta? Si es así, reconstruirlo es más rápido que repararlo.
Regla práctica: servidor histórico, muy personalizado o cuya copia nunca se ha restaurado, servidor nuevo. Servidor estándar, imagen restaurada con éxito y ventana aceptada, actualización in situ.
Qué vía para qué servidor
Desplace la tabla
| Situación del servidor | Vía recomendada | Por qué |
|---|---|---|
| VPS de aplicaciones en 22.04, sin panel, pocos repositorios de terceros | Actualización in situ con `do-release-upgrade` | Procedimiento estándar de Ubuntu, marcha atrás restaurando la imagen |
| VPS de aplicaciones descrito en código (Ansible, Compose) | Servidor nuevo con 24.04 | Reconstruir cuesta menos que reparar; el antiguo queda intacto hasta el cambio |
| Servidor cPanel estándar, imagen del sistema restaurable | Actualización in situ con ELevate | Actualización in situ con ELevate, la herramienta que indica la documentación de cPanel, con detección de bloqueos antes de empezar |
| Servidor cPanel muy personalizado o copia nunca restaurada | Servidor nuevo y transferencia de cuentas | Las copias de cuentas no cubren el sistema; la transferencia deja intacto el origen |
| Sitios con PHP anterior a 8.1 en el servidor cPanel | Servidor nuevo, o migrar antes los sitios | ELevate se bloquea si un usuario emplea una versión de PHP demasiado antigua |
| Servidor en un entorno de tipo contenedor | Servidor nuevo | ELevate se niega a ejecutarse en un entorno de tipo contenedor |
Requisitos con cifras antes de lanzar nada
Para un VPS estándar, la documentación de Ubuntu pide un sistema totalmente actualizado, espacio para varios gigabytes de descarga y una persona presente: la actualización es interactiva y puede durar varias horas. Prevea una consola fuera de banda (consola web o VNC del proveedor) por si SSH no vuelve.
Para un servidor cPanel, ELevate publica sus umbrales de espacio libre: 5 GB en /, 120 MB en /boot, 750 MB en /tmp para Ubuntu, 1,5 GB en /usr/local/cpanel y 5 GB en /var/lib. Exige acceso root interactivo, una licencia de cPanel válida, la última versión menor de la versión de cPanel esperada para su sistema (la documentación de ELevate pide la versión 134 partiendo de Ubuntu 22: relea ese requisito el día de la intervención) y JetBackup 5 o posterior si lo usa. Ni upcp ni una copia de cPanel deben estar ejecutándose al arrancar. Y prevea varios accesos al servidor: SSH, consola del proveedor y, si es posible, IPMI.
Procedimiento para un VPS de aplicaciones, sin panel
Hacer el inventario
Anote la versión del sistema con
lsb_release -a, las fuentes APT de terceros conls /etc/apt/sources.list.d/, y luego las versiones de lo que sirve sus sitios:php -v,nginx -v,mysql --version. Esa lista se convierte en su plan de pruebas.Copiar y restaurar una vez
Haga una imagen del VPS en el proveedor y restáurela en una máquina de prueba: una copia que nunca se ha restaurado es una hipótesis. Refuércela con una copia fuera del servidor de las bases de datos, los volúmenes y
/etc. Nuestra guía de copias de seguridad con Restic en un VPS detalla la puesta en marcha.Actualizar primero un clon
Cree un VPS de prueba a partir de la imagen y ejecute en él todo el procedimiento. Anote cada pregunta de la herramienta, cada servicio que falle y cada repositorio desactivado. La actualización de producción ya no debe deparar sorpresas.
Dejar 22.04 totalmente actualizada
Ejecute
sudo apt updatey luegosudo apt dist-upgrade -o APT::Get::Always-Include-Phased-Updates=true, como prescribe la documentación de Ubuntu Server. Si existe el archivo/run/reboot-required, reinicie antes de continuar.Abrir una sesión que sobreviva a una desconexión
Ejecute
tmux new -s actualizacion(oscreen) antes de la actualización, para que perder la conexión SSH no interrumpa el trabajo en curso. Mantenga abierta la consola del proveedor en otra pestaña.Lanzar la actualización
Compruebe primero que se ofrece una versión con
do-release-upgrade -cy después ejecutesudo do-release-upgrade. La herramienta resume lo que va a hacer y pide confirmación. Aviso de la documentación: una vez terminada la descarga, el proceso ya no se puede cancelar. Es su punto de no retorno, y a partir de ahí la marcha atrás es restaurar la imagen.Responder, reiniciar, reactivar
Para cada archivo de configuración que haya modificado, conserve su versión, que es la opción por defecto, salvo los archivos necesarios para arrancar el nuevo kernel. Reinicie cuando la herramienta lo pida, porque el sistema no se considera actualizado hasta ese reinicio. Reactive después los repositorios de terceros desactivados, reescribiéndolos para 24.04, y repita su plan de pruebas.
Procedimiento para un servidor cPanel con ELevate
Verificar el punto de partida
Compruebe la licencia de cPanel, la versión de cPanel & WHM que espera la documentación de ELevate y la última versión menor instalada. Actualice los paquetes del sistema con
apt upgrade. Verifique que la versión de MySQL o MariaDB es compatible con Ubuntu 24.04.Tomar una imagen completa del servidor
ELevate no hace ninguna copia antes de actualizar. Haga una instantánea del servidor entero y pruebe su restauración: es la única marcha atrás que describe la documentación de ELevate ante un fallo grave.
Descargar el script
Ejecute
wget -O /scripts/elevate-cpanel https://raw.githubusercontent.com/cpanel/elevate/release/elevate-cpanely luegochmod 700 /scripts/elevate-cpanel. El script debe ejecutarse desde/scriptsy estar al día.Lanzar la comprobación en seco
/scripts/elevate-cpanel --checkno modifica nada y lista los bloqueos conocidos: espacio en disco, archivosshd_config, PHP demasiado antiguo, una versión de JetBackup anterior a la 5, entorno de contenedor, nombres de interfaz de red enethX. Repítala hasta obtener un informe vacío.Levantar los bloqueos uno a uno
Retire o migre los sitios que usan una versión de PHP anterior a 8.1, deje que
upcpy las copias terminen, libere espacio. Si cPanel gestiona su MySQL, la herramienta propone pasar a MariaDB durante la actualización: decídalo con el cliente, antes de la ventana.Arrancar y vigilar
Ejecute
/scripts/elevate-cpanel --start. El proceso avanza en cinco etapas con un reinicio entre cada una y otro al final, con más de 30 minutos de servidor inaccesible. Siga su avance con/scripts/elevate-cpanel --statusy/scripts/elevate-cpanel --log. Si el proceso se detiene por un error, corríjalo y ejecute/scripts/elevate-cpanel --continue.Validar tras la actualización
Abra WHM y compruebe los servicios, los sitios de cada cuenta, el envío y la recepción de correo y las tareas programadas. Pruebe los sitios con el PHP que usan realmente, no solo su página de inicio.
Qué se rompe entre 22.04 y 24.04, según las notas de versión
Este apartado recoge las notas de versión de Ubuntu 24.04 LTS, no una prueba nuestra sobre su pila. Primero, los repositorios de terceros y los PPA se desactivan durante la actualización, lo que deja Docker, PHP o un agente de supervisión en la fuente antigua hasta que se reescriba. Las fuentes de Ubuntu pasan al formato deb822, en /etc/apt/sources.list.d/ubuntu.sources.
En el lado web, nginx pasa a la versión 1.24 (la LTS anterior traía la 1.18), Apache a la 2.4.58 y PHP a la 8.3.6, donde 22.04 ofrece PHP 8.1. Un sitio que dependa de una función retirada entre esas versiones de PHP se descubre en la ejecución, no en la actualización. Python 3.12 pasa a ser el valor por defecto, lo que afecta a sus scripts de administración.
En cuanto a las conexiones, los ajustes de sshd_config los lee ahora un generador de systemd que gobierna la unidad ssh.socket: compruebe el puerto de escucha tras la actualización. needrestart reinicia los servicios afectados por una actualización de biblioteca, también durante las actualizaciones automáticas. TLS 1.0, TLS 1.1 y DTLS 1.0 quedan desactivados a la fuerza, lo que puede dejar sin servicio a un cliente de correo antiguo. Por último, la herramienta de actualización elimina el paquete freeradius sin que aparezca siempre en el resumen.
Qué probar en el clon antes de la ventana del cliente
- Repositorios de terceros — cada fuente desactivada debe reactivarse para 24.04, con su clave gestionada sin
apt-key. - Sitios PHP — repita las páginas críticas de cada sitio con PHP 8.3: formularios, pago, tareas programadas.
- nginx y Apache — ejecute
nginx -ttras la actualización y compare los vhosts, los módulos y las redirecciones. - SSH — compruebe el puerto y el acceso por clave con una segunda sesión abierta antes de cerrar la primera.
- Correo — envíe y reciba, incluso desde un cliente antiguo que TLS 1.0 o 1.1 haría fallar.
- Paquetes retirados — compare
apt list --installedantes y después para detectar un paquete desaparecido, comofreeradius. - Tareas programadas y copias — una copia que falla en silencio tras la actualización es la avería más cara.
Escribir la marcha atrás antes de la ventana
Anote por escrito, antes de actuar, quién restaura la imagen, cuánto tarda y a partir de qué síntoma se renuncia. La restauración es la única marcha atrás una vez superado el punto de no retorno: fije el umbral en frío, no a las 2 de la madrugada. Prefiera una ventana en la que el cliente pueda validar a la mañana siguiente.
Después de 24.04: el camino a 26.04 pasa por aquí
La documentación de Ubuntu prohíbe saltarse una LTS: se pasa de una LTS a la siguiente, y la actualización de 22.04 a 24.04 es, por tanto, la etapa obligatoria antes de 26.04. Ubuntu 24.04 sigue con mantenimiento de seguridad estándar hasta mayo de 2029: una vez actualizados, sus servidores dejan de ser urgentes. La actualización de 24.04 a 26.04.1 está abierta desde el 29 de septiembre de 2026, lo que le deja elegir el momento; se detalla en nuestra guía Ubuntu 24.04 a 26.04 en un VPS.
El mismo razonamiento, con otro panel, está en nuestra guía Debian 11 fin de vida con Plesk. Para un parque de servidores, agrupe por cliente: una ventana de intervención que trata sistema, PHP y base de datos cuesta menos que tres visitas.
