Ciclo de vida de Fedora Server: actualizar cada 13 meses

¿Durante cuánto tiempo recibe actualizaciones de seguridad una versión de Fedora?

Un servidor Fedora requiere una actualización de versión aproximadamente una vez al año, durante todo el tiempo que la máquina exista. Fedora publica una nueva versión aproximadamente cada seis meses. Cada versión recibe soporte hasta unas cuatro semanas después del lanzamiento de la versión posterior a la siguiente, lo que equivale a unos 13 meses de actualizaciones. Después de esa fecha, la versión deja de recibir correcciones de seguridad. El equipo sigue funcionando, pero con un conjunto de paquetes que nadie parchea.

Las fechas concretan este ciclo. En agosto de 2026, las versiones con soporte son Fedora 43 y Fedora 44. Fedora 44 se lanzó el 28 de abril de 2026 y su fin de vida útil está programado para junio de 2027. Fedora 42 se lanzó en abril de 2025 y alcanzó su fin de vida útil en mayo de 2026, cuatro semanas después de la llegada de Fedora 44. Por lo tanto, un servidor creado a partir de una imagen de Fedora 42 quedó sin soporte trece meses después, sin que se hubiera cometido ningún error.

Fedora frente a una LTS, en meses

LTS significa soporte a largo plazo: una versión que el proveedor mantiene con parches durante años en lugar de meses. EOL significa fin de vida útil, la fecha en la que cesan los parches. A continuación se detalla lo que cada proyecto publica para la versión que usted instalaría hoy.

[
  {
    "distro": "Fedora 44",
    "support_window": 13,
    "upgrades_per_decade": 10
  },
  {
    "distro": "Ubuntu 26.04 LTS",
    "support_window": 60,
    "upgrades_per_decade": 2
  },
  {
    "distro": "Debian 13 stable",
    "support_window": 36,
    "upgrades_per_decade": 3
  },
  {
    "distro": "AlmaLinux 10",
    "support_window": 120,
    "upgrades_per_decade": 1
  }
]

Fedora le ofrece 13 meses por versión. Una Ubuntu LTS ofrece 60, y una reconstrucción empresarial como AlmaLinux ofrece 120. Lea la segunda columna como la factura. En diez años, Fedora requiere aproximadamente 10 actualizaciones de todo el sistema operativo, frente a 2 en la Ubuntu LTS. La cifra de 36 meses de Debian corresponde a su soporte de seguridad regular, y un equipo LTS independiente extiende la mayoría de las versiones a unos cinco años.

Estos son periodos de soporte publicados, verificados en agosto de 2026, no tiempo de actividad medido. El motivo por el que las cadencias difieren pertenece a la diferencia entre Ubuntu LTS y las versiones intermedias en un servidor. Lo que importa aquí es el trabajo que cada una genera para usted.

En qué consiste realmente una actualización de versión de Fedora

DNF 5 es el gestor de paquetes predeterminado desde Fedora 41, y dnf lo ejecuta. El comando system-upgrade forma parte del propio dnf5, por lo que no es necesario instalar ningún plugin previamente. Comience desde la versión actual, completamente actualizada:

sudo dnf upgrade --refresh
sudo reboot

El reinicio es importante porque la actualización se resuelve en función de lo que está instalado y en ejecución; un kernel o una actualización de glibc aplicados a medias dificultan el diagnóstico del siguiente paso. Ahora, prepare la nueva versión. Sustituya 44 por la versión a la que desea actualizar:

sudo dnf system-upgrade download --releasever=44

Esto resuelve toda la transacción, descarga todos los paquetes y no modifica nada en el sistema en ejecución. Espere unos cuantos miles de paquetes y entre uno y tres gigabytes en un servidor pequeño. Si dnf no puede resolver la transacción, se detiene aquí e indica el paquete que la bloqueó. Este es el escenario ideal, ya que el fallo ocurre mientras la máquina sigue activa y usted aún dispone de una shell.

A continuación, ejecútelo:

