1 03/11/2026 9 min

IBM Cloud CLI si installa bene su Linux, ma conviene farlo con un metodo coerente con l’uso che ne farai: workstation, jump host, macchina di build o server amministrativo. La scelta giusta non è solo “come si installa”, ma anche come si aggiorna, come si verifica l’integrità del pacchetto e come si evita di sporcare il sistema con file sparsi in home o nel PATH.

In pratica hai tre strade sensate: usare il metodo ufficiale via script di installazione, installare il pacchetto nativo se disponibile per la tua distribuzione, oppure usare un’installazione locale per utente quando non hai privilegi root o non vuoi toccare il sistema. La procedura cambia poco nel risultato finale, ma cambia molto in termini di manutenzione e rollback.

Prerequisiti minimi e scelta del metodo

Prima di iniziare, verifica questi punti:

  • una distribuzione Linux recente con accesso a internet;
  • permessi di scrittura nella home dell’utente o privilegi amministrativi se vuoi installare a livello di sistema;
  • curl e bash disponibili, perché il metodo ufficiale li usa spesso come base operativa;
  • spazio libero sufficiente in /usr/local o nella directory home, a seconda del tipo di installazione.

Se lavori su una macchina condivisa o gestita da policy restrittive, la scelta più prudente è l’installazione per utente. Se invece stai preparando una macchina amministrativa standardizzata, ha più senso un’installazione di sistema con percorso stabile e aggiornamenti documentati.

Installazione con metodo ufficiale IBM

Il canale più lineare è quello ufficiale IBM, che in genere fornisce un installer o un pacchetto adatto alla piattaforma. La logica è semplice: scarichi il componente corretto, lo lanci, poi verifichi che il binario sia raggiungibile dal terminale e che la versione corrisponda a quella prevista.

Un flusso tipico, da adattare alla pagina ufficiale del prodotto, è questo:

curl -fsSL <URL_UFFICIALE_IBM_CLOUD_CLI> -o ibmcloud-installer.sh
bash ibmcloud-installer.sh

Il punto critico qui non è il comando in sé, ma la fonte del file. Usa sempre l’URL ufficiale della documentazione IBM per il tuo sistema operativo e la tua architettura. Se il link cambia, non forzare mirror casuali: è un software che userai per autenticarti e interagire con ambienti cloud, quindi la provenienza conta più della comodità.

Dopo l’installazione, controlla subito se il comando è nel PATH:

which ibmcloud
ibmcloud --version

Se which non restituisce nulla, il problema non è necessariamente l’installazione: può essere un PATH non aggiornato, un’installazione locale che richiede l’inizializzazione della shell oppure un binario collocato in una directory non inclusa nella variabile d’ambiente. In quel caso conviene aprire una nuova sessione terminale e, se serve, verificare il file di startup della shell.

Installazione per utente senza toccare il sistema

Se non hai root o vuoi mantenere l’ambiente separato dal sistema, l’installazione in home è la scelta più pulita. È anche quella più semplice da rimuovere: in genere basta cancellare la directory dell’applicazione e togliere la riga di export dal profilo shell.

Il principio è sempre lo stesso: scarichi il pacchetto, lo estrai nella tua home, poi aggiungi la directory dei binari al PATH. Un esempio generico, da adattare al formato distribuito da IBM, è questo:

mkdir -p ~/opt/ibmcloud
cd ~/opt/ibmcloud
curl -fsSL <URL_UFFICIALE_IBM_CLOUD_CLI> -o ibmcloud.tar.gz
tar -xzf ibmcloud.tar.gz

A questo punto devi rendere eseguibile il binario e renderlo visibile alla shell. In molti casi il pacchetto crea già una struttura pronta, quindi il passaggio reale è solo l’export del PATH:

echo 'export PATH="$HOME/opt/ibmcloud/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc
ibmcloud --version

Se usi zsh, il file giusto è di solito ~/.zshrc. Se lavori su host condivisi con policy severe, evita di modificare file di sistema come /etc/profile o /etc/bashrc senza una richiesta esplicita: il blast radius sarebbe troppo ampio per una semplice CLI utente.

Installazione di sistema e impatto operativo

Quando l’installazione è globale, il vantaggio è la standardizzazione: tutti gli operatori trovano lo stesso comando nello stesso posto. Lo svantaggio è che ogni aggiornamento o rimozione ha effetto su più utenti e può rompere automazioni che si aspettano una certa versione.

Il posizionamento più comune è sotto /usr/local/bin o in una directory dedicata sotto /opt, con un symlink verso una cartella presente nel PATH. Questa soluzione è spesso più robusta di un’estrazione “a caso” direttamente in root del filesystem, perché separa chiaramente i file dell’applicazione dal resto del sistema.

Un esempio operativo, quando hai già estratto i file in una directory stabile:

sudo ln -s /opt/ibmcloud/bin/ibmcloud /usr/local/bin/ibmcloud
ibmcloud --version

Qui il rollback è immediato: rimuovi il symlink e lasci intatta la directory applicativa. È una delle ragioni per cui i collegamenti simbolici sono preferibili a copie sparse del binario in più punti del filesystem.

Verifica dell’installazione e controllo della versione

La verifica non dovrebbe limitarsi a “il comando parte”. Devi controllare almeno tre cose: che il binario sia raggiungibile, che la versione sia quella attesa e che la shell non stia risolvendo un vecchio path per errore.

