Come installare WordOps su Ubuntu passo dopo passo

WordOps è un toolkit pensato per installare e amministrare stack web su Ubuntu in modo rapido, con Nginx, PHP-FPM, MariaDB e strumenti utili per il provisioning dei siti. Ha senso usarlo quando vuoi un ambiente ordinato, replicabile e abbastanza standardizzato da ridurre gli errori manuali, ma senza rinunciare al controllo diretto del server.

Prima di partire conviene chiarire il contesto: questa procedura è adatta a un’installazione pulita o a un server appena predisposto. Se sul sistema ci sono già stack web, database o configurazioni personalizzate, il rischio è sovrascrivere porte, servizi o dipendenze. In quel caso il passo corretto è fare un inventario dello stato attuale e verificare eventuali conflitti prima di procedere.

Requisiti minimi e controllo preliminare

WordOps si installa su Ubuntu recente; nella pratica, le versioni LTS sono la scelta più sensata per stabilità e supporto. Prima di toccare il server, verifica tre cose: privilegi amministrativi, connettività verso i repository e spazio disco sufficiente per pacchetti, log e database.

Un controllo rapido evita metà dei problemi tipici dell’installazione:

lsb_release -a || cat /etc/os-release

Il risultato deve confermare una versione supportata di Ubuntu. Se il comando non è disponibile, il fallback su /etc/os-release basta per identificare la release. Se stai lavorando su un server remoto, assicurati anche di avere accesso SSH con un utente dotato di sudo.

Controlla poi spazio e memoria, perché l’installazione di stack web non è onerosa come un ambiente di build, ma su macchine piccole il margine operativo si assottiglia presto:

df -h
free -h

Se la partizione root è quasi piena o la RAM è insufficiente, l’installazione può fallire a metà o lasciare servizi in stato incoerente. In quel caso conviene liberare spazio o aumentare le risorse prima di andare avanti.

Aggiornamento del sistema prima dell’installazione

Su un server appena creato o non aggiornato da tempo, il primo passo utile è mettere in ordine i pacchetti di base. Questo riduce problemi di dipendenze e ti evita di installare WordOps sopra librerie vecchie o incoerenti.

sudo apt update
sudo apt upgrade -y

Dopo l’aggiornamento, se il kernel o componenti fondamentali sono cambiati, è prudente riavviare il server prima di installare il resto. Non è obbligatorio in assoluto, ma in pratica riduce il rischio di avere servizi che leggono librerie vecchie o si agganciano a moduli non ancora ricaricati.

Per verificare che il sistema sia tornato operativo dopo un reboot, basta controllare uptime e servizi essenziali:

uptime
systemctl --failed

Il secondo comando deve restituire zero unità in errore. Se compaiono servizi falliti, conviene capire il motivo prima di installare altro, perché potresti confondere un problema preesistente con uno introdotto da WordOps.

Installazione di WordOps su Ubuntu

La via più lineare è usare lo script ufficiale di installazione. È il punto in cui devi essere più rigoroso: esegui il download solo da fonte nota, verifica che l’URL sia quello previsto e conserva sempre la possibilità di ripetere il passo da zero se qualcosa va storto.

In genere il flusso è questo:

cd /tmp
wget -qO wo wops.cc && sudo bash wo

Se l’URL di distribuzione cambia nel tempo, il principio non cambia: scarica lo script dal canale ufficiale indicato dalla documentazione del progetto e lancialo con privilegi amministrativi. Se preferisci un approccio più prudente, scarica prima il file, ispezionalo e solo dopo eseguilo.

Un controllo minimo del file scaricato è sempre una buona pratica:

file wo
sed -n '1,40p' wo

Qui l’obiettivo non è leggere tutto lo script, ma verificare che il contenuto sia coerente con ciò che ti aspetti: niente binari strani, niente testo corrotto, niente redirect non previsti. Se il file non sembra corretto, interrompi e verifica la fonte.

Durante l’installazione, WordOps può chiedere conferme o scaricare dipendenze aggiuntive. Lascia che completi il provisioning senza intervenire su altri servizi nel frattempo. Se stai lavorando su un server di produzione, il blast radius è medio-alto: l’installazione tocca pacchetti di sistema, servizi web e database. Il rollback realistico, in caso di errore grave, è ripristinare snapshot o backup del sistema, non “annullare” selettivamente tutto a mano.

Verifica dell’installazione e primi controlli

Quando l’installazione termina, il primo obiettivo è verificare che WordOps sia presente e che i comandi rispondano correttamente. Non partire subito con i siti: prima accertati che la base funzioni.

wo --help
wo stack status

Il primo comando deve mostrare l’elenco delle opzioni disponibili; il secondo, se supportato nella tua versione, deve restituire lo stato dello stack o dei servizi gestiti. Se un comando non è riconosciuto, non è necessariamente un errore grave: può dipendere dalla versione installata. In quel caso verifica la documentazione locale o il comportamento del tool con wo help.

Controlla anche che i servizi principali siano attivi a livello systemd:

systemctl status nginx
systemctl status mariadb
systemctl status php*-fpm

Su alcune distribuzioni il pattern php*-fpm va adattato alla versione installata, quindi è normale dover prima elencare le unità disponibili:

systemctl list-units --type=service | grep -E 'php.*fpm|nginx|mariadb'

Se uno dei servizi è inattivo o in errore, guarda subito i log prima di tentare riavvii ripetuti:

journalctl -u nginx -n 50 --no-pager
journalctl -u mariadb -n 50 --no-pager

Le ultime righe di log spesso bastano per capire se il problema è una porta già occupata, un file di configurazione errato o una dipendenza mancante. È il momento giusto per fermarsi e correggere la causa, non per forzare il servizio a partire alla cieca.

