Installare WordPress con Bitnami su Ubuntu 20.04 LTS

Quando Bitnami ha senso su Ubuntu 20.04 LTS

Se l’obiettivo è portare online WordPress in modo rapido e con meno variabili possibili, lo stack Bitnami su Ubuntu 20.04 LTS è una strada sensata. Non è la scelta più “pulita” se vuoi costruire tutto a mano, ma è pratica quando conta avere un pacchetto coerente con Apache, PHP, MariaDB e le impostazioni base già allineate. Il punto non è solo installare WordPress: è farlo con un perimetro chiaro, un punto di backup semplice e una configurazione che non si rompa al primo aggiornamento di sistema.

Su Ubuntu 20.04 LTS il vantaggio principale è la stabilità del sistema operativo, mentre Bitnami riduce la frammentazione dello stack applicativo. In cambio, devi accettare che i componenti non vivano dove li troveresti in una installazione LAMP tradizionale. I binari, le configurazioni e i log stanno sotto /opt/bitnami, quindi conviene decidere subito se vuoi gestire il server “alla Bitnami” oppure integrare parti del sistema con strumenti standard di Ubuntu. Mischiare i due approcci senza disciplina è il modo più veloce per creare confusione operativa.

Prerequisiti reali, non teorici

Prima di toccare il server, verifica di avere un IP pubblico raggiungibile, un nome DNS già pronto o almeno un piano per puntarlo dopo l’installazione, accesso SSH con privilegi sudo e uno spazio disco ragionevole. Per un sito WordPress base, 20 GB sono il minimo sindacale; sotto quella soglia rischi di trovarti stretto appena entrano media, backup locali e log. Se il server è dietro firewall o security group, apri solo ciò che serve: SSH, HTTP e HTTPS. Il resto deve rimanere chiuso fino a prova contraria.

Controlla anche la versione di Ubuntu. Questa guida è pensata per 20.04 LTS, quindi se sei su 22.04 o 24.04 la logica resta simile, ma cambiano dettagli di pacchettizzazione, supporto e in alcuni casi il comportamento dei servizi. Non dare per scontato che un installer Bitnami vecchio sia il più adatto a una release nuova: la compatibilità va letta nella documentazione del pacchetto che scarichi, non nell’inerzia di chi “l’ha sempre fatto così”.

Installazione dello stack Bitnami

Bitnami distribuisce installer completi per Linux. La procedura concreta cambia in base alla release del pacchetto, ma il flusso è sempre lo stesso: scaricare l’installer, renderlo eseguibile e lanciare il setup come utente con privilegi elevati. Prima di partire, conviene aggiornare l’indice pacchetti di sistema e assicurarsi che il server abbia strumenti base come curl e wget.

Un esempio operativo, da adattare alla versione effettiva che scegli, è questo:

sudo apt update
sudo apt install -y curl wget
cd /tmp
wget https://example.com/bitnami-wordpress-installer.run
chmod +x bitnami-wordpress-installer.run
sudo ./bitnami-wordpress-installer.run

Il dettaglio importante è il percorso di installazione: Bitnami usa normalmente /opt/bitnami. Dentro troverai Apache, PHP, MariaDB, WordPress e gli script di controllo. Questa struttura è comoda perché isola tutto, ma richiede che tu sappia dove guardare quando qualcosa non funziona. Se cerchi i log nel classico /var/log/apache2, potresti perdere tempo inutile.

Durante l’installazione ti verranno chiesti alcuni parametri, tra cui password amministrative e nome host. Qui la regola è semplice: non usare credenziali banali, non riutilizzare password e non lasciare il sito esposto prima di aver completato la configurazione minima. Se il server è in produzione o quasi-produzione, salva le credenziali in un gestore sicuro e non in un file di testo sul desktop dell’operatore.

Primo accesso e verifica del servizio

Una volta terminato il setup, il primo controllo non è “vedere la home”, ma verificare che i servizi interni siano vivi. Con Bitnami hai in genere uno script di controllo dedicato. Se il pacchetto installato lo prevede, usa i comandi di stato per Apache, MariaDB e PHP-FPM o moduli equivalenti. Il vantaggio è che non dipendi dal solo browser: capisci subito se il problema è a livello di servizio o di applicazione.

sudo /opt/bitnami/ctlscript.sh status

Se i servizi risultano attivi, prova una richiesta locale verso la macchina. Questo separa i problemi di rete dai problemi applicativi. Un controllo utile è:

curl -I http://127.0.0.1/

Ti aspetti un HTTP/1.1 200 OK oppure un redirect verso HTTPS, a seconda di come è configurato lo stack. Se ottieni timeout, refused o 5xx, il problema non è DNS: è già sul server o nel servizio web. Se invece in locale funziona ma da fuori no, il layer da guardare è firewall, security group, NAT o bilanciatore.

