EPEL e CRB su Rocky e AlmaLinux: guida a dnf

Perché dnf non trova il pacchetto richiesto

EPEL e CRB sono i due repository che un server Rocky Linux o AlmaLinux appena installato non include automaticamente. Per questo, su un sistema nuovo, dnf install htop risponde con No match for argument: htop e quindi con Error: Unable to find a match: htop. Non c’è alcun problema e nessun mirror è inattivo. La distribuzione di base include intenzionalmente un insieme limitato di pacchetti. CRB è presente, ma disabilitato. EPEL è invece un repository della community separato, che devi aggiungere.

Su Ubuntu lo stesso pacchetto si trova in universe e universe è abilitato su quasi tutte le immagini cloud. Per questo la domanda non si pone. La famiglia Red Hat organizza i pacchetti in modo diverso e parte da un insieme predefinito più limitato. La correzione richiede tre comandi. Il resto di questa guida riguarda un aspetto che spesso non viene spiegato durante la prima settimana: cosa offrono questi repository, cosa non garantiscono e come impedire che un repository di terze parti finisca per controllare silenziosamente il sistema di base.

Come sono stati verificati questi comandi. I nostri container di test eseguono solo Ubuntu, quindi i comandi dnf riportati di seguito non sono stati eseguiti sui nostri sistemi di test. Sono conformi alla documentazione di Rocky Linux e AlmaLinux. Ogni passaggio indica l’output previsto. Verificalo sul tuo server invece di incollare subito l’intero blocco.

Cosa sono BaseOS, AppStream e CRB?

BaseOS è il sistema operativo vero e proprio: kernel, glibc, systemd e userland di base. Le versioni restano congelate per tutta la durata della release principale e le correzioni di sicurezza vengono applicate tramite backport a queste versioni congelate. Un numero di versione che in BaseOS sembra vecchio di anni non indica un pacchetto privo di patch. Indica una versione vecchia, ma aggiornata con le patch, che è proprio lo scopo di una distribuzione enterprise.

AppStream contiene i componenti eseguiti sopra il sistema di base: web server, database, runtime dei linguaggi, editor e agent di monitoraggio. Nella versione 8, gran parte di AppStream era distribuita come moduli con stream alternativi, quindi dnf module list era importante e si sceglieva, per esempio, uno stream PHP. La versione 9 ha eliminato quasi tutta la modularità, quindi su Rocky 9 e Alma 9 normalmente si trova una sola versione di un componente e non è necessario abilitare prima alcun modulo.

Extras è abilitato per impostazione predefinita ed è molto ridotto. Contiene soprattutto i pacchetti di release per altri repository, da cui proviene epel-release stesso. Per questo non è mai necessario affidarsi a un URL casuale per installare EPEL su Rocky o Alma.

CRB è il repository CodeReady Builder, chiamato PowerTools nella versione 8. Contiene la parte della distribuzione necessaria per la compilazione: header di sviluppo, librerie statiche e strumenti di test e documentazione richiesti dai pacchetti durante la compilazione. È già presente sul mirror, ma disabilitato per impostazione predefinita. Nel prodotto Red Hat lo stesso contenuto si chiama CodeReady Linux Builder, è incluso nell'abbonamento e Red Hat dichiara che non è coperto dal supporto. Rocky e Alma ereditano sia il contenuto sia la disabilitazione predefinita.

Per chi proviene da Debian o Ubuntu: main riunisce i pacchetti runtime e gli header -dev in un unico archivio, quindi non è necessario abilitare CRB. L'equivalente più vicino a EPEL è universe, gestito dalla comunità e senza alcuna garanzia di supporto da parte del fornitore.

Che cos'è EPEL e chi lo gestisce

EPEL significa Extra Packages for Enterprise Linux. È un progetto Fedora: pacchetti presenti in Fedora, ricompilati per la release enterprise corrente e gestiti dall'EPEL Special Interest Group, composto soprattutto da volontari della community Fedora. Red Hat ospita l'infrastruttura di build e mirror e alcuni ingegneri Red Hat gestiscono pacchetti al suo interno. Il rapporto si limita a questo. EPEL non è un prodotto Red Hat. Non esistono un contratto di supporto o uno SLA (service level agreement) associati a un pacchetto EPEL, né su RHEL né su una sua ricompilazione.

