Comandi per installare pacchetti RPM su CentOS e Red Hat

Su CentOS e Red Hat il modo corretto di installare un pacchetto RPM dipende da cosa vuoi ottenere: installazione da repository, file locale, verifica di dipendenze, ispezione del contenuto o recupero di informazioni prima del deploy. Nella pratica, il comando giusto non è sempre `rpm -i`: per la maggior parte dei casi operativi conviene passare da `dnf` o `yum`, perché risolvono le dipendenze e tengono traccia dello stato del sistema in modo coerente.

La differenza è semplice ma importante. `rpm` lavora direttamente sul database locale dei pacchetti e non scarica dipendenze da solo. `yum` e `dnf` invece interrogano i repository configurati, calcolano le dipendenze e installano tutto quello che serve. Se stai gestendo server in produzione, questa distinzione ti evita metà dei problemi classici: librerie mancanti, upgrade parziali, pacchetti “presenti ma rotti”, rollback complicati.

La regola pratica: repository prima, file locale solo quando serve

Se il pacchetto è disponibile in un repository affidabile, usa `dnf install` su CentOS 8/Stream e Red Hat Enterprise Linux 8/9, oppure `yum install` sulle release più vecchie. Se invece hai un file `.rpm` scaricato a mano, puoi installarlo con `dnf install ./pacchetto.rpm`, che è preferibile a `rpm -i` perché prova comunque a risolvere le dipendenze dai repository configurati.

Un errore frequente è trattare ogni RPM come un file qualsiasi. In realtà un RPM è un’unità coerente con metadati, dipendenze e script di installazione. Se forzi l’installazione con `rpm --nodeps` o `rpm -ivh --force`, stai aggirando i controlli che ti proteggono da un sistema incoerente. In ambiente di test può avere senso, in produzione no, salvo contesto ben chiaro e piano di rollback.

Installazione da repository con dnf o yum

Il caso più comune è l’installazione di un pacchetto direttamente dai repository configurati. Qui il comando è lineare:

sudo dnf install nginx

Su sistemi più vecchi o dove `dnf` non è ancora il gestore principale, il comando equivalente è:

sudo yum install nginx

Prima di confermare, il gestore mostra il riepilogo delle dipendenze, la dimensione del download e i pacchetti coinvolti. È il punto in cui controlli se stai per introdurre componenti inattesi. In un server esposto, questo passaggio va letto davvero, non premuto a occhi chiusi.

Se vuoi fare una verifica preventiva senza modificare nulla, usa il simulatore:

sudo dnf install --assumeno nginx

Il risultato atteso è che `dnf` mostri il piano di installazione e poi si fermi senza applicare cambiamenti. È utile quando devi validare il comportamento di una nuova repo o capire se un aggiornamento trascina dipendenze indesiderate.

Installare un file RPM locale con dnf

Quando hai già il file RPM in locale, il metodo più pulito resta `dnf install` puntando al percorso del file. Esempio:

sudo dnf install ./mio-pacchetto-1.2.3-1.el8.x86_64.rpm

Il prefisso `./` è importante: segnala a `dnf` che stai passando un file locale, non il nome di un pacchetto da repository. In questo modo il gestore può comunque cercare e risolvere le dipendenze nei repository abilitati. Se manca una dipendenza, riceverai un errore esplicito invece di un’installazione monca.

Se il file è stato scaricato da una sorgente esterna, prima di installarlo conviene verificarne l’integrità e l’origine. Al minimo controlla checksum o firma GPG, se disponibili. In contesti di sicurezza più rigidi, questo non è un optional: un RPM non verificato è un vettore di supply-chain risk, non solo un file da installare.

Per vedere cosa contiene un file RPM senza installarlo, usa `rpm -qip` per i metadati e `rpm -qlp` per l’elenco dei file:

rpm -qip ./mio-pacchetto-1.2.3-1.el8.x86_64.rpm
rpm -qlp ./mio-pacchetto-1.2.3-1.el8.x86_64.rpm

Il primo comando mostra nome, versione, release, architettura, summary e dipendenze dichiarate. Il secondo elenca i file che verranno posizionati sul filesystem. È un controllo veloce ma molto utile prima di toccare un nodo critico.

Quando usare rpm direttamente

`rpm` è lo strumento basso livello. Lo usi quando vuoi interrogare il database locale, installare un pacchetto senza passare dal resolver di `dnf`, verificare firme, elencare file o controllare quale pacchetto possiede un certo binario. Per installazione pura, il comando classico è:

sudo rpm -ivh ./mio-pacchetto-1.2.3-1.el8.x86_64.rpm

