Ubuntu LTS ou versão intermédia no servidor?

Ubuntu LTS versus versões intermédias: a resposta curta

Escolher entre uma versão Ubuntu LTS e uma versão intermédia para um servidor resume-se a um número: durante quanto tempo essa versão continua a receber atualizações de segurança. Uma LTS recebe cinco anos de manutenção de segurança padrão. Uma versão intermédia recebe nove meses de atualizações. Depois, as atualizações terminam, e é necessário atualizar ou reconstruir o sistema. Execute uma LTS em qualquer sistema de que dependam outras pessoas. Use uma versão intermédia apenas quando puder reconstruir o sistema sem ter de pedir autorização a ninguém.

LTS significa suporte de longo prazo. A Canonical publica uma LTS a cada dois anos, em abril dos anos pares, e uma versão intermédia a cada seis meses entre essas versões. A versão 26.04 LTS foi lançada em 23 de abril de 2026, e a sua manutenção de segurança padrão prolonga-se até 2031. A versão 26.10 está prevista para 15 de outubro de 2026. É uma versão intermédia, pelo que o seu ciclo termina em julho de 2027.

Por quanto tempo cada versão do Ubuntu recebe suporte

[
  {
    "label": "LTS, standard support",
    "support_months": 60,
    "upgrades_over_5_years": 1
  },
  {
    "label": "LTS with Ubuntu Pro",
    "support_months": 120,
    "upgrades_over_5_years": 0
  },
  {
    "label": "Interim release",
    "support_months": 9,
    "upgrades_over_5_years": 10
  }
]

Estes são os valores da política publicados pela Canonical em agosto de 2026, não medições feitas num servidor de teste. Uma versão LTS recebe 60 meses de manutenção de segurança padrão. Isso corresponde a 1 atualização de versão planeada em cinco anos. Uma versão intermédia recebe 9 meses. Permanecer no ciclo de versões intermédias durante esses mesmos cinco anos exige 10 atualizações de versão, porque não é possível saltar uma versão e cinco anos contêm dez delas.

Uma subscrição Ubuntu Pro aumenta o período da versão LTS para 120 meses, ou dez anos, e alarga a cobertura do componente main para todo o arquivo. Em agosto de 2026, o Pro é gratuito para uso pessoal em até cinco máquinas, o que cobre a maioria das pequenas frotas de VPS. Não existe uma opção equivalente para uma versão intermédia. O período de nove meses é a oferta completa, e nenhuma subscrição o prolonga.

O custo de nove meses num servidor real

Use 26.10 como exemplo prático. Esta versão é lançada em 15 de outubro de 2026 e a sua manutenção de segurança termina em julho de 2027, seguindo o mesmo ciclo de nove meses que terminou a manutenção de 25.10 em julho de 2026. Visto no calendário, isto parece significar uma janela de manutenção a cada três trimestres. Essa leitura do calendário está errada, e conduz a custos mais elevados.

Uma atualização de versão substitui o sistema operativo no local. do-release-upgrade reescreve as fontes do apt, desativa repositórios de terceiros, altera a versão de quase todos os pacotes instalados, interrompe o processo para perguntar sobre ficheiros de configuração que editou e reinicia o sistema no fim. Por isso, é uma janela planeada e não uma tarefa executada em segundo plano.

Se executar a atualização através de ssh, a ferramenta protege-o contra a perda da própria ligação. Inicia a sua própria sessão screen e abre um segundo sshd, informando-o primeiro:

To make recovery in case of failure easier, an additional sshd will
be started on port '1022'. If anything goes wrong with the running ssh
you can still connect to the additional one.

Permita essa configuração. Se a firewall ou a firewall de rede separada do seu fornecedor bloquear a porta 1022, essa alternativa não estará disponível. Nesse caso, uma ligação interrompida deixa o conjunto de pacotes parcialmente atualizado. Executar o processo dentro de tmux ou screen fornece a mesma proteção em qualquer servidor.

