Come installare Composer su CentOS 9

Su CentOS 9 Composer conviene installarlo in modo esplicito, verificando prima i prerequisiti e poi il binario scaricato. Così eviti installazioni opache, riduci il rischio di trovarsi con una versione vecchia nei repository e mantieni il controllo su dove finisce l’eseguibile.

Quando usare l’installazione manuale

Se ti serve Composer per sviluppare o gestire applicazioni PHP, l’approccio più affidabile su CentOS 9 è installarlo come binario globale, partendo da PHP già presente e da alcuni strumenti minimi. I pacchetti del sistema possono esistere, ma spesso non sono allineati alla release più recente o alle esigenze di un progetto che usa dipendenze aggiornate.

Prima di toccare il sistema, conviene classificare l’intervento come change controllato: l’obiettivo è installare un tool lato server senza impattare applicazioni in produzione. Il blast radius è basso, ma tocca comunque il filesystem e il path di esecuzione, quindi vale la pena fare un controllo iniziale e tenere pronto un rollback semplice.

Prerequisiti minimi su CentOS 9

Composer richiede PHP funzionante e alcuni strumenti di base per il download e la verifica. Se PHP non è presente, o se la versione è troppo vecchia rispetto a ciò che richiede il progetto, il problema va risolto prima di procedere.

Verifica la situazione con questi comandi:

php -v
curl --version
php -m | grep -E 'openssl|mbstring|json|phar'

Atteso: PHP risponde con una versione installata, curl è disponibile e i moduli base non mancano. Se php non esiste, installalo prima con il gestore pacchetti della tua macchina; se manca un modulo, il progetto potrebbe partire lo stesso ma poi fallire in fase di installazione dipendenze o runtime.

Se vuoi avere una base completa per un ambiente PHP tipico, puoi aggiungere i pacchetti più comuni. Non è obbligatorio per Composer in sé, ma evita molti falsi problemi successivi:

sudo dnf install -y php php-cli php-json php-mbstring php-xml curl unzip git

Questo comando non è distruttivo, ma introduce pacchetti nel sistema. Il rollback, se davvero necessario, è la rimozione dei pacchetti installati e l’eventuale ripristino di una snapshot o backup del server, se il contesto lo prevede.

Verifica della firma e download dell’installer

La parte più importante non è scaricare Composer, ma farlo con un minimo di verifica. L’installer ufficiale pubblica un checksum da confrontare: è una protezione semplice, ma sufficiente per intercettare un download corrotto o alterato.

Il flusso corretto è questo: scarichi lo script di installazione, recuperi il checksum atteso, confronti il valore e solo dopo esegui l’installer. Se salti il controllo, stai affidandoti al solo canale HTTPS, che non è un sostituto della verifica.

cd /tmp
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php -r "copy('https://composer.github.io/installer.sig', 'composer.sig');"
php -r "if (hash_file('sha384', 'composer-setup.php') === trim(file_get_contents('composer.sig'))) { echo 'Installer verified'.PHP_EOL; } else { echo 'Installer corrupt'.PHP_EOL; unlink('composer-setup.php'); }"

Atteso: il comando stampa Installer verified. Se compare Installer corrupt, non proseguire: cancella il file scaricato, controlla connettività, DNS e proxy, poi ripeti il download. In un contesto aziendale, se il server esce su Internet tramite proxy, conviene verificare anche che non stia riscrivendo o intercettando i contenuti.

Installazione globale del binario

Una volta validato l’installer, puoi installare Composer in un percorso globale. La scelta più comune è /usr/local/bin/composer, che permette di richiamarlo da qualunque utente connesso alla macchina, purché il PATH sia configurato correttamente.

Il comando da usare è questo:

sudo php composer-setup.php --install-dir=/usr/local/bin --filename=composer

Atteso: l’installer conferma l’avvenuta installazione e crea il binario in /usr/local/bin/composer. Se vuoi essere più prudente, puoi prima installarlo in una directory temporanea e poi spostarlo manualmente, ma nella pratica l’installazione diretta è già abbastanza pulita se hai verificato il checksum.

Per controllare che il file sia effettivamente presente e avviabile:

ls -l /usr/local/bin/composer
composer --version

Atteso: permessi di esecuzione sul file e una risposta del tipo Composer version X.Y.Z. Se composer non viene trovato, il problema è quasi sempre nel PATH oppure nella posizione d’installazione. In quel caso verifica con echo $PATH e controlla che /usr/local/bin sia incluso.

Installazione per utente e differenze operative

In alcuni ambienti non vuoi rendere disponibile Composer a tutto il sistema. Per esempio su server condivisi o macchine dove le policy sono restrittive, può avere senso installarlo nella home dell’utente operativo. Il vantaggio è ridurre l’impatto, lo svantaggio è che ogni utente deve gestire il proprio binario e il proprio PATH.

Un’installazione per utente può essere utile anche in fase di test. In questo caso il principio è lo stesso, ma il file finisce in un percorso come ~/bin o ~/.local/bin. Devi poi assicurarti che la directory sia nel PATH della sessione utente, altrimenti Composer esiste ma non è richiamabile direttamente.

