Por quanto tempo o Fedora Server recebe atualizações?

Quanto tempo uma versão do Fedora recebe atualizações de segurança?

Um servidor Fedora precisa de uma atualização de versão aproximadamente uma vez por ano, enquanto a máquina existir. O Fedora publica uma nova versão aproximadamente a cada seis meses. Cada versão recebe suporte até cerca de quatro semanas depois do lançamento da versão dois ciclos à frente. Isso corresponde a aproximadamente 13 meses de atualizações. Depois dessa data, a versão deixa de receber correções de segurança. O servidor continua a funcionar, mas com um conjunto de pacotes que já não recebe correções.

As datas tornam isto concreto. Em agosto de 2026, as versões suportadas são Fedora 43 e Fedora 44. O Fedora 44 foi lançado em 28 de abril de 2026, e o fim de vida está previsto para junho de 2027. O Fedora 42 foi lançado em abril de 2025 e chegou ao fim de vida em maio de 2026, quatro semanas depois da chegada do Fedora 44. Portanto, um servidor criado a partir de uma imagem Fedora 42 ficou sem suporte treze meses depois, sem que ninguém tivesse feito nada de errado.

Fedora versus uma versão LTS, em meses

LTS significa suporte de longo prazo: uma versão que o fornecedor continua a corrigir durante anos, e não apenas meses. EOL significa fim de vida, a data em que as correções deixam de ser publicadas. Estes são os prazos publicados por cada projeto para a versão que instalaria hoje.

[
  {
    "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
  }
]

O Fedora oferece 13 meses de suporte por versão. Uma versão Ubuntu LTS oferece 60, e uma reconstrução empresarial como o AlmaLinux oferece 120. Leia a segunda coluna como o custo operacional. Ao longo de dez anos, o Fedora exige aproximadamente 10 atualizações de todo o sistema operativo, contra 2 no Ubuntu LTS. O valor de 36 meses do Debian corresponde ao seu suporte de segurança regular, e uma equipa LTS separada prolonga a maioria das versões para cerca de cinco anos.

Estes são períodos de suporte publicados, verificados em agosto de 2026, e não uma medição de disponibilidade. A razão para as cadências serem diferentes é explicada em a diferença entre o Ubuntu LTS e as versões intermédias num servidor. O que importa aqui é o trabalho que cada opção cria para si.

O que uma atualização de versão do Fedora realmente envolve

O DNF 5 é o gestor de pacotes predefinido desde o Fedora 41, e dnf executa-o. O comando system-upgrade faz parte do próprio dnf5, por isso não é necessário instalar primeiro nenhum plugin. Se está a migrar de um servidor Debian ou Ubuntu, a maior parte dos comandos usados no dia a dia tem um equivalente direto de apt para dnf, e a atualização de versão abaixo é uma das poucas tarefas sem um equivalente real. Comece pela versão atual, totalmente atualizada:

sudo dnf upgrade --refresh
sudo reboot

O reboot é importante porque a atualização é resolvida com base no que está instalado e em execução. Por isso, uma atualização do kernel ou da glibc aplicada apenas parcialmente torna o passo seguinte mais difícil de analisar. Agora prepare a nova versão. Substitua 44 pela versão para a qual vai migrar:

sudo dnf system-upgrade download --releasever=44

Isto resolve toda a transação e transfere todos os pacotes, sem alterar o sistema em execução. Conte com alguns milhares de pacotes e entre um e três gigabytes num servidor pequeno. Se o dnf não conseguir resolver a transação, para neste ponto e indica o pacote que a bloqueou. Esse é o cenário preferível, porque a falha ocorre enquanto a máquina ainda está disponível e ainda tem uma shell.

Depois, execute-a:

sudo dnf offline status
sudo dnf system-upgrade reboot

dnf offline status confirma que uma transação está preparada e à espera. dnf system-upgrade reboot reinicia a máquina numa transação offline: um boot mínimo em que a transação RPM é executada de forma autónoma. Isto funciona assim porque substituir a glibc e o systemd enquanto os serviços estão em execução pode deixar o sistema instalado apenas parcialmente. O servidor fica inacessível durante toda a transação, normalmente durante vários minutos num VPS pequeno, e depois reinicia novamente com a nova versão. Planeie dois reboots e um período em que o SSH não responde.

Quando o sistema voltar:

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

/etc/fedora-release deverá apresentar uma linha semelhante a Fedora release 44 (Forty Four). O subcomando log apresenta o log da transação desse boot offline. Esse é o único registo do que aconteceu enquanto não tinha uma shell. distro-sync instala na nova versão os pacotes que tenham ficado para trás. repoquery --extras lista os pacotes instalados que já não estão em nenhum repositório ativado. É aí que encontra restos de um repositório que nunca publicou pacotes para a nova versão.

