Como ativar EPEL e CRB no Rocky Linux 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 recebe por predefinição. Por isso, dnf install htop num sistema novo 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 intencionalmente um conjunto reduzido de pacotes. O CRB está presente, mas desativado. O EPEL é um repositório comunitário separado que tem de ser adicionado.

No Ubuntu, o mesmo pacote está em universe. O universe está ativado em quase todas as imagens cloud, por isso esta questão não surge. A família Red Hat organiza os pacotes de forma diferente e fornece menos pacotes 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 que deve ver. Verifique cada passo 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, glibc, systemd e o espaço de utilizador básico. As versões são congeladas durante todo o ciclo de vida da versão principal, e as correções de segurança são integradas nessas versões congeladas. Um número de versão que parece ter vários anos no BaseOS não indica um pacote sem correções. Trata-se de uma versão antiga corrigida, que é precisamente o objetivo de uma distribuição empresarial.

AppStream contém os componentes executados sobre o sistema: 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 era necessário escolher, por exemplo, um stream do PHP. A versão 9 eliminou quase toda a modularidade. Por isso, no Rocky 9 e no Alma 9, normalmente existe uma versão de cada componente e não é necessário ativar primeiro um módulo.

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 é necessário 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 a parte de compilação da distribuição: cabeçalhos de desenvolvimento, bibliotecas estáticas e as 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 está desativado por predefinição. No produto da Red Hat, o mesmo conteúdo chama-se CodeReady Linux Builder. Está incluído na subscrição, mas 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 do Ubuntu: main mistura 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, que é mantido pela comunidade e não inclui qualquer compromisso de suporte do fornecedor.

O que é o EPEL e quem está por trás do projeto

EPEL significa Extra Packages for Enterprise Linux. É um projeto do Fedora: pacotes existentes 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 reconstrução.

Uma política torna o EPEL seguro para ativação: um pacote EPEL nunca pode substituir um pacote da distribuição base. Se o AppStream disponibiliza nginx, o EPEL não o disponibiliza. Essa regra é aplicada pelas pessoas que analisam os pacotes EPEL, portanto é uma garantia apenas do EPEL. Ela não protege contra qualquer outro componente que adicionar mais tarde.

A garantia de duração também é diferente da da distribuição base, e é aqui que os problemas surgem no terceiro ano. A versão de um pacote BaseOS fica congelada durante os dez anos de vida da versão principal. Um mantenedor do EPEL compromete-se com uma janela muito mais curta: 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 avançam para uma nova versão major a meio do ciclo de vida da sua distribuição, porque o EPEL acompanha o Fedora. Por isso, uma operação rotineira dnf upgrade pode instalar uma nova versão major 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.

Há ainda outra consequência que deve conhecer antes de ativar o EPEL: o EPEL é compilado contra a versão minor mais recente do RHEL. Se mantiver um servidor numa versão minor mais antiga, usando um mirror congelado ou um repositório de uma versão específica do fornecedor, um pacote EPEL pode exigir uma biblioteca base mais recente do que a instalada. O dnf comunica isso como uma dependência em falta, o que parece um problema do mirror quando, na realidade, é um problema de 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 próxima secção explica porquê.

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 é ativado por predefinição a partir da versão 10.0, devido a uma 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 rebuilds.

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

dnf repoquery --repo=epel htop

Esse comando mostra o nome, a versão e a arquitetura do pacote. Nenhuma saída significa que o repositório está ativado, mas não está a devolver 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 “no such command: config-manager”

Este é o primeiro ponto que causa problemas e acontece exatamente nas imagens que a maioria dos provedores de VPS fornece.

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 por dnf-plugins-core, que uma instalação completa do servidor instala, 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 você não puder instalar o plugin porque o repositório necessário é o que está desativado, edite o arquivo diretamente. Descubra 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 se perde ao fazer a alteração manualmente. dnf repolist --enabled confirma o resultado.

Alguns pacotes do EPEL não sã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 indicar 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 predefinição na versão 10, especificamente para o evitar. --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 próxima atualização 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 imprime uma linha From repo. dnf list installed mostra a mesma informação na terceira coluna, com um @ no início. 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 indica que alguém executou rpm -i num ficheiro transferido. A linha repoquery apresenta uma contagem por repositório. É a forma mais rápida de descobrir que um servidor herdado tem quarenta pacotes de um repositório de que nunca ouviu falar. O último comando apresenta exatamente os pacotes fornecidos por um repositório. Esse inventário é necessário antes de decidir removê-lo.

O equivalente no apt é apt-cache policy <package>. Vale a pena manter as equivalências entre comandos do dnf e do apt abertas num segundo separador durante o primeiro mês, porque os conceitos correspondem, mesmo quando as flags 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 uma linguagem pode disponibilizar a sua própria compilação de uma biblioteca que o BaseOS também fornece, e o dnf instala-a, 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 seleciona então o pacote base mesmo quando a versão do repositório 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 forte. excludepkgs= bloqueia pacotes com determinados nomes num 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 fornecer o seu próprio agente pode ser configurado numa 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 definição a conhecer. Um pacote de um repositório de terceiros pode ficar oculto quando um módulo AppStream fornece o mesmo nome. A opção module_hotfixes=1 na secção desse repositório diz ao dnf para deixar de o filtrar. Se um pacote estiver visível para dnf repoquery mas não instalar num sistema com a versão 8, essa é normalmente a causa. A versão 9 removeu quase todos os módulos, por isso isto raramente acontece nessa versão.

