1 29/10/2026 8 min

Installare PHP e ImageMagick su Ubuntu 24.04 LTS

Su Ubuntu 24.04 LTS l’installazione di PHP e ImageMagick è semplice, ma il punto vero non è “farli installare”: è portarli in uno stato coerente con il web server, con i moduli giusti, con una versione supportata e con una verifica finale che eviti di scoprire problemi solo dopo il deploy. In pratica, conviene distinguere subito tra ambiente di test e ambiente di produzione, perché cambiano i rischi, il blast radius e il modo in cui si valida il risultato.

Il caso tipico è questo: il sistema deve eseguire applicazioni PHP che generano o manipolano immagini, ad esempio thumbnail, watermark, conversioni di formato o resize. In quel contesto, ImageMagick da solo non basta; serve anche l’estensione PHP corretta, e spesso conviene decidere in anticipo se usare Apache con PHP-FPM oppure Nginx con PHP-FPM. La scelta non è cosmetica: cambia il punto in cui si applicano i timeout, il carico sui processi e il modo in cui si debuggano gli errori.

Pacchetti da installare su Ubuntu 24.04

Su Ubuntu 24.04 il punto di partenza più pulito è installare il runtime PHP, l’estensione per ImageMagick e il binario di ImageMagick. In molti casi basta questo per avere una base funzionante.

sudo apt update
sudo apt install php php-cli php-fpm php-imagick imagemagick

Dopo l’installazione, la prima verifica da fare non è l’applicazione web, ma i pacchetti effettivamente presenti e la versione di PHP caricata dal sistema. Su Ubuntu 24.04 la versione di default può cambiare in base agli aggiornamenti del repository, quindi è meglio leggere lo stato reale invece di assumere un numero.

php -v
apt policy php php-fpm php-imagick imagemagick

Se il comando php -v restituisce una versione coerente con quella attesa e apt policy mostra i pacchetti installati dal repository Ubuntu, la base è corretta. Se invece vedi versioni miste, o un PHP installato da una fonte esterna, conviene fermarsi e chiarire la catena di fornitura prima di toccare l’ambiente web.

Verificare che ImageMagick sia disponibile in PHP

Il punto più frequente di errore non è ImageMagick in sé, ma l’estensione PHP che non viene caricata nel contesto giusto. In CLI può risultare attiva, mentre nel PHP usato dal web server no. Per questo conviene controllare sia il modulo sia il contesto di esecuzione.

php -m | grep -i imagick
php --ri imagick

Se php -m mostra imagick e php --ri imagick restituisce le informazioni del modulo, il caricamento da CLI è corretto. Questo però non garantisce ancora che il web server stia usando lo stesso PHP. In ambienti con più versioni o con FPM separati, il controllo va ripetuto dal lato web con una pagina di diagnostica temporanea o con il log applicativo.

Per una verifica rapida lato web, il metodo più affidabile è creare temporaneamente un file PHP minimo nella document root, leggerlo via browser e poi rimuoverlo subito dopo. Il file deve essere effimero e non contenere nulla di sensibile.

<?php
phpinfo();

Se nella pagina phpinfo() trovi la sezione imagick, allora il modulo è caricato nel contesto del web server. In produzione, però, questo tipo di controllo va trattato come temporaneo: non lasciare mai una pagina di diagnostica esposta oltre il tempo necessario, perché espone dettagli dell’ambiente che non servono agli utenti.

Apache con PHP-FPM su Ubuntu 24.04

Se usi Apache, su Ubuntu 24.04 la strada più ordinata è PHP-FPM con proxy_fcgi. È una soluzione stabile, facile da monitorare e più pulita del vecchio mod_php in molti contesti moderni. Il vantaggio pratico è che separi il web server dal runtime PHP e gestisci meglio il comportamento sotto carico.

sudo a2enmod proxy_fcgi setenvif
sudo a2enconf php*-fpm
sudo systemctl restart apache2

Dopo il riavvio, verifica che Apache stia effettivamente parlando con il socket FPM corretto. Su Ubuntu, il file di configurazione può cambiare in base alla versione installata, ma il controllo operativo resta lo stesso: Apache deve inoltrare i file .php al servizio FPM attivo.

systemctl status php8.3-fpm --no-pager
apache2ctl -M | grep -E 'proxy_fcgi|setenvif'

Se il servizio FPM risulta active (running) e i moduli Apache richiesti sono caricati, il percorso è corretto. Se invece trovi errori 502 o 503 dopo l’abilitazione, il primo sospetto va al socket FPM, ai permessi del file socket o a una mismatch tra versione PHP e configurazione Apache. In quel caso non serve “rifare tutto”: basta leggere i log e confrontare il percorso del socket con quello realmente in uso.