sudo dnf offline status
sudo dnf system-upgrade reboot

dnf offline status confirma que hay una transacción preparada y pendiente. dnf system-upgrade reboot reinicia la máquina para realizar una transacción offline: un arranque mínimo donde la transacción de RPM se ejecuta por sí sola. Funciona de este modo porque reemplazar glibc y systemd bajo servicios en ejecución es la forma en que se obtiene un sistema instalado a medias. Su servidor no estará disponible durante toda la transacción, generalmente varios minutos en un VPS pequeño, y luego se reiniciará de nuevo en la nueva versión. Planifique dos reinicios y un periodo en el que SSH no responderá.

Cuando vuelva a estar disponible:

cat /etc/fedora-release
sudo dnf system-upgrade log --number=-1
sudo dnf distro-sync
sudo dnf repoquery --extras

/etc/fedora-release debería mostrar una línea como Fedora release 44 (Forty Four). El subcomando log imprime el registro de la transacción de ese arranque offline, que es el único historial de lo que ocurrió mientras no tenía acceso a la shell. distro-sync actualiza cualquier elemento pendiente a las versiones de la nueva distribución. repoquery --extras enumera los paquetes instalados que ya no están en ningún repositorio habilitado; aquí es donde encontrará los restos de un repositorio que nunca se publicó para la nueva versión.

Realice una instantánea del disco antes del paso de descarga. La transacción se ejecuta mientras usted no puede ver la pantalla, por lo que si falla durante el arranque offline, SSH no volverá y su única forma de acceder será a través de la consola que le proporcione su proveedor, ya sea VNC o serie. Asegúrese de tener acceso a una consola o una instantánea antes de empezar, no después.

Una comprobación más que la gente suele omitir:

sudo find /etc -name '*.rpmnew' -o -name '*.rpmsave'

Cuando un paquete incluye un nuevo archivo de configuración predeterminado y usted ha editado el anterior, RPM no sobrescribe su archivo. Escribe la versión del paquete junto a él como .rpmnew. Por lo tanto, su sshd o nginx seguirá comportándose exactamente igual que en la versión anterior, mientras que los nuevos valores predeterminados permanecerán sin leer en el disco. Lea esos archivos después de cada actualización. Instalar rpmconf y ejecutar sudo rpmconf -a le permitirá revisarlos uno a uno y ver las diferencias.

Los repositorios de terceros son los que interrumpen la actualización

Los paquetes propios de Fedora se mueven al unísono el día del lanzamiento. Cualquier elemento externo a Fedora sigue su propio calendario. La mayoría de los repositorios de proveedores incluyen $releasever en su URL, por lo que en el momento en que actualiza, dnf comienza a solicitar una ruta que quizás aún no exista.

Enumere lo que tiene:

sudo dnf repo list --enabled
grep -R -e baseurl -e metalink /etc/yum.repos.d/

Para cada repositorio que no sea de Fedora, pruébelo contra la versión de destino antes de confirmar cualquier acción:

sudo dnf --releasever=44 --repo=docker-ce-stable makecache

Si el proveedor ha publicado para esa versión, dnf descarga los metadatos y finaliza silenciosamente. Si no, obtendrá un error 404 para una ruta como https://download.docker.com/linux/fedora/44/x86_64/stable/repodata/repomd.xml, y el mismo fallo detendrá system-upgrade download más adelante. En las primeras semanas tras un lanzamiento de Fedora, esta es la razón más común por la que una actualización no comienza.

Tiene dos opciones. Esperar unas semanas a que el proveedor publique, que suele ser la decisión correcta. O actualizar sin ese repositorio:

sudo dnf system-upgrade download --releasever=44 --disable-repo=docker-ce-stable

Deshabilitar un repositorio no elimina sus paquetes. Permanecen instalados y sin gestionar, y si bloquean la transacción, dnf lo notificará. Añadir --allowerasing permite a dnf eliminar paquetes instalados para resolver el conflicto, así que lea la lista de eliminación antes de aceptarla. En esa lista es donde los usuarios pierden un servidor de base de datos que pretendían conservar.