Crie um snapshot do disco antes do passo de transferência. A transação é executada enquanto não consegue ver o ecrã. Se falhar durante o boot offline, o SSH não voltará a responder e a única forma de acesso será a consola disponibilizada pelo fornecedor, VNC ou serial. Confirme que tem acesso a uma consola ou a um snapshot antes de começar, não depois.

Há ainda uma verificação que muitas pessoas ignoram:

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

Quando um pacote fornece um novo ficheiro de configuração predefinido e editou o ficheiro antigo, o RPM não substitui o seu ficheiro. Em vez disso, grava a versão fornecida pelo pacote ao lado dele como .rpmnew. Assim, o sshd ou o nginx continua a comportar-se exatamente como na versão antiga, enquanto as novas predefinições ficam no disco sem serem utilizadas. Leia esses ficheiros depois de cada atualização. Instalar rpmconf e executar sudo rpmconf -a apresenta-os um de cada vez e mostra as diferenças.

Os repositórios de terceiros são o que impede a atualização

Os pacotes da própria Fedora avançam em conjunto no dia do lançamento. Tudo o que vem de fora da Fedora segue o calendário de outra entidade. A maioria dos repositórios de fornecedores inclui $releasever no URL. Por isso, assim que atualiza, o dnf começa a procurar um caminho que pode ainda não existir.

Liste os repositórios configurados:

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

Para cada repositório que não pertença à Fedora, teste-o contra a versão de destino antes de iniciar qualquer alteração:

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

Se o fornecedor já publicou pacotes para essa versão, o dnf transfere os metadados e termina sem apresentar mensagens. Caso contrário, recebe um erro 404 para um caminho como https://download.docker.com/linux/fedora/44/x86_64/stable/repodata/repomd.xml, e a mesma falha interromperá system-upgrade download mais tarde. Nas primeiras semanas após o lançamento de uma versão da Fedora, esta é a causa mais comum para uma atualização não começar.

Há duas opções. Aguarde algumas semanas até o fornecedor publicar os pacotes. Normalmente, esta é a opção correta. Em alternativa, atualize sem esse repositório:

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

Desativar um repositório não remove os respetivos pacotes. Eles continuam instalados e sem gestão por um repositório. Se bloquearem a transação, o dnf informa-o. Adicionar --allowerasing permite ao dnf remover pacotes instalados para resolver o conflito. Por isso, leia a lista de remoções antes de a aceitar. É nessa lista que alguém pode perder um servidor de base de dados que pretendia manter.

O que acontece a um servidor Fedora que perde a janela

Nada acontece no próprio dia. A falha surge na próxima vez que utilizar o gestor de pacotes. As releases em fim de vida são retiradas da rede de mirrors e movidas para o arquivo, por isso dnf upgrade falha ao obter os metadados, com um erro 404 no URL do metalink da sua release:

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

A máquina continua a servir tráfego, o que torna o problema silencioso e perigoso. Não recebe atualizações de segurança. Também não consegue instalar nada. Assim, no dia em que surgir um aviso de segurança para OpenSSH ou nginx, não terá uma forma suportada de aplicar a correção.

É possível recuperar, mas o processo é lento. Pode apontar os repositórios para o arquivo do Fedora em https://dl.fedoraproject.org/pub/archive/fedora/linux/ e atualizar a partir daí. O Fedora pressupõe um salto de uma ou duas releases de cada vez. Assim, uma máquina com quatro releases de atraso exige vários saltos consecutivos. Cada salto tem a sua própria possibilidade de falhar e é executado sem visibilidade durante um boot offline. Num VPS, recriar a máquina com uma imagem atual e transferir os dados costuma ser uma tarefa mais curta e segura. É o mesmo trabalho que os primeiros dez minutos num VPS novo.

As atualizações automáticas corrigem uma versão. Nunca fazem a atualização para outra versão.

O Fedora pode instalar as atualizações com um temporizador:

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

As definições estão em /etc/dnf/automatic.conf, que substitui os valores predefinidos fornecidos em /usr/share/dnf5/dnf5-plugins/automatic.conf. apply_updates está desativado por predefinição. Assim, sem configuração adicional, o temporizador transfere as atualizações, mas não instala nenhuma. upgrade_type escolhe entre default e security. reboot aceita never, when-changed ou when-needed.

Isto mantém o sistema atualizado dentro da mesma versão. Nunca muda o Fedora 43 para o Fedora 44, porque a atualização de versão é uma operação separada e deliberada que reinicia o sistema para executar uma transação offline. Esta é a diferença prática em relação a uma versão LTS. No Ubuntu, as atualizações de segurança não assistidas mantêm uma máquina atualizada durante toda a janela de cinco anos sem qualquer alteração de versão. A alteração de versão é uma tarefa planeada, como a atualização da versão 24.04 para a 26.04, executada uma vez em cada poucos anos.

Quando o Fedora é a escolha certa para executar no servidor

O Fedora é uma boa escolha quando a novidade é o objetivo.

