Come abilitare il repository EPEL su Amazon Linux 2

Su Amazon Linux 2 il punto da chiarire subito è questo: EPEL non si abilita “a mano” nello stesso modo di una distribuzione RHEL/CentOS classica. Nella pratica, la strada corretta passa dal pacchetto di compatibilità messo a disposizione per Amazon Linux 2 e da una verifica accurata della configurazione dei repository prima di installare qualsiasi pacchetto.

© TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster — https://trgtkls.it — tutti i diritti riservati.

Questo articolo ti mostra come arrivare a un setup pulito, come verificare che il repository sia davvero disponibile e come evitare gli errori più comuni: metadati non aggiornati, conflitti di priorità, pacchetti presi dal repository sbagliato e dipendenze trascinate senza controllo.

Perché EPEL su Amazon Linux 2 va trattato con attenzione

EPEL, cioè Extra Packages for Enterprise Linux, è una sorgente molto usata per ottenere pacchetti non inclusi nei repository base delle famiglie Enterprise Linux. Su Amazon Linux 2, però, conviene non dare per scontata la piena equivalenza con CentOS o RHEL: i repository disponibili, i nomi dei pacchetti e la loro compatibilità possono cambiare nel tempo in base al ciclo di supporto e ai pacchetti resi disponibili da Amazon.

In altre parole: prima verifichi, poi installi. È il modo più sicuro per evitare che un semplice yum install introduca dipendenze inattese o cambi comportamenti già stabili in produzione.

Verifica dello stato iniziale del sistema

Prima di toccare i repository, controlla lo stato dei sorgenti configurati. L’obiettivo è capire se il sistema vede già un pacchetto EPEL-like, se esistono repository di terze parti attivi e se la cache dei metadati è coerente.

1. Elenca i repository configurati:

sudo yum repolist all

Atteso: vedi i repository base di Amazon Linux 2 e, se già presente, un repository legato a EPEL o a compatibilità extra. KO: il repository non compare, risulta disabilitato oppure mostra errori di metadati.

1. Controlla il pacchetto che gestisce la configurazione dei repository:

rpm -qa | grep -E 'epel|amazon-linux-extras|release'

Atteso: trovi il pacchetto previsto per l’abilitazione del repository o comunque un riferimento coerente con Amazon Linux 2. KO: nessun pacchetto rilevante, oppure versioni incoerenti rispetto alla distribuzione in uso.

1. Pulisci eventuali metadati vecchi prima di procedere:

sudo yum clean all
sudo yum makecache

Atteso: la cache si rigenera senza errori HTTP, DNS o timeout. Se la cache fallisce, il problema non è EPEL ma la connettività o il mirror configurato.

Abilitazione del repository EPEL su Amazon Linux 2

Il metodo corretto dipende dalla disponibilità del pacchetto nel tuo ambiente. Nella maggior parte dei casi, il passaggio operativo è installare il pacchetto di rilascio EPEL compatibile con Amazon Linux 2 e poi verificare che il file di repository sia stato creato in modo corretto.

1. Installa il pacchetto di rilascio EPEL compatibile, se disponibile nei repository abilitati:

sudo yum install -y epel-release

Atteso: il pacchetto viene installato senza conflitti e crea i file di repository sotto /etc/yum.repos.d/. KO: il pacchetto non esiste nei repository attivi oppure la dipendenza non è risolvibile.

Se il comando precedente non trova epel-release, non forzare pacchetti casuali presi da altre release. In quel caso devi prima verificare quali repository aggiuntivi sono davvero supportati nel tuo ambiente Amazon Linux 2 e, solo dopo, scegliere una sorgente compatibile.

1. Verifica che il file repository sia stato creato e contenga i parametri giusti:

ls -l /etc/yum.repos.d/ | grep -i epel
cat /etc/yum.repos.d/epel.repo

Atteso: il file epel.repo esiste ed è leggibile. Dentro dovresti trovare una sezione repository con enabled=1 o comunque una configurazione coerente con l’abilitazione desiderata. KO: il file manca, è vuoto o ha impostazioni disabilitate.

1. Ricarica la cache dei metadati e verifica che il repository risulti attivo:

sudo yum clean all
sudo yum repolist enabled

Atteso: EPEL compare tra i repository abilitati e non ci sono errori di recupero metadati. Se il repository appare ma non scarica i dati, il problema è quasi sempre nella raggiungibilità del mirror o in un filtro di rete.

Controllo dei metadati e priorità dei repository

Una volta abilitato il repository, il rischio principale non è tanto “averlo attivato”, ma averlo attivato male. Su sistemi che usano più repository contemporaneamente, un pacchetto può arrivare dal sorgente sbagliato se la priorità non è chiara o se il pacchetto base e quello extra hanno nomi simili.

Per ridurre il rischio, verifica sempre quale repository fornisce il pacchetto che vuoi installare.

