Como habilitar EPEL e CRB no Rocky e AlmaLinux

Por que o dnf não encontra o pacote pretendido

EPEL e CRB são os dois repositórios que um servidor Rocky Linux ou AlmaLinux acabado de instalar não fornece por predefinição. Por isso, dnf install htop numa máquina nova responde com No match for argument: htop e depois com Error: Unable to find a match: htop. Não há nada avariado e nenhum mirror está indisponível. A distribuição base fornece deliberadamente um conjunto reduzido de pacotes. O CRB está presente, mas desativado. O EPEL é um repositório comunitário separado que tem de adicionar.

No Ubuntu, o mesmo pacote está em universe e universe está ativado em quase todas as imagens cloud. Por isso, esta questão normalmente nem surge. A família Red Hat distribui os pacotes de forma diferente e usa menos componentes por predefinição. A correção requer três comandos. O restante deste guia explica o que esses repositórios fornecem, o que não fornecem e como impedir que um repositório de terceiros assuma silenciosamente o controlo do sistema base.

Como estes comandos foram verificados. Os nossos contentores de teste de comandos executam apenas Ubuntu, por isso os comandos dnf abaixo não foram executados nas nossas próprias máquinas de teste. Eles seguem a documentação do Rocky Linux e do AlmaLinux. Cada passo indica o resultado esperado. Verifique cada um no seu próprio servidor, em vez de colar todo o bloco de uma só vez.

O que são BaseOS, AppStream e CRB?

BaseOS é o próprio sistema operativo: o kernel, a glibc, o systemd e o espaço de utilizador essencial. As versões aqui raramente mudam durante o ciclo de vida da versão principal. A maioria das correções, incluindo as de segurança, é integrada na versão que já tem instalada, embora uma versão menor ocasionalmente atualize um componente essencial para uma versão upstream mais recente. Por exemplo, o AlmaLinux 9.2 atualizou os pacotes de espaço de utilizador do SELinux para a versão 3.5. Um número de versão que parece antigo no BaseOS não indica um pacote sem correções. É uma versão antiga com correções aplicadas. Esse é precisamente o objetivo de uma distribuição empresarial.

AppStream contém os componentes executados sobre o sistema base: servidores Web, bases de dados, runtimes de linguagens, editores e agentes de monitorização. Na versão 8, grande parte do AppStream era disponibilizada como módulos com streams alternativos, pelo que dnf module list era importante e tinha de escolher, por exemplo, um stream do PHP. A versão 9 disponibiliza a versão predefinida de cada aplicação como um pacote normal. Assim, no Rocky 9 e no Alma 9, um dnf install normal instala essa versão sem ser necessário ativar primeiro um módulo. As versões alternativas continuam a ser disponibilizadas como module streams: a documentação do RHEL 9 identifica o PHP 8.0 como o pacote php normal e o PHP 8.1 e 8.2 como os streams php:8.1 e php:8.2. O AlmaLinux 9.8 também adicionou novos streams, como MariaDB 11.8, PostgreSQL 18 e Ruby 4.0. Se precisar de uma versão diferente da predefinida, dnf module list continua a ser importante na versão 9.

Extras está ativado por predefinição e é muito pequeno. Contém sobretudo pacotes de release para outros repositórios. É daí que vem o próprio epel-release. Por esse motivo, nunca precisa de confiar num URL aleatório para instalar o EPEL no Rocky ou no Alma.

CRB é o repositório CodeReady Builder, chamado PowerTools na versão 8. Contém os componentes de compilação da distribuição: cabeçalhos de desenvolvimento, bibliotecas estáticas e ferramentas de testes e documentação de que os pacotes precisam durante a compilação. O repositório já está disponível no mirror, mas fica desativado por predefinição. No produto da Red Hat, o mesmo conteúdo chama-se CodeReady Linux Builder, está incluído na subscrição e a Red Hat declara que não é abrangido pelo suporte. O Rocky e o Alma herdam tanto o conteúdo como a desativação por predefinição.

Para leitores que vêm do Debian ou Ubuntu: main combina pacotes de runtime e cabeçalhos -dev no mesmo arquivo, pelo que não existe um CRB para ativar. O equivalente mais próximo do EPEL é universe, mantido pela comunidade e sem qualquer compromisso de suporte do fornecedor.