Configurazione iniziale di WordPress senza improvvisare

La fase iniziale di WordPress è il momento in cui molti ambienti diventano fragili per eccesso di fretta. Imposta subito lingua, titolo del sito, utente amministratore e password forte. Non usare “admin” come nome utente e non lasciare il sito in uno stato di configurazione provvisoria più del necessario. Una installazione lasciata mezza aperta è una porta aperta, non un cantiere innocuo.

Se il wizard ti chiede il nome host o se devi configurare il dominio manualmente, assicurati che il record DNS punti all’IP corretto prima di forzare il traffico pubblico. Un semplice controllo evita ore di diagnosi sbagliata:

dig +short A esempio.it
curl -I https://esempio.it

Il primo comando deve restituire l’IP previsto; il secondo deve mostrare un codice coerente con lo stato del sito. Se il DNS non è allineato, il sito può sembrare “giù” anche se il server è perfetto. In ambienti con CDN o proxy, il controllo va fatto anche sul layer edge, perché il record corretto non garantisce che il traffico finisca davvero sull’origin giusto.

HTTPS: abilitare TLS senza creare un castello fragile

Su un sito WordPress esposto pubblicamente HTTPS non è opzionale. Il punto non è solo la cifratura del traffico: è evitare warning del browser, problemi di login e contenuti misti che rompono media e risorse statiche. Con Bitnami puoi usare il tool di configurazione certificati incluso nello stack oppure integrare un certificato già emesso da una CA. Se hai già una policy aziendale su certificati, seguila: non ha senso introdurre un secondo percorso solo perché lo stack lo consente.

In linea generale, il flusso è: ottenere un certificato valido, configurare Apache perché risponda in HTTPS, forzare il redirect da HTTP a HTTPS e verificare che WordPress generi URL corretti. Se il certificato è Let’s Encrypt, la parte delicata è il rinnovo automatico. Se è un certificato enterprise, la parte delicata è il rinnovo manuale prima della scadenza. In entrambi i casi, metti un alert sulla data di expiration e non affidarti alla memoria.

openssl s_client -connect esempio.it:443 -servername esempio.it 

Con questo controllo verifichi handshake, catena e nome host presentato. Se il browser mostra un certificato valido ma WordPress continua a generare link in HTTP, il problema è nella configurazione dell’URL del sito, non nel TLS. In quel caso devi allineare i valori di siteurl e home nel database o dalla UI di WordPress, evitando modifiche casuali ai file di core.

Hardening minimo che vale subito il costo

Non serve trasformare questo server in una fortezza per guadagnare un po’ di igiene. Bastano poche misure fatte bene. La prima è limitare l’accesso SSH con chiavi, disabilitare il login root diretto e, se possibile, restringere l’accesso per IP. La seconda è tenere WordPress aggiornato insieme ai plugin e ai temi che davvero servono. La terza è verificare che i permessi dei file siano coerenti con il modello di esecuzione dello stack Bitnami.

Un controllo utile è verificare che il web server non abbia più privilegi del necessario sui file applicativi. In un ambiente Bitnami, i percorsi si concentrano sotto /opt/bitnami, quindi conviene capire bene chi possiede cosa prima di cambiare permessi a caso. Una modifica troppo permissiva può funzionare oggi e diventare un problema di sicurezza domani. Una troppo restrittiva, invece, può rompere upload, aggiornamenti e cache.

Per la superficie d’attacco, controlla anche ciò che è realmente esposto sulla rete. Se il server ospita solo WordPress, non ha senso lasciare porte inutili aperte. Un audit minimo con ss -tulpn o con il pannello del provider ti dice quali servizi ascoltano davvero. Se trovi qualcosa che non ti aspetti, fermati e capisci prima di intervenire.

sudo ss -tulpn

Backup: il vero test di maturità dell’installazione

Un’installazione WordPress senza backup verificato è un esperimento, non un servizio. Con Bitnami hai il vantaggio di una struttura abbastanza prevedibile: file applicativi, database e configurazioni vivono in percorsi noti. Questo semplifica sia lo snapshot della VM sia il backup applicativo. La cosa importante è non confondere “avere una copia” con “avere un ripristino funzionante”.

Il livello minimo è questo: backup del database, backup della directory WordPress e un test di restore su una macchina o ambiente separato. Se fai solo dump SQL ma perdi media e plugin, il sito torna online a metà. Se salvi i file ma non il database, la struttura dei contenuti si scompone. Se fai snapshot del disco senza sapere come ripristinarlo, hai solo spostato il problema nel tempo.

mysqldump -u root -p nome_db > backup-nome_db.sql
sudo tar -czf backup-bitnami-wordpress.tar.gz /opt/bitnami