Se lavori su una macchina amministrata in modo centralizzato, però, la versione globale resta la scelta più lineare. Meno variabili per chi interviene dopo, meno sorprese quando uno script di deploy richiama composer da cron, da pipeline o da un servizio systemd.

Verifiche post-installazione che evitano problemi falsi

Dopo l’installazione, non fermarti alla sola risposta di composer --version. Vale la pena controllare anche il comportamento con PHP, perché Composer è solo un wrapper intelligente attorno al runtime e alle sue estensioni.

Questi controlli aiutano a capire se l’ambiente è sano:

composer diagnose
php -i | grep -i 'Loaded Configuration File'
php -m | sort

composer diagnose è utile perché evidenzia problemi di connettività, TLS, cache, configurazione PHP e permessi. Non risolve tutto, ma ti dà subito una fotografia utile. Se segnala problemi di rete, il sospetto non è Composer: di solito si tratta di DNS, proxy, CA bundle o filtri in uscita.

Se il server non riesce a parlare con i repository, controlla anche la risoluzione dei nomi e il certificato del sistema. Su CentOS 9, un problema ricorrente è una CA bundle non aggiornata o un ambiente con proxy aziendale che altera le richieste HTTPS. In quel caso, prima di toccare Composer, conviene verificare la connettività verso getcomposer.org e i mirror dei pacchetti del progetto.

Aggiornamento di Composer senza rompere gli script

Una volta installato, Composer si aggiorna da sé. In genere basta eseguire composer self-update, ma in ambienti dove la stabilità conta più dell’ultima release conviene ragionare sulla versione da mantenere, non sull’aggiornamento automatico continuo.

Per vedere quale versione è in uso:

composer --version

Per aggiornare alla release stabile più recente:

sudo composer self-update

Se vuoi limitare il rischio, puoi evitare aggiornamenti indiscriminati in produzione e standardizzare una versione testata in staging prima di portarla sui server applicativi. Il blast radius dell’aggiornamento è basso, ma non nullo: una nuova versione può cambiare il comportamento del solver o la gestione di alcuni flag.

Rollback semplice: se un aggiornamento crea problemi, puoi tornare alla versione precedente con il meccanismo di rollback di Composer stesso, quando disponibile nella tua installazione, oppure reinstallare manualmente la versione nota e verificata in precedenza. Per questo è utile annotare la release in uso prima di cambiare qualcosa.

Uso corretto in progetti PHP su CentOS 9

Installare Composer è il primo passo; usarlo bene è il secondo. In un progetto PHP tipico, il comando più importante è composer install, che legge il file composer.lock e installa dipendenze coerenti con la versione approvata dal team.

In ambiente di produzione, la regola pratica è semplice: se il lock file esiste, usa composer install; se stai sviluppando un pacchetto o devi aggiornare le dipendenze, allora entra in gioco composer update. Mischiare i due approcci senza criterio è il modo più rapido per introdurre differenze tra ambienti.

Un flusso essenziale può essere questo:

cd /var/www/app
composer install --no-dev --optimize-autoloader

--no-dev evita di portarsi dietro dipendenze di sviluppo, mentre --optimize-autoloader migliora il caricamento delle classi in ambienti dove conta la reattività. Non è una cura miracolosa, ma su progetti medi o grandi fa una differenza concreta, soprattutto quando il carico aumenta.

Problemi tipici su CentOS 9 e come leggerli

Se l’installazione sembra andare a buon fine ma poi Composer non funziona, i punti da controllare sono quasi sempre gli stessi. Il primo è il PHP usato dal terminale: potresti avere una versione differente da quella del web server o del container applicativo. Il secondo è la disponibilità delle estensioni richieste dal progetto. Il terzo è l’accesso in rete verso i repository.

Un errore del tipo Command not found indica un problema di PATH o di installazione. Un errore TLS o di certificato indica invece un problema di trust store, proxy o data/ora del sistema. Se il problema appare durante il download delle dipendenze, controlla anche lo stato del disco: uno spazio insufficiente può far fallire l’estrazione dei pacchetti e lasciare installazioni parziali.

Per una verifica rapida dello spazio disponibile:

df -h

Se il filesystem è quasi pieno, il rischio non riguarda solo Composer: anche PHP, log e aggiornamenti di sistema possono iniziare a comportarsi male. In quel caso il rollback non è legato a Composer ma alla capacità del sistema di tornare in uno stato operativo con spazio libero sufficiente.

Procedura sintetica consigliata

Se vuoi una sequenza essenziale e ripetibile, la versione pratica è questa: verifica PHP, scarica l’installer, controlla il checksum, installa il binario in /usr/local/bin, poi esegui i test di diagnosi. È il percorso che minimizza sorprese e ti lascia un’installazione pulita, leggibile e facile da manutenzionare.

1. Controlla php -v e la presenza dei moduli base.
2. Scarica composer-setup.php e verifica il checksum.
3. Installa in /usr/local/bin/composer.
4. Esegui composer --version e composer diagnose.
5. Se serve, integra il comando nel flusso applicativo con un utente dedicato e permessi minimi.

Assunzione operativa: il server ha accesso HTTPS verso il sito ufficiale di Composer e PHP è già installato o installabile senza conflitti di policy.