Come installare Backdrop CMS su Ubuntu 24.04 o 22.04 -- TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster

1 1 visite 18/04/2026 Pubblicato il: 18/04/2026 00:59 Tempo di lettura: 12 min

Backdrop CMS su Ubuntu 24.04 o 22.04: cosa serve davvero

Backdrop CMS gira senza problemi su Ubuntu 22.04 e 24.04, ma l’installazione riesce bene solo se prepari prima tre pezzi: web server, PHP con le estensioni giuste e un database MySQL/MariaDB pulito. La parte che crea più errori non è il CMS in sé, ma il contorno: virtual host, permessi sul filesystem, rewrite e limiti PHP troppo stretti.

Se vuoi evitare giri a vuoto, l’obiettivo è semplice: arrivare a una pagina iniziale di Backdrop servita da Apache o Nginx, con database funzionante, upload abilitati e cron impostato. In questa guida uso una procedura compatibile con entrambe le versioni di Ubuntu, con esempi pratici e punti di verifica dopo ogni fase.

Scelta dello stack: Apache o Nginx

Backdrop CMS non impone un web server specifico. Se vuoi la strada più lineare, Apache con mod_rewrite è la scelta più rapida. Nginx funziona bene, ma richiede una configurazione di rewrite più attenta e un backend PHP-FPM corretto.

Per un’installazione standard su VPS o server dedicato, Apache riduce i punti di errore. Se invece stai già usando Nginx come reverse proxy o hai altri siti PHP-FPM, puoi restare su quello. L’importante è non mischiare configurazioni “a metà”: Apache senza rewrite attivo o Nginx senza try_files sono le due cause classiche di installazione apparentemente riuscita ma navigazione rotta.

Prerequisiti: pacchetti, PHP e database

Backdrop richiede PHP recente e alcune estensioni comuni. Su Ubuntu 24.04 la versione di default è già adeguata; su 22.04 va bene comunque il ramo fornito dai repository standard nella maggior parte dei casi. Prima di installare, aggiorna l’indice pacchetti e prepara il sistema.

sudo apt update
sudo apt -y upgrade

Installa i pacchetti minimi. Qui sotto trovi un set ragionevole per Apache e MariaDB; se usi Nginx, sostituisci Apache con PHP-FPM e Nginx.

sudo apt install -y apache2 mariadb-server php libapache2-mod-php \
  php-cli php-mysql php-gd php-xml php-mbstring php-curl php-zip php-json \
  php-opcache php-intl php-xmlrpc unzip curl

Controlla subito la versione PHP e il servizio database. Se uno dei due non parte, fermati qui: Backdrop non risolve problemi di base del sistema.

php -v
systemctl status mariadb --no-pager
systemctl status apache2 --no-pager

Atteso: PHP 8.x, MariaDB attivo e Apache in esecuzione. Se usi Nginx, sostituisci il controllo di Apache con systemctl status nginx --no-pager e verifica che PHP-FPM sia attivo con systemctl status php8.x-fpm --no-pager.

Database: crea utente e schema senza esporre privilegi inutili

Backdrop usa un database dedicato. Non usare l’utente root del database per l’applicazione: è una scorciatoia che complica audit e recupero incidenti. Crea invece database e utente con privilegi limitati al solo schema dell’app.

sudo mysql

CREATE DATABASE backdropdb CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
CREATE USER 'backdropuser'@'localhost' IDENTIFIED BY 'password_forte_da_rigenerare';
GRANT ALL PRIVILEGES ON backdropdb.* TO 'backdropuser'@'localhost';
FLUSH PRIVILEGES;
EXIT;

La password va trattata come segreto: mettila in un password manager o in un vault, non in chiaro dentro note operative condivise. Se hai già creato un account con una password temporanea, ruotala prima del go-live.

Verifica l’accesso al database con un login reale. Questo test elimina subito errori di autenticazione, socket e privilegi.

mysql -u backdropuser -p -h localhost backdropdb -e "SHOW TABLES;"

Se il comando restituisce una tabella vuota senza errori, la connessione funziona. Se vedi errori di access denied, controlla nome utente, host consentito e password. Se il client non trova il socket, verifica che MariaDB sia avviato e che il file di socket sia quello previsto dalla distro.

Scaricare Backdrop CMS e posizionarlo nel document root

Scarica il pacchetto ufficiale dalla pagina di distribuzione del progetto e decomprimilo in una directory dedicata. Evita di lavorare dentro directory temporanee o home utente: il docroot deve essere stabile e coerente con il virtual host.

cd /tmp
curl -LO https://github.com/backdrop/backdrop/releases/download/1.29.0/backdrop.zip
unzip backdrop.zip
sudo mkdir -p /var/www/backdrop
sudo rsync -a backdrop/ /var/www/backdrop/

Se la versione cambia, aggiorna l’URL con il rilascio corrente. Il punto non è il numero esatto, ma il flusso: scarica, verifica, estrai, copia nel document root. Se preferisci, puoi usare il pacchetto tar.gz equivalente quando disponibile.