O que é o EPEL e quem o mantém

EPEL significa Extra Packages for Enterprise Linux. É um projeto do Fedora: pacotes que existem no Fedora, recompilados para a versão empresarial atual e mantidos pelo EPEL Special Interest Group, composto principalmente por voluntários da comunidade Fedora. A Red Hat aloja a infraestrutura de compilação e de mirrors, e alguns engenheiros da Red Hat mantêm pacotes no projeto. A relação termina aí. O EPEL não é um produto da Red Hat. Não existe contrato de suporte nem SLA (service level agreement) associado a um pacote EPEL, seja no RHEL ou numa recompilação.

Uma política torna o EPEL seguro para ativar: um pacote EPEL nunca pode substituir um pacote da distribuição base. Se o AppStream disponibiliza nginx, o EPEL não disponibiliza esse pacote. Essa regra é aplicada pelas pessoas que revêem os pacotes EPEL, pelo que é uma garantia apenas sobre o EPEL. Ela não protege contra qualquer outro repositório que seja adicionado posteriormente.

A garantia de duração também é diferente da da distribuição base, e é isso que causa problemas no terceiro ano. Um pacote BaseOS normalmente mantém a mesma versão durante os dez anos de vida da versão principal, com correções integradas nessa versão e apenas uma ou outra atualização deliberada para uma nova base. Um mantenedor do EPEL compromete-se com uma janela muito mais curta: a proposta de tempos de vida dos pacotes baseada na versão do EPEL define-a como pelo menos uma versão minor do RHEL ou 13 meses, consoante o que for mais curto. Na prática, a maioria dos pacotes é mantida durante muito mais tempo. Alguns são retirados quando o mantenedor deixa de os manter, e alguns passam para uma nova versão principal a meio do ciclo de vida da sua distribuição, porque o EPEL acompanha o Fedora. Por isso, uma operação de rotina dnf upgrade pode instalar uma nova versão principal de uma ferramenta EPEL numa máquina que considerava estável, e um pacote de que depende pode deixar de receber atualizações sem qualquer anúncio que chegue até si. Uma nova versão também não entra em execução num serviço que já esteja ativo, pelo que needs-restarting indica quais os processos que continuam a usar o binário antigo depois de a transação terminar.

Há ainda uma consequência que deve conhecer antes de ativar o EPEL: os pacotes não são compilados tendo como base a versão minor mais antiga que poderá estar a manter num servidor. A política do EPEL do Fedora compila a versão minor mais recente do EPEL 10 com base no CentOS Stream 10 e as versões minor mais antigas do EPEL 10 com base em versões minor específicas do RHEL 10. O EPEL 8 e o EPEL 9 têm as suas próprias definições de destino. Se mantiver um servidor numa versão minor mais antiga, usando um mirror congelado ou um repositório de uma versão pontual do fornecedor, um pacote EPEL pode exigir uma biblioteca base mais recente do que a disponível no sistema. O dnf apresenta isso como uma dependência em falta, fazendo parecer que existe um problema no mirror quando, na realidade, existe uma incompatibilidade entre versões.

Ative o CRB e instale o EPEL no Rocky ou Alma

sudo dnf install -y dnf-plugins-core
sudo dnf config-manager --set-enabled crb
sudo dnf install -y epel-release
sudo dnf makecache
dnf repolist --enabled

dnf repolist --enabled deve agora listar baseos, appstream, extras, crb e epel. Também pode aparecer uma pequena entrada epel-cisco-openh264, adicionada por epel-release. Se crb não estiver nessa lista, a ativação não foi aplicada, e a secção seguinte explica o motivo.

No Rocky 8 e no Alma 8, o repositório ainda se chama PowerTools, por isso o comando intermédio passa a ser sudo dnf config-manager --set-enabled powertools. Os IDs dos repositórios diferenciam maiúsculas de minúsculas. A documentação antiga do CentOS 8 escreve-o como PowerTools, com maiúsculas, e esse valor não corresponde. No AlmaLinux 10, o repositório CRB fica ativado por predefinição a partir da versão 10.0, devido à alteração feita em setembro de 2025. Nesse caso, só precisa do passo epel-release.

