Instale o DNF no RHEL/CentOS 7: Um Guia Técnico Completo

DNF (Dandified YUM) é o gestor de pacotes de próxima geração para distribuições Linux baseadas em RPM, concebido como substituto completo do YUM. Oferece uma resolução de dependências mais rápida através da biblioteca `libsolv`, menor consumo de memória e uma API Python estável. Embora o RHEL/CentOS 7 venha com YUM por defeito, o DNF pode ser totalmente instalado através do repositório EPEL e pode ser executado em paralelo com — ou como substituto transparente do — YUM no mesmo sistema.

Este guia percorre o processo de instalação completo, explica as diferenças arquiteturais entre YUM e DNF, aborda casos extremos do mundo real e fornece uma referência de comandos pronta para produção.

Por que o DNF Supera o YUM no RHEL/CentOS 7

Antes de tocar no terminal, compreender *por que* a atualização é importante ajuda-o a tomar uma decisão informada — especialmente num ambiente de VPS Hosting de longa duração onde a fiabilidade da gestão de pacotes é crítica.

Diferenças Arquiteturais Fundamentais

O YUM baseia-se num resolvedor de dependências em Python que tem problemas de desempenho bem documentados com grandes árvores de dependências. O DNF substitui esse resolvedor pelo `libsolv`, um motor de resolução de dependências baseado em SAT-solver originalmente desenvolvido pela SUSE. As consequências práticas são significativas:

• Velocidade de resolução de dependências: O DNF resolve cadeias de dependências complexas numa fração do tempo que o YUM necessita, particularmente notável ao resolver conflitos em grandes conjuntos de pacotes.
• Consumo de memória: O YUM carrega todos os metadados do repositório para a memória. O DNF utiliza carregamento lazy e armazena em cache de forma mais agressiva, reduzindo o pico de utilização de RAM.
• Estabilidade da API: A API Python do YUM mudava de forma imprevisível entre versões menores. O DNF expõe uma API Python documentada e com versão em que os autores de plugins podem confiar.
• Arquitetura de plugins: O DNF utiliza um sistema de plugins limpo baseado em hooks. Os plugins do YUM frequentemente interferem uns com os outros devido ao acoplamento fraco.
• Histórico de transações: O DNF mantém uma base de dados de histórico de transações mais rica, tornando as reversões e auditorias mais precisas.

YUM vs. DNF: Comparação de Funcionalidades

Pré-requisitos

Antes de prosseguir, confirme o seguinte:

• Uma instância em execução de RHEL 7 ou CentOS 7 (bare metal, VM ou um VPS na nuvem).
• Acesso root ou sudo — todos os comandos de instalação requerem privilégios elevados.
• Conectividade ativa à internet — o repositório EPEL deve estar acessível.
• Pelo menos 500 MB de espaço livre em disco para o DNF, as suas dependências e a cache de metadados do repositório.

Se estiver a executar uma instalação mínima do CentOS 7 num Servidor Dedicado, verifique se `curl` e `wget` estão disponíveis, pois ocasionalmente estão ausentes em imagens simplificadas.

Passo 1: Atualizar os Pacotes do Sistema Existentes

Sincronizar a sua base de dados de pacotes antes de instalar novo software evita conflitos de versões e garante que o pacote de lançamento EPEL é instalado corretamente em relação ao estado atual da sua base de dados RPM.

“`bash

sudo yum update -y

“`

O que isto faz: Descarrega e aplica todas as atualizações disponíveis para os pacotes atualmente instalados, atualiza os metadados do repositório e reconstrói o bloqueio de transação RPM. Num sistema de produção, agende isto durante uma janela de manutenção — as atualizações do kernel requerem um reinício para entrar em vigor.

Caso extremo: Se `yum update` falhar com um erro `Multilib version problems`, execute `sudo yum update –setopt=protected_multilib=false -y` como solução temporária, e depois investigue os pacotes em conflito antes de prosseguir.

Passo 2: Ativar o Repositório EPEL

O DNF não está disponível nos repositórios base padrão do CentOS/RHEL 7. O repositório Extra Packages for Enterprise Linux (EPEL), mantido pelo projeto Fedora, disponibiliza-o.