As perguntas sobre os ficheiros de configuração são o que transforma uma atualização de quinze minutos numa hora:

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?

Manter o seu ficheiro significa ignorar qualquer alteração feita na nova configuração predefinida. Aceitar o ficheiro do maintainer significa perder as suas medidas de hardening até as repor. Nenhuma das respostas é segura sem saber o que mudou nessa versão. Por isso, ler as notas da versão faz parte da janela e não é uma tarefa opcional.

Depois, multiplique o custo pelo número de servidores. Um VPS no ciclo intermédio requer dez janelas de atualização em cinco anos. Cinco VPS requerem cinquenta, exceto se cada servidor for descartável e reconstruído a partir de uma imagem. Cinco servidores no ciclo LTS requerem cinco atualizações no mesmo período, e pode escolher o mês em que cada uma ocorre.

Por que você não pode ignorar uma versão do Ubuntu

Os caminhos de atualização são fixos. Uma versão intermediária é atualizada para a versão seguinte, seja ela qual for. Uma LTS é atualizada diretamente para a LTS seguinte ou para a versão intermediária seguinte, se você solicitar. Nenhuma atualização salta duas versões de uma vez. Para passar de 26.10 para 28.04 LTS, é necessário passar por 27.04 e 27.10 ou reinstalar a máquina.

Vale a pena conhecer o mecanismo, porque ele mostra que essa regra não é flexível. do-release-upgrade obtém um ficheiro meta-release de changelogs.ubuntu.com e depois descarrega uma ferramenta de atualização criada para uma transição específica. A Canonical cria e testa uma transição de cada vez, portanto um salto que ignore uma versão não tem ferramenta nem testes correspondentes. O atualizador não recusa a operação por precaução. Não existe nada que ele possa oferecer.

A versão que é apresentada para atualização vem de uma linha de configuração:

grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c

Prompt=lts oferece apenas a LTS seguinte. Prompt=normal oferece a versão seguinte, seja LTS ou não. Prompt=never não oferece nenhuma versão. É assim que você impede que um colega bem-intencionado inicie uma atualização que não foi planeada. Numa versão que não é LTS, lts comporta-se exatamente como normal, porque a versão seguinte a 26.10 é 27.04 nas duas configurações. A verificação imprime Checking for a new Ubuntu release e depois uma linha New release ... available. ou No new release found.

Existe mais uma regra de calendário que causa problemas. A atualização de LTS para LTS não é oferecida no dia em que a nova LTS é lançada. Ela é disponibilizada com a primeira point release, e o lançamento de 26.04.1 está agendado para 27 August 2026. Uma máquina com 24.04 e Prompt=lts que respondeu No new release found. durante o verão de 2026 não estava com problemas. Estava a seguir a política definida. Quando o caminho for disponibilizado, a atualização de 24.04 para 26.04 LTS é a execução que deve ser planeada e ensaiada.

Quando escolher uma versão intermediária

Há quatro casos em que ela é realmente vantajosa:

• Precisa agora, neste servidor, de uma versão do kernel ou do espaço de utilizador que o arquivo LTS não disponibiliza.
• A máquina é um host de compilação, um executor de CI ou um ambiente de testes que recria a partir de uma imagem. Nesse caso, a atualização consiste numa nova instância e não numa janela de manutenção.
• Uma funcionalidade de hardware ou do hypervisor foi disponibilizada depois de o LTS ser congelado, e não existe backport.
• Está a verificar o que o próximo LTS incluirá. O 28.04 é montado a partir do 26.10, 27.04 e 27.10, e encontrar uma alteração incompatível numa VPS de reserva custa menos do que encontrá-la no servidor importante.

A maioria das pessoas que escolhe uma versão intermediária precisa de um pacote mais recente, não de uma distribuição mais recente. Existem duas alternativas mais económicas. A pilha de habilitação de hardware traz kernels de versões posteriores para um LTS: no 24.04, é sudo apt install linux-generic-hwe-24.04, e avança a cada point release, começando pela segunda. Para uma única aplicação, uma imagem de container ou o repositório do próprio fornecedor atualiza um componente, em vez de atualizar todo o sistema operativo.