epel-release vem de extras, que já está ativado. Por isso, não há nenhum URL para validar nem nenhuma chave para importar manualmente. O pacote escreve /etc/yum.repos.d/epel.repo e instala a chave de assinatura do EPEL em /etc/pki/rpm-gpg/. Confirme gpgcheck=1 nesse ficheiro e ignore qualquer guia que recomende contornar um erro de assinatura com --nogpgcheck. Uma verificação de assinatura falhada significa que o pacote não corresponde ao que declara ou que o relógio do sistema está errado.

No Rocky, epel-release também instala um pequeno auxiliar em /usr/bin/crb. Assim, sudo crb enable e crb status executam a mesma tarefa sem o plugin. Verifique se o tem com command -v crb antes de depender dele, porque não está presente em todas as variantes de todas as reconstruções.

Para confirmar que o EPEL está acessível, e não apenas listado, peça-lhe um pacote que só ele disponibiliza:

dnf repoquery --repo=epel htop

Isto apresenta o nome, a versão e a arquitetura do pacote. Nenhuma saída significa que o repositório está ativado, mas não devolve resultados. Normalmente, isso indica um problema no mirror ou nos metadados, e não na configuração. Nesse caso, tente sudo dnf clean all && sudo dnf makecache a seguir.

Por que o dnf informa que não existe o comando: config-manager

Este é o primeiro problema encontrado por muitas pessoas. Ele ocorre justamente nas imagens fornecidas pela maioria dos provedores de VPS.

No such command: config-manager. Please use /usr/bin/dnf --help
It could be a DNF plugin command, try: "dnf install 'dnf-command(config-manager)'"

config-manager é um plugin, não um subcomando integrado do dnf. Ele é fornecido pelo dnf-plugins-core, que uma instalação completa do servidor inclui, mas que imagens mínimas, imagens de nuvem e imagens de contêiner não incluem. A própria sugestão do dnf funciona porque o pacote declara essa capacidade virtual:

sudo dnf install -y 'dnf-command(config-manager)'

Coloque-o entre aspas. Os parênteses são sintaxe do shell. Portanto, uma versão sem aspas falha com um erro de sintaxe, e não com um erro do dnf.

Se não for possível instalar o plugin porque o repositório necessário é o que está desabilitado, edite o arquivo diretamente. Identifique qual arquivo contém a seção, abra-o e defina enabled=1 em [crb]:

grep -rl crb /etc/yum.repos.d/

É exatamente isso que config-manager grava. Portanto, nada é perdido ao fazer a alteração manualmente. dnf repolist --enabled confirma o resultado.

Alguns pacotes do EPEL não serão instalados enquanto o CRB não estiver ativado

A segunda armadilha comum gera um erro que nunca menciona o CRB. Um pacote do EPEL que depende de uma biblioteca disponibilizada apenas no CRB falha durante a resolução de dependências. A mensagem indica a biblioteca e o pacote que a solicitou:

Error:
 Problem: conflicting requests
  - nothing provides libexample.so.0()(64bit) needed by examplepkg-1.4-2.el9.x86_64 from epel

A causa é o CRB estar desativado. Por isso, o dnf não consegue consultar o único repositório que fornece essa biblioteca. Verifique os dois pontos pela ordem:

dnf repolist --enabled
dnf --enablerepo=crb repoquery --whatprovides 'libexample.so.0()(64bit)'

Se o segundo comando identificar um pacote, mas a instalação simples continuar a falhar, o CRB está desativado. Este tipo de erro é suficientemente comum para que o AlmaLinux tenha ativado o CRB por padrão na versão 10, especificamente para evitar que ocorra. --enablerepo=crb também funciona como uma opção temporária numa única instalação, mas mantenha o CRB ativado permanentemente se utilizar o EPEL, porque a atualização seguinte do EPEL pode introduzir uma nova dependência do CRB sem aviso prévio.

De que repositório veio este pacote?

Depois de algumas semanas com quatro repositórios ativados, a pergunta útil deixa de ser o que está instalado e passa a ser de onde veio.

dnf repolist --all
dnf info htop
dnf repoquery --installed --qf '%{from_repo} %{name}' | sort | uniq -c | sort -rn
dnf repository-packages epel list installed