“`bash

sudo yum install epel-release -y

“`

Verificar se o repositório está ativo:

“`bash

yum repolist | grep epel

“`

O resultado esperado deve mostrar `epel/x86_64` com uma contagem de pacotes diferente de zero (tipicamente 13.000+). Se o repositório aparecer desativado, force a sua ativação:

“`bash

sudo yum-config-manager –enable epel

“`

Nota de segurança: Os pacotes EPEL são compilados e assinados pela equipa de infraestrutura do Fedora. O pacote `epel-release` instala a chave GPG automaticamente. Pode verificar a impressão digital da chave no servidor de chaves oficial do Fedora antes de confiar nos pacotes deste repositório — um passo que vale a pena dar em sistemas de produção reforçados.

Atrás de um proxy ou firewall? Se o seu servidor não consegue alcançar os mirrors do Fedora diretamente, configure `/etc/yum.conf` com as suas definições de proxy:

“`ini

proxy=http://your-proxy-server:port

proxy_username=user

proxy_password=pass

“`

Passo 3: Instalar o DNF

Com o EPEL ativo, instale o DNF e as suas dependências principais num único comando:

“`bash

sudo yum install dnf -y

“`

Isto inclui `dnf`, `dnf-data`, `python-dnf`, `libcomps`, `librepo` e `libsolv` como dependências automáticas. O tamanho total do download está tipicamente entre 3–8 MB dependendo do que já está instalado.

O que é instalado:

• `dnf` — o binário principal e a interface de linha de comandos
• `libsolv` — o resolvedor de dependências baseado em SAT
• `librepo` — a biblioteca de download paralelo
• `libcomps` — parser XML comps para grupos de pacotes
• `python-dnf` — bindings Python e a biblioteca principal do DNF

Passo 4: Verificar a Instalação

Confirme que o DNF está operacional e verifique a sua versão:

“`bash

dnf –version

“`

Uma instalação bem-sucedida produz um resultado semelhante a:

“`

4.0.9.2

Installed: dnf-0:4.0.9.2-1.el7.noarch at …

Built : CentOS BuildSystem <http://bugs.centos.org> at …

“`

Execute uma verificação de sanidade mais profunda listando os repositórios disponíveis vistos pelo DNF:

“`bash

dnf repolist

“`

O resultado deve espelhar o que `yum repolist` mostra, confirmando que o DNF herdou corretamente a sua configuração de repositório existente de `/etc/yum.repos.d/`.

Importante: O DNF no CentOS 7 lê os mesmos ficheiros `.repo` de repositório que o YUM. Não é necessária nenhuma migração de repositório. Ambas as ferramentas partilham `/etc/yum.repos.d/` e `/var/cache/` (em subdiretórios separados).

Passo 5: Referência de Comandos Principais do DNF

O DNF é intencionalmente compatível com os comandos do YUM. A tabela seguinte cobre as operações que utilizará com mais frequência:

Histórico de Transações e Reversão do DNF

Esta é uma das funcionalidades operacionalmente mais valiosas do DNF e uma que o YUM trata de forma deficiente. Cada instalação, atualização ou remoção é registada em `/var/lib/dnf/history/`. Para inspecionar transações recentes:

“`bash

dnf history list

“`

Para ver exatamente o que mudou numa transação específica:

“`bash

dnf history info <transaction-id>

“`

Para desfazer uma transação (por exemplo, reverter uma atualização problemática):

“`bash

sudo dnf history undo <transaction-id>

“`

Esta capacidade é particularmente útil num VPS com cPanel onde uma atualização de pacote pode entrar em conflito com as dependências do painel de controlo.

Ficheiro de Configuração do DNF

A configuração global do DNF encontra-se em `/etc/dnf/dnf.conf`. Parâmetros de ajuste principais para uso em produção:

“`ini

[main]

gpgcheck=1

installonly_limit=3

clean_requirements_on_remove=True

best=True

skip_if_unavailable=False

“`

• `installonly_limit=3` — mantém apenas as últimas 3 versões do kernel, evitando que `/boot` fique cheio.
• `clean_requirements_on_remove=True` — remove automaticamente dependências órfãs ao remover pacotes.
• `best=True` — instala sempre a versão mais recente disponível, gerando um erro em vez de fazer downgrade silenciosamente.