Primo sito con WordOps: creazione e test

Una volta validato il tool, puoi passare alla creazione del primo sito. WordOps semplifica molto il provisioning, ma conviene comunque ragionare come faresti a mano: nome host corretto, DNS già puntato, document root chiara e PHP coerente con l’applicazione.

La sintassi esatta varia in base alla versione e ai moduli installati, ma il flusso tipico prevede la creazione del sito con un dominio specifico e l’eventuale selezione della versione PHP. Prima di eseguire il comando definitivo, controlla la guida locale di WordOps per i parametri effettivamente disponibili nel tuo ambiente.

wo site create example.com --php81 --wp

Questo è un esempio concettuale: il dominio va sostituito con quello reale e gli switch possono cambiare in base alla release del tool. Il punto operativo è sempre lo stesso: creare il sito con una configurazione esplicita, non affidarsi ai default se non li hai verificati prima.

Subito dopo la creazione, testa la risposta HTTP dal server stesso, in modo da separare i problemi di DNS da quelli dell’origin:

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

Se la risposta locale è corretta ma il dominio pubblico no, il problema è quasi sempre a monte: DNS, CDN, proxy o firewall. Se invece anche il localhost non risponde come previsto, il difetto è sul lato Nginx/PHP o nella configurazione del sito appena creato.

HTTPS, certificati e sicurezza di base

Su un server esposto a Internet, il passo successivo quasi obbligato è abilitare HTTPS. WordOps di solito integra il supporto ai certificati in modo semplice, ma il punto non è solo “attivare il lucchetto”: bisogna essere sicuri che il nome host risolva correttamente e che la porta 80 sia raggiungibile per la challenge del certificato, se usi un metodo HTTP-01.

Prima di richiedere il certificato, controlla che il dominio punti davvero al server:

dig +short example.com
curl -I http://example.com

Se il DNS non è ancora propagato o punta a un IP errato, la richiesta del certificato fallisce o si completa sul server sbagliato. Anche qui conviene risolvere prima la causa e non insistere con tentativi ripetuti.

Dal punto di vista della sicurezza, non lasciare aperti servizi che non ti servono. Dopo l’installazione, verifica quali porte sono realmente in ascolto:

ss -tulpn

Ti interessa vedere solo ciò che è coerente con lo stack: tipicamente SSH, HTTP/HTTPS, database solo se esposto localmente o su rete privata. Se compare un servizio inatteso, va identificato prima di considerarlo normale.

Gestione operativa: aggiornamenti, backup e manutenzione

WordOps semplifica il provisioning, ma la parte importante arriva dopo: aggiornamenti, coerenza delle configurazioni e backup. Ogni modifica al sito o allo stack dovrebbe essere tracciabile. Se cambi una configurazione Nginx o PHP, salva prima una copia del file e annota la differenza.

Un approccio prudente è questo:

Per esempio, se devi intervenire su un virtual host, conserva sempre il file originale in una copia con data o usa un sistema di versioning locale. In caso di errore, il rollback deve essere immediato: ripristini il file precedente, ricarichi Nginx e ricontrolli i log.

sudo cp /etc/nginx/sites-available/example.com.conf /etc/nginx/sites-available/example.com.conf.bak
sudo nginx -t
sudo systemctl reload nginx

Il comando nginx -t è il controllo minimo che non va saltato: se la sintassi è errata, il reload fallisce o, peggio, potresti interrompere il servizio. Il test di configurazione deve essere sempre parte del flusso, non un extra facoltativo.

Problemi tipici dopo l’installazione

I casi più frequenti non sono misteriosi: porta 80 o 443 già occupate, DNS non allineato, certificato non emesso, PHP-FPM non avviato, permessi errati sulla document root o database non raggiungibile. Il modo corretto di affrontarli è sempre lo stesso: osservare prima, modificare poi.

Se il sito restituisce 502, il problema spesso è tra Nginx e PHP-FPM. La verifica minima è capire se il socket o il servizio PHP esiste davvero e se risponde:

systemctl status php8.1-fpm
journalctl -u php8.1-fpm -n 50 --no-pager

Se ricevi 500, guarda i log dell’applicazione e di Nginx. Se la pagina non si carica ma il server risponde, controlla la catena DNS/CDN/proxy. Se il server sembra “morto”, verifica in ordine: carico, disco, memoria, stato dei servizi e log di sistema.

top
journalctl -p err -n 50 --no-pager
df -h

Questi tre controlli bastano spesso a distinguere un problema di risorse da un problema di configurazione. Se il disco è pieno, il rollback operativo può essere liberare spazio o spostare log e backup; se la RAM è al limite, va valutato un resize o una configurazione più leggera; se i log mostrano errori di sintassi, si corregge il file e si ricarica il servizio.

Quando WordOps ha senso e quando no

WordOps è una buona scelta se vuoi un setup rapido, ripetibile e basato su componenti noti. È meno adatto se devi costruire un’architettura molto personalizzata, se vuoi totale libertà sui dettagli di provisioning oppure se il server è già fortemente standardizzato con strumenti diversi. In quel caso il rischio non è tecnico in sé, ma operativo: due sistemi di gestione che si sovrappongono tendono a generare confusione e interventi doppi.

La regola pratica è semplice: usa WordOps quando vuoi ridurre il tempo di setup e mantenere uno stack coerente; evita di mescolarlo con configurazioni manuali non documentate. Se devi intervenire a mano, fallo in modo controllato, con backup e con la consapevolezza che il tool potrebbe rigenerare o sovrascrivere parte della configurazione in aggiornamenti successivi.

Assunzioni: server Ubuntu recente, accesso root o sudo disponibile, installazione su macchina non già stratificata da altri stack web, dominio già pronto o in fase di configurazione.