Il controllo minimo è questo:

command -v ibmcloud
ibmcloud --version

Se command -v restituisce un percorso, il binario è visibile alla shell. Se la versione non coincide con quella installata, il caso tipico è un conflitto tra più installazioni: una in /usr/local/bin, una in home e magari un residuo in una directory più alta nel PATH. In quel caso la verifica più utile è:

type -a ibmcloud

Questo comando ti mostra tutte le occorrenze trovate. Se ne vedi più di una, hai già trovato il motivo di un comportamento incoerente tra sessioni diverse.

Aggiornamento senza sorprese

Per una CLI usata in amministrazione cloud, l’aggiornamento va trattato come un change controllato, non come un semplice refresh. Il motivo è banale: alcune automazioni o script possono dipendere da opzioni, alias o plugin che cambiano tra release.

Prima di aggiornare, annota la versione corrente e conserva il metodo di installazione usato. Se hai installato in home, il rollback è quasi sempre la sostituzione della directory vecchia con quella nuova. Se hai installato a livello di sistema, è bene fare un backup del percorso o almeno mantenere il pacchetto precedente disponibile per un ritorno rapido.

Un flusso prudente è questo:

  1. verifica la versione corrente con ibmcloud --version;
  2. leggi le note di rilascio della versione che vuoi installare;
  3. scarica il nuovo pacchetto in una directory separata, senza sovrascrivere subito l’esistente;
  4. testa il nuovo binario in una shell nuova o con PATH temporaneo;
  5. solo dopo, sostituisci il link o la directory attiva.

Questo approccio riduce il rischio di interrompere sessioni aperte o script pianificati che usano la versione precedente.

Connessione, login e primo test operativo

Una volta installata la CLI, il test vero non è solo eseguire il comando, ma verificare che la parte di autenticazione funzioni nel tuo contesto. IBM Cloud CLI viene usata spesso per login interattivo, token, API key o flussi automatizzati, quindi l’installazione è corretta solo se il tool riesce a parlare con l’account e con la regione prevista.

Il comando esatto dipende dal tipo di autenticazione che userai. Per un controllo base, puoi verificare la disponibilità dei comandi principali e l’help:

ibmcloud help
ibmcloud login --help

Se questi comandi rispondono correttamente, la CLI è installata e il sottosistema di help è operativo. Il passo successivo è introdurre le credenziali nel modo previsto dal tuo processo, ma senza incollarle in chiaro nel terminale o nei file di shell. Per le automazioni, usa variabili d’ambiente, secret manager o file protetti con permessi stretti.

Problemi comuni su Linux e come riconoscerli

Il problema più frequente è un PATH incompleto. Il sintomo è semplice: il pacchetto sembra installato, ma la shell risponde command not found. In questo caso la causa non è il software, ma il punto di aggancio nella sessione utente.

Un secondo problema è la mancanza di permessi su directory di installazione o di esecuzione. Se il file esiste ma non parte, controlla i permessi con un comando come questo:

ls -l $(command -v ibmcloud)

Se il file non è eseguibile, il fix è banale ma va fatto con criterio: prima identifichi il binario corretto, poi applichi il permesso solo a quello, non a directory intere o a percorsi ambigui.

Terzo caso: conflitto tra più versioni. Succede spesso quando una versione è installata in home e una di sistema è rimasta da test precedenti. Il controllo con type -a ibmcloud chiarisce subito quale binario viene chiamato per primo. Se trovi duplicati, scegli una sola fonte autorevole e rimuovi il resto.

Rimozione pulita e rollback

La rimozione dipende dal metodo usato. Se hai installato con un pacchetto di sistema, usa il gestore pacchetti della distribuzione o il procedimento previsto dal vendor. Se hai installato in home, basta eliminare la directory dell’applicazione e togliere la riga che hai aggiunto nel file di startup della shell.

Per un’installazione utente, il rollback tipico è questo:

rm -rf ~/opt/ibmcloud
sed -i '/ibmcloud/d' ~/.bashrc
source ~/.bashrc

Questo esempio è volutamente diretto, ma va usato con attenzione: rm -rf è distruttivo e va applicato solo al percorso giusto, dopo aver verificato che contenga davvero i file della CLI. Se non sei certo del path, fermati e controllalo prima con pwd e ls.

Per un’installazione di sistema, il rollback più sicuro è rimuovere il symlink o ripristinare la versione precedente della directory applicativa. Se hai un backup del percorso in /opt, il ritorno è immediato e non richiede di toccare il resto del sistema.

Una sequenza consigliata per ambienti reali

Se devi standardizzare la procedura per un team, la sequenza migliore è questa: scegli un metodo unico, documenta l’URL ufficiale o il pacchetto di riferimento, definisci il percorso di installazione, aggiungi il controllo versione al termine della procedura e conserva una nota di rollback. È una CLI, quindi la tentazione di “installare al volo” è forte, ma in ambienti operativi conviene trattarla come qualsiasi altro componente di supporto all’amministrazione.

In sintesi operativa: installa, verifica, controlla il PATH, testa l’help, poi passa al login reale. Se qualcosa non torna, la prima domanda non è “la CLI è rotta?”, ma “dove sta il binario e quale versione sto davvero eseguendo?”. Quasi sempre il problema si risolve lì.