1 12/05/2026 8 min

Su AlmaLinux 8 Lighttpd è una scelta sensata quando vuoi un web server leggero, con footprint ridotto e configurazione pulita. Non sostituisce Apache o Nginx in ogni scenario, ma su siti statici, applicazioni semplici o front-end davanti a PHP-FPM fa il suo dovere senza portarsi dietro più complessità del necessario.

Qui sotto trovi una procedura completa e verificabile: installazione, avvio del servizio, apertura del firewall, collegamento a PHP-FPM e controlli finali. L’obiettivo non è “farlo partire”, ma metterlo in piedi in modo che resti stabile e prevedibile dopo il primo reboot.

1. Verificare lo stato del sistema prima di toccare il web server

Prima di installare pacchetti, conviene capire se il nodo è sano e se ci sono vincoli già presenti: spazio disco, repository attivi, conflitti con altri web server e stato del firewall. In produzione questi dettagli fanno differenza, soprattutto quando il problema non è Lighttpd ma il contorno.

Controlla almeno questi punti:

df -h / /var /tmp

Se una delle partizioni è quasi piena, installare e poi testare il web server è poco utile: i log, la cache e i file temporanei possono fallire subito dopo il deploy.

systemctl status firewalld --no-pager

Se il firewall è attivo, va aperta la porta HTTP prima di considerare il servizio “raggiungibile”.

rpm -q httpd nginx lighttpd

Il comando serve a capire se esiste già un web server che potrebbe occupare la porta 80. Se Apache o Nginx sono installati e in ascolto, Lighttpd non potrà bindare la stessa porta senza un cambio di configurazione.

2. Installare Lighttpd dai repository di AlmaLinux

Su AlmaLinux 8, Lighttpd è in genere disponibile dai repository standard o da EPEL a seconda della configurazione del sistema. La strada corretta è verificare i metadati dei repository prima di forzare installazioni manuali o pacchetti scaricati a mano.

Abilita EPEL se necessario e installa il pacchetto:

sudo dnf install -y epel-release
sudo dnf install -y lighttpd

Se il pacchetto non viene trovato, non improvvisare con RPM presi altrove: prima verifica quali repository sono attivi e se EPEL è realmente disponibile sul nodo.

dnf repolist

Il risultato atteso è la presenza di un repository che contenga Lighttpd. Se manca, la chiusura del gap è lì: repository non abilitato, mirror non aggiornato o policy locale che blocca l’accesso ai pacchetti.

3. Avviare e abilitare il servizio systemd

Una volta installato, il servizio va avviato e reso persistente al boot. Su AlmaLinux 8 il controllo passa da systemd, quindi è inutile limitarsi al solo avvio manuale.

sudo systemctl enable --now lighttpd

Verifica subito lo stato:

systemctl status lighttpd --no-pager

Lo stato atteso è active (running). Se vedi failed, il passo successivo non è riavviare a caso ma leggere il journal.

journalctl -u lighttpd -b --no-pager

Qui trovi errori di configurazione, problemi di permessi o conflitti sulla porta in ascolto. È il punto più rapido per separare un errore di sintassi da un problema di rete o di file system.

4. Aprire il firewall per HTTP e, se serve, HTTPS

Se firewalld è attivo, senza apertura della porta il server può essere in ascolto ma restare irraggiungibile dall’esterno. Questo è uno dei casi classici in cui il servizio sembra “rotto” mentre il problema è solo a livello di filtering.

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

Controlla la configurazione effettiva:

firewall-cmd --list-services

Se stai esponendo solo HTTP in fase iniziale, apri solo quella porta. Minimizzare la superficie d’attacco è una scelta migliore del classico “apro tutto e poi vedo”.

5. Capire dove vive la configurazione di Lighttpd

Su AlmaLinux la configurazione principale si trova in genere in /etc/lighttpd/lighttpd.conf, con eventuali moduli e frammenti aggiuntivi sotto /etc/lighttpd/conf.d/. Prima di cambiare qualcosa, fai una copia di lavoro o usa un controllo versione locale se il server è gestito con discipline operative serie.

Il controllo sintattico va fatto prima del reload:

lighttpd -tt -f /etc/lighttpd/lighttpd.conf

Se il comando restituisce errori, correggerli è più veloce che cercare la causa a runtime. Lighttpd è abbastanza schietto nei messaggi di validazione: sfruttalo.

6. Configurazione minima per servire contenuti statici

La configurazione base può essere molto semplice. In molti casi basta definire la document root e verificare che il modulo di access log sia attivo. Un esempio essenziale:

server.document-root        = "/var/www/lighttpd"
server.errorlog             = "/var/log/lighttpd/error.log"
accesslog.filename          = "/var/log/lighttpd/access.log"
server.port                 = 80

Crea la directory del sito e un file di test:

sudo mkdir -p /var/www/lighttpd
echo '<h1>Lighttpd su AlmaLinux 8</h1>' | sudo tee /var/www/lighttpd/index.html

Qui il punto non è il contenuto, ma la verifica del flusso end-to-end: filesystem, permessi, servizio e risposta HTTP.

Imposta i permessi in modo coerente con l’utente del servizio. Su molte installazioni Lighttpd gira come lighttpd o nobody, ma non dare per scontato il nome: leggi il file di unità o la configurazione effettiva se hai dubbi.

grep -E '^(server.username|server.groupname)' /etc/lighttpd/lighttpd.conf

Se il processo non ha permessi di lettura sulla document root, il sintomo sarà un 403 o un errore nei log, non un messaggio elegante a video.

7. Integrare PHP-FPM invece di usare moduli vecchi

