Come installare Snipe-IT su Ubuntu 24.04 -- TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster

1 1 visite 10/04/2026 Pubblicato il: 10/04/2026 20:00 Tempo di lettura: 13 min

Snipe-IT su Ubuntu 24.04 si installa bene con Nginx, PHP 8.3-FPM, MariaDB e TLS, ma la differenza tra un deploy che funziona e uno che resta stabile sta nei dettagli: versione PHP allineata, estensioni corrette, permessi stretti, virtual host puntato su /public e coda/scheduler attivi. Se uno di questi pezzi è fuori posto, il wizard può anche aprirsi, ma poi arrivano 500, login instabile, mail che non partono o job che non girano.

Questa guida segue un percorso pratico, pensato per un server pulito con accesso sudo, un dominio già risolto via DNS e la possibilità di aprire le porte 80 e 443. Se il DNS non è ancora pronto, puoi comunque installare tutto e chiudere l’HTTPS dopo; se invece l’obiettivo è andare in produzione, conviene farlo bene fin dall’inizio per non dover rincorrere problemi di cookie, redirect e URL generate male.

Stack consigliato e perché conviene tenerlo semplice

Per Ubuntu 24.04 la combinazione più lineare resta: Nginx come web server, PHP 8.3-FPM come runtime applicativo e MariaDB come database. È una scelta coerente con i repository standard della release, con systemd per la gestione dei servizi e con il modo in cui Laravel, quindi Snipe-IT, si aspetta di essere servito. Evito volutamente stack più complessi o varianti non necessarie: qui l’obiettivo è ridurre il numero di punti di rottura.

In pratica, i problemi tipici non nascono quasi mai dal codice di Snipe-IT. Nascono da estensioni PHP mancanti, permessi sbagliati su storage e bootstrap/cache, database creato con charset errato, virtual host che punta alla directory sbagliata o cache Laravel lasciate a metà. Se sistemi questi punti, il resto è ordinaria amministrazione.

Controlli iniziali: cosa verificare prima di installare

Prima di scaricare il codice conviene verificare il runtime già presente sul server. Questo evita di scoprire a installazione avviata che manca PHP-FPM, che Nginx non è attivo o che il client MariaDB non è disponibile. Sono controlli banali, ma in produzione fanno risparmiare tempo perché limitano il numero di variabili aperte.

php -v
nginx -v
mysql --version
systemctl status php8.3-fpm --no-pager

Se uno di questi comandi fallisce, fermati lì e chiudi il gap prima di procedere. Guardare solo php -v non basta: il binario CLI può essere corretto mentre il socket usato da Nginx punta a un’altra versione o a un FPM non attivo. Il sintomo classico, in quel caso, è un 502 Bad Gateway o una pagina bianca con log PHP vuoti.

Installazione dei pacchetti base su Ubuntu 24.04

Aggiorno prima il sistema e poi installo i pacchetti necessari. L’ordine è importante: se qualcosa manca, lo vedo subito nei log o nel wizard iniziale, senza dover capire se il problema dipende dal codice o dal sistema operativo.

sudo apt update
sudo apt -y upgrade
sudo apt -y install nginx mariadb-server git unzip curl composer
sudo apt -y install php8.3-fpm php8.3-cli php8.3-common php8.3-mysql php8.3-xml php8.3-curl php8.3-mbstring php8.3-zip php8.3-bcmath php8.3-gd php8.3-intl php8.3-ldap php8.3-imap php8.3-opcache

Le estensioni ldap e imap non sono sempre indispensabili al primo avvio, ma in ambienti aziendali tornano spesso utili per integrazioni con directory e posta. Se sai già che non ti servono, puoi ometterle; in un’installazione standard, però, conviene averle già pronte per evitare un secondo giro di manutenzione più avanti.

Verifica subito che i moduli siano caricati dal runtime PHP effettivamente usato da FPM:

php -m | egrep 'mbstring|xml|curl|zip|bcmath|gd|intl|mysqli|pdo_mysql|opcache'
systemctl is-active nginx php8.3-fpm mariadb

Se un modulo non compare, la causa è quasi sempre una di queste: pacchetto non installato, servizio PHP diverso da quello atteso o binario CLI non allineato con il socket FPM. Questo è uno dei punti in cui si perde più tempo se si guarda solo il lato web e non si controlla il runtime reale.

