Come installare OpenStackClient su Rocky Linux e AlmaLinux 8

OpenStackClient su Rocky Linux 8 e AlmaLinux 8 si installa senza difficoltà, ma vale la pena scegliere con attenzione il metodo: pacchetti del sistema, repository aggiuntivi oppure ambiente Python isolato. La differenza non è cosmetica. Cambia la gestione degli aggiornamenti, il rischio di conflitto con librerie di sistema e la facilità con cui mantieni il client allineato alla tua cloud.

In pratica, il percorso più solido dipende da come usi il nodo. Se ti serve una postazione amministrativa pulita e vuoi evitare di sporcare il sistema, l’approccio con virtualenv resta il più prevedibile. Se invece hai bisogno di una macchina “di servizio” con strumenti standardizzati e aggiornamenti gestiti dal package manager, i pacchetti RPM sono la scelta naturale. Su Rocky e AlmaLinux 8 la compatibilità con OpenStackClient è buona, ma conviene verificare sempre la versione disponibile nei repository abilitati prima di affidarsi al primo pacchetto trovato.

Quale problema risolve OpenStackClient

OpenStackClient è il client unificato da linea di comando per interagire con i servizi OpenStack: compute, networking, storage, identity e così via. Invece di usare utility separate per ogni componente, lavori con un unico comando base, openstack, e sottocomandi coerenti tra loro. Questo riduce gli errori operativi, soprattutto quando cambi progetto, regione o profilo di autenticazione.

Per un amministratore, il punto non è solo “installarlo”, ma farlo in modo ripetibile. Su sistemi RHEL-like di ottava generazione, i pacchetti possono arrivare da repository di distribuzione, da canali aggiuntivi o da Python Package Index. Ogni scelta ha effetti diversi su dipendenze, supporto e manutenzione.

Verifica preliminare dei repository su Rocky e AlmaLinux 8

Prima di installare, controlla quali repository sono attivi e quali moduli o pacchetti Python hai già nel sistema. In molti casi il problema non è OpenStackClient in sé, ma un repository mancante o disallineato che porta versioni vecchie o dipendenze incomplete.

Per una verifica rapida:

sudo dnf repolist
sudo dnf module list python3

Se i repository base sono attivi e il sistema è aggiornato, hai già una buona base. In caso di installazioni minime, può mancare qualche dipendenza di Python o un canale necessario a risolvere il pacchetto. Se non sai quali repository siano abilitati nel tuo ambiente, questo è il primo dato da raccogliere prima di procedere.

Metodo consigliato: virtualenv per un client isolato

Se vuoi evitare conflitti con i pacchetti del sistema, crea un ambiente virtuale dedicato. È l’opzione che consiglio quando il nodo serve soprattutto come workstation di amministrazione o jump host per operazioni OpenStack. Ti lascia libertà di aggiornare il client senza toccare il Python di sistema.

Installa prima gli strumenti necessari:

sudo dnf install -y python3 python3-pip python3-virtualenv

Su alcuni sistemi python3-virtualenv può non essere necessario se usi il modulo venv incluso in Python 3, ma installarlo non crea problemi e semplifica il lavoro in ambienti dove la dotazione iniziale è ridotta.

Crea una directory dedicata e un ambiente isolato:

mkdir -p ~/venv-openstack
python3 -m venv ~/venv-openstack/osc

Attiva l’ambiente:

source ~/venv-openstack/osc/bin/activate

A questo punto installa OpenStackClient con pip:

pip install --upgrade pip
pip install python-openstackclient

La verifica più semplice è controllare la versione e l’help del comando:

openstack --version
openstack --help

Output atteso: il comando deve rispondere con una versione coerente con i pacchetti installati nel virtualenv e mostrare l’elenco dei sottocomandi principali. Se ricevi errori su librerie mancanti, il problema è quasi sempre nel set di dipendenze Python del virtualenv o nel fatto che il pacchetto non è stato installato nell’ambiente attivo.

Installazione con pacchetti RPM: quando conviene

Se vuoi un’installazione più “sistemica”, prova prima il pacchetto disponibile nei repository abilitati. È la strada da preferire quando il nodo è gestito con policy standard, strumenti di patching centralizzati o un workflow che richiede meno dipendenze custom.

La ricerca del pacchetto si fa così:

sudo dnf search openstackclient
sudo dnf info python3-openstackclient

Se il pacchetto è disponibile, installalo con:

sudo dnf install -y python3-openstackclient

Qui il vantaggio è la semplicità: niente ambienti da attivare, niente path personalizzati, aggiornamenti gestiti da dnf update. Lo svantaggio è che potresti non avere l’ultima release di OpenStackClient oppure potresti ereditare una combinazione di dipendenze decisa dal maintainer del repository.

Verifica l’installazione con:

rpm -q python3-openstackclient
openstack --version

Se il pacchetto risulta installato ma il comando non viene trovato, controlla il path:

command -v openstack
echo $PATH

In un’installazione RPM corretta, il binario deve trovarsi in un percorso standard come /usr/bin/openstack. Se il percorso non è presente, c’è un problema di installazione o di ambiente shell.

Quando il pacchetto non c’è: repository aggiuntivi e dipendenze