Una regola rende EPEL sicuro da abilitare: un pacchetto EPEL non deve mai sostituire un pacchetto della distribuzione di base. Se AppStream distribuisce nginx, EPEL non lo farà. La regola è applicata dalle persone che revisionano i pacchetti EPEL, quindi costituisce una garanzia limitata a EPEL. Non protegge da qualunque altro componente aggiunto in seguito.

Anche la durata del supporto differisce da quella della distribuzione di base, ed è questo che può creare problemi al terzo anno. La versione di un pacchetto BaseOS resta invariata per tutti i dieci anni di vita della release principale. Un manutentore EPEL si impegna per un periodo molto più breve: almeno una release minor di RHEL o 13 mesi, a seconda di quale sia il periodo più breve. In pratica, la maggior parte dei pacchetti viene gestita molto più a lungo. Alcuni vengono ritirati quando il manutentore interrompe il lavoro, mentre altri passano a una nuova versione principale durante il ciclo di vita della distribuzione, perché EPEL segue Fedora. Di conseguenza, un normale dnf upgrade può installare una nuova versione principale di uno strumento EPEL su una macchina che si riteneva stabile; inoltre, un pacchetto da cui dipendi può smettere di ricevere aggiornamenti senza un annuncio che ti raggiunga.

Prima di abilitarlo è importante conoscere un'altra conseguenza: EPEL viene compilato per la release minor più recente di RHEL. Se mantieni un server su una release minor precedente, usando un mirror congelato o un repository del fornitore relativo a una point release, un pacchetto EPEL può richiedere una libreria di base più recente di quella disponibile. dnf segnala il problema come dipendenza mancante e può sembrare un problema del mirror, quando in realtà si tratta di una differenza di versione.

Abilitare CRB e installare EPEL su Rocky o 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 dovrebbe ora elencare baseos, appstream, extras, crb e epel. Potresti vedere anche una piccola voce epel-cisco-openh264, aggiunta da epel-release. Se crb manca dall'elenco, l'abilitazione non è andata a buon fine; la sezione successiva spiega il motivo.

Su Rocky 8 e Alma 8 il repository si chiama ancora PowerTools, quindi il comando centrale diventa sudo dnf config-manager --set-enabled powertools. Gli ID dei repository distinguono tra maiuscole e minuscole. La documentazione meno recente per CentOS 8 lo indica come PowerTools con le maiuscole, ma questo valore non corrisponde. Su AlmaLinux 10 il repository CRB è abilitato per impostazione predefinita a partire dalla versione 10.0, in seguito alla modifica di settembre 2025. In questo caso è quindi sufficiente il passaggio epel-release.

epel-release proviene da extras, che è già abilitato. Non è quindi necessario fidarsi di un URL né importare manualmente una chiave. Il pacchetto scrive /etc/yum.repos.d/epel.repo e installa la chiave di firma EPEL in /etc/pki/rpm-gpg/. Verifica gpgcheck=1 in quel file e ignora qualsiasi guida che suggerisca di aggirare un errore di firma con --nogpgcheck. Un controllo della firma non riuscito indica che il pacchetto non corrisponde a quanto dichiarato oppure che l'orologio del sistema è errato.

Su Rocky, epel-release installa anche un piccolo helper in /usr/bin/crb. Di conseguenza, sudo crb enable e crb status svolgono la stessa funzione senza il plugin. Verifica se è disponibile con command -v crb prima di farvi affidamento, perché non è presente in ogni ramo di ogni rebuild.

Per verificare che EPEL sia raggiungibile, invece di essere soltanto elencato, chiedigli un pacchetto disponibile esclusivamente in quel repository:

dnf repoquery --repo=epel htop

Il comando stampa il nome, la versione e l'architettura del pacchetto. Nessun output significa che il repository è abilitato ma non restituisce risultati. Di solito si tratta di un problema del mirror o dei metadati, non della configurazione. Prova quindi sudo dnf clean all && sudo dnf makecache.

Perché dnf restituisce “no such command: config-manager”

Questo è il primo punto che crea problemi e si verifica proprio sulle immagini fornite dalla maggior parte dei provider 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 è un plugin, non un sottocomando integrato di dnf. È incluso in dnf-plugins-core, che viene installato su un server completo, ma non nelle immagini minimali, nelle immagini cloud e nelle immagini dei container. Il suggerimento generato da dnf funziona perché il pacchetto dichiara questa capacità virtuale:

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

Racchiudetelo tra virgolette. Le parentesi fanno parte della sintassi della shell; senza virgolette, il comando restituisce un errore di sintassi invece di un errore di dnf.