Su Ubuntu è sensato assegnare la proprietà dei file all’utente del web server, ma senza aprire permessi in modo indiscriminato. In un setup Apache tipico l’utente è www-data.

sudo chown -R www-data:www-data /var/www/backdrop
sudo find /var/www/backdrop -type d -exec chmod 755 {} \;
sudo find /var/www/backdrop -type f -exec chmod 644 {} \;

Questo assetto è conservativo e riduce il rischio di scrittura fuori controllo. Se in seguito devi abilitare upload o aggiornamenti dal pannello, la directory files sarà il punto da trattare con attenzione, non l’intero sito.

Apache: virtual host, rewrite e document root

Con Apache, il virtual host deve puntare alla directory corretta e il rewrite deve essere attivo. Backdrop si aspetta URL puliti; se il modulo rewrite manca o il AllowOverride è bloccato, il sito può mostrare la home ma fallire sulle pagine interne.

sudo a2enmod rewrite
sudo systemctl reload apache2

Crea un file di virtual host, ad esempio /etc/apache2/sites-available/backdrop.conf.

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/backdrop

    <Directory /var/www/backdrop>
        Options FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/backdrop_error.log
    CustomLog ${APACHE_LOG_DIR}/backdrop_access.log combined
</VirtualHost>

Abilita il sito e ricarica Apache.

sudo a2ensite backdrop.conf
sudo apache2ctl configtest
sudo systemctl reload apache2

Il controllo apache2ctl configtest deve restituire Syntax OK. Se trovi errori, non andare avanti: correggi prima il virtual host. Un errore di sintassi qui ti fa perdere tempo più avanti, quando il problema sembra essere del CMS ma in realtà è del web server.

Nginx: configurazione essenziale con PHP-FPM

Se scegli Nginx, il blocco server deve instradare correttamente le richieste a PHP-FPM e lasciare a Backdrop la gestione degli URL. La logica di base è: file esistenti serviti direttamente, tutto il resto passato a index.php.

sudo apt install -y nginx php-fpm
sudo systemctl enable --now nginx

Esempio di server block, da salvare in /etc/nginx/sites-available/backdrop.

server {
    listen 80;
    server_name example.com www.example.com;
    root /var/www/backdrop;
    index index.php index.html;

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

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

    location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ {
        expires max;
        log_not_found off;
    }
}

Adatta il path del socket PHP-FPM alla versione installata. Su Ubuntu 22.04 potresti vedere php8.1-fpm.sock, su 24.04 spesso una versione più recente. Il modo più veloce per chiudere il dubbio è guardare la directory /run/php/ con ls -l /run/php/.

Dopo aver creato il file, abilita il sito e testa la sintassi.

sudo ln -s /etc/nginx/sites-available/backdrop /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Installazione web: primo avvio e setup guidato

A questo punto apri il dominio nel browser. Se il DNS è già puntato e il certificato non blocca la navigazione, Backdrop dovrebbe mostrarti il wizard di installazione. Qui configuri lingua, database e account amministrativo.

Nella schermata database inserisci:

Database name: backdropdb
Database username: backdropuser
Database password: quella scelta in precedenza
Host: localhost

Se il wizard non parte e vedi una pagina bianca o un errore 500, non saltare subito a cambiare il CMS. Prima controlla i log del web server e di PHP. Su Apache, i file utili sono in /var/log/apache2/; su Nginx, in /var/log/nginx/; per PHP-FPM, il log dipende dalla versione e dalla configurazione del pool.

Un errore frequente è il valore di memory_limit troppo basso o estensioni PHP mancanti. Se il wizard si interrompe senza messaggi chiari, verifica le estensioni caricate.

php -m | egrep 'mbstring|xml|gd|curl|zip|mysqli|pdo_mysql|intl'

Se manca una estensione, installala e riavvia il servizio PHP o il web server. Per esempio, dopo aver aggiunto un modulo PHP, su Apache con mod_php basta spesso un reload; con PHP-FPM è meglio riavviare il pool.

Permessi su files e directory: il punto che rompe gli aggiornamenti

Backdrop scrive file in alcune aree precise, soprattutto la directory dei file caricati e i percorsi temporanei. La tentazione di mettere tutto in scrittura globale è forte, ma sbagliata. Meglio capire quali directory devono essere scrivibili e lasciare il resto protetto.

Dopo l’installazione, verifica la presenza della directory dei file, in genere sotto /var/www/backdrop/files o in un path definito dal sito. Se il web installer ti propone un percorso diverso, usa quello coerente con la tua configurazione.

sudo mkdir -p /var/www/backdrop/files
sudo chown -R www-data:www-data /var/www/backdrop/files
sudo chmod -R 755 /var/www/backdrop/files

Se prevedi upload frequenti o aggiornamenti dal pannello amministrativo, controlla anche il file system temporaneo configurato in Backdrop. Il controllo migliore è aprire il pannello e provare un upload piccolo, poi verificare che il file compaia nella directory prevista e che il proprietario sia corretto.

Configurazione base dopo il primo login

