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 toda la vida útil de la máquina. Fedora publica una nueva versión aproximadamente cada seis meses. Cada versión cuenta con 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. A fecha de 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 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 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. Durante 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 de LTS independiente extiende la mayoría de las versiones a unos cinco años.

Estos son los periodos de soporte publicados, verificados en agosto de 2026, no el 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 hay que instalar ningún plugin previamente. Si proviene de un entorno Debian o Ubuntu, la mayor parte de lo que escribe habitualmente tiene un equivalente directo de apt a dnf, y la actualización de versión que se detalla a continuación es una de las pocas tareas sin un homólogo real. 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 migrar:

sudo dnf system-upgrade download --releasever=44

Esto resuelve la transacción completa y descarga todos los paquetes, sin realizar cambios en el sistema en ejecución. Espere unos 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 en espera. dnf system-upgrade reboot reinicia la máquina para realizar una transacción offline: un arranque mínimo donde la transacción RPM se ejecuta de forma aislada. Funciona así porque reemplazar glibc y systemd bajo servicios en ejecución es la causa de que un sistema quede instalado a medias. Su servidor no estará accesible 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 del 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 lista los paquetes instalados que ya no pertenecen a ningún repositorio habilitado; aquí es donde encontrará los restos de repositorios que no se publicaron 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 acceso será la consola que proporcione su proveedor, ya sea VNC o serie. Confirme que dispone de 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 permanecen 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 podría no existir todavía.

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. Espere unas semanas a que el proveedor publique, que suele ser la decisión correcta. O actualice 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 que dnf elimine paquetes instalados para resolver el conflicto, así que lea la lista de eliminación antes de aceptarla. 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 el plazo

No ocurre nada el mismo día. El fallo aparece la próxima vez que interactúa con el gestor de paquetes. Las versiones que han llegado al fin 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 sigue sirviendo tráfico, lo cual es precisamente lo que hace que esto sea silencioso y peligroso. No recibe actualizaciones de seguridad. Tampoco puede instalar nada, así que el día que se publique un aviso de seguridad para OpenSSH o nginx, no tendrá ninguna 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 requiere realizar el salto de una o dos versiones cada 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 supone el mismo trabajo 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.

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 sobrescribe los valores predeterminados de /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 actualizado dentro de la misma versión. Nunca actualizará Fedora 43 a Fedora 44, ya que una actualización 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 lo que ofrecen las versiones 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 tanto, el software que se compila y ejecuta hoy en Fedora se está probando para 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 llega a 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 nuevas versiones.
• Alguien se encarga de la actualización. Fedora funciona bien 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 las personas que desean Fedora en un servidor buscan dos o tres paquetes actuales, no un sistema operativo actual. Ambos son separables. Utilice una versión LTS o una reconstrucción empresarial como base y, a continuación, obtenga el software nuevo solo donde realmente lo necesite. Una imagen de contenedor le proporciona la nueva versión de la aplicación en un host que nunca tendrá que actualizar para ello (ejecutar Docker en un VPS). Un repositorio del proveedor para el único paquete que le interesa, como PostgreSQL o nginx, actualiza ese elemento y deja la base intacta.

El compromiso es honesto en ambas direcciones. Un contenedor le ofrece un nuevo espacio de usuario sobre el kernel antiguo del host, por lo que no ayuda cuando lo que necesita es 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 la parte que le cuesta una ventana de mantenimiento cada año en Fedora.

Si elige Fedora para un servidor, marque el ciclo en un calendario. Cuando se lanza una versión, espere unas semanas a que los repositorios del proveedor se actualicen, realice una instantánea, actualice y, después, verifique que los servicios hayan vuelto a funcionar. Ese ritmo cuesta aproximadamente una hora al año y funciona. La versión que falla es aquella en la que la actualización solo se recuerda 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 cada seis meses aproximadamente y mantiene el soporte de cada una hasta cuatro semanas después del lanzamiento de la segunda versión posterior. Fedora 44 se lanzó el 28 de abril de 2026 y su fin de vida útil está programado para junio de 2027. Una vez pasada esa fecha, la versión deja de recibir actualizaciones de seguridad y sus paquetes se retiran de los espejos (mirrors) para pasar al 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 precisamente 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 en el nombre de un paquete o 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 realizar una cadena de actualizaciones.

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

El servidor sigue funcionando pero deja de recibir parches. El siguiente dnf upgrade fallará con un error 404 en la URL del metalink para su versión, ya que las versiones fuera de soporte 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 sobre una versión con soporte. Hasta que realice una de estas dos acciones, 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 opción razonable si existe una justificación. 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 tenga una vida útil corta por diseño. Elija una distribución LTS o una reconstrucción empresarial cuando desee aplicar parches a un servidor durante años sin cambiar su versión.