dnf info num pacote instalado mostra uma linha From repo. dnf list installed mostra a mesma informação na terceira coluna, com um @ à frente. Assim, @epel significa que o pacote foi instalado a partir do EPEL, e @System significa que o dnf não sabe de onde veio. Normalmente, isso acontece porque alguém executou rpm -i num ficheiro transferido. A linha repoquery mostra uma contagem por repositório. É a forma mais rápida de descobrir que um servidor herdado tem quarenta pacotes de um repositório que nunca ouviu mencionar. O último comando lista exatamente o que um repositório lhe forneceu. Esse inventário é necessário antes de decidir removê-lo.

O equivalente no apt é apt-cache policy <package>. Vale a pena manter os equivalentes dos comandos dnf e apt abertos num segundo separador durante o primeiro mês, porque os conceitos correspondem diretamente, mesmo quando as opções são diferentes.

Como impedir que um repositório de terceiros substitua um pacote base?

O EPEL promete não fazer isto. Nenhum outro repositório faz essa promessa. Um repositório de fornecedor para uma base de dados, um agente ou um runtime de linguagem pode disponibilizar a sua própria versão de uma biblioteca que o BaseOS também fornece, e o dnf instala essa versão porque a regra predefinida do dnf é simples: vence a versão mais alta, independentemente da origem.

Dois controlos fazem a maior parte do trabalho, e ambos ficam no ficheiro do repositório em /etc/yum.repos.d/.

priority= decide qual repositório vence quando mais de um disponibiliza o mesmo nome de pacote. Os números mais baixos vencem e o valor predefinido é 99. Por isso, atribua um número baixo aos repositórios base e um número alto a qualquer repositório de terceiros. O dnf passa então a escolher o pacote base mesmo quando a versão de terceiros é mais recente. O dnf moderno trata deste caso diretamente, por isso o pacote separado yum-plugin-priorities da era do CentOS 7 já não faz parte da solução.

includepkgs= é a opção de filtragem mais restritiva. excludepkgs= bloqueia pacotes com nomes específicos de um repositório, o que exige prever o que esse repositório poderá disponibilizar. includepkgs= inverte esse comportamento: este repositório pode fornecer estes nomes e nada mais. Um repositório de fornecedor que só deve disponibilizar o seu próprio agente precisa de uma única linha.

[vendor-tools]
name=Vendor tools for EL9
baseurl=https://packages.example.com/el9/x86_64/
enabled=1
gpgcheck=1
gpgkey=https://packages.example.com/RPM-GPG-KEY-vendor
priority=90
includepkgs=vendor-agent,vendor-agent-plugins

Na versão 8, há mais uma configuração a conhecer. Um pacote de um repositório de terceiros pode ficar oculto quando um módulo do AppStream fornece o mesmo nome. module_hotfixes=1, na secção desse repositório, indica ao dnf que deve deixar de o filtrar. Se um pacote que o repositório do fornecedor disponibiliza claramente for indicado como inexistente, ou não puder ser instalado, num sistema com a versão 8, essa é normalmente a causa: a filtragem modular torna o pacote invisível para a maioria dos comandos do dnf, em vez de indicar um conflito. A versão 9 tem menos módulos, mas continua a disponibilizar streams de módulos. Por isso, a mesma filtragem pode aplicar-se quando um pacote do fornecedor partilha o nome com um módulo.

Para fixar um pacote numa versão específica, instale python3-dnf-plugin-versionlock e use sudo dnf versionlock add <package>. Isto equivale a apt-mark hold. Tenha atenção a uma diferença que costuma afetar quem vem do Debian: no apt, vence um Pin-Priority mais alto; no dnf, vence um priority mais baixo.

Por que misturar repositórios adjacentes do RHEL torna um servidor impossível de atualizar

Rocky, Alma, CentOS Stream, Oracle Linux e RHEL são suficientemente semelhantes para que os pacotes de uma distribuição sejam instalados nas outras, mas suficientemente diferentes para que o resultado deixe de ser um sistema que alguém possa suportar. O motivo dessa proximidade e a razão pela qual o Stream, em particular, está agora à frente do RHEL em vez de estar ao lado dele estão em a história de como o Red Hat Linux se dividiu em Fedora e RHEL e do que aconteceu com o CentOS.

