Quali configurazioni Apache / PHP conosci e quanto sono buone?


8

Volevo chiederti dei metodi di configurazione di PHP / Apache che conosci, i loro pro e contro. Inizierò me stesso:

---------------- PHP come modulo Apache ----------------

Pro : buona velocità poiché non è necessario avviare exe ogni volta, specialmente in modalità mpm-worker . Puoi anche usare vari acceleratori PHP in questa modalità come APC o eAccelerator.

Contro : se si esegue apache in modalità mpm-worker, è possibile che si verifichino problemi di stabilità perché ogni problema tecnico in qualsiasi script php porterà all'instabilità dell'intero pool di thread di quel processo apache. Anche in questa modalità tutti gli script vengono eseguiti per conto dell'utente apache. Questo è negativo per la sicurezza. La configurazione di mpm-worker richiede che PHP sia compilato in modalità thread-safe. Almeno i repository predefiniti CentOS e RedHat non hanno una versione PHP thread-safe, quindi su questi sistemi operativi devi compilare almeno PHP da solo (c'è un modo per attivare worker mpm su Apache). L'uso di binari PHP thread-safe è considerato sperimentale e instabile. Inoltre, molte estensioni PHP non supportano la modalità thread-safe o non sono state testate bene in modalità thread-safe.

---------------- PHP come CGI ----------------

Questa sembra essere la configurazione predefinita più lenta che sembra essere una "truffa" stessa;)

---------------- PHP come CGI tramite mod_suphp ----------------

Pro : suphp consente di eseguire script php per conto del proprietario del file di script. In questo modo è possibile separare in modo sicuro siti diversi sulla stessa macchina. Inoltre, suphp consente di utilizzare diversi file php.ini per host virtuale.

Contro : PHP in modalità CGI significa meno prestazioni. In questa modalità non è possibile utilizzare acceleratori php come APC perché ogni volta che viene generato un nuovo processo per gestire lo script rende inutilizzabile la cache del processo precedente. A proposito, conosci il modo di applicare un acceleratore in questa configurazione? Ho sentito qualcosa sull'uso di shm per la cache bytecode php. Inoltre, in questa modalità non è possibile configurare PHP tramite file .htaccess. Per questo dovrai installare P ECL htscanner se devi impostare varie opzioni per script tramite .htaccess (direttive php_value / php_flag)

---------------- PHP come CGI tramite suexec ----------------

Questa configurazione sembra la stessa di suphp, ma ho sentito che è più lenta e meno sicura. Si applicano quasi gli stessi pro e contro.

---------------- PHP come FastCGI ----------------

Pro : lo standard FastCGI consente al singolo processo php di gestire diversi script prima che il processo php venga interrotto. In questo modo si ottengono prestazioni poiché non è necessario creare un nuovo processo php per ogni script. Puoi anche usare acceleratori PHP in questa configurazione (vedi la sezione contro per commenti). Inoltre, FCGI quasi come suphp consente anche l'esecuzione di processi php per conto di alcuni utenti. mod_fcgid sembra avere il supporto fcgi più completo e la flessibilità per apache.

Contro : l'uso dell'acceleratore php in modalità fastcgi comporterà un elevato consumo di memoria perché ogni processo PHP avrà la propria cache bytecode (a meno che non ci sia un acceleratore che può usare la memoria condivisa per la cache bytecode. Esiste?). FastCGI è anche un po 'complesso da configurare. È necessario creare vari file di configurazione e apportare alcune modifiche alla configurazione.

Sembra che fastcgi sia la configurazione PHP più stabile, sicura, veloce e flessibile, tuttavia, un po 'difficile da configurare. Ma, forse, mi sono perso qualcosa?

I commenti sono benvenuti!

Risposte:


3

L'esecuzione di PHP tramite FastCGI ti darà sicuramente la massima flessibilità. Non solo puoi tranquillamente utilizzare un Apache mpm worker, ma puoi anche utilizzare un altro server web (ad esempio nginx).

Ma anche se stai con Apache, "PHP tramite FastCGI" non è al momento un'opzione, ma almeno due: mod_fastcgi, mod_fcgid. Inoltre, è possibile utilizzare processi FastCGI dinamici, statici o esterni; con o senza suexec. E poi c'è il gestore di processi FastCGI interno di PHP, che ora è sostituito dal bellissimo PHP-FPM in PHP 5.3. Tutte queste opzioni hanno diversi pro e contro e possono portare a diversi problemi.

Data la scelta, sceglierei mod_fastcgi con PHP-FPM al momento, principalmente perché consente configurazioni estremamente versatili e stabili.


1
> Sceglierei mod_fcgid con PHP-FPM Questo ti impedirà di usare APC. Solo mod_fastcgi consente di utilizzare server FCGI esterni (che è PHP-FPM). Se usi mod_fcgid tutti i vantaggi dati da php-fpm verranno azzerati.
Vladislav Rastrusny,