Database MariaDB: utente dedicato, charset corretto, privilegi minimi

Snipe-IT non ha bisogno di privilegi globali sul database. Crea un database dedicato, un utente dedicato e assegna solo i permessi necessari su quel database. È una scelta più sicura e rende più semplice qualsiasi revisione successiva.

sudo mysql
CREATE DATABASE snipeit CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'snipeituser'@'localhost' IDENTIFIED BY 'PASSWORD_FORTE_E_RANDOM';
GRANT ALL PRIVILEGES ON snipeit.* TO 'snipeituser'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Il charset utf8mb4 non è un vezzo: evita problemi con nomi contenenti caratteri non ASCII, descrizioni importate da altre fonti e dati che potrebbero includere simboli o emoji. Se usi una collation diversa, l’app può comunque partire, ma ti porti dietro edge case fastidiosi da correggere dopo.

Per una verifica rapida della connessione:

mysql -u snipeituser -p -h localhost snipeit -e 'SHOW TABLES;'

Un output vuoto è normale se il database è appena creato. Un errore di accesso, invece, indica credenziali sbagliate o privilegi non applicati. In quel caso non ha senso proseguire con il wizard web: prima si sistema il DB, poi si passa all’applicazione.

Download del codice e posizione corretta dell’applicazione

La directory applicativa va tenuta sotto /var/www o in un path equivalente, ma sempre separata dai file di configurazione del sistema. Per un ambiente di produzione è meglio bloccare una release nota invece di inseguire il ramo principale, così eviti cambi di comportamento non controllati.

cd /var/www
sudo git clone https://github.com/snipe/snipe-it.git snipe-it
cd snipe-it

Se vuoi lavorare su una versione specifica, controlla i tag disponibili e fai checkout di una release stabile:

git tag | tail
# esempio:
# git checkout v7.x.x

La regola importante è questa: il web server deve leggere il progetto, ma non deve poter scrivere ovunque. In scrittura servono soprattutto storage e bootstrap/cache. Dare ownership totale all’intero tree è la scorciatoia che poi complica audit, hardening e troubleshooting.

Configurazione del file .env: qui si decide metà dell’installazione

Il file .env è il centro operativo di Snipe-IT. Qui definisci URL pubblica, timezone, database, mail e parametri di cache. Se questi valori sono incoerenti, il wizard può anche terminare, ma poi avrai redirect strani, sessioni che non si mantengono o URL generate con schema sbagliato.

Parti dal template incluso nel progetto:

cp .env.example .env

Compila almeno i campi essenziali:

APP_URL=https://snipeit.example.com
APP_TIMEZONE=Europe/Rome
DB_DATABASE=snipeit
DB_USERNAME=snipeituser
DB_PASSWORD=PASSWORD_FORTE_E_RANDOM
MAIL_HOST=mail.example.com
MAIL_PORT=587
MAIL_USERNAME=...
MAIL_PASSWORD=...

Se prevedi di servire il sito in HTTPS, APP_URL deve già riflettere l’URL finale con https://. Lasciarlo in HTTP è una delle cause più comuni di login che sembrano fallire, cookie non coerenti e redirect che girano a vuoto.

Genera poi la chiave applicativa di Laravel:

php artisan key:generate

Se il comando fallisce, il problema è quasi sempre uno tra: dipendenza mancante, permessi errati nella directory del progetto o incompatibilità tra versione PHP e librerie installate. Il log più utile, in caso di errore, è storage/logs/laravel.log.

Permessi corretti su storage e cache: il punto più sottovalutato

Laravel deve poter scrivere in storage e bootstrap/cache. Se questi percorsi non sono scrivibili dal processo PHP, il risultato tipico è una pagina bianca, un 500 o un wizard che si interrompe senza messaggi chiari. Qui non serve “aprire tutto”: serve dare i permessi giusti ai percorsi giusti.

sudo chown -R www-data:www-data /var/www/snipe-it
sudo find /var/www/snipe-it -type d -exec chmod 755 {} \;
sudo find /var/www/snipe-it -type f -exec chmod 644 {} \;
sudo chmod -R ug+rwx /var/www/snipe-it/storage /var/www/snipe-it/bootstrap/cache

Se vuoi essere più rigoroso, puoi usare un gruppo dedicato invece di affidarti completamente a www-data, ma per una installazione standard questa configurazione è già corretta e abbastanza prudente.

Controllo rapido:

sudo -u www-data test -w /var/www/snipe-it/storage && echo OK
sudo -u www-data test -w /var/www/snipe-it/bootstrap/cache && echo OK

Se uno dei due test fallisce, il problema è locale e non riguarda Nginx o MariaDB. Correggi prima i permessi, poi riprova il wizard.

Virtual host Nginx: serve la directory public, non la root del progetto

Il virtual host deve puntare a /var/www/snipe-it/public, non alla root del repository. Questo dettaglio è essenziale: se servi la directory sbagliata, rischi di esporre file interni o di rompere il routing dell’applicazione. Qui non c’è nulla di “opzionale”.

sudo nano /etc/nginx/sites-available/snipe-it.conf

Configurazione base consigliata:

server {
    listen 80;
    server_name snipeit.example.com;
    root /var/www/snipe-it/public;
    index index.php;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

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

    location ~ /\.(?!well-known).* {
        deny all;
    }
}

Abilita il sito e verifica la sintassi prima del reload:

sudo ln -s /etc/nginx/sites-available/snipe-it.conf /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Il controllo nginx -t è il primo filtro serio: se la configurazione è sbagliata, lo scopri prima di interrompere il servizio. Se poi il sito risponde con 502, il primo sospetto va al socket PHP-FPM, che deve corrispondere alla versione installata e attiva.

Dipendenze applicative e inizializzazione di Laravel

Una volta posizionato il codice, installa le dipendenze PHP tramite Composer. Su Ubuntu 24.04 il pacchetto composer è normalmente disponibile e basta per il flusso standard. Se il progetto segnala vincoli di versione, non forzare: leggi l’errore e allinea il runtime prima di andare oltre.

cd /var/www/snipe-it
composer install --no-dev --prefer-dist --optimize-autoloader

Dopo l’installazione, prepara schema e cache di Laravel. Il comando di migrazione scrive nel database, quindi è normale in una nuova installazione; su un’istanza già in uso va trattato come change controllato e non come operazione da eseguire senza backup.

php artisan migrate --force
php artisan config:cache
php artisan route:cache
php artisan view:cache

Se uno di questi passaggi si ferma, il log da controllare è sempre il solito: storage/logs/laravel.log. In alternativa, se il problema è lato PHP-FPM, guarda anche il journal del servizio:

journalctl -u php8.3-fpm -n 100 --no-pager

Primo accesso al wizard e segnali da controllare subito

A questo punto il sito dovrebbe rispondere sul dominio configurato. Apri http://snipeit.example.com oppure, se il certificato è già pronto, direttamente https://snipeit.example.com. Il wizard iniziale verifica requisiti, database e alcune impostazioni di base.

Se compare una pagina bianca o un 500, il primo controllo utile è il log applicativo:

tail -n 100 /var/www/snipe-it/storage/logs/laravel.log

Se invece il wizard segnala estensioni mancanti o errori sui permessi, il problema è quasi sempre nel runtime PHP o nei permessi delle directory scrivibili. In quel caso non serve reinstallare tutto: correggi il punto preciso, svuota le cache se necessario e riprova.

Durante il primo login conviene controllare quattro cose concrete:

L’URL generata è quella attesa e usa lo schema corretto.
La sessione resta valida dopo un refresh della pagina.
Asset e icone si caricano senza errori 404 o mixed content.
Timezone e timestamp corrispondono all’orario desiderato.

HTTPS con Let’s Encrypt: meglio chiuderlo subito

Su un’istanza esposta a utenti reali, l’HTTPS non è un optional. Se DNS e porta 80 sono già raggiungibili, su Ubuntu 24.04 la via più semplice resta Certbot con plugin Nginx. È una strada veloce e abbastanza robusta, a patto che il virtual host sia già corretto.

sudo apt -y install certbot python3-certbot-nginx
sudo certbot --nginx -d snipeit.example.com

Dopo l’emissione, verifica il rinnovo automatico:

sudo systemctl status certbot.timer --no-pager
sudo certbot renew --dry-run

Se la richiesta del certificato fallisce, il problema di solito non è Snipe-IT: controlla DNS, porta 80, nome host del virtual server e raggiungibilità dall’esterno. In pratica, la correzione va fatta sul routing o sul front-end, non sull’applicazione.

Scheduler, queue e manutenzione: il pezzo che evita guai dopo il go-live