Se non potete installare il plugin perché il repository necessario è quello disabilitato, modificate direttamente il file. Individuate il file che contiene la sezione, apritelo e impostate enabled=1 sotto [crb]:

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

È esattamente ciò che scrive config-manager, quindi la modifica manuale non comporta alcuna perdita. dnf repolist --enabled conferma il risultato.

Alcuni pacchetti EPEL non si installano finché CRB non è abilitato

La seconda causa comune produce un errore che non cita mai CRB. Un pacchetto EPEL che dipende da una libreria disponibile solo in CRB non supera la risoluzione delle dipendenze. Il messaggio indica la libreria e il pacchetto che la richiede:

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

La causa è che CRB è disabilitato, quindi dnf non può vedere l'unico repository che fornisce quella libreria. Verifica i due aspetti nel seguente ordine:

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

Se il secondo comando indica un pacchetto mentre la semplice installazione continua a non riuscire, CRB è disabilitato. Questo tipo di errore è abbastanza comune da aver spinto AlmaLinux ad abilitare CRB per impostazione predefinita nella versione 10, proprio per evitarlo. --enablerepo=crb funziona anche come flag una tantum per una singola installazione, ma lascia CRB abilitato in modo permanente se utilizzi EPEL, perché il successivo aggiornamento di EPEL potrebbe introdurre una nuova dipendenza da CRB senza avvisarti in anticipo.

Da quale repository proviene questo pacchetto?

Dopo alcune settimane con quattro repository abilitati, la domanda utile non è più quali pacchetti siano installati, ma da dove provengano.

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 su un pacchetto installato stampa una riga From repo. dnf list installed mostra le stesse informazioni nella terza colonna, precedute da @: @epel indica quindi che il pacchetto è stato installato da EPEL, mentre @System indica che dnf non sa da dove provenga. In genere significa che qualcuno ha eseguito rpm -i su un file scaricato. La riga repoquery mostra il numero di pacchetti per repository. È il modo più rapido per scoprire che un server ereditato contiene quaranta pacchetti provenienti da un repository di cui non hai mai sentito parlare. L'ultimo comando elenca esattamente ciò che un repository ti ha fornito. Questo inventario è necessario prima di decidere di rimuoverlo.

L'equivalente nell'ecosistema apt è apt-cache policy <package>. Le corrispondenze tra i comandi dnf e apt conviene tenerle aperte in una seconda scheda durante il primo mese, perché i concetti corrispondono anche quando le opzioni non sono le stesse.

Come impedire che un repository di terze parti sostituisca un pacchetto di base?

EPEL promette di non farlo. Nessun altro repository offre questa garanzia. Il repository di un fornitore per un database, un agent o un runtime può distribuire una propria build di una libreria già fornita da BaseOS, e dnf la installa perché la regola predefinita di dnf è semplice: vince la versione più alta, indipendentemente dalla sua origine.

Due controlli svolgono la maggior parte del lavoro ed entrambi si trovano nel file del repository in /etc/yum.repos.d/.

priority= decide quale repository ha la precedenza quando più repository contengono lo stesso nome di pacchetto. Vincono i numeri più bassi e il valore predefinito è 99. Assegna quindi un numero basso ai repository di base e uno alto a ogni repository di terze parti. dnf utilizzerà così il pacchetto di base anche quando la versione di terze parti è più recente. Le versioni moderne di dnf gestiscono questo comportamento direttamente, quindi il pacchetto separato yum-plugin-priorities dell'epoca di CentOS 7 non è più necessario.

includepkgs= è l'opzione di filtro più restrittiva. excludepkgs= blocca da un repository i pacchetti indicati, ma richiede di prevedere quali pacchetti potrebbe distribuire. includepkgs= inverte il comportamento: questo repository può fornire soltanto questi nomi, e nessun altro pacchetto. Per un repository del fornitore che deve distribuire esclusivamente il proprio agent, basta una riga.