Nginx con PHP-FPM su Ubuntu 24.04

Con Nginx il principio è simile, ma il punto di integrazione è nel blocco server. Anche qui PHP-FPM resta la scelta più lineare. La configurazione corretta evita errori classici come il passaggio sbagliato del file path o la gestione impropria degli script PHP.

sudo systemctl enable --now php8.3-fpm
sudo systemctl enable --now nginx

Il blocco di configurazione deve includere il passaggio a FPM e il controllo del file esistente. Ecco un esempio essenziale, da adattare al tuo virtual host.

location ~ \.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

Dopo ogni modifica, valida la sintassi prima di ricaricare il servizio. È un controllo banale, ma è quello che evita downtime inutili quando si lavora su server già in produzione.

sudo nginx -t
sudo systemctl reload nginx

Se nginx -t fallisce, non forzare il reload: correggi prima il file. Se il reload passa ma le pagine PHP restituiscono errore, controlla subito il log di Nginx e quello di FPM, perché il problema di solito è uno tra socket, permessi o path document root non coerente.

Controllare l’estensione Imagick da una pagina PHP

Una volta verificato che il modulo è caricato, conviene fare un test funzionale, non solo una verifica teorica. Il modo più semplice è creare un piccolo script che istanzia Imagick, legge un’immagine e produce un output elementare. Questo ti dice se la libreria funziona davvero nel contesto applicativo.

<?php
try { $img = new Imagick('test.jpg'); $img->resizeImage(300, 0, Imagick::FILTER_LANCZOS, 1); header('Content-Type: image/jpeg'); echo $img->getImageBlob();
} catch (Throwable $e) { http_response_code(500); echo $e->getMessage();
}

Il vantaggio di questo test è che copre sia il caricamento del modulo sia l’accesso ai delegate e alle librerie necessarie per leggere e ricodificare l’immagine. Se il file non viene aperto, oppure compare un errore su formati non supportati, il problema potrebbe non essere PHP ma la build di ImageMagick o le policy di sicurezza del sistema.

In alcune installazioni, specialmente se si lavora con PNG, WebP o PDF, serve anche verificare che i formati siano effettivamente abilitati. ImageMagick può essere installato correttamente ma non supportare un formato specifico in base alle librerie disponibili nel sistema.

convert -list format | grep -E 'PNG|WEBP|PDF|JPEG'

Se il formato richiesto non compare o risulta limitato, il fix non è nel PHP ma nel pacchetto sottostante o nelle dipendenze di sistema. Qui è importante non tirare a indovinare: controlla il supporto reale prima di cambiare codice applicativo.

Permessi, sicurezza e superficie d’attacco

ImageMagick lavora su file che spesso arrivano dall’utente finale. Questo significa che la sicurezza non è un dettaglio laterale: è parte della configurazione. Il rischio non è solo il file malevolo, ma anche il consumo eccessivo di CPU e memoria su immagini grandi o volutamente anomale.

La mitigazione pratica è semplice: limita dove possibile i permessi del processo PHP, conserva i file caricati in un’area dedicata, imposta limiti ragionevoli su upload e dimensioni massime, e controlla i timeout del web server e di FPM. Se l’applicazione consente upload e trasformazioni, il collo di bottiglia può diventare il processore prima ancora del disco.

Se devi esporre questa funzionalità in produzione, conviene anche verificare gli aggiornamenti di sicurezza dei pacchetti installati e la coerenza della versione PHP usata dal sito. Non è raro trovare sistemi con CLI aggiornata e FPM fermo a una versione diversa, soprattutto dopo interventi manuali o migrazioni parziali.

Verifiche finali dopo l’installazione

Quando l’installazione è finita, la sequenza corretta è: servizio attivo, modulo caricato, test funzionale, log puliti. Se anche uno solo di questi punti non torna, il lavoro non è concluso. Il controllo finale deve essere ripetibile e rapido, così puoi usarlo anche dopo aggiornamenti futuri.

systemctl is-active php8.3-fpm
php -m | grep -i imagick
journalctl -u php8.3-fpm -n 50 --no-pager

La condizione desiderata è semplice: il servizio FPM deve risultare attivo, il modulo deve comparire tra quelli caricati e i log non devono mostrare errori ripetuti all’avvio o durante l’esecuzione delle richieste. Se trovi warning sporadici ma non impattanti, documentali comunque: spesso diventano il primo segnale di un problema futuro.

Assunzione operativa: ambiente Ubuntu 24.04 LTS con PHP installato dai repository ufficiali, web server Apache o Nginx, e uso di ImageMagick tramite estensione imagick per elaborazione immagini lato server.