Quello era, ovviamente, uno stupido errore di battitura. Scusami per la confusione, l'ho corretta.
conte

2

Non rispondo davvero alla tua domanda, ma non capisco che FastCGI sia difficile da configurare. È diverso da sostituire con gli altri metodi (mod_php, mod_python, ...), pertanto potrebbe essere necessario riscrivere una parte del codice. Questa può essere la parte difficile, ma per la configurazione di Apache, almeno, trovo che sia un gioco da ragazzi. Ad esempio, stavo testando un'applicazione WSGI in Python e volevo vedere come funzionava con tutti i protocolli supportati da WSGI. Ecco il file host virtuale con le configurazioni per tutti i protocolli (con mod_fastcgi):

<VirtualHost *:8888>
DocumentRoot "/home/test/"
#FastCGIExternalServer /home/test/wsgi -host 127.0.0.1:3333
#SCGIMount / 127.0.0.1:3333
FastCgiServer /home/test/wsgi/fcgi.py -idle-timeout 60 -processes 1
<Directory "/home/test/wsgi/">
    Options +ExecCGI +FollowSymLinks
    AddHandler fastcgi-script .py
    #AddHandler wsgi-script .py
    #AddHandler cgi-script .py
</Directory>
</VirtualHost>

Non mi sembra complesso. Certo, FastCGI supporta molte opzioni e può essere modificato a morte, ma questa è un'altra questione.

Per eseguire è come un altro utente, utilizzare suexec e FastCGIWrapper, quindi, diventa:

FastCGIWrapper On
<VirtualHost *:8888>
SuexecUserGroup test test
DocumentRoot "/home/test/"
FastCgiServer /var/www/test/fcgi.py -idle-timeout 60 -processes 1
<Directory "/var/www/test/">
    Options +ExecCGI +FollowSymLinks
    AddHandler fastcgi-script .py
</Directory>
</VirtualHost>

E vedi questo link per un php.ini personalizzato, ma dovresti essere in grado di specificarlo con l' -initial-envopzione, ad es

FastCgiServer /var/www/test/fcgi.py -idle-timeout 60 -processes 1 -inital-env PHPRC=/blah/

Sì, aggiungere config ad apache è semplice. Ma la tua configurazione non consente di eseguire script per conto del loro proprietario o almeno da un utente specifico. Inoltre, php.ini personalizzato non può essere utilizzato nel tuo caso (preferisco limitare open_basedir per ogni virtualhost solo per la sua directory)
Vladislav Rastrusny

Non conosco bene PHP, ma questi sono gli stessi problemi che affronti con il CGI diretto. E puoi facilmente eseguire fastcgi come server esterno come qualsiasi utente ti piaccia.
Dan Andreatta,

Aggiunte ulteriori informazioni alla risposta.
Dan Andreatta,

1

Un buon candidato è: Apache 2 ITK MPM

apache2-mpm-itk (in breve solo mpm-itk) è un MPM (Multi-Processing Module) per il server web Apache. mpm-itk ti consente di eseguire ciascuno dei tuoi vhost sotto un uid e gid separati - in breve, gli script e i file di configurazione per un vhost non devono più essere leggibili per tutti gli altri vhost.

Ha funzionato molto bene con uno dei nostri clienti con centinaia di VirtualHosts con molti visitatori.

Ottieni tutti i Pro dall'esecuzione di PHP come modulo e risolvi alcuni dei contro.


Sì, ma è stato aggiornato l'ultima volta un anno prima. E ciò che è ancora più importante apre un potenziale insieme di sicurezza. "Poiché mpm-itk deve essere in grado di setuid (), viene eseguito come root (sebbene limitato con le funzionalità POSIX ove possibile) fino a quando la richiesta non viene analizzata e il vhost determinato. Ciò significa che qualsiasi falla di sicurezza prima che la richiesta venga analizzata sarà un buco nella sicurezza della radice. (Il posto più probabile è probabilmente in mod_ssl.) "
Vladislav Rastrusny il

Il codice funziona, è molto stabile e probabilmente non c'è motivo di aggiornarlo. Il modulo ha uno sviluppatore Debian attivo (non conosco lo sviluppatore originale). Ed è FOSS e non molto complicato.
rkthkr,

0

Per me, la domanda è qual è lo scopo del web server. Serve più di un host virtuale? In tal caso, devi sacrificare le prestazioni per una sicurezza isolata. Sì, le prestazioni ne risentono, ma con l'hardware di oggi dovrebbe essere necessario un bel po 'di traffico per portare importanti problemi di prestazioni.

Se le prestazioni sono così importanti, esegui un sito su un server VPS o dedicato e configura le prestazioni.


Chiedo solo delle possibili varianti. Non per scegliere il migliore. Sceglierò me stesso.
Vladislav Rastrusny,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.