Para fixar um pacote numa versão específica, instale python3-dnf-plugin-versionlock e use sudo dnf versionlock add <package>. Isso equivale a apt-mark hold. Tenha em atenção uma inversão que costuma causar problemas a quem vem do Debian: no apt, um Pin-Priority mais alto vence; 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 próximos para que os respetivos pacotes sejam instalados uns nos outros, mas suficientemente diferentes para que o resultado deixe de ser um sistema que alguém possa suportar.

O mecanismo são os números de versão. O CentOS Stream 9 fica à frente do RHEL 9. Por isso, apontar um sistema Rocky 9 para um repositório Stream, mesmo uma única vez e mesmo para um único pacote, deixa instalados pacotes com versões à frente de qualquer versão que o Rocky venha a disponibilizar. Quando é lançada a próxima versão minor do Rocky, a versão desse pacote é inferior à instalada. Por isso, dnf upgrade não lhe mexe. A máquina passa a executar uma combinação que ninguém testou. E permanece assim silenciosamente durante anos, enquanto assume que está atualizada.

O sintoma é dnf upgrade não indicar 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 corresponder ao que os repositórios ativados disponibilizam, incluindo downgrades. Desative primeiro o repositório externo. Depois execute a ferramenta e leia a lista proposta antes de a aceitar. A reparação falha quando o RPM mais antigo já não está disponível 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.

Os restos do ELevate são outra forma comum deste problema. O ELevate é a ferramenta de migração do AlmaLinux baseada no Leapp. É usada para atualizar um sistema CentOS 7 ou converter entre rebuilds. Uma migração feita à pressa deixa ficheiros de repositórios EL7 em /etc/yum.repos.d/ e pacotes EL7 ainda instalados. Encontre-os com rpm -qa | grep el7. Cada um deles é um pacote que nenhum repositório ativado poderá atualizar. Numa execução posterior do Leapp, são apresentados como pacotes que não podem ser mapeados. Isto transforma-se num bloqueio à atualização que terá de resolver manualmente. Remova estes restos enquanto o servidor está estável, e não no dia em que precisar da próxima atualização major.

Um repositório de um fornecedor que sobrepõe um pacote do AppStream é a versão menos grave do mesmo problema. A linha includepkgs acima é a correçã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. Por isso, um deles tem de ser removido. Tome a decisão uma vez, registe a exclusão e siga uma ordem comprovada: o guia instalação do Docker no Rocky Linux explica quais pacotes da distribuição devem ser removidos primeiro.

A tradução de apt para dnf ao configurar 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 equivalente que seja necessário memorizar. O dnf atualiza os metadados segundo o seu próprio agendamento, e dnf makecache força essa atualização imediatamente.
• apt-cache policy <pkg> torna-se dnf info <pkg>, com dnf list --showduplicates <pkg> adicional 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 funcionar na ordem inversa.
• 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 sobre reiniciar estão explicados 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ê, na sua gestão de configuração ou num ficheiro simples no servidor. Essa nota vale mais do que parece quando o servidor tem três anos e está sob responsabilidade de 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 no EPEL já está no AppStream. A monitorização do sistema é o exemplo mais claro, porque o Performance Co-Pilot é disponibilizado nos repositórios base e não precisa de qualquer componente de terceiros. Cada repositório adicional é mais uma entidade que pode disponibilizar-lhe um pacote 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 aspetos: a comparação entre Rocky Linux e AlmaLinux aborda a filosofia de reconstrução, porque o AlmaLinux agora procura compatibilidade ABI (application binary interface), em vez de uma reconstrução linha a linha.

FAQ

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

Execute sudo dnf install -y dnf-plugins-core, depois sudo dnf config-manager --set-enabled crb e, em seguida, sudo dnf install -y epel-release. Confirme com dnf repolist --enabled, que deve listar baseos, appstream, extras, crb e epel. Habilite 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, e não crb.

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

O EPEL é amplamente utilizado e segue uma política segundo a qual os seus pacotes nunca substituem pacotes da distribuição base. Portanto, habilitá-lo não altera o conteúdo fornecido 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 um mantenedor pode comprometer-se 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, e 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 o 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; e o produto da própria Red Hat chama ao conteúdo CodeReady Linux Builder. O repositório contém cabeçalhos de desenvolvimento, bibliotecas estáticas e ferramentas de compilação, e está desabilitado por padrão no Rocky e no AlmaLinux 9. O AlmaLinux 10 habilita-o por padrão a partir da versão 10.0. Por isso, verifique dnf repolist --enabled antes de executar o comando de habilitação nessa versão.

Como removo novamente o EPEL sem causar problemas?

Comece por fazer 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. Avalie 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 nenhum pacote e simplesmente tiver de ser removido, sudo dnf repository-packages epel remove limpa o conjunto numa única transação. Leia atentamente a lista proposta antes de confirmá-la.