Come installare WonderCMS su AlmaLinux 9

Su AlmaLinux 9, WonderCMS gira bene se tieni separati i tre pezzi che contano davvero: web server, PHP-FPM e permessi sul filesystem. Il CMS è leggero, ma proprio perché è minimale non perdona configurazioni approssimative: una directory sbagliata, SELinux lasciato a caso o un PHP-FPM non allineato al socket e ti ritrovi con schermate bianche o 403 apparentemente inspiegabili.

Qui la scelta più pulita è Nginx con PHP-FPM. Apache funziona, ma su un’installazione essenziale come WonderCMS Nginx riduce rumore operativo e rende più semplice capire dove si rompe il flusso: DNS, edge, web server, PHP, file system. L’obiettivo è arrivare a un sito funzionante con una base reversibile, così se qualcosa non torna puoi tornare indietro senza lasciare configurazioni sparse.

Prerequisiti reali, non teorici

Prima di installare, verifica tre cose: accesso root o sudo, un record DNS già puntato al server e una macchina aggiornata. Se il dominio non risolve ancora, l’installazione locale può anche andare a buon fine, ma il test finale via browser ti confonderà con un problema che non è del CMS.

Controlla anche la release di AlmaLinux e lo stato base dei servizi. Se stai partendo da un server appena creato, conviene aggiornare subito il sistema e installare i pacchetti necessari in un colpo solo.

sudo dnf update -y
sudo dnf install -y nginx php php-fpm php-cli php-curl php-zip php-mbstring php-gd php-xml unzip curl policycoreutils-python-utils

Il pacchetto policycoreutils-python-utils serve per SELinux, non per bellezza. Su molte installazioni è la differenza tra “funziona in permissive” e “funziona davvero in enforcing”.

Scaricare WonderCMS in una directory pulita

WonderCMS è distribuito come archivio ZIP. La strategia più lineare è creare una document root dedicata, scaricare l’archivio, estrarlo e poi assegnare i permessi corretti al servizio web. Evita di scompattare direttamente dentro directory già piene di test o vecchi file: quando qualcosa va storto, vuoi sapere con precisione cosa hai aggiunto.

sudo mkdir -p /var/www/wondercms
cd /tmp
curl -L -o wondercms.zip https://wondercms.com/releases/latest
sudo unzip wondercms.zip -d /var/www/wondercms

Il link di download può cambiare nel tempo: se il repository o la pagina ufficiale modificano il percorso, prendi il file dal sito del progetto e sostituisci l’URL. Se non hai certezza dell’endpoint, non inventarlo: verifica la release corrente nella documentazione del progetto o nella pagina di download prima di automatizzare.

Dopo l’estrazione, controlla che i file siano effettivamente presenti nella root del sito e non in una sottocartella annidata. L’errore classico è ritrovarsi con Nginx che punta a una directory vuota mentre il CMS sta un livello più sotto.

ls -la /var/www/wondercms

Se vedi una struttura con file PHP, asset e una pagina iniziale, sei nel posto giusto. Se invece compare una directory extra, correggi subito il percorso del root nella configurazione web.

Configurazione Nginx per WonderCMS

WonderCMS non richiede rewrite complicati, ma Nginx deve passare i file PHP a PHP-FPM e consentire il fallback corretto delle richieste. La configurazione minima è piccola, ma va scritta bene: un errore nel try_files o nel socket PHP e il sito sembra morto pur essendo online.

server {
    listen 80;
    server_name example.com www.example.com;

    root /var/www/wondercms;
    index index.php index.html;

    access_log /var/log/nginx/wondercms_access.log;
    error_log /var/log/nginx/wondercms_error.log;

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

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass unix:/run/php-fpm/www.sock;
    }

    location ~* \.(png|jpg|jpeg|gif|ico|css|js|svg|woff|woff2)$ {
        expires 30d;
        access_log off;
        log_not_found off;
    }

    location ~ /\. {
        deny all;
    }
}

Il punto più delicato è fastcgi_pass unix:/run/php-fpm/www.sock;. Su AlmaLinux 9 il socket standard del pool predefinito è spesso quello, ma se hai creato un pool dedicato o cambiato la configurazione, il percorso può essere diverso. Non dare per scontato il nome del socket: verifica il file di configurazione PHP-FPM prima di ricaricare Nginx.

grep -R "^listen =" /etc/php-fpm.d /etc/php-fpm.conf