O mecanismo são os números de versão. O CentOS Stream 9 está à frente do RHEL 9, e a Red Hat descreve o código do Stream como aquilo que se torna a próxima versão minor do RHEL. Apontar um servidor Rocky 9 para um repositório Stream, mesmo uma só vez e mesmo para um único pacote, deixa instalados pacotes cujas versões estão à frente das versões atualmente fornecidas pelo Rocky. Uma versão minor posterior do Rocky pode alcançá-las, mas nada garante que forneça esse pacote com uma versão igual ou superior à instalada. Até isso acontecer, dnf upgrade não o atualizará. A máquina passa a executar uma combinação que ninguém testou e pode permanecer assim silenciosamente durante anos, enquanto você presume que está corrigida.

O sintoma é dnf upgrade não reportar nada para fazer, enquanto sudo dnf distro-sync propõe fazer downgrade de uma longa lista de pacotes. distro-sync é a ferramenta de reparação: força todos os pacotes instalados a corresponderem ao que os repositórios ativados realmente oferecem, incluindo downgrades. Desative primeiro o repositório externo, execute a ferramenta e leia a lista proposta antes de aceitá-la. A reparação falha quando o RPM antigo já não está no mirror. Nesse ponto, recriar o servidor a partir de uma imagem limpa é mais rápido e seguro do que lutar com o resolvedor de dependências.

Restos de uma migração com ELevate são outra forma comum deste problema. ELevate é a ferramenta de migração do AlmaLinux baseada no Leapp, usada para atualizar um servidor CentOS 7 ou para converter entre rebuilds. Uma migração apressada deixa ficheiros de repositório EL7 em /etc/yum.repos.d/ e pacotes EL7 ainda instalados. Encontre-os com rpm -qa | grep el7. Cada um é um pacote que nenhum repositório ativado poderá atualizar, e uma execução posterior do Leapp irá reportá-los como pacotes que não consegue mapear. Isso torna-se um bloqueio à atualização que você terá de resolver manualmente. Remova-os enquanto o servidor está estável, não no dia em que precisar da próxima atualização major.

Um repositório de fornecedor que se sobrepõe a um pacote do AppStream é a versão menos grave do mesmo problema, e a linha includepkgs acima é a solução. As ferramentas de contentores são o caso habitual, porque containerd.io do repositório próprio do Docker entra em conflito com runc do AppStream, pelo que um deles tem de ser removido. Tome a decisão uma vez, registe a exclusão e siga uma ordem conhecida: o guia de instalação do Docker no Rocky Linux explica quais pacotes da distribuição devem ser removidos primeiro.

A tradução de apt para dnf em repositórios

