DREAMSNET.IT – IT Solutions. Realizzazioni Siti Web, Siti Internet, Software gestionali, consulenza sistemistica Linux

Progettare bene un web server, significa anche effettuare una scelta opportuna su come far girare l’interprete PHP.

Se è vero che Apache di default fornisca il classico mod_php che va bene tecnicamente per tutte le configurazioni senza (apparentemente) troppi problemi, è anche vero che guardando nel dettaglio tutte le varie possibili soluzioni, con un pizzico di tempo potremmo effettuare una configurazione ottimale sopratutto per quei server WEB che si ritrovano a far girare più siti web in modalità virtual hosting (più siti su un solo server).

A differenza di un web hosting dedicato (un server web su cui gira uno o più siti dello stesso cliente) lavorare in ambiente condiviso implica ragionare tenendo conto di concetti importantissimi per la sicurezza e le prestazioni : la separazione dei privilegi e il modo in cui viene implementata questa caratteristica.

Va premesso che questo articolo non affronterà la parte tecnica dell’installazione e configurazione di ogni possibile modalità (per quello ci sono innumerevoli tutorial in rete), ma vuole essere una panoramica introduttiva che aiuti il lettore a fare una scelta oculata tra soluzioni apparantemente equivalenti ma profondamente diverse.

Al fine di gestire un sito PHP, il server deve interpretare il codice PHP e generare una pagina quando i visitatori accedono al sito.
Si interpreta il codice in base a quale libreria PHP si sta utilizzando, ad esempio PHP 4 o PHP 5.
Un handler PHP (o gestore) è colui che effettivamente carica le librerie in modo che possano essere utilizzate per l’interpretazione.
I gestori di PHP determinano come PHP viene caricato sul server.

E’ fondamentale per le prestazioni del server, selezionare il gestore che si adatta meglio alla propria situazione.
Selezionando il gestore giusto è importante tanto quanto la versione di PHP stesso.
Un gestore non è necessariamente sempre migliore di un altro, ma dipende dalla configurazione e dalle esigenze.

Di quale caching avete bisogno ? Di quali moduli avete bisogno ? ecc …

mod_php (DSO)

DSO è anche conosciuto come mod_php. DSO significa: Dynamic Shared Object. Questa è una configurazione o, ma è generalmente considerato il gestore più veloce.
Gestisce PHP come modulo di Apache. Ciò significa che gli script PHP verranno eseguiti come utente Apache, che è l’utente: ‘apache o httpd o www-data o nobody’.

Riguardo mod_php si dovrebbe dire ben poco. Esso è infatti installato di default in tutte le distribuzioni Linux al momento che si installi un Webserver APACHE con PHP.
Va sottolineato Apache e non webserver alternativi come lighthttpd o NGINX, perchè mod_php non funzionano con questi altri.
E’ la soluzione classica, la più utilizzata dagli utenti pigri, ma sicuramente non la più ottimale. Nemmeno la più sicura.

mod_php infatti non dispone di caratteristiche di progettazione atte a garantire una separazione privilegi adeguata. Anzi, non la offre proprio.
Esso infatti si limita ad eseguire gli script PHP con gli stessi permessi del webserver che lo invoca, normalmente httpd, www-data, apache o nobody.

Ciò significa che per gestire vhosts multipli si dovranno impostare i permessi dei singoli vhosts con permessi non separati tra loro, dando la possibilità al webserver di leggere e scrivere file e cartelle con i permessi del webserver stesso.

DSO ha due inconvenienti. In primo luogo, tutti i file creati da uno script PHP avrà la proprietà dell’utente con cui gira Apache.
Essi non saranno leggibili dal webserver altrimenti. Siti web che hanno bisogno di caricare i file tramite PHP avranno problemi di autorizzazione di file a patto di non modificare i permessi in configurazioni fin troppo permissive.

Il secondo svantaggio è un problema di sicurezza. I file creati avranno la proprietà del webserver. Se un hacker trova un exploit nello script PHP, potrebbe realizzare un file con gli stessi privilegi file di sistema importanti che sono anche di proprietà del webserver. Questo darà loro la possibilità di modificare i file  al di fuori di tale account utente.

Per ovviare a queste mancanze sono state implementate feature empiriche e obsolete come safe_mode() e l’open_basedir(), puri palliativi per tentar di arginare un male che va risolto alla radice.

Risolvere alla radice il male significa usare configurazioni che supportano la separazione dei privilegi.
Tra queste troviamo suPHP, FCGId (tecnicamente l’evoluzione di FastCGI) e PHP-FPM.

suPHP

suPHP è stato il primo abbozzo per tentare una reale separazione privilegi utenti.

SuPHP altro non è che un modulo per Apache che ci dà la possibilità di presentarci al sistema come un utente differente dal default (www-data, httpd o apache).
Esso funziona solo su Apache e come il precedente mod_php è inutilizzabile su altri webserver.