• Precisa de um kernel ou de um userspace mais recente do que qualquer LTS disponibiliza: hardware recente ou uma stack de contentores e systemd que ainda está a um ano de uma versão empresarial. O Fedora também passa para novos kernels upstream durante o ciclo de uma versão, por isso esta vantagem não ocorre apenas no momento da instalação.
• Está a validar o que está a caminho do RHEL (Red Hat Enterprise Linux). O Fedora alimenta o CentOS Stream, que alimenta o RHEL, por isso o software que compila e é executado hoje no Fedora está a ser testado contra a plataforma empresarial de daqui a alguns anos.
• A máquina foi concebida para ter uma vida curta. Um build runner ou uma máquina de testes destruída ao fim de dois meses nunca chega à data de fim de vida. A mesma lógica aplica-se a VMs descartáveis que entrega a agentes de programação, em que a máquina é recriada com muito mais frequência do que as versões do Fedora.
• Alguém é responsável pela atualização. O Fedora é adequado num servidor com um responsável identificado e uma entrada no calendário. É uma escolha inadequada para a máquina de que todos se esqueceram.

O caminho intermédio: pacotes atuais numa base estável

A maioria das pessoas que quer Fedora num servidor quer dois ou três pacotes atuais, não um sistema operativo atual. As duas coisas podem ser separadas. Use uma versão LTS ou uma reconstrução empresarial como base e obtenha o software mais recente apenas onde é necessário. Uma imagem de contentor fornece a versão nova da aplicação num host que não precisa de ser atualizado por causa dela (executar Docker numa VPS). Um repositório do fornecedor para o único pacote relevante, como PostgreSQL ou nginx, atualiza esse componente e deixa a base inalterada.

A troca é clara nos dois sentidos. Um contentor fornece um userspace novo sobre o kernel antigo do host, por isso não ajuda quando o kernel é o componente que precisa de ser atualizado. Um repositório do fornecedor fornece um pacote novo numa base que o fornecedor testou menos. Nos dois casos, as atualizações de segurança do sistema base continuam a seguir o ciclo da versão LTS, e esse ciclo é o que lhe impõe uma janela de manutenção todos os anos no Fedora.

Se escolher Fedora para um servidor, coloque o ciclo num calendário. Quando uma versão for lançada, aguarde algumas semanas para que os repositórios dos fornecedores acompanhem a versão, crie um snapshot, faça a atualização e confirme depois que os serviços voltaram a funcionar. Esse ritmo custa cerca de uma hora por ano e funciona. A versão que falha é aquela em que a atualização só é lembrada porque algo já deixou de funcionar.

FAQ

Durante quanto tempo uma versão do Fedora recebe suporte?

Cerca de 13 meses. O Fedora publica uma versão aproximadamente a cada seis meses e oferece suporte a cada uma até cerca de quatro semanas depois do lançamento da versão dois ciclos posterior. O Fedora 44 foi lançado em 28 April 2026, com o fim de vida previsto para June 2027. Quando essa data chega, a versão deixa de receber atualizações de segurança e os respetivos pacotes saem dos mirrors e passam para o arquivo do Fedora.

Posso ignorar uma versão do Fedora e atualizar duas versões de uma só vez?

Sim, dentro de certos limites. dnf system-upgrade download --releasever= aceita como destino uma ou duas versões posteriores, e avançar duas versões de cada vez é precisamente o funcionamento de um ciclo de atualização anual. Avançar mais do que isso não é um caminho suportado, e cada versão adicional aumenta a probabilidade de uma alteração do nome de um pacote ou do formato de configuração interromper a transação. Se uma máquina já estiver várias versões atrasada e tiver ultrapassado o fim de vida, recriá-la com uma imagem atual é normalmente mais rápido do que executar uma cadeia de atualizações.

O que acontece se o meu servidor Fedora chegar ao fim de vida?

O servidor continua a funcionar, mas deixa de receber correções. O próximo dnf upgrade falha com um 404 no URL de metalink da sua versão, porque as versões que chegaram ao fim de vida são movidas para o arquivo em dl.fedoraproject.org. Pode redirecionar os ficheiros de repositório para esse arquivo e atualizar por etapas, ou recriar o servidor com uma versão suportada. Até executar uma destas opções, nenhuma atualização de segurança pode chegar à máquina e nenhum pacote será instalado.

O Fedora é uma má escolha para um servidor de produção?

É uma má escolha como opção predefinida, mas uma escolha razoável quando existe uma justificação. O custo é uma atualização completa do sistema operativo todos os anos, para sempre, numa máquina que talvez prefira não alterar. Escolha o Fedora quando precisar de um kernel ou userspace mais recente do que o disponibilizado por uma versão LTS, ou quando o servidor tiver sido concebido para uma utilização curta. Escolha uma versão LTS ou uma reconstrução empresarial quando quiser aplicar correções num servidor durante anos sem alterar a sua versão.