Se il socket risulta diverso, aggiorna la direttiva fastcgi_pass di conseguenza. Questo è uno dei casi in cui il problema sembra “del CMS” ma in realtà è un mismatch tra web server e FPM.

Dopo aver creato il file, abilita e ricarica Nginx. Se la configurazione ha un errore sintattico, Nginx lo segnala prima del restart completo.

sudo nginx -t
sudo systemctl enable --now nginx
sudo systemctl reload nginx

PHP-FPM: servizio, pool e versione

WonderCMS non ha bisogno di una versione PHP esotica, ma ha bisogno di un PHP coerente con i moduli installati. Su AlmaLinux 9 la combinazione standard del repository è in genere sufficiente. L’errore più comune è installare PHP ma dimenticare PHP-FPM, oppure lasciare il servizio fermo e poi inseguire il problema dal lato web server.

sudo systemctl enable --now php-fpm
sudo systemctl status php-fpm --no-pager

Se il servizio non parte, guarda il log del journal prima di toccare altro.

journalctl -u php-fpm -n 50 --no-pager

In assenza di personalizzazioni, il pool www va bene. Se vuoi separare i siti per isolamento, crea un pool dedicato con utente e socket propri; è una scelta sensata quando il server ospita più applicazioni, meno utile su un’istanza monouso.

Se modifichi il pool, ricorda che il blast radius è limitato al processo PHP del sito, non all’intera macchina, ma devi mantenere il rollback semplice: conserva il file originale o un backup dello snippet prima di cambiare listen, user e group.

Permessi corretti e proprietà dei file

WonderCMS scrive alcuni dati nella propria directory. Questo significa che i permessi devono essere coerenti con il demone web, ma senza aprire troppo il filesystem. La soluzione pratica è assegnare la proprietà al servizio web o, in alternativa, usare un gruppo dedicato con accesso mirato. Per un’installazione semplice, la proprietà al runtime di Nginx/PHP-FPM è la via più immediata.

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

Questi permessi sono conservativi e sufficienti nella maggior parte dei casi. Se il CMS richiede scrittura su file specifici, non allargare tutto il tree con 777: individua il file o la directory che deve essere scrivibile e limita lì l’eccezione.

Per verificare che il web server possa leggere i file, un test semplice è chiedere il documento principale via localhost.

curl -I http://127.0.0.1

Se ottieni 200 o 302 sei nella zona buona. Se vedi 403, controlla ownership, direttiva root e policy SELinux. Se vedi 502, il problema è quasi sempre tra Nginx e PHP-FPM.

SELinux: la parte che molti saltano e poi pagano dopo

Su AlmaLinux 9 SELinux è normalmente in enforcing. Non trattarlo come un fastidio da disattivare: su un server esposto è un controllo utile. Per WonderCMS la regola base è permettere al web server di leggere i file della document root e, se necessario, scrivere dove il CMS salva contenuti o cache.

getenforce
ls -Zd /var/www/wondercms

Se il contesto non è quello atteso, applica il tipo corretto alla directory del sito.

sudo semanage fcontext -a -t httpd_sys_content_t "/var/www/wondercms(/.*)?"
sudo restorecon -Rv /var/www/wondercms

Se WonderCMS deve scrivere in una directory specifica, ad esempio per upload o dati di configurazione, assegna solo lì il contesto scrivibile.

sudo semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/wondercms/data(/.*)?"
sudo restorecon -Rv /var/www/wondercms/data

Se qualcosa continua a fallire, non spegnere SELinux a caso. Prima osserva gli AVC nel journal o nel log audit e verifica il motivo esatto del blocco.

sudo ausearch -m AVC,USER_AVC -ts recent

Questo ti dà un indizio concreto su quale path o quale permesso manca. In produzione, è il modo giusto per chiudere il gap senza abbassare il livello di sicurezza dell’intero host.

Avvio del sito e primo accesso

A questo punto il sito dovrebbe rispondere via HTTP. Se il dominio è già puntato correttamente, prova il browser; altrimenti usa il nome host o l’IP pubblico per un test preliminare. L’importante è distinguere il problema di pubblicazione DNS dal problema applicativo.

curl -I http://example.com

Se il server risponde ma il browser mostra una pagina vuota, apri subito i log di Nginx e verifica gli errori PHP. La pagina bianca, su un CMS PHP leggero, è quasi sempre un errore runtime nascosto o un problema di permessi su un file scritto al primo avvio.