Per applicazioni PHP la scelta più pulita è Lighttpd davanti a PHP-FPM, non CGI vecchio stile. È più semplice da mantenere, più veloce da diagnosticare e più coerente con un stack moderno su AlmaLinux 8.

Installa PHP-FPM e un set minimo di moduli utili:

sudo dnf install -y php-fpm php-cli php-mysqlnd php-opcache

Abilita e avvia PHP-FPM:

sudo systemctl enable --now php-fpm

Verifica che il socket sia presente:

ls -l /run/php-fpm/www.sock

Se il socket non esiste, il problema è PHP-FPM, non Lighttpd. In quel caso leggi il journal del servizio PHP:

journalctl -u php-fpm -b --no-pager

Per collegare Lighttpd a PHP-FPM, abilita i moduli FastCGI necessari. In molte installazioni basta includere una configurazione simile:

server.modules += ( "mod_fastcgi" )
fastcgi.server = ( ".php" =>
  ((
    "socket" => "/run/php-fpm/www.sock",
    "broken-scriptfilename" => "enable"
  ))
)

La sintassi esatta può variare in base alla versione del pacchetto e ai moduli caricati. Se il file di configurazione locale include già un profilo FastCGI, adattalo invece di duplicarlo. Duplicare blocchi simili è un modo rapido per generare errori ambigui al riavvio.

8. Testare PHP con un file controllato

Una volta collegato PHP-FPM, crea un file minimale per verificare l’esecuzione dinamica. Evita script complessi: qui serve solo confermare che il passaggio web server → FastCGI → PHP funzioni.

cat <<'EOF' | sudo tee /var/www/lighttpd/info.php
<?php phpinfo();
EOF

Apri http://IP_DEL_SERVER/info.php dal browser o usa curl:

curl -I http://127.0.0.1/info.php

Il risultato atteso è HTTP/1.1 200 OK. Se ottieni 404, la document root non è quella prevista. Se ottieni 403, quasi sempre è una questione di permessi o contesto SELinux. Se ottieni 503, il backend FastCGI non sta rispondendo.

9. SELinux: il dettaglio che spesso blocca tutto

Su AlmaLinux 8 SELinux è normalmente in enforcing. Questo è un bene, ma significa che i permessi Unix da soli non bastano. Se Lighttpd deve leggere una document root non standard, il contesto SELinux può impedirlo anche quando owner e mode sembrano corretti.

Controlla il contesto dei file:

ls -Z /var/www/lighttpd

Se serve un contesto web standard, ripristina quello corretto:

sudo restorecon -Rv /var/www/lighttpd

Per capire se SELinux sta davvero bloccando qualcosa, cerca gli AVC nel journal o nel log audit:

sudo ausearch -m AVC,USER_AVC -ts recent

Se emergono denials, il fix corretto è adattare contesti, boolean o policy, non disattivare SELinux per comodità. Disabilitarlo sposta il problema e allarga la superficie d’attacco.

10. Rendere la configurazione più robusta

Una volta che il servizio risponde, conviene sistemare alcuni dettagli che evitano problemi futuri. Il primo è il log: senza access log ed error log chiari, il troubleshooting diventa lento e sporco.

Il secondo è il binding. Se il nodo deve servire più siti, valuta virtual host espliciti invece di accumulare eccezioni nella configurazione principale. Meno logica sparsa nel file base significa meno errori al reload.

Il terzo è il controllo della sintassi prima di ogni reload. Un semplice script di validazione o un hook operativo che esegue lighttpd -tt -f /etc/lighttpd/lighttpd.conf riduce parecchio gli incidenti da typo.

Se vuoi un minimo di hardening, valuta anche:

  • disattivare moduli non usati;
  • limitare i permessi della document root;
  • tenere PHP-FPM su socket Unix locale invece che su porta TCP se non serve rete;
  • monitorare spazio disco e crescita dei log.

    • 11. Verifica finale con comandi pratici

    La verifica finale deve essere semplice e ripetibile. Non serve una suite di test pesante per confermare che il servizio base sia sano.

  • Controlla che il demone sia attivo.
    • systemctl is-active lighttpd

    Atteso: active.

  • Controlla che stia ascoltando sulla porta corretta.
    • ss -ltnp | grep ':80'

    Atteso: processo lighttpd in ascolto su 0.0.0.0:80 o sull’IP previsto.

  • Controlla la risposta HTTP locale.
    • curl -I http://127.0.0.1

    Atteso: codice 200 o 301 coerente con la tua configurazione.

  • Controlla i log dopo il primo accesso.
    • tail -n 20 /var/log/lighttpd/access.log
 tail -n 20 /var/log/lighttpd/error.log

    Atteso: richiesta registrata senza errori PHP o denial SELinux.

    12. Rollback operativo se qualcosa non torna

    Se dopo l’installazione il nodo non si comporta come previsto, il rollback minimo è fermare Lighttpd, disabilitarlo al boot e ripristinare eventuali file di configurazione dalla copia fatta prima delle modifiche.

    sudo systemctl disable --now lighttpd

    Se hai cambiato /etc/lighttpd/lighttpd.conf, ripristina la versione precedente e rilancia solo il test di sintassi, non direttamente il servizio:

    lighttpd -tt -f /etc/lighttpd/lighttpd.conf

    Questo approccio tiene basso il blast radius: niente modifiche ai dati, niente interventi sul database e nessun cambio irreversibile se il problema è solo nella configurazione del web server.

    Assunzione operativa: il nodo è un server AlmaLinux 8 standard con accesso root o sudo, repository raggiungibili e nessun web server alternativo che debba restare in ascolto sulla stessa porta.