[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

Nella versione 8 c'è un'altra impostazione da conoscere. Un pacchetto di un repository di terze parti può essere nascosto quando un modulo AppStream fornisce lo stesso nome. In questo caso, module_hotfixes=1 nella sezione del repository indica a dnf di interrompere il filtro. Se un pacchetto è visibile a dnf repoquery ma non viene installato su un sistema con versione 8, questa è di solito la causa. La versione 9 ha rimosso quasi tutti i moduli, quindi il problema si presenta raramente.

Per bloccare un pacchetto a una versione specifica, installa python3-dnf-plugin-versionlock e usa sudo dnf versionlock add <package>. È l'equivalente di apt-mark hold. Nota un'inversione che può confondere chi proviene da Debian: in apt vince un Pin-Priority più alto, mentre in dnf vince un priority più basso.

Perché la combinazione di repository adiacenti a RHEL rende un server non aggiornabile

Rocky, Alma, CentOS Stream, Oracle Linux e RHEL sono abbastanza simili da consentire l'installazione reciproca dei relativi pacchetti, ma anche abbastanza diversi da produrre un sistema che nessuno può più supportare.

Il meccanismo dipende dai numeri di versione. CentOS Stream 9 precede RHEL 9 nello sviluppo, quindi puntare un sistema Rocky 9 a un repository Stream, anche una sola volta e per un solo pacchetto, significa installare pacchetti con versioni più recenti di qualsiasi versione che Rocky rilascerà. Quando arriva la release minor successiva di Rocky, la versione di quel pacchetto è precedente a quella già installata e dnf upgrade non la sostituirà. La macchina esegue quindi una combinazione che nessuno ha testato e può rimanere così inosservata per anni, mentre si presume che sia aggiornata.

Il sintomo è dnf upgrade che non segnala nulla da fare, mentre sudo dnf distro-sync propone il downgrade di un lungo elenco di pacchetti. distro-sync è lo strumento di ripristino: forza la corrispondenza di ogni pacchetto installato con ciò che i repository abilitati offrono, inclusi i downgrade. Disabilita prima il repository estraneo, quindi esegui lo strumento e leggi l'elenco proposto prima di confermare. Il ripristino non riesce quando l'RPM precedente non è più disponibile sul mirror. In quel caso, ricreare il server da un'immagine pulita è più rapido e sicuro che forzare il risolutore delle dipendenze.

I residui di ELevate sono l'altra forma comune dello stesso problema. ELevate è lo strumento di migrazione di AlmaLinux basato su Leapp. Serve per aggiornare un sistema CentOS 7 o per convertirlo tra distribuzioni derivate. Una migrazione eseguita troppo rapidamente lascia i file dei repository EL7 in /etc/yum.repos.d/ e mantiene installati i pacchetti EL7. Individuabili con rpm -qa | grep el7. Ognuno di questi pacchetti non può essere aggiornato da alcun repository abilitato. Una successiva esecuzione di Leapp li segnala come pacchetti che non è possibile associare. Questo diventa un blocco per l'aggiornamento, da risolvere manualmente. Rimuovili mentre il server è operativo e stabile, non il giorno in cui ti serve il successivo aggiornamento major.

Un repository del fornitore che sostituisce un pacchetto AppStream è la forma meno grave della stessa anomalia, e la riga includepkgs precedente è la soluzione. Gli strumenti per i container sono il caso più comune. containerd.io proveniente dal repository di Docker entra in conflitto con runc proveniente da AppStream, quindi uno dei due deve essere rimosso. Prendi una decisione una volta sola, annota l'esclusione e segui una sequenza verificata: la guida Installare Docker su Rocky Linux indica quali pacchetti della distribuzione rimuovere per primi.

La corrispondenza tra apt e dnf per i repository

• /etc/apt/sources.list.d/*.sources diventa /etc/yum.repos.d/*.repo, dove un singolo file può contenere diversi [sections], ciascuno con il proprio ID.
• add-apt-repository universe diventa dnf install epel-release, con la differenza che universe si trova ancora nell’archivio di Ubuntu, mentre EPEL è un progetto separato.
• apt update non ha un equivalente da ricordare. dnf aggiorna i metadati secondo una propria pianificazione e dnf makecache forza l’aggiornamento immediato.
• apt-cache policy <pkg> diventa dnf info <pkg>, con dnf list --showduplicates <pkg> per visualizzare tutte le versioni disponibili.
• apt-mark hold diventa dnf versionlock add, a partire da python3-dnf-plugin-versionlock.
• Il pinning in /etc/apt/preferences.d/ diventa priority= nella sezione del repository, con numeri che aumentano nella direzione opposta.
• dpkg -S /path/to/file diventa rpm -qf /path/to/file.

Gli aggiornamenti automatici si trasferiscono come concetto, non come sintassi, perché qui non esiste unattended-upgrades. Il timer, il file di configurazione e la scelta se riavviare il sistema sono descritti in dnf-automatic su Rocky e Alma.

Riduci al minimo l’elenco dei repository

Abilita CRB, installa epel-release, quindi annota che cosa hai fatto e perché, nel sistema di gestione della configurazione oppure in un file di testo semplice sul server. Questa nota diventa molto più importante di quanto sembri quando il server ha tre anni e a gestirlo è un’altra persona.

Cerca prima di aggiungere. Esegui dnf search, poi dnf info, e solo dopo valuta l’aggiunta di un nuovo repository. Una parte sorprendentemente consistente dei pacchetti per cui si abilita EPEL è già disponibile in AppStream. Il monitoraggio del sistema è l’esempio più evidente: Performance Co-Pilot è disponibile nei repository di base e non richiede repository di terze parti. Ogni repository aggiuntivo introduce un altro soggetto che può fornirti un pacchetto da un giorno all’altro, e ciascuno rende più complesso il successivo aggiornamento principale.

Se stai ancora scegliendo tra le due distribuzioni, questa organizzazione è identica su entrambe e epel-release si comporta nello stesso modo. Le differenze effettive sono altrove: il confronto tra Rocky Linux e AlmaLinux illustra le rispettive filosofie di ricostruzione, perché AlmaLinux ora punta alla compatibilità ABI (application binary interface) anziché a una ricostruzione riga per riga.

FAQ

Come si abilita EPEL su Rocky Linux 9 o AlmaLinux 9?

Eseguire sudo dnf install -y dnf-plugins-core, quindi sudo dnf config-manager --set-enabled crb e infine sudo dnf install -y epel-release. Verificare con dnf repolist --enabled, che dovrebbe elencare baseos, appstream, extras, crb e epel. Abilitare CRB prima di installare i pacchetti EPEL, perché molti dipendono da librerie disponibili soltanto in CRB. Nella versione 8 l'ID del repository è powertools anziché crb.

È sicuro abilitare EPEL su un server di produzione?

EPEL è ampiamente utilizzato e si basa su una policy secondo cui i pacchetti EPEL non sostituiscono mai i pacchetti della distribuzione di base. La sua abilitazione non modifica quindi i contenuti forniti da BaseOS o AppStream. Il limite riguarda il supporto: EPEL è un progetto Fedora gestito da volontari e non offre alcun service level agreement. Inoltre, un maintainer può impegnarsi a mantenere un pacchetto per una sola release minor di RHEL o per 13 mesi. Mantenere un inventario con dnf repository-packages epel list installed e usare dnf versionlock per ogni pacchetto EPEL da cui dipende un servizio esposto ai clienti.

Perché dnf restituisce l'errore no such command: config-manager?

Perché config-manager è un plugin di dnf, non un comando incorporato, e le immagini minimali o quelle dei container vengono distribuite senza dnf-plugins-core. Il messaggio indica direttamente la correzione: sudo dnf install -y 'dnf-command(config-manager)', racchiuso tra virgolette affinché la shell non interpreti le parentesi. Se non è ancora possibile installare pacchetti, eseguire grep -rl crb /etc/yum.repos.d/, aprire il file indicato e impostare manualmente enabled=1 nella sezione [crb].

Qual è la differenza tra CRB e PowerTools?

Sono lo stesso repository con due nomi diversi. La versione 8 lo chiama PowerTools e usa l'ID powertools; la versione 9 e quelle successive lo chiamano CRB e usano l'ID crb. Il prodotto Red Hat equivalente chiama questo contenuto CodeReady Linux Builder. Il repository contiene header di sviluppo, librerie statiche e strumenti per la fase di build. Su Rocky e AlmaLinux 9 è disabilitato per impostazione predefinita. AlmaLinux 10 lo abilita per impostazione predefinita a partire da 10.0. Verificare quindi dnf repolist --enabled prima di eseguire il comando di abilitazione.

Come si rimuove EPEL senza causare problemi?

Creare prima un inventario con dnf repository-packages epel list installed, perché la rimozione del solo pacchetto epel-release non rimuove i pacchetti installati da EPEL. Questi pacchetti restano sul disco, perdono la sorgente degli aggiornamenti e non ricevono più correzioni di sicurezza, senza che venga generato un errore che lo segnali. Valutare ogni pacchetto singolarmente, rimuovere o sostituire quelli non più necessari e solo dopo eseguire sudo dnf remove epel-release. Se un pacchetto EPEL non ha sostituito alcun pacchetto e deve semplicemente essere rimosso, sudo dnf repository-packages epel remove elimina l'insieme in un'unica transazione. Leggere quindi con attenzione l'elenco proposto prima di confermare.