sudo tail -n 50 /var/log/nginx/wondercms_error.log
sudo journalctl -u php-fpm -n 50 --no-pager

Se invece il browser restituisce 404, il root del server block non punta alla directory giusta o l’archivio è stato estratto in un livello diverso. Se ottieni 502, torna al socket PHP-FPM e alla sua disponibilità. Se ottieni 403, il problema è quasi sempre permessi o contesto SELinux.

Creazione della configurazione iniziale di WonderCMS

Alla prima apertura, WonderCMS guida nella configurazione iniziale. Qui il punto non è solo “creare l’admin”, ma farlo con un criterio operativo: password robusta, accesso amministrativo limitato e backup del file di configurazione appena il sito è online.

Se il progetto salva le impostazioni in un file o in una directory dedicata, annota subito il percorso reale. Non dare per scontato che coincida con la document root: molti CMS leggeri separano codice e dati per evitare sovrascritture accidentali durante gli aggiornamenti.

Se nella tua installazione compare un file di configurazione editabile, salva una copia prima di modificare qualsiasi parametro manualmente. Un backup semplice è più utile di una restaurazione improvvisata quando devi tornare operativo in fretta.

sudo cp -a /var/www/wondercms /var/www/wondercms.backup.$(date +%F)

Questo backup è intenzionalmente grezzo ma efficace: non sostituisce un vero sistema di versioning, però ti dà un punto di ritorno immediato se una modifica alla configurazione o ai file del CMS rompe l’accesso.

HTTPS con Let’s Encrypt: fallo subito, non dopo

Se il sito è esposto su Internet, il certificato TLS va messo subito. Rimandarlo significa lasciare credenziali e sessioni in chiaro più a lungo del necessario. Con Nginx su AlmaLinux 9, la strada più lineare è usare Certbot dal repository disponibile per la distribuzione o il metodo ufficiale del progetto.

sudo dnf install -y certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

Dopo l’emissione, verifica il rinnovo automatico. Il certificato valido oggi non serve a molto se tra 60 giorni il rinnovo fallisce e il sito inizia a mostrare warning ai visitatori.

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

Se usi un reverse proxy o un CDN davanti a Nginx, il test va fatto tenendo conto della catena completa. In quel caso il certificato sul backend potrebbe non essere quello pubblico, ma va comunque mantenuto coerente con la strategia di terminazione TLS scelta.

Hardening minimo sensato

WonderCMS è piccolo, ma piccolo non significa trascurabile. Riduci l’esposizione superflua e lascia attivi solo i servizi necessari. Se non ti serve SSH esposto al mondo, limita l’accesso; se il server ospita solo il CMS, non lasciare porte aperte per software non utilizzato.

Dal lato applicativo, evita account amministrativi condivisi e conserva le credenziali in un password manager. Se il CMS offre opzioni di protezione del pannello o di cambio percorso dell’area admin, usale: non risolvono tutto, ma alzano il costo degli attacchi opportunistici.

Dal lato sistema, tieni aggiornati Nginx, PHP e i pacchetti di base. Su un host web, i problemi più costosi arrivano spesso da vulnerabilità note rimaste aperte per pigrizia operativa, non da exploit sofisticati.

Verifiche finali e rollback rapido

Quando la macchina è online, fai una verifica completa e corta: risposta HTTP, log puliti, PHP-FPM attivo, SELinux senza AVC recenti e certificato valido se hai già attivato HTTPS. Non fermarti al “si apre nel browser”: controlla anche che il backend non stia generando errori silenziosi.

curl -I https://example.com
sudo systemctl is-active nginx php-fpm
sudo tail -n 20 /var/log/nginx/wondercms_error.log
sudo ausearch -m AVC,USER_AVC -ts recent

Se qualcosa non torna, il rollback deve essere semplice: ripristina la configurazione Nginx precedente, torna al backup della directory del sito e riavvia i servizi coinvolti. Non cambiare tre variabili insieme quando stai cercando di rimettere in piedi un sito piccolo; altrimenti non capisci quale intervento ha rotto o risolto il problema.

In pratica, l’installazione corretta di WonderCMS su AlmaLinux 9 non è una questione di pacchetti, ma di allineamento tra percorso web, PHP-FPM, permessi e SELinux. Se questi quattro punti sono coerenti, il resto è lineare. Se uno solo è fuori posto, il CMS sembra difettoso anche quando non lo è.