Le opzioni significano questo: `-i` installa, `-v` mostra output verboso, `-h` stampa le barre di avanzamento. È comodo, ma non risolve dipendenze. Se il pacchetto dipende da librerie mancanti, l’installazione fallisce. Questo fallimento non è un difetto: è il comportamento corretto, perché ti segnala che il sistema non è pronto.

Se ti serve aggiornare un pacchetto già presente, `rpm -Uvh` sostituisce la versione precedente quando possibile:

sudo rpm -Uvh ./mio-pacchetto-1.2.4-1.el8.x86_64.rpm

Anche qui il limite resta lo stesso: niente risoluzione automatica delle dipendenze. Per questo, in ambienti reali, `rpm` è più adatto a verifiche, audit e casi particolari che non alla gestione ordinaria dei software stack.

Controllare firma, provenienza e integrità

Prima di installare un RPM scaricato da una sorgente esterna, verifica la firma GPG se il pacchetto è firmato. Il controllo base è:

rpm -K ./mio-pacchetto-1.2.3-1.el8.x86_64.rpm

L’output atteso in un caso sano è qualcosa che indichi integrità e firma valide, ad esempio `digests signatures OK`. Se il pacchetto proviene da un repository aziendale, la chiave pubblica deve essere già importata nel sistema o distribuita tramite canale controllato. Se non lo è, non compensare con eccezioni manuali: il punto non è “far partire l’installazione”, ma mantenere verificabile la catena di fiducia.

Per vedere quali chiavi GPG sono presenti nel database RPM, puoi usare:

rpm -qa gpg-pubkey\*

Se devi importare una chiave di repository, fallo solo da fonte attendibile e documentata. Il comando tipico è `rpm --import`, ma il valore operativo sta nel sapere da dove arriva la chiave e come viene ruotata quando cambia il repository. In altre parole: la sicurezza non è il comando, è il processo attorno al comando.

Capire cosa installerai prima di toccare il sistema

Quando lavori su server condivisi o nodi delicati, prima di installare conviene capire se il pacchetto è già presente, quale versione è installata e a quale repository appartiene. Alcuni comandi utili:

rpm -q nginx
rpm -qi nginx
rpm -ql nginx

`rpm -q` verifica se il pacchetto esiste nel database locale. `rpm -qi` mostra i metadati del pacchetto installato. `rpm -ql` elenca i file installati. Se il pacchetto non è presente, il comando restituisce un messaggio chiaro come `package nginx is not installed`.

Per cercare quale pacchetto fornisce un file o un binario, su sistemi con repository abilitati puoi usare `dnf provides` o `repoquery`:

dnf provides /usr/sbin/nginx
repoquery -f /usr/sbin/nginx

Questo è utile quando hai un errore di servizio e vuoi capire rapidamente se manca il pacchetto giusto o se il binario è stato rimosso da un upgrade incompleto.

Repository locali, file .repo e gestione della sorgente

Nella gestione quotidiana dei server, il problema spesso non è installare un RPM ma rendere ripetibile l’installazione. Per questo i repository contano più del singolo file. I file di configurazione dei repository stanno normalmente in `/etc/yum.repos.d/`. Ogni file `.repo` definisce un blocco con nome, baseurl, enabled e gpgcheck.

Esempio minimale di repository:

[azienda-app]
name=Azienda App Repository
baseurl=https://repo.example.com/el8/
enabled=1
gpgcheck=1
gpgkey=https://repo.example.com/RPM-GPG-KEY-azienda

Con una configurazione simile, l’installazione diventa ripetibile e l’audit più semplice. Se hai bisogno di disabilitare temporaneamente una sorgente, puoi farlo nel file `.repo` o con opzioni a comando. La scelta dipende dalla durata del cambio: per una modifica rapida e circoscritta, il flag a riga di comando è meno invasivo; per un cambio strutturale, meglio aggiornare il file e versionarlo in gestione configurazione.

Disabilitare o abilitare repository al bisogno

Se un sistema ha più repository e vuoi evitare che `dnf` prenda pacchetti da una sorgente sbagliata, puoi filtrare il comportamento. Per esempio, installare da un repository specifico:

sudo dnf --enablerepo=azienda-app install mio-pacchetto

Oppure escludere temporaneamente un repository problematico:

sudo dnf --disablerepo=repo-terze-parti install mio-pacchetto

Questa tecnica è utile quando una repo esterna introduce conflitti di versione o dipendenze incoerenti. Il punto non è “nascondere” il problema, ma ridurre il blast radius mentre verifichi quale sorgente sta contaminando il piano di installazione.