Una volta dentro al pannello, fai subito tre cose: imposta il nome del sito, verifica il timezone e configura il canale email. Anche se il sito è online, senza mail affidabile ti accorgerai tardi di problemi con reset password, notifiche e moduli.

Se il server invia posta direttamente, controlla che l’MTA locale sia attivo e che il record DNS SPF sia coerente. Se usi un relay esterno, fai un test da pannello o con un modulo di prova e controlla i log mail del sistema. Non dare per scontato che il semplice invio di una mail di prova equivalga a una deliverability sana.

Imposta anche il cron di Backdrop. Senza cron, molte operazioni periodiche restano indietro: pulizia cache, controlli schedulati, attività di manutenzione dei moduli.

sudo crontab -u www-data -e

*/10 * * * * /usr/bin/php /var/www/backdrop/core/scripts/cron.php

Verifica il path di cron.php nella tua installazione, perché può variare a seconda della struttura dei file. Se il comando non produce output non è un problema di per sé; il vero controllo è nel log dell’app o nella comparsa delle attività pianificate.

HTTPS: certificato, redirect e compatibilità

Su un sito pubblico, HTTPS non è opzionale. Se il dominio è già risolto correttamente, il passo più rapido è usare Let’s Encrypt con Certbot. Su Apache il flusso è molto lineare; su Nginx richiede un paio di controlli in più sul server block.

sudo apt install -y certbot python3-certbot-apache
sudo certbot --apache -d example.com -d www.example.com

Dopo l’emissione, controlla il redirect da HTTP a HTTPS e la scadenza del certificato. Il comando di prova più rapido è curl -I http://example.com, che deve mostrare un 301 verso HTTPS, e curl -I https://example.com, che deve restituire 200 o 302 coerenti con il comportamento del sito.

Se usi un CDN o un reverse proxy esterno, evita doppi redirect o loop tra edge e origin. In quel caso Backdrop deve vedere correttamente lo schema originale della richiesta; se no potresti avere login che saltano o link generati in HTTP. Il sintomo tipico è una home corretta ma form o redirect incoerenti.

Controlli finali: cosa verificare prima di considerare chiusa l’installazione

Un’installazione non è finita quando compare la home. È finita quando i punti essenziali sono stabili e replicabili: login, CRUD base, upload, cron, mail e log puliti. Fai quindi una verifica minima e pratica.

Apri il sito in HTTP e HTTPS e conferma il redirect corretto.
Effettua login nel pannello amministrativo.
Crea una pagina di prova e salvala.
Carica un file piccolo e verifica che finisca nella directory prevista.
Lancia il cron manualmente o attendi il ciclo pianificato e controlla che non generi errori.

Per i log, una rapida ispezione basta spesso a intercettare problemi nascosti.

sudo tail -n 50 /var/log/apache2/backdrop_error.log
sudo tail -n 50 /var/log/nginx/error.log
sudo journalctl -u php8.3-fpm -n 50 --no-pager

Se vedi warning ripetuti su permessi, sessioni o file temporanei, correggili prima di mettere il sito in produzione. Sono problemi piccoli solo finché il traffico è basso; poi diventano ticket continui e ripristini manuali.

Problemi tipici e come chiuderli in fretta

Se la schermata iniziale non compare, la sequenza giusta è sempre la stessa: controlla il layer, poi la prova minima, poi la modifica. In pratica: DNS risolve? Il web server risponde? PHP è attivo? Il database accetta connessioni? I log mostrano un errore preciso? Questo ordine evita di cambiare dieci cose insieme e non capire quale abbia funzionato.

Se il problema è una pagina bianca, il primo sospetto è quasi sempre PHP o un errore applicativo mascherato. Se il problema è un 403, guarda permessi e direttive del virtual host. Se il problema è un 500 subito dopo il submit del form database, il controllo va su credenziali, estensioni PHP e schema del database. Se il problema è un loop di redirect, il punto critico è la gestione di HTTPS e proxy.

In caso di dubbio, il comando più utile resta sempre uno dei più semplici: una richiesta HTTP diretta al server, senza browser e senza cache intermedie.

curl -I http://example.com
curl -I https://example.com

Se questi due test non tornano, non è ancora il momento di toccare Backdrop. Prima rimetti in ordine il path di rete, il virtual host o il certificato. Solo dopo ha senso intervenire sul CMS.

Conclusione operativa: installazione pulita, senza scorciatoie

Installare Backdrop CMS su Ubuntu 22.04 o 24.04 non è complicato, ma funziona bene solo se tratti l’installazione come un piccolo stack, non come un singolo pacchetto. Il risultato affidabile arriva da pochi passaggi fatti bene: pacchetti coerenti, database dedicato, web server configurato con rewrite, permessi sensati, HTTPS e cron.

Se vuoi un setup che regga anche dopo il primo mese, il consiglio pratico è questo: fai la procedura una volta in modo pulito, poi salva il virtual host, la configurazione PHP e i comandi di provisioning in un repository o in una nota operativa versionata. È il modo migliore per evitare che la prossima reinstallazione diventi un esercizio di memoria.