Qué sucede con un servidor Fedora que pierde su ventana de soporte

No ocurre nada el día exacto del vencimiento. El fallo aparece la próxima vez que interactúa con el gestor de paquetes. Las versiones al final de su vida útil se retiran de la red de réplicas y se trasladan al archivo, por lo que dnf upgrade falla al intentar obtener los metadatos, devolviendo un error 404 en la URL del metalink de su versión:

Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=fedora-42&arch=x86_64

La máquina continúa sirviendo tráfico, lo cual es precisamente lo que hace que esta situación sea silenciosa y peligrosa. No recibe actualizaciones de seguridad. Tampoco puede instalar nada, por lo que el día que se publique un aviso de seguridad para OpenSSH o nginx, no tendrá una forma soportada de aplicar el parche.

Salir de esta situación es posible pero lento. Puede redirigir los repositorios al archivo de Fedora en https://dl.fedoraproject.org/pub/archive/fedora/linux/ y actualizar desde allí. Fedora espera realizar saltos de una o dos versiones a la vez, por lo que un equipo con cuatro versiones de retraso implica varios saltos consecutivos, cada uno con su propia probabilidad de fallo y ejecutándose a ciegas en un arranque sin conexión. En un VPS, reconstruir sobre una imagen actual y migrar los datos suele ser la tarea más corta y segura, y requiere el mismo esfuerzo que los primeros diez minutos en un VPS nuevo.

Las actualizaciones automáticas aplican parches a una versión. Nunca realizan una actualización de versión (upgrade).

Fedora puede instalar sus actualizaciones mediante un temporizador:

sudo dnf install -y dnf5-plugin-automatic
sudo systemctl enable --now dnf5-automatic.timer

Los ajustes residen en /etc/dnf/automatic.conf, que prevalece sobre los valores predeterminados de fábrica en /usr/share/dnf5/dnf5-plugins/automatic.conf. apply_updates está desactivado por defecto, por lo que, tras la instalación inicial, el temporizador descarga las actualizaciones pero no instala nada. upgrade_type permite elegir entre default y security. reboot acepta never, when-changed o when-needed.

Esto mantiene el sistema al día dentro de la misma versión. Nunca actualizará Fedora 43 a Fedora 44, ya que el cambio de versión es una operación independiente y deliberada que requiere reiniciar en una transacción fuera de línea. Esa es la diferencia práctica frente a una versión LTS. En Ubuntu, las actualizaciones de seguridad desatendidas mantienen una máquina durante todo el ciclo de cinco años sin cambiar de versión, y el cambio de versión en sí es una tarea planificada, como la actualización de 24.04 a 26.04 que ocurre cada pocos años.

Cuándo Fedora es la opción adecuada para un servidor

Fedora es una buena elección cuando la novedad es el objetivo principal.

• Necesita un kernel o un espacio de usuario más reciente que cualquier versión LTS: hardware reciente, o una pila de contenedores y systemd que aún tardará un año en llegar a una versión empresarial. Fedora también actualiza a nuevos kernels upstream durante el ciclo de vida de una versión, por lo que no es solo una ventaja puntual durante la instalación.
• Está validando lo que se integrará en RHEL (Red Hat Enterprise Linux). Fedora alimenta a CentOS Stream, que a su vez alimenta a RHEL, por lo que el software que se compila y ejecuta en Fedora hoy se está probando contra la plataforma empresarial de dentro de un par de años.
• La máquina tiene una vida útil corta por diseño. Un ejecutor de compilaciones o un equipo de pruebas que se destruye en dos meses nunca alcanza su fecha de fin de vida útil. La misma lógica se aplica a máquinas virtuales desechables que entrega a agentes de programación, donde el equipo se reconstruye con mucha más frecuencia de lo que Fedora lanza versiones.
• Alguien se encarga de la actualización. Fedora es adecuada en un servidor con un responsable asignado y una entrada en el calendario. Es una mala opción para el equipo que todos han olvidado.