Quando uma versão intermédia é a escolha errada

• Qualquer sistema com utilizadores pagantes ou uma escala de plantão. Estaria a aceitar uma atualização obrigatória duas vezes por ano em troca de versões de pacotes que talvez nunca utilize.
• Qualquer máquina onde unattended-upgrades faça a aplicação das atualizações de segurança. Essa automatização nunca é melhor do que o repositório de segurança de onde obtém os pacotes.
• Uma frota que atualiza manualmente, porque o custo real é uma janela de manutenção multiplicada pelo número de máquinas.
• Qualquer sistema que instale e depois não volte a consultar durante um ano. Uma versão intermédia esquecida transforma-se num servidor exposto à Internet e sem correções nove meses depois.

Esta última falha é silenciosa, o que a torna perigosa. Quando uma versão chega ao fim da vida útil, os respetivos pacotes passam para old-releases.ubuntu.com, pelo que sudo apt update começa a falhar contra archive.ubuntu.com com erros 404. As listas de pacotes armazenadas no disco ficam desatualizadas. unattended-upgrades continua a ser executado conforme o temporizador e continua a escrever linhas como esta em /var/log/unattended-upgrades/unattended-upgrades.log:

No packages found that can be upgraded unattended and no pending auto-removals

Essa linha é igual num servidor totalmente atualizado e num servidor cuja versão terminou há quatro meses. Se ninguém consultar os erros do apt ou acompanhar a data de fim da vida útil, nada na máquina indica qual das duas situações está a ocorrer.

O tipo de alteração que chega primeiro ao ciclo intermédio

Em março de 2026, um engenheiro da Canonical propôs, no Ubuntu Discourse, remover o carregador de arranque GRUB assinado fornecido para secure boot no 26.10. A proposta remove os controladores de sistema de ficheiros para btrfs, hfsplus, xfs e zfs, os analisadores de imagens JPEG e PNG, as tabelas de partições Apple, /boot em LVM, RAID por software diferente de RAID 1 e um /boot encriptado com LUKS. A razão apresentada é que os analisadores dentro de um carregador de arranque são uma fonte recorrente de problemas de segurança e que a lógica de armazenamento e encriptação deve ficar no initramfs, o pequeno sistema de ficheiros inicial em RAM que o kernel monta antes do root real. Em agosto de 2026, isto é uma proposta em discussão, não uma alteração lançada.

Na maioria das instâncias VPS, isto não mudaria nada, porque arrancam sem secure boot a partir de um /boot ext4 simples numa tabela de partições GPT. Verifique a sua instância em vez de assumir. Se o seu root for ZFS, ou se /boot estiver em btrfs ou dentro de LUKS, esta é exatamente a classe de alteração que chega primeiro no ciclo intermédio. A recomendação do próprio tópico para os utilizadores afetados é permanecer numa versão LTS. Essa recomendação resume todo o argumento numa frase. É nas versões intermédias que as alterações são experimentadas. É numa versão LTS que chegam depois de dois anos de versões intermédias terem revelado o que quebram.

O mesmo padrão surge em menor escala em cada versão intermédia. As versões predefinidas da base de dados, do runtime da linguagem e da configuração do init avançam, pelo que ficheiros de configuração que funcionavam podem deixar de funcionar. Atualizar as versões predefinidas é precisamente a função de uma versão intermédia. Por isso, ler as notas da versão antes de cada uma dessas dez atualizações faz parte do custo que aceitou pagar.

Escolher o track ao criar o servidor

Escolha o track no momento da instalação, porque alterá-lo depois exige reinstalar o sistema ou executar uma sequência de upgrades. Num servidor novo, quatro comandos mostram a situação atual:

lsb_release -a
grep -i prompt /etc/update-manager/release-upgrades
sudo do-release-upgrade -c
pro security-status