Passo 6: Configurar o DNF como Gestor de Pacotes Padrão

No RHEL/CentOS 7, o YUM permanece como padrão do sistema. Tem duas opções para tornar o DNF a sua interface principal.

Opção A: Alias de Shell (Nível de Utilizador, Não Destrutivo)

Adicione o seguinte a `~/.bashrc` (para o utilizador atual) ou `/etc/bashrc` (para todo o sistema):

“`bash

alias yum='dnf'

“`

Aplique imediatamente:

“`bash

source ~/.bashrc

“`

Limitação: Este alias aplica-se apenas a sessões de shell interativas. Scripts que invocam `yum` diretamente através do seu caminho absoluto (`/usr/bin/yum`) ou que são executados sob utilizadores diferentes (por exemplo, tarefas cron, unidades systemd) não são afetados.

Opção B: Ligação Simbólica (Nível do Sistema)

Para uma substituição mais completa, crie uma ligação simbólica que redireciona o binário `yum` para `dnf`:

“`bash

sudo mv /usr/bin/yum /usr/bin/yum.bak

sudo ln -s /usr/bin/dnf /usr/bin/yum

“`

Aviso crítico: Esta abordagem afeta todos os utilizadores e todos os scripts em todo o sistema. Teste exaustivamente num ambiente que não seja de produção primeiro. Alguns scripts do sistema e ferramentas de terceiros (incluindo certos componentes do cPanel/WHM) chamam explicitamente `/usr/bin/yum` e podem comportar-se de forma inesperada se o binário for substituído. Faça sempre uma cópia de segurança do binário original conforme mostrado acima.

Opção C: DNF como Plugin do YUM (Recomendado para Servidores)

A abordagem mais limpa para servidores de produção é deixar o YUM intacto e simplesmente usar `dnf` explicitamente nos seus próprios fluxos de trabalho e scripts de automação. Isto evita qualquer risco de quebrar as ferramentas do sistema enquanto lhe dá acesso completo às capacidades do DNF.

Armadilhas Práticas e Casos Extremos

Estes são problemas que surgem em implementações reais e raramente são abordados em tutoriais básicos.

Conflitos de chave GPG: Se instalar pacotes de múltiplos repositórios de terceiros, a aplicação mais rigorosa de GPG do DNF (quando `gpgcheck=1`) pode rejeitar pacotes que o YUM aceitava silenciosamente. Importe sempre as chaves GPG do repositório explicitamente com `sudo rpm –import <key-url>`.

Incompatibilidade de plugins: Alguns plugins do YUM (por exemplo, `yum-plugin-fastestmirror`) não têm equivalente direto no DNF ou comportam-se de forma diferente. O DNF tem o seu próprio plugin `fastestmirror` (`dnf-plugin-fastestmirror`), mas não está ativado por defeito. Instale-o com `sudo dnf install python3-dnf-plugin-fastestmirror`.

Divergência de localização da cache: O YUM armazena metadados em cache em `/var/cache/yum/`. O DNF utiliza `/var/cache/dnf/`. Se o espaço em disco for limitado, ambas as caches podem coexistir e consumir espaço significativo. Execute `sudo dnf clean all` e `sudo yum clean all` independentemente para recuperar espaço.

Gestão de subscrições RHEL: Em sistemas RHEL 7 registados (ao contrário do CentOS), o plugin `subscription-manager` integra-se com o YUM. O DNF no RHEL 7 pode não respeitar totalmente os repositórios com acesso por subscrição sem configuração adicional. Verifique com `subscription-manager repos –list-enabled` após a mudança.

Sensibilidade à versão Python: O DNF no CentOS 7 utiliza bindings Python 2 (`python-dnf`). Se tiver atualizado para Python 3 no seu sistema, certifique-se de que não está a quebrar inadvertidamente a cadeia de dependências `python-dnf`. O DNF 4+ no RHEL 8+ utiliza Python 3 nativamente.

Planear o Seu Caminho de Migração para Além do CentOS 7

