glug: configurazione apache+php (risposta molto lunga...)

[Marco Masetti]

Ok, la risposta e' stata gia' data dal Debe, ed adesso che il php respira ritorniamo sui nostri passi e cerchiamo di capire qualcosa...

> Hai verificato se apache carica php4_module?
un modulo puo' essere staticamente compilato con apache (e quindi sara' gia' presente in ogni processo httpd) oppure puo' essere caricato dinamicamente allo start up del processo principale.
Il vantaggio di caricare un modulo dinamicamente al runtime e' che verra' condiviso da piu' processi e quindi risparmieremo parecchia ram durante l'esecuzione, guarda questo estratto del comando top:

 PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND 
 9479 root      15   0  2912 2028  1976 S     0.0  0.3   0:00 httpd
 9499 webAppal  15   0  4168 3776  3060 S     0.5  0.7   0:04 httpd

che ci dice che ogni processo httpd figlio (quelli per interdeci che servono le richieste http) occupa circa 3.7 Mb in RAM (colonna RSS), ma di cui ben 3 Mb sono moduli shared (colonna SHARE), e questo ci permette di farne girare un bel po' (o almeno di dire non e' certo per colpa di apache che siamo a corto di Ram...).
I moduli condivisi hanno estensione '.so'.

[come capire se un module e' presente nel processo]
Per verificare se un modulo e' compilato staticamente nel binario basta rintracciare il binario httpd ed eseguire il comando:

#>./httpd -l 

che ci da la lista dei moduli compilati nel processo.
A questo punto si presentano tre casi:

1) massimo culo
nella lista compare il fatidico mod_php4

2) culo normale
nella lista non compare il fatidico mod_php4 ma ci si apre il cuore trovando invece il modulo mod_so, chi non sa a cosa serve legga oltre...

3) massima sfiga
entrambi i moduli non rispondono all'appello.

[a cosa serve mod_so]
Serve a permettere ad apache di lincare dinamicamente librerie a runtime. 

[come compilare apache con il supporto per i shared objects]
Se ci capita di ricompilare Apache (e dovremo per forza farlo se rientriamo nel caso 3), per essere sicuri di trovarcelo dentro bisogna dare il comando (una volta scompattato il tarball con i sorgenti)

#> ./configure --enable-module=so [ + altri parametri di configurazione]

[come si compila un modulo come shared per apache]
Con apache2 di solito basta fargli capire dove e' il tool apxs (Apache extension tool, si trova tra i binari di apache). Se la libreria si compila con la solita sequenza di solito bastano i comandi:

#> ./configure --with-apxs=<path to apxs> [+ altri parametri]
#> make && make test && make install

una volta ottenuto il modulo <qualcosa>.so, possiamo tranquillamente spostarlo a mano sotto il direttorio $APACHE_HOME/modules se abbiamo apache 2 (o $APACHE_HOME/libexec per apache 1.3)

[come si configura il caricamento di un modulo]
Il Debe ha mostrato le direttive per il purista, colui che ha raggiunto il mantra.
> In caso negativo devi abilitare il modulo e far ricaricare ad apache la
> nuova configurazione.
> 
> Traduzione:
> 
> if [ -z $(apache-modconf apache query mod_php4) ]
>   then
>     apache-modconf apache enable mod_php4
>     /etc/init.d/apache reload
> fi
in realta' un semplice:

LoadModule php4_module        modules/mod_php4.so

piazzato da qualche parte nell'httpd.conf dovrebbe bastare (ed e' inoltre la soluzione standard, che va bene su qualunque piattaforma....)

Ciao,
Marco.
PS: l'avevo detto che era lunga! Non ti arrabbiare se ti ho fatto perdere 10 minuti del tuo tempo!
> 
> -- 
> ciao,
> debe
> _______________________________________________
> glug mailing list
> glug@genova.linux.it
> http://lists.linux.it/listinfo/glug

-- 
--------------------------------------------
Marco Masetti
Project Manager - Research & Innovation
Softeco Sismat SpA
Via De Marini, 1 - Torre WTC
16145 - Genova
phone: (+39) 010 6026.333/.1
fax  : (+39) 010 6026.350
email: marco.masetti@softeco.it
web  : www.softeco.it
--------------------------------------------
ILS :   masetti@linux.it
GLUG:   http://genova.linux.it
PMI :   http://www.perl.it
--------------------------------------------