El camino intermedio: paquetes actuales sobre una base estable

La mayoría de los usuarios que desean Fedora en un servidor buscan dos o tres paquetes actuales, no un sistema operativo actual. Ambos aspectos son separables. Utilice una distribución LTS o una reconstrucción empresarial como base y, a continuación, incorpore el software nuevo solo donde realmente lo necesite. Una imagen de contenedor le proporciona la versión nueva de la aplicación en un host que nunca tendrá que actualizar para ese fin (ejecutar Docker en un VPS). Un repositorio del proveedor para el paquete específico que le interesa, como PostgreSQL o nginx, actualiza ese componente y deja intacta la base.

El compromiso es transparente en ambos sentidos. Un contenedor le ofrece un espacio de usuario nuevo sobre el kernel antiguo del host, por lo que no resulta útil si lo que necesita es precisamente el kernel. Un repositorio del proveedor le proporciona un paquete nuevo sobre una base que el proveedor ha probado menos. Ambos dejan las actualizaciones de seguridad del sistema base bajo el ciclo de vida LTS, y ese ciclo es el que le obliga a programar una ventana de mantenimiento anual en Fedora.

Si decide utilizar Fedora para un servidor, marque el ciclo en su calendario. Cuando se lanza una versión, espere unas semanas a que los repositorios del proveedor se actualicen, realice una instantánea, ejecute la actualización y verifique que los servicios se hayan restablecido. Ese ritmo requiere aproximadamente una hora al año y funciona. La versión que falla es aquella en la que la actualización se recuerda solo porque algo ya se ha roto.

FAQ

¿Cuánto tiempo tiene soporte una versión de Fedora?

Aproximadamente 13 meses. Fedora publica una versión aproximadamente cada seis meses y da soporte a cada una hasta unas cuatro semanas después del lanzamiento de la versión posterior a la siguiente. Fedora 44 se lanzó el 28 de abril de 2026 y su fin de vida útil está programado para junio de 2027. Cuando pasa esa fecha, la versión deja de recibir actualizaciones de seguridad y sus paquetes se retiran de los espejos hacia el archivo de Fedora.

¿Puedo saltarme una versión de Fedora y actualizar dos versiones a la vez?

Sí, dentro de ciertos límites. dnf system-upgrade download --releasever= acepta un objetivo una o dos versiones por delante, y saltar de dos en dos es exactamente cómo funciona un ritmo de actualización anual. Ir más allá no es una ruta soportada, y cada versión adicional aumenta la probabilidad de que un cambio de nombre de paquete o un cambio en el formato de configuración detenga la transacción. Si una máquina ya tiene varias versiones de retraso y ha superado su fin de vida útil, reconstruirla sobre una imagen actual suele ser más rápido que una cadena de actualizaciones.

¿Qué sucede si mi servidor Fedora llega al fin de su vida útil?

Sigue funcionando pero deja de recibir parches. El siguiente dnf upgrade falla con un error 404 en la URL del metalink para su versión, porque las versiones al final de su vida útil se mueven al archivo en dl.fedoraproject.org. Puede redirigir los archivos de repositorio a ese archivo y actualizar por saltos, o reconstruir el servidor en una versión con soporte. Hasta que haga una de estas dos cosas, ninguna actualización de seguridad podrá llegar a la máquina y no se instalará ningún paquete.

¿Es Fedora una mala elección para un servidor de producción?

Es una mala elección por defecto y una elección razonable si hay un motivo. El coste es una actualización completa del sistema operativo cada año, de forma indefinida, en una máquina que quizás prefiera no tocar. Elija Fedora cuando necesite un kernel o un espacio de usuario más reciente de lo que ofrece una versión LTS, o cuando el servidor sea de corta duración por diseño. Elija una versión LTS o una reconstrucción empresarial cuando desee aplicar parches a un servidor durante años sin cambiar su versión.