Snipe-IT non va trattato come un sito statico. Ha attività pianificate, notifiche e processi asincroni che conviene far girare in modo prevedibile. Se lasci tutto fermo, alcune operazioni restano in coda più del dovuto o non partono proprio. Una installazione che “si apre” ma non esegue scheduler e queue è incompleta.

Imposta il cron per l’utente che esegue l’applicazione, in genere www-data:

sudo crontab -u www-data -e

* * * * * cd /var/www/snipe-it && php artisan schedule:run >> /dev/null 2>&1

Se usi worker separati per le code, valuta un servizio systemd dedicato o un process manager coerente con il tuo standard operativo. Non è obbligatorio per un laboratorio, ma in un ambiente reale aiuta molto a mantenere prevedibili mail, notifiche e job differiti.

Backup e aggiornamenti: decidili prima del primo utilizzo serio

Prima ancora di affidare l’istanza agli utenti, definisci una strategia minima di backup. Servono almeno il dump del database, il file .env e i dati persistenti caricati dall’applicazione. Senza questi elementi ogni upgrade diventa un salto nel buio.

mysqldump -u root -p snipeit | gzip > /backup/snipeit-$(date +%F).sql.gz
sudo tar -czf /backup/snipeit-files-$(date +%F).tar.gz /var/www/snipe-it

In più, conserva almeno la configurazione Nginx e il virtual host in un punto versionato o in una directory di backup separata. Quando qualcosa si rompe, avere il diff pronto vale più di dieci tentativi fatti a memoria.

Per gli aggiornamenti, la sequenza corretta è semplice: leggere le note di rilascio, fare backup, aggiornare, verificare migrazioni e solo dopo riaprire il servizio agli utenti. Snipe-IT può cambiare schema o requisiti tra una release e l’altra, quindi l’upgrade improvvisato è il modo più rapido per trasformare un servizio funzionante in un recupero dati.

Problemi tipici e diagnosi rapida

Ci sono alcuni sintomi che tornano spesso e che conviene riconoscere subito. Se Nginx risponde con 502, controlla il socket PHP-FPM e lo stato di php8.3-fpm. Se la pagina è bianca, guarda storage/logs/laravel.log. Se il wizard non scrive nulla, verifica i permessi di storage e bootstrap/cache. Se il database rifiuta la connessione, controlla utente, password, host e collation.

Un altro errore frequente è installare Snipe-IT in una directory non servita dal virtual host e poi cercare il problema nel codice. Prima di scavare altrove, verifica sempre il document root: deve puntare a /var/www/snipe-it/public, non alla root del repository.

Infine, non sottovalutare il timezone. In ambienti con più amministratori o con audit frequenti, timestamp incoerenti generano confusione su asset, attività e ticket. Impostarlo bene all’inizio evita discussioni inutili dopo.

Checklist finale prima di consegnare l’istanza

Prima di considerare chiusa l’installazione, conviene fare una verifica finale molto concreta. Se questi punti sono a posto, l’istanza è ragionevolmente pronta per l’uso operativo:

Nginx risponde sul dominio corretto e il virtual host punta a /public.
PHP 8.3-FPM è attivo e il socket corrisponde alla configurazione Nginx.
MariaDB contiene il database dedicato con charset utf8mb4.
.env ha URL, timezone, DB e mail coerenti con l’ambiente reale.
storage e bootstrap/cache sono scrivibili da www-data.
Composer ha installato le dipendenze senza errori bloccanti.
Le cache Laravel sono state generate e il wizard è completato.
Scheduler e, se necessari, worker di coda sono attivi.
Il certificato TLS è emesso e il rinnovo automatico è verificato.
Esiste almeno un backup testato di database e file applicativi.

Conclusione operativa

Installare Snipe-IT su Ubuntu 24.04 non è difficile, ma richiede metodo: pacchetti allineati, database dedicato, permessi stretti, virtual host corretto, cache Laravel inizializzate e manutenzione di base già pensata. Se questi elementi sono solidi, l’istanza resta stabile anche dopo il primo login, dopo gli import e dopo l’avvio delle attività pianificate.

La vera differenza tra un ambiente che “parte” e uno affidabile sta nella disciplina iniziale. Sistemare bene ora significa evitare ore di debugging più avanti, soprattutto su una piattaforma che gestisce asset, utenti e inventario e che quindi deve essere prevedibile, non improvvisata.