sudo yum info nomepacchetto
sudo yum list available | grep -i nomepacchetto

Atteso: il pacchetto compare nel repository corretto e la versione proposta è quella che ti aspetti. KO: versioni multiple, provenienze diverse o dipendenze non allineate.

Se gestisci ambienti con molti repository, valuta anche il file di configurazione della priorità dei repo, quando presente. Non è un dettaglio cosmetico: in produzione evita che EPEL sovrascriva componenti base con build non previste.

Installazione di prova di un pacchetto EPEL

Il modo più pulito per confermare che EPEL sia davvero operativo è installare un pacchetto noto e innocuo, usato spesso come test. L’idea è verificare il percorso completo: repository attivo, download dei metadati, risoluzione dipendenze, installazione.

1. Scegli un pacchetto non critico e verifica la disponibilità:

sudo yum search nomepacchetto

Atteso: il pacchetto viene trovato e mostra il repository di origine. Se non compare, EPEL potrebbe non essere realmente attivo oppure il pacchetto non è più presente nel ramo compatibile con Amazon Linux 2.

1. Installa il pacchetto e osserva l’origine dei file:

sudo yum install -y nomepacchetto
rpm -qi nomepacchetto

Atteso: l’installazione si completa e rpm -qi mostra un pacchetto coerente con il repository extra. KO: conflitti di dipendenze, versione errata o pacchetto installato da un repository inatteso.

Errori tipici e come leggerli in fretta

Quando l’abilitazione fallisce, il messaggio d’errore guida quasi sempre verso una delle cause sotto. La lettura rapida evita tentativi alla cieca.

• Repository non trovato: il pacchetto di release non è disponibile o il sistema non ha accesso al mirror corretto.
• Errore di metadati: la cache è corrotta, il mirror risponde male o c’è un problema di rete.
• Conflitto di dipendenze: un pacchetto EPEL richiede librerie non presenti o versioni incompatibili con Amazon Linux 2.
• Pacchetto presente ma non installabile: il repository è visibile, ma il ramo della release non contiene più quel build.

Se vuoi una verifica chirurgica, guarda l’output completo del gestore pacchetti e non solo la riga finale. Nei casi di errore di rete, il punto debole emerge quasi sempre in uno di questi tre livelli: DNS, reachability HTTP verso il mirror, oppure filtro proxy/firewall.

Approccio sicuro in produzione

Su un host in produzione, l’abilitazione di EPEL va trattata come un change controllato. Prima di procedere, salva lo stato dei repository e annota i pacchetti che intendi installare. Se qualcosa va storto, devi poter tornare al punto di partenza senza rimettere mano a mezzo sistema.

1. Salva una copia dei repository attivi:

sudo cp -a /etc/yum.repos.d /root/yum.repos.d.backup.$(date +%F)

Rollback: ripristino della directory da backup se il cambio introduce repository indesiderati o comportamenti anomali. Blast radius: limitato alla configurazione yum/dnf e ai pacchetti installati dopo il cambio.

1. Documenta il pacchetto che stai installando e la versione attesa:

Qui non serve inventare nulla: la versione va letta dal repository o dal manifest del tuo stack applicativo. Se il pacchetto è parte di un’applicazione, verifica anche l’eventuale compatibilità con PHP, OpenSSL, librerie di sistema e servizi già in esecuzione.

1. Dopo l’installazione, controlla i servizi coinvolti e i log recenti:

systemctl --failed
journalctl -p err -n 50 --no-pager

Atteso: nessun servizio nuovo in failed state e nessun errore correlato al pacchetto appena aggiunto. Se compare un problema, il rollback deve essere immediato e limitato al pacchetto o al repository appena introdotto.

Rollback operativo

Se il repository è stato abilitato ma non vuoi mantenerlo, il rollback più semplice è disabilitare il repo e rimuovere il pacchetto di release, sempre dopo aver verificato che non ci siano dipendenze dirette da esso.

sudo sed -i 's/^enabled=1/enabled=0/' /etc/yum.repos.d/epel.repo
sudo yum clean all

Atteso: il repository non compare più tra quelli attivi e la cache viene rigenerata senza includerlo. Se vuoi un rollback più netto, valuta la rimozione del pacchetto di release solo dopo aver controllato che nessun pacchetto installato dipenda da quel repository per aggiornamenti futuri.

Checklist finale

• Il repository EPEL compare in yum repolist enabled.
• /etc/yum.repos.d/epel.repo esiste ed è coerente con l’abilitazione prevista.
• I metadati si aggiornano senza errori con yum makecache.
• Il pacchetto di test viene risolto dal repository corretto.
• Non ci sono servizi in errore dopo l’installazione.

Assunzione operativa: il sistema è Amazon Linux 2 standard, con accesso Internet o a un mirror aziendale funzionante, e il repository EPEL viene usato per installare pacchetti non critici o già validati in staging.