Tra i suoi vantaggi :

• Ogni vhost esegue PHP con il proprio user/group
• I file PHP possono avere permessi 640 (rw-r—–). Ciò è perfetto per i file di configurazione con password e dati sensibili
• I file e le cartelle create da PHP sono scritte con user/group del proprio vhost.
• Può essere usato un file php.ini per ogni vhost (configurazioni personalizzate, impostazioni di sicurezza e performance su misura)

L’obiettivo lo raggiunge bene se non fosse a scapito delle prestazioni davvero ridotte.

Esso infatti è circa il 30 – 40% più lento e meno performante del classico mod_php.

Questo succede per le tempistiche bibliche dello spawning di un nuovo processo per ogni richiesta e l’effettuazione di una fork() che rende il tutto davvero ingestibile e inaccettabile sopratutto su siti ad alto traffico o su server che ospitano centinaia o migliaia di siti in virtual hosting.

fcgiD e FastCGI

fcgid invece è una soluzione derivata dal più obsoleto e non mantenuto fastcgi da cui prende comunque l’assonanza nel nome.

FastCGI (aka: mod_fcgid o fcgi) è una variante del CGI (Common Gateway Interface) ad alte prestazioni.

Ha la sicurezza e proprietà nonchè vantaggi di suPHP riguardo alla separazione dei privilegi degli utenti.
Inoltre può essere utilizzato a differenza di mod_php e suPHP anche su webserver diversi da Apache.

La differenza principale con suPHP è che con FastCGI si può risparmiare notevolmente sulle prestazioni della CPU e dare velocità prossime a quella della DSO (mod_php).
Può essere utilizzato anche con un opcode cacher come eAccelerator o APC, che può ulteriormente aiutare velocità il caricamento delle pagine, ma a causa della separazione privilegi dei processi non potrà accedere alla memoria condivisa di cacher come APC, xCACHE, eAccelerator.

Ciò si traduce in un elevato utilizzo della memoria. Questo anche perché invece di creare il processo di PHP ogni volta che viene chiamato, come suPHP, mantiene una sessione persistente aperta in background.

Se vi piace la sicurezza offerta da suPHP e volete avere performance simili a quelle di DSO (ovvero molto veloci) questa è una soluzione da tenere in considerazione sopratutto su versioni di php inferiori alla 5.3

PHP-FPM

A partire da php 5.3 infatti è stata implementata e messo in produzione il gestore PHP-FPM acronimo di FastCGI Process Manager.

PHP-FPM è una implementazionealternativa di PHP FastCGI con alcune funzioni utili per i siti di qualsiasi dimensione e specialmente per i siti e webserver particolarmente carichi.

PHP-FPM è destinato principalmente ai siti web gravati da numerose richieste HTTP. E’ possibile lanciare più pool di processi FastCGI in ascolto su porte separate per soddisfare le esigenze di ambienti virtuali multi-dominio in virtual hosting.

Offre inoltre:

• Processo di gestione avanzato con possibilità di fare uno stop/start controllato.
• La possibilità di avviare lavoratori con differenti uid/gid/chroot/ambienti e impostazioni di php.ini diverse (sostituisce safe_mode)
• Registrazione di stdout e stderr .
• Riavvio di emergenza in caso di distruzione accidentale della opcode cache
• Supporto per l’upload accelerato.
• Supporto per lo “slowlog” che registra le pagine che richiedono troppo tempo per essere completate

È possibile utilizzare PHP-FPM come back-end a qualsiasi server web e non essere più legati ad Apache.
Un altro vantaggio (che ha anche mod_php), è quello di gestire la memoria condivisa e dunque gestire in modo trasparente e indolore sistemi di caching PHP come APC, eAccelerator, xCACHE.

Riassumendo in breve:

	Sicurezza	Prestazioni	Integrazione Caching	Adatto Virtual Hosting	Non Apache
mod_php	Bassissima	Altissime	Si. Molto facile e indolore	No. Sconsigliatissimo	No
suPHP	Altissima	Bassissime	No.	Si. Non consigliato	No
FastCGI	Altissima	Alte	Si. Complessa, pochi vantaggi	Si. Consigliato	Si.
PHP-FPM	Altissima	Molto Alte	Si. Molto facile e indolore	Si. Consigliatissimo	Si.

Le informazioni fino ad ora elencate sono più che sufficienti per mettervi in condizione di fare una scelta intelligente. Scelta che in un webserver adibito al virtual hosting nel mio caso si traduce senza esito a PHP-FPM.

Solo in situazioni in cui si ospita un solo dominio in un server VPS ad esempio, posso permettermi il lusso di usare ciò che offre la casa (mod_php) senza troppi problemi riguardo la sicurezza dato che quel sito rimane comunque l’unico sito che gira sul server.