O CentOS 7 atingiu o fim de vida a 30 de junho de 2024. Instalar o DNF é uma melhoria operacional útil, mas não altera a postura de segurança subjacente de uma distribuição EOL. Se ainda estiver a executar cargas de trabalho no CentOS 7, um plano de migração para AlmaLinux 8/9, Rocky Linux 8/9 ou RHEL 8/9 deve constar do seu roteiro. Todas estas distribuições utilizam o DNF nativamente, tornando a familiaridade que constrói agora diretamente transferível.

Para equipas que gerem múltiplos serviços em infraestrutura envelhecida, os Painéis de Controlo VPS podem simplificar significativamente a gestão de ambientes paralelos durante uma janela de migração.

Se as suas cargas de trabalho incluem stacks de alojamento web, migrar para uma distribuição moderna também lhe permite tirar pleno partido da automação de Certificados SSL via Certbot e ACME, que tem suporte significativamente melhor no RHEL 8+ e seus derivados.

Matriz de Decisão de Referência Rápida

Utilize esta lista de verificação antes e depois da instalação para confirmar uma configuração limpa e segura para produção:

• [ ] `yum update -y` concluído sem erros antes de instalar o EPEL
• [ ] Repositório EPEL verificado como ativo via `yum repolist | grep epel`
• [ ] `dnf –version` retorna uma cadeia de versão válida
• [ ] O resultado de `dnf repolist` corresponde ao resultado de `yum repolist`
• [ ] `/etc/dnf/dnf.conf` revisto e ajustado para o seu ambiente
• [ ] `installonly_limit` definido para evitar o overflow da partição `/boot`
• [ ] Decisão tomada sobre a estratégia de alias vs. ligação simbólica vs. coexistência
• [ ] Binário YUM com cópia de segurança se a abordagem de ligação simbólica for utilizada
• [ ] Tarefas cron e scripts de automação auditados para caminhos `yum` codificados
• [ ] Cronograma de migração EOL do CentOS 7 documentado

FAQ

O DNF e o YUM podem coexistir no mesmo sistema CentOS 7 sem conflitos?

Sim. Ambas as ferramentas leem de `/etc/yum.repos.d/` e mantêm diretórios de cache separados. Partilham a base de dados RPM (`/var/lib/rpm`), pelo que uma transação concluída por uma é imediatamente visível para a outra. Executar ambas simultaneamente (por exemplo, duas instalações concorrentes) causará um conflito de bloqueio RPM, mas o uso sequencial é totalmente seguro.

A instalação do DNF no CentOS 7 vai quebrar os plugins YUM existentes?

Não. O DNF instala-se como um binário independente e não modifica a instalação do YUM. Os seus plugins YUM existentes permanecem intactos. No entanto, o DNF não carrega plugins YUM — se depender de plugins YUM específicos, precisa de encontrar e instalar os seus equivalentes DNF separadamente.

O DNF no CentOS 7 suporta módulos DNF (fluxos de módulos)?

Não. Os fluxos de módulos DNF são uma funcionalidade introduzida no DNF 4 e no RHEL/CentOS 8. A versão do DNF disponível via EPEL para o CentOS 7 é o DNF 4.x, mas o suporte a fluxos de módulos requer a infraestrutura do repositório AppStream, que não existe no CentOS 7.

Por que é que `dnf update` produz por vezes resultados diferentes de `yum update` no mesmo sistema?

O resolvedor `libsolv` do DNF aplica uma lógica de dependências mais rigorosa e pode resolver seleções de versões de forma diferente do resolvedor interno do YUM. Na maioria dos casos o resultado é idêntico, mas em ambientes com dependências complexas ou conflituosas, o DNF pode selecionar versões de pacotes diferentes ou recusar transações que o YUM teria permitido silenciosamente. Isto é uma funcionalidade, não um erro — o comportamento do DNF é mais previsível e auditável.

É seguro usar o DNF num servidor CentOS 7 que aloja aplicações web de produção?

Sim, com a ressalva de que utilize a abordagem de coexistência (deixe o YUM intacto, use o DNF explicitamente) em vez de substituir o binário do YUM. Verifique se qualquer software de painel de controlo ou automação de implementação no seu servidor não tem suposições codificadas sobre o comportamento do YUM antes de mudar o seu fluxo de trabalho principal para o DNF.