• /etc/apt/sources.list.d/*.sources torna-se /etc/yum.repos.d/*.repo, onde um ficheiro pode conter vários [sections], cada um com o seu próprio id.
• add-apt-repository universe torna-se dnf install epel-release, com a diferença de que universe continua no arquivo próprio do Ubuntu e o EPEL é um projeto separado.
• apt update não tem um equivalente que seja necessário memorizar. O dnf atualiza os metadados segundo o seu próprio agendamento, e dnf makecache força a atualização imediatamente.
• apt-cache policy <pkg> torna-se dnf info <pkg>, juntamente com dnf list --showduplicates <pkg> para ver todas as versões disponíveis.
• apt-mark hold torna-se dnf versionlock add, a partir de python3-dnf-plugin-versionlock.
• O pinning em /etc/apt/preferences.d/ torna-se priority= na secção do repositório, com os números a aumentar na direção oposta.
• dpkg -S /path/to/file torna-se rpm -qf /path/to/file.

As atualizações automáticas são transferidas como conceito, e não como sintaxe, porque aqui não existe unattended-upgrades. O temporizador, o ficheiro de configuração e a decisão de reiniciar estão descritos em dnf-automatic no Rocky e Alma.

Mantenha a lista de repositórios curta

Ative o CRB, instale epel-release e registe o que fez e porquê, seja na sua gestão de configuração, seja num ficheiro simples no servidor. Essa nota vale mais do que parece quando o servidor tem três anos e está a ser administrado por outra pessoa.

Pesquise antes de adicionar. Execute dnf search, depois dnf info e só então considere adicionar um novo repositório. Uma parte surpreendentemente grande do software que as pessoas ativam o EPEL para obter já está no AppStream. O monitoramento do sistema é o exemplo mais claro, porque o Performance Co-Pilot é disponibilizado nos repositórios base e não precisa de nada de terceiros. Cada repositório adicional é mais uma entidade que pode disponibilizar um pacote para o seu servidor numa terça-feira, e cada um deles torna a próxima atualização principal mais difícil.

Se ainda está a escolher entre as duas distribuições, esta estrutura é igual em ambas e epel-release comporta-se da mesma forma. As diferenças reais estão noutros pontos: a comparação entre Rocky Linux e AlmaLinux aborda a filosofia de reconstrução, uma vez que o AlmaLinux agora visa a compatibilidade ABI (application binary interface), em vez de uma reconstrução linha a linha.

FAQ

Como habilito o EPEL no Rocky Linux 9 ou AlmaLinux 9?

Execute sudo dnf install -y dnf-plugins-core, depois sudo dnf config-manager --set-enabled crb e, por fim, sudo dnf install -y epel-release. Confirme com dnf repolist --enabled, que deverá listar baseos, appstream, extras, crb e epel. Ative o CRB antes de instalar pacotes do EPEL, porque muitos deles dependem de bibliotecas fornecidas apenas pelo CRB. Na versão 8, o ID do repositório é powertools em vez de crb.

É seguro ativar o EPEL num servidor de produção?

O EPEL é amplamente utilizado e segue uma política segundo a qual os pacotes do EPEL nunca substituem um pacote da distribuição base. Por isso, ativá-lo não altera o conteúdo disponibilizado pelo BaseOS ou pelo AppStream. A ressalva é o suporte: o EPEL é um projeto voluntário do Fedora, sem acordo de nível de serviço, e a proposta de ciclo de vida dos pacotes do EPEL pede que um mantenedor se comprometa com um pacote durante apenas uma versão secundária do RHEL ou 13 meses. Mantenha um inventário com dnf repository-packages epel list installed e use dnf versionlock em qualquer pacote do EPEL do qual dependa um serviço exposto aos clientes.

Por que o dnf informa no such command: config-manager?

Porque config-manager é um plugin do dnf, não um comando integrado, e as imagens mínimas ou de contentores são distribuídas sem dnf-plugins-core. A própria mensagem indica a correção: sudo dnf install -y 'dnf-command(config-manager)', entre aspas para impedir que a shell interprete os parênteses. Se ainda não puder instalar nada, execute grep -rl crb /etc/yum.repos.d/, abra o ficheiro indicado e defina enabled=1 manualmente na secção [crb].

Qual é a diferença entre CRB e PowerTools?

São o mesmo repositório com dois nomes. A versão 8 chama-lhe PowerTools, com o ID powertools. A versão 9 e posteriores chamam-lhe CRB, com o ID crb. O nome usado pelo produto da Red Hat é CodeReady Linux Builder. O repositório contém cabeçalhos de desenvolvimento, bibliotecas estáticas e ferramentas de compilação. Está desativado por predefinição no Rocky e no AlmaLinux 9. O AlmaLinux 10 ativa-o por predefinição a partir da versão 10.0. Por isso, verifique dnf repolist --enabled antes de executar o comando de ativação.

Como removo novamente o EPEL sem causar problemas?

Comece por criar um inventário com dnf repository-packages epel list installed, porque remover apenas o pacote epel-release não remove nada que tenha sido instalado a partir do EPEL. Esses pacotes permanecem no disco, deixam de ter uma fonte de atualizações e deixam de receber correções de segurança, sem qualquer erro que o informe disso. Analise cada pacote individualmente, remova ou substitua os que já não forem necessários e só depois execute sudo dnf remove epel-release. Se algo do EPEL não tiver substituído outro pacote e tiver simplesmente de ser removido, sudo dnf repository-packages epel remove limpa o conjunto numa única transação. Leia atentamente a lista proposta antes de a confirmar.