lsb_release -a deve indicar a release que pretendia instalar e, numa LTS, a linha de descrição termina com LTS. A linha Prompt deve corresponder ao track escolhido, não ao track incluído na imagem disponibilizada pelo fornecedor. do-release-upgrade -c numa LTS atual deve responder No new release found.. Se indicar uma release interim, Prompt está definido como normal e alguém deve confirmar se isso foi intencional. pro security-status indica quantos pacotes instalados estão abrangidos por cada fluxo de atualizações e informa claramente quando a máquina não está associada a uma subscrição.

Depois, registe a data de fim de vida num local onde a possa consultar novamente, junto das restantes notas de implementação desse servidor. Isto faz parte do trabalho realizado em os primeiros dez minutos num VPS novo, porque uma data de suporte que exista apenas na memória de alguém é a que termina sem ser detetada. Se pretende evitar completamente o ciclo de seis meses, o modelo de releases do FreeBSD comparado com o Linux merece uma hora de leitura antes de escolher uma plataforma para toda a frota.

FAQ

Devo usar uma versão interim do Ubuntu num servidor de produção?

Em quase todos os casos, não. Uma versão interim deixa de receber atualizações de segurança nove meses depois do seu lançamento. Assim, usar essa versão em produção implica uma janela de atualização obrigatória aproximadamente duas vezes por ano, para sempre. As exceções legítimas são máquinas que já recria a partir de uma imagem, como runners de CI e hosts de compilação. Nesses casos, a atualização consiste numa nova instância e não numa janela de manutenção. Se houver utilizadores reais dependentes do servidor, instale a LTS e use as janelas poupadas noutra tarefa.

Durante quanto tempo uma versão interim do Ubuntu recebe suporte?

Nove meses. A versão 26.10 é lançada em 15 October 2026 e a sua manutenção de segurança termina em July 2027, seguindo o mesmo ciclo que terminou a versão 25.10 em July 2026. Todas as versões interim seguem este modelo: são lançadas em April ou October e terminam nove meses depois. Uma LTS recebe cinco anos de manutenção de segurança padrão, prolongados para dez anos com Ubuntu Pro, que em August 2026 é gratuito para uso pessoal em até cinco máquinas.

Posso ignorar versões do Ubuntu durante uma atualização?

Não. do-release-upgrade avança uma versão de cada vez: uma versão interim passa para a versão seguinte, e uma LTS pode passar diretamente para a LTS seguinte. Para passar de 26.10 para 28.04 LTS, primeiro tem de executar a atualização através de 27.04 e 27.10 ou reinstalar a máquina. A Canonical cria e testa uma transição de cada vez, e o atualizador descarrega uma ferramenta específica para essa transição. Por isso, não existe uma ferramenta para uma transição de duas versões e essa opção nunca é disponibilizada.

O que acontece quando a minha versão do Ubuntu chega ao fim da vida útil?

Os pacotes passam para old-releases.ubuntu.com. Por isso, sudo apt update começa a falhar contra archive.ubuntu.com com erros 404, e não são publicadas novas atualizações de segurança para essa versão. Nada na máquina anuncia esta situação. O servidor continua a funcionar e a servir tráfego, enquanto cada vulnerabilidade publicada entretanto permanece aberta. A recuperação exige uma atualização da versão executada sob pressão de tempo ou uma recriação da máquina. Por isso, monitorize a data em vez dos sintomas.

O kernel da LTS é demasiado antigo para hardware novo?

Normalmente, não, porque uma LTS não mantém o kernel original durante cinco anos. A pilha de ativação de hardware, HWE, disponibiliza kernels de versões posteriores nas point releases da LTS. Numa instalação de servidor, pode ativá-la com um pacote como linux-generic-hwe-24.04. Confirme o que está a executar com uname -r antes de assumir que o kernel é o bloqueio. Se o componente em falta for uma versão de userspace e não do kernel, um contentor ou um repositório do fabricante representa uma alteração muito menor do que mover toda a máquina para a versão interim.