Questi comandi sono un punto di partenza, non una politica definitiva. In produzione devi pensare anche a retention, cifratura dei backup, destinazione off-site e verifica periodica del ripristino. Se i backup restano sullo stesso volume del sito, un guasto al disco ti lascia senza sito e senza copia. Se restano in chiaro, stai aggiungendo un rischio inutile.

Aggiornamenti e manutenzione senza rompere il sito

La manutenzione di uno stack Bitnami va trattata come un change controllato, non come un click impulsivo. Prima di aggiornare, annota la versione del pacchetto, controlla lo stato dei servizi, fai backup e definisci il rollback. Se l’aggiornamento riguarda WordPress, plugin o tema, fai prima un test in staging. Se riguarda lo stack sottostante, leggi bene le note di release e verifica se ci sono cambi di compatibilità con PHP, database o Apache.

Il comportamento più sano è aggiornare con una finestra di manutenzione, osservare gli errori lato web e controllare i log. I log Bitnami sono spesso sotto /opt/bitnami/apache2/logs/ e quelli dell’applicazione possono essere in wp-content o nel pannello di debug di WordPress, se abilitato. Non attivare debug permanente in produzione: se serve, abilitalo per il tempo strettamente necessario e poi spegnilo.

Se dopo un aggiornamento vedi pagina bianca, 500 o redirect anomali, non saltare subito alle modifiche invasive. Prima verifica quale layer si è rotto: PHP, plugin, tema, database o rewrite rules. Nella pratica, molte rotture “misteriose” sono plugin incompatibili o cache lato applicazione che nasconde l’errore reale. Un semplice controllo dei log ti fa risparmiare tempo e riduce il rischio di peggiorare la situazione.

Problemi tipici e dove guardarli per primi

Se il sito non risponde, la sequenza corretta è quasi sempre: DNS, rete, servizio web, PHP, database, storage. Se il nome non risolve, non ha senso aprire il codice. Se il web server risponde ma WordPress no, il problema è più in alto nello stack. Se il sito è lento, misurare TTFB e p95 aiuta più di mille ipotesi. Se il disco è pieno, ogni altro ragionamento è secondario.

Un paio di comandi rapidi chiariscono molto:

df -h
free -m
sudo journalctl -u apache2 --no-pager -n 50

Nel caso di Bitnami, il nome del servizio potrebbe variare in base al pacchetto e alla distribuzione dello stack, quindi se apache2 non restituisce nulla, usa lo script di controllo incluso. Il concetto resta identico: non indovinare, osserva. Se il problema è memoria, potresti vedere OOM killer o processi terminati. Se il problema è disco, i log lo diranno con chiarezza. Se il problema è database, vedrai timeout o connessioni rifiutate lato applicazione.

Quando conviene uscire da Bitnami

Bitnami è comodo finché il tuo obiettivo è rapidità, coerenza e manutenzione relativamente semplice. Se però devi integrare il server con standard molto rigidi, automazione avanzata o policy di sistema che pretendono gestione nativa dei pacchetti, potresti preferire una installazione manuale con stack classico. Non è una bocciatura di Bitnami: è una scelta di governance. La domanda giusta non è “Bitnami è buono?”, ma “Bitnami è adatto al modo in cui questo ambiente deve essere governato?”.

In un hosting piccolo o medio, o in un ambiente di test che deve somigliare a produzione senza assorbirne tutta la complessità, Bitnami resta una soluzione concreta. In un’infrastruttura con standard forti su logging centralizzato, hardening, conformità e patching, devi valutare se il vantaggio iniziale compensa il costo di integrazione. La risposta cambia da contesto a contesto, e fingere il contrario porta quasi sempre a una futura migrazione fatta male.

Checklist finale prima di mettere il sito in produzione

Prima del go-live, verifica questi punti in ordine: il dominio risolve sull’IP corretto, il certificato TLS è valido, WordPress risponde in HTTPS, il login amministrativo funziona, i backup sono eseguibili e il restore è stato provato almeno una volta. Se usi plugin essenziali, controlla che siano aggiornati e realmente necessari. Ogni plugin in più è una variabile in più, non un premio gratuito.

Fai anche un controllo di base sui tempi di risposta. Non serve un laboratorio APM per capire se il sito è sano: basta registrare TTFB, tempo di apertura home e risposta del login prima e dopo il rilascio. Se i numeri peggiorano in modo netto, hai un segnale. Se restano stabili, hai almeno una baseline utile per i controlli futuri.

In sintesi operativa, la qualità di una installazione WordPress con Bitnami su Ubuntu 20.04 LTS non dipende dall’installer in sé, ma da quanto bene gestisci DNS, TLS, backup, permessi e aggiornamenti. Il pacchetto ti fa risparmiare tempo all’inizio; la disciplina operativa ti evita di perderlo dopo.