Non tutti gli ambienti hanno OpenStackClient nei repository base. In quel caso, la domanda vera non è “come forzarlo”, ma “da quale canale devo prenderlo senza introdurre disordine”. La scelta dipende dalla tua politica di piattaforma. In ambienti enterprise, spesso il client viene distribuito tramite repository interni o mirror controllati; in ambienti più piccoli, il virtualenv resta la soluzione più pulita.

Se usi repository esterni, documenta sempre la provenienza del pacchetto e mantieni una copia della configurazione del repository. Prima di aggiungere sorgenti nuove, verifica il rischio di conflitto con librerie Python già presenti nel sistema.

Un controllo utile è vedere quali dipendenze verrebbero installate o aggiornate:

sudo dnf deplist python3-openstackclient

Se il comando mostra dipendenze non risolte o versioni incompatibili, fermati lì e non procedere alla cieca. In questi casi è meglio tornare al virtualenv o sistemare il repository corretto piuttosto che trascinare nel sistema pacchetti eterogenei.

Configurare le credenziali OpenStack in modo ordinato

Installare il client è solo metà del lavoro. Per usarlo davvero ti serve un file di ambiente o variabili coerenti con la cloud di riferimento. Il metodo più comune è un file RC fornito dall’admin o generato dal dashboard, che imposta endpoint, progetto, utente e dominio.

Un file tipico viene caricato così:

source ~/openrc

Subito dopo, fai una verifica non distruttiva:

env | grep -E '^OS_'
openstack token issue

Se openstack token issue restituisce un token valido, il client è installato e autenticato correttamente. Se invece ottieni errori di autenticazione, il problema potrebbe essere nel file RC, nel certificato, nell’endpoint identity o nel clock del sistema. Non dare per scontato che sia un errore del client: spesso il client funziona e fallisce l’autenticazione per cause esterne.

Problemi tipici su Rocky e AlmaLinux 8

Ci sono alcuni casi ricorrenti che vale la pena riconoscere subito. Il primo è l’incompatibilità tra versioni di Python e pacchetti installati in modo misto, ad esempio un client installato via pip che si appoggia a librerie di sistema non coerenti. Il secondo è la presenza di più installazioni di openstack nel path, che porta a usare un binario diverso da quello appena installato.

Per diagnosticare il primo caso, controlla dove sta prendendo il comando e quali moduli Python usa:

which openstack
python3 -c 'import sys; print(sys.executable)'
pip show python-openstackclient

Se which openstack punta a un binario inatteso, hai trovato il conflitto. Se pip show non restituisce il pacchetto nel virtualenv, probabilmente stai usando il pip sbagliato o non hai attivato l’ambiente.

Per il secondo caso, un controllo dei conflitti RPM aiuta a capire se il sistema ha più versioni o file sovrapposti:

rpm -qa | grep -i openstackclient

Se trovi più pacchetti o installazioni sovrapposte, la soluzione più sicura è scegliere un solo metodo e rimuovere il resto con cautela, dopo aver verificato quale binario è effettivamente usato in produzione o negli script.

Uso operativo essenziale del client

Una volta installato, i comandi più utili sono quelli di verifica e inventario. Non serve partire subito con operazioni invasive. Meglio confermare che il client legga correttamente il contesto e poi interrogare la cloud in modo progressivo.

Esempi utili:

openstack server list
openstack image list
openstack volume list
openstack network list

Se uno di questi comandi fallisce, il messaggio di errore è più importante del comando stesso. Un errore di endpoint indica un problema di configurazione; un errore di autorizzazione punta a credenziali o ruoli; un timeout suggerisce rete, DNS o service endpoint non raggiungibile.

Aggiornamenti, manutenzione e rollback

Se hai scelto il virtualenv, l’aggiornamento è semplice e reversibile. Prima di toccare il client, annota la versione in uso e conserva il requirements installato, così puoi tornare indietro se una release nuova introduce regressioni.

source ~/venv-openstack/osc/bin/activate
pip freeze > ~/venv-openstack/requirements.txt
pip install --upgrade python-openstackclient

Rollback nel virtualenv:

pip install -r ~/venv-openstack/requirements.txt

Se invece hai usato RPM, il rollback dipende dalla disponibilità della versione precedente nel repository o nella cache locale. In ambienti gestiti, conviene mantenere una finestra di aggiornamento breve e testare il client su una macchina di staging prima di distribuirlo ovunque. Il raggio d’azione di un aggiornamento del client è limitato, ma non nullo: può rompere script automatizzati o alias che dipendono da opzioni deprecate.

Scelta pratica consigliata

Se vuoi un consiglio netto: su Rocky Linux e AlmaLinux 8, per una postazione di amministrazione usa virtualenv con python-openstackclient via pip. È il metodo più pulito, il più facile da isolare e quello che crea meno attrito tra versioni di sistema e versioni del client. Se il nodo deve essere standardizzato con gli altri strumenti del sistema, allora prova prima il pacchetto RPM disponibile nei repository ufficiali o interni.

La regola operativa resta la stessa: installa, verifica il binario, conferma il contesto OpenStack con openstack token issue e solo dopo passa ai comandi di gestione delle risorse. Così separi i problemi di installazione da quelli di autenticazione e dalla salute della cloud, evitando di inseguire falsi positivi.

Assunzione: il sistema è Rocky Linux 8 o AlmaLinux 8 aggiornato, con accesso a repository funzionanti e credenziali OpenStack già disponibili per i test di autenticazione.