Come configurare Webuzo e pubblicare qualsiasi applicazione

Webuzo funziona bene quando lo usi per quello che è: un pannello di provisioning e gestione, non un sostituto della progettazione dell’architettura. Se l’obiettivo è pubblicare qualsiasi applicazione — PHP classico, framework moderni, CMS, backend API, nodi Node.js o stack misti — la differenza la fanno tre cose: come prepari il server, come separi i virtual host, e come controlli i punti fragili tipici di un hosting condiviso o semi-dedicato.

Il problema più comune non è “installare Webuzo”, ma arrivare a una configurazione in cui ogni applicazione abbia il suo dominio, il suo runtime, il suo database, il suo certificato e i suoi log. Quando questi elementi sono confusi, i guasti diventano banali da innescare e noiosi da diagnosticare: PHP che punta alla versione sbagliata, document root errata, permessi incoerenti, DNS non allineato, proxy invertito che rompe gli header, cron non attivi, SSL emesso sul nome sbagliato. Pubblicare bene significa ridurre questi attriti prima del go-live.

Quando Webuzo è la scelta giusta

Ha senso se vuoi centralizzare provisioning, domini, database, email e certificati su una singola macchina Linux con operatività semplice. È una buona opzione per piccoli hosting, ambienti di staging, VPS di team ridotti e server applicativi dove il tempo di setup conta più della costruzione manuale di ogni componente. Se invece hai bisogno di multi-tenant rigoroso, orchestrazione distribuita o policy complesse di security hardening, Webuzo può restare utile come pannello, ma non deve dettare il disegno dell’infrastruttura.

La regola pratica è questa: usa Webuzo per standardizzare la gestione, non per nascondere la topologia. Devi sempre sapere quale web server serve il sito, quale versione PHP è attiva, dove vive il database, dove finiscono i log e quale processo ascolta sulle porte pubbliche.

Preparazione del server prima di toccare il pannello

Prima di installare o usare Webuzo in produzione, verifica lo stato base del sistema. Se il server è già sporco, nessun pannello lo renderà più affidabile. Controlla spazio disco, RAM, time sync, firewall e risoluzione DNS locale. In pratica: se il nodo non è sano a livello OS, il problema lo vedrai dopo, ma con più passaggi da scartare.

Controlli minimi consigliati:

• spazio libero sufficiente su / e /var;
• hostname corretto e coerente con il FQDN pubblico;
• record DNS già pronti per i domini che andrai a pubblicare;
• porte 80 e 443 raggiungibili dall’esterno;
• cron attivo;
• backup pianificato prima di mettere dati reali.

Un controllo rapido del nodo può essere questo:

hostnamectl
ip a
ss -tulpn | egrep ':(80|443|3306|22)\s'
df -h
free -m
timedatectl status

Se qui trovi anomalie, correggile prima di pubblicare applicazioni. Un disco quasi pieno o un clock sfasato produce effetti che sembrano “bug dell’app” ma sono solo sintomi dell’host.

Installazione e primo accesso: cosa verificare davvero

Dopo l’installazione, la prima verifica non è l’estetica del pannello: è capire se i servizi base sono attivi e se Webuzo espone correttamente l’interfaccia amministrativa. Il percorso preciso varia a seconda della distribuzione e della versione del pannello, ma l’idea resta la stessa: controlla che web server, database e servizi di supporto siano in esecuzione, poi accedi all’URL di amministrazione dalla rete prevista.

Se il pannello non risponde, non partire subito dal reinstallare. Verifica prima il layer di trasporto e il servizio locale:

systemctl status webuzo
systemctl status httpd
systemctl status nginx
systemctl status mariadb
journalctl -u webuzo -n 50 --no-pager

Non tutti i stack usano gli stessi nomi di servizio, quindi il punto non è memorizzare un comando unico, ma confermare quale web server e quale database il tuo server sta effettivamente usando. Se il pannello è dietro reverse proxy o CDN, il problema può stare anche lì: in quel caso la prova più utile è una curl -I verso il backend diretto e una verso il nome pubblico.

Pubblicare un’applicazione PHP classica

Per un’applicazione PHP tradizionale, il flusso corretto è semplice: dominio, document root, versione PHP, database, permessi, SSL. Se salti uno di questi passaggi, il sito può sembrare online ma restare parzialmente rotto. Il caso tipico è la home page che risponde e le pagine interne che generano errori 500 perché il framework o il CMS non trova estensioni, directory scrivibili o configurazioni coerenti.

Passi consigliati:

1. crea il dominio o sottodominio dal pannello e assegna la document root corretta;
2. verifica che la versione PHP scelta sia compatibile con l’applicazione;
3. crea il database e l’utente con privilegi limitati al solo schema dell’app;
4. carica i file applicativi nella directory pubblica corretta;
5. imposta owner e permessi in modo coerente con il web server;
6. abilita HTTPS e forza il redirect solo dopo aver verificato il sito in HTTP e in HTTPS;
7. controlla i log applicativi e quelli del web server dopo il primo accesso.