Verifiche dopo l’installazione

Dopo l’installazione, non fermarti al messaggio di successo. Controlla almeno tre cose: presenza del pacchetto, servizio avviato se previsto, e integrità dei file principali. Un set minimo di verifiche può essere questo:

rpm -q nginx
systemctl status nginx --no-pager
ss -ltnp | grep ':80\|:443'

Il primo comando conferma la presenza del pacchetto. Il secondo mostra se il servizio è attivo o se è fallito in avvio. Il terzo verifica che il demone stia realmente ascoltando sulle porte attese. Se il pacchetto è installato ma il servizio è down, il problema non è più l’RPM: bisogna guardare configurazione, permessi, dipendenze runtime o errori nei log.

Per i servizi gestiti da systemd, il log più utile è spesso quello del journal:

journalctl -u nginx -b --no-pager

Se l’errore riguarda un’applicazione web o un componente custom, cerca anche i log applicativi nel path previsto dalla distro o dal pacchetto. Su sistemi LAMP/LEMP il punto di rottura spesso non è l’installazione del binario ma la configurazione del servizio e dei suoi moduli.

Rimozione, downgrade e reinstallazione pulita

Quando un pacchetto crea problemi, la rimozione va fatta con criterio. Con `dnf` o `yum` puoi disinstallare in modo coerente con il database dei pacchetti:

sudo dnf remove nginx

Se devi tornare a una versione precedente, il downgrade è possibile quando la versione vecchia è disponibile nei repository o nel cache locale:

sudo dnf downgrade nginx

In caso di reinstallazione pulita, prima rimuovi il pacchetto, poi verifica che non restino file di configurazione critici o directory di stato che possano influenzare il nuovo avvio. Attenzione però: cancellare manualmente file in `/etc` o sotto `/var/lib` senza sapere chi li usa è spesso peggio del problema iniziale. Se devi intervenire, documenta i path coinvolti e conserva un backup.

Errori tipici e come leggerli

Alcuni errori ricorrono spesso. `Nothing to do` significa che il pacchetto è già presente o che il nome non corrisponde a nulla di installabile. `No match for argument` indica che il nome del pacchetto non è disponibile nei repository attivi. `conflicting requests` o `problem with installed package` suggeriscono un conflitto tra versioni o dipendenze. `Failed to download metadata` punta invece a un problema di rete, DNS, proxy o repository non raggiungibile.

Quando il messaggio è poco chiaro, il metodo corretto è restringere il campo. Prima controlla la connettività verso il repository, poi la risoluzione DNS, poi l’accesso HTTPS e infine la validità dei metadati. Un test rapido può essere:

curl -I https://repo.example.com/el8/repodata/repomd.xml
getent hosts repo.example.com

Se `curl` fallisce ma `getent hosts` funziona, il problema è più probabilmente TLS, proxy o firewall. Se fallisce anche la risoluzione, la radice è DNS. Questa separazione evita di perdere tempo su `dnf` quando il guasto è altrove.

Gestione dei pacchetti in contesti automatici

In ambienti automatizzati, il pacchetto non va installato “a mano” ma tramite script idempotenti, playbook o pipeline. Il comando di base resta simile, ma il controllo cambia: devi poter eseguire lo stesso task più volte senza effetti collaterali. Con Ansible, per esempio, il modulo `dnf` o `yum` gestisce bene questo scenario perché evita reinstallazioni inutili e segnala solo i cambiamenti effettivi.

Un esempio concettuale è questo: se il tuo sistema di provisioning deve garantire la presenza di `nginx`, il flusso corretto è verificare lo stato desiderato, applicare il pacchetto solo se manca e poi controllare il servizio. L’errore da evitare è lanciare installazioni ripetute senza stato, perché in un parco macchine grande questo produce drift e diagnosi più lente.

Scelta operativa finale

Se devi ricordare una sola regola, tieni questa: usa `dnf` o `yum` per quasi tutto, usa `rpm` per ispezionare o per casi speciali. Installa da repository quando puoi, da file locale quando serve, e verifica sempre firma, dipendenze e stato del servizio dopo l’installazione. Su CentOS e Red Hat la differenza tra un sistema stabile e uno fragile spesso non sta nel comando in sé, ma nel fatto che il comando sia stato scelto con il livello giusto di controllo.

In pratica, la sequenza più solida è: identificare il pacchetto, controllare la fonte, simulare l’installazione, applicare il cambio, verificare servizio e log. È una routine semplice, ma è anche quella che riduce gli errori più costosi nei server Linux di produzione.