Un esempio di verifica lato shell, utile per capire se il vhost punta davvero alla cartella giusta:

curl -I http://example.com
curl -I https://example.com
ls -la /home/username/public_html

Se la risposta HTTP mostra un sito diverso da quello atteso, il problema è quasi sempre nel mapping del virtual host o nel DNS che punta a un vecchio indirizzo. Se invece il mapping è corretto ma l’app non parte, il secondo sospetto è la versione PHP o una dipendenza mancante.

Versioni PHP e compatibilità: il punto dove si rompe più spesso

Con Webuzo puoi gestire più versioni PHP, ma non devi trattarle come un dettaglio estetico. Un’app moderna può richiedere estensioni specifiche, limiti di memoria più alti, opcache attivo o un handler diverso. Il rischio pratico è pubblicare il sito con la versione “di default” del server e scoprire dopo che Composer, framework o CMS falliscono in fase di bootstrap.

Le verifiche minime da fare sono due: quale versione PHP è assegnata al dominio e quali estensioni sono caricate. Se hai accesso alla shell, un test rapido è questo:

php -v
php -m | egrep 'curl|gd|intl|mbstring|mysqli|pdo|xml|zip|opcache'

Se il comando CLI mostra una versione ma il sito ne usa un’altra, non è un bug: è un disallineamento tra binario da terminale e runtime del vhost. In questo caso devi verificare la configurazione del dominio dal pannello e, se necessario, il file di configurazione del web server o del PHP handler. L’errore opposto è ancora più comune: si aggiorna PHP per il dominio ma non si controllano le estensioni, e l’app resta ferma su una funzione non disponibile.

Database: separazione, credenziali e test di connessione

Ogni applicazione dovrebbe avere il suo database e il suo utente, con privilegi minimi. Evita account condivisi tra più siti: quando un’app viene compromessa o malconfigurata, il danno si allarga subito. In Webuzo la gestione del database è comoda, ma la policy resta tua: un database per applicazione, un utente per applicazione, password ruotata quando serve e mai esposta in chiaro nei file pubblici.

Per testare una connessione, usa il layer applicativo o un client MySQL/MariaDB dal server:

mysql -u appuser -p -h 127.0.0.1 appdb
SHOW DATABASES;
SELECT VERSION();

Se il login fallisce, distingui subito tra errore di credenziali, socket locale e servizio fermo. Un sito che restituisce pagina bianca o 500 spesso non ha un problema “di PHP”, ma semplicemente non riesce a parlare col database. Nei log applicativi cerca messaggi su timeout, connessione rifiutata, access denied o schema mancante. Se il DB è remoto, aggiungi anche la verifica di rete e firewall.

HTTPS, certificati e redirect: evitare il classico loop

Il certificato va emesso sul nome corretto, dopo che il DNS punta davvero al server e prima di forzare redirect aggressivi. Il loop classico nasce quando si attiva il redirect HTTPS prima che il certificato sia valido o prima che il vhost risponda correttamente su 443. Il risultato è un sito che “sembra” online ma non carica oppure genera warning e redirect infiniti.

Controlli pratici:

openssl s_client -connect example.com:443 -servername example.com 

Se il certificato non corrisponde al dominio o non include il nome richiesto, il problema è nel provisioning SSL o nel vhost. Se il certificato è corretto ma il browser continua a segnalare errore, controlla catena intermedia, SNI e eventuale proxy/CDN davanti al server. In presenza di CDN, il certificato lato origin e quello lato edge sono due cose diverse: devi verificare entrambi.

Pubblicare framework moderni e app con build separata

Con applicazioni moderne il punto non è solo servire file PHP. Molte app hanno build frontend, variabili d’ambiente, cache, code worker e processi separati. Webuzo può ospitarle, ma devi decidere con chiarezza dove gira ogni componente. Se il framework richiede un reverse proxy verso un processo Node o un’app Python, il pannello da solo non basta: devi configurare il backend, il dominio, il proxy e i permessi in modo coerente.

Per un deploy pulito, separa almeno questi elementi:

1. codice sorgente in una directory non pubblica o comunque distinta dalla document root;
2. directory pubblica con solo gli asset o l’entrypoint necessario;
3. file di configurazione con variabili ambiente fuori dal web root;
4. processo worker o app server gestito da systemd o da un supervisore affidabile;
5. cache e storage persistente con permessi coerenti.

Un esempio tipico è un’app Laravel o Symfony: il web server deve puntare alla cartella pubblica corretta, mentre il resto del progetto rimane fuori dall’esposizione diretta. Se invece pubblichi l’intera codebase nella root web, stai aumentando inutilmente la superficie d’attacco.

Node.js, Python e altri runtime: quando il pannello non basta

Per applicazioni non-PHP, Webuzo può essere utile come strato di gestione del dominio e del certificato, ma il runtime vero va trattato come servizio di sistema. Un’app Node o Python non dovrebbe vivere come processo lanciato a mano in shell: va resa persistente, loggata e riavviabile. Il pannello può aiutare, ma la resilienza la ottieni con systemd, file di unità chiari e una porta locale dietro reverse proxy.

Esempio concettuale: l’app ascolta su 127.0.0.1:3000, mentre il dominio pubblico passa dal web server. In questo modo non esponi direttamente il processo applicativo su Internet e mantieni il controllo su TLS, header e accessi. Se il backend si ferma, il proxy ti restituisce errore immediato invece di lasciare il client in timeout senza contesto.

Per verificare il backend locale:

curl -I http://127.0.0.1:3000
systemctl status myapp
journalctl -u myapp -n 100 --no-pager

Se il test locale funziona ma il dominio pubblico no, il problema è nel proxy o nel vhost. Se il test locale fallisce, il problema è nel servizio applicativo, non nel pannello.

Permessi, ownership e upload: la parte che genera più incidenti silenziosi

Molti bug di pubblicazione sono semplicemente problemi di permessi. Un’app non può scrivere nella cache, nel filesystem temporaneo o nelle directory di upload; oppure, al contrario, è troppo permissiva e lascia scrivibili file che non dovrebbero esserlo. Il risultato cambia, ma il difetto di fondo è lo stesso: ownership incoerente.

La regola operativa è mantenere il principio del minimo privilegio. Le directory che devono essere scritte dall’app vanno identificate esplicitamente, non con chmod 777 o scorciatoie simili. Un controllo di base può essere:

find /home/username/public_html -maxdepth 2 -type d -printf '%M %u %g %p\n' | head -50
find /home/username/public_html -maxdepth 2 -type f -printf '%M %u %g %p\n' | head -50

Se trovi file appartenenti a root o directory non scrivibili dall’utente del sito, correggi con criterio e verifica subito il comportamento dell’app. Meglio una modifica piccola e reversibile che un reset massivo dei permessi su tutta la home.

DNS e propagazione: il falso problema che blocca i deploy

Un sito appena pubblicato può sembrare rotto quando in realtà il DNS non è ancora allineato. Non dare per scontato che il dominio punti al server giusto solo perché lo vedi da casa tua. Controlla sempre i record A/AAAA e, se usi proxy o CDN, il comportamento del nome pubblico e del backend origin. La verifica più semplice è un dig o un nslookup verso i resolver che ti interessano.

dig +short example.com A
dig +short example.com AAAA
dig +trace example.com

Se il record è corretto ma il traffico raggiunge il server sbagliato, il problema può stare nella cache del resolver, nel vecchio IP ancora attivo, o in un proxy intermedio. In fase di migrazione, tieni sempre un TTL ragionevole e prepara un rollback del DNS verso il vecchio origin fino a quando non hai validato il nuovo stack.

Backup e rollback: l’unica parte non negoziabile

Prima di pubblicare o migrare un sito su Webuzo, fai un backup reale e verificato: file, database, configurazioni del vhost, eventuali cron e variabili ambiente. Il backup non è “esiste una copia da qualche parte”, ma “so ripristinarla senza improvvisare”. Se il sito è critico, prova almeno un restore su ambiente separato.

Una procedura minima di rollback deve includere:

1. ripristino dei file applicativi dalla copia precedente;
2. ripristino del database o import del dump;
3. ripristino della configurazione del dominio e del certificato se modificati;
4. switch DNS o reverse proxy al precedente origin;
5. verifica finale con curl e controllo log.

Se non hai un rollback documentato, non hai finito il deployment. Hai solo spostato il rischio più avanti.

Checklist operativa prima del go-live

Questa è la lista che uso per evitare i guasti più banali:

1. dominio risolve all’IP corretto;
2. HTTP risponde con il sito giusto;
3. HTTPS presenta il certificato corretto;
4. versione PHP compatibile e con estensioni richieste;
5. database raggiungibile e credenziali testate;
6. permessi corretti sulle directory scrivibili;
7. cron attivi se l’app li richiede;
8. log applicativi consultabili;
9. backup esistente e rollback provato;
10. monitoraggio minimo su spazio disco, RAM e error rate.

Se anche uno solo di questi punti è incerto, il sito può essere “pubblicato” ma non è ancora operativo in modo affidabile. La differenza tra un pannello usato bene e uno usato male sta tutta qui: il primo ti fa risparmiare tempo senza nascondere la complessità; il secondo la sposta soltanto più in basso.

Conclusione operativa: pubblicare qualsiasi applicazione senza farsi male

Webuzo è comodo quando diventa il punto di gestione coerente di domini, runtime, database e certificati. Ma la pubblicazione di un’app non si riduce a “caricare i file e premere attiva”. Serve disciplina: separare i layer, verificare il DNS, controllare il runtime, proteggere i segreti, limitare i permessi e preparare un rollback. Con questo approccio puoi pubblicare quasi qualsiasi applicazione su un VPS o su un server dedicato senza trasformare il pannello in una scatola nera.

Assunzione: il server è Linux recente, con accesso amministrativo, e Webuzo è usato come strato di provisioning sopra uno stack web classico.