Ceci n'est pas une pipe

Su tutte le Debian Squeeze c’è una correzione al volo da fare al php.ini dedicato agli script eseguiti lato server (a.k.a. command line). La correzione è di vitale importanza, ma solo se avete messo in cron script php e non volete che il server si rifiuti di eseguirli perché richiedono più memoria di quella allocabile. Il problema è dovuto al parametro:

memory_limit = -1

Visto così sembrerebbe un flag disabilitato e ci aspetteremmo quindi che non ci sia alcun limite nella memoria allocabile, invece il comportamento è tutt’altro:

PHP Fatal error:  Allowed memory size of 33554432 bytes exhausted (tried to allocate 64 bytes) in /var/www/clients/client21/web54/web/XXXXXX.php on line 212

Per ovviare al problema, è bene specificare quale effettivamente è il limite di memoria che intendiamo imporre ad uno script php eseguito da linea di comando. Il parametro si trova nel file:

/etc/php5/cli/php.ini

E la modifica da effettuare è la seguente:

; Maximum amount of memory a script may consume (128MB)
; http://php.net/memory-limit
;memory_limit = -1
memory_limit = 128M

Also sprach Zio Vania

Da un paio di settimane per uno dei miei server di test ho aggiornato Apache2 MPM portandolo dalla versione “Prefork” alla “Worker”. Ho deciso di fare questa prova dopo avere letto alcuni post interessanti che descrivevano un notevole miglioramento nelle performance di WordPress dopo avere effettuato questo tipo di aggiornamento. Il periodo di prova ha confermato tutto: sul server in questione – dove gira una non più fiammante “Lenny” – ho potuto registrare una netta riduzione del load average durante l’esecuzione forzata di un elevato numero di processi PHP5 in FastCGI generati attraverso chiamate concorrenti a WordPress, una sorta di banchwork casalingo ottenuto con semplici script PHP autoprodotti.

Spiego rapidamente in che cosa consista la differenza tra le due versioni di Apache, almeno per gli aspetti che interessano poi le performance di WordPress: mentre la versione normalmente considerata standard – detta “Prefork” – utilizza un Multi-Processing Module basato sui processi, la versione “Worker” utilizza invece i thread. Il modello “Prefork” gestisce un processo per ogni connessione, mentre il modello “Worker” gestisce un processo per ogni gruppo di thread ed un thread per ogni connessione. In questo modo, la versione “Worker” di Apache2 tende ad utilizzare meno memoria e a distribuire meglio le chiamate al processore indirizzandole al maggior numero di core – anche per questo motivo si tende a considerare “Worker” più adatta a server multicore, nel senso che è su quelli che si possono misurare i miglioramenti di performance più significativi.

Attenzione però, lo scotto da pagare può essere notevolmente scoraggiante per moltissimi di voi: PHP5 potrà girare solo in modalità mod_fcgid mentre si dovrà per forza rinunciare al mod_php5 di Apache! Pensateci bene quindi prima di effettuare questo tipo di operazione.

Per come sono solito a configurare i miei server, il passaggio da “Prefork” a “Worker” nel mio caso ha richiesto un solo comando:

aptitude install apache2-mpm-worker

Aptitude mi ha avvisato subito che l’installazione di questo pacchetto avrebbe determinato la rimozione di libapache2-mod-php5:

# aptitude install apache2-mpm-worker
Lettura della lista dei pacchetti in corso... Fatto
Generazione dell'albero delle dipendenze in corso
Lettura informazioni sullo stato... Fatto
Lettura delle informazioni sullo stato esteso
Inizializzazione dello stato dei pacchetti... Fatto
Lettura delle descrizioni dei task... Fatto
I seguenti pacchetti sono DIFETTOSI:
libapache2-mod-php5
I seguenti pacchetti NUOVI (NEW) saranno installati:
apache2-mpm-worker
I seguenti pacchetti saranno RIMOSSI:
apache2-mpm-prefork{a}
0 pacchetti aggiornati, 1 installati, 1 da rimuovere e 0 non aggiornati.
È necessario prelevare 0B/242kB di archivi. Dopo l'estrazione, verranno occupati 8192B.
I seguenti pacchetti hanno dipendenze non soddisfatte:
libapache2-mod-php5: Dipende: apache2-mpm-prefork (> 2.0.52) ma non è installabile o
apache2-mpm-itk ma non è installabile
Le seguenti azioni permetteranno di soddisfare queste dipendenze:
Rimuovere i seguenti pacchetti:
libapache2-mod-php5
Il punteggio è 119


Se si decide di procedere – ripeto: rinunciando definitivamente a mod_PHP5! – l’installazione avverrà in pochi secondi, con il solito riavvio finale di apache mediante:

/etc/init.d/apache2 restart

Da questo momento in avanti non resta che godersi le straordinarie prestazioni di Apache2 MPM “Worker”.

Quelli che hanno la cattiva abitudine di installare le applicazioni web nella document root si trovano  spesso a dover affrontare un fastidioso problema: l’impossibilità di gestire directory e sub-directory estranee all’applicazione a causa delle restrizioni di accesso imposte dal file .htaccess.

L’esempio più tipico è quello del CMS Drupal. Supponiamo di averlo installato e reso completamente accessibile all’URL:

http://www.miodominio.xx/

Il file .htaccess di Drupal controllerà tutto quello che può o non può essere accessibile al di sotto della propria document root, che in questo caso coincide esattamente con la document root del virtual host. Infatti il file .htaccess si trova nella radice del filesystem dedicato a questa applicazione:

http://www.miodominio.xx/.htaccess

In questo modo, se decidiamo di creare una qualsiasi nuova directory, questa subirà le medesime restrizioni scritte nel file .htaccess durante l’installazione di Drupal, come ad esempio l’impossibilità di navigare liberamente tra i suoi file e le subdirectory che essa contiene:

http://www.miodominio.xx/test/

Questa directory non è accessibile in questo modo, ma solo richiamando il nome del file in essa contenuto a cui vogliamo accedere, ad esempio:

http://www.miodominio.xx/test/pippo.html
http://www.miodominio.xx/test/imago.jpg

Se non viene indicato alcun file, viene cercato e mostrato il solo file index.php:

http://www.miodominio.xx/test/index.php

Se il file index.php non esiste, non viene mostrato il contenuto della directory – come molti si aspetterebbero – ma al contrario viene generato un bell’errore 404  (File Not Found).

Per ovviare a questo problema è sufficiente agire sul file .htacces, aggiungendo le istruzioni che rendono la directory /test/ immune da queste regole, immediatamente dopo l’inizializzazione del RewriteEngine:

<IfModule mod_rewrite.c>
RewriteEngine on
#
# ECCO LE DUE RIGHE DI ISTRUZIONI:
RewriteCond %{REQUEST_URI} "/test/"
RewriteRule (.*) $1 [L]
#

Provare per credere.

Mi è capitato spesso di dover mettere mano a server UNIX/Linux con una gestione dei VirtualHost di Apache compromessa da anni di utilizzo incontrollato del server da parte di amministratori di sistema non proprio ordinati. Il risultato di solito è un grande numero di utenti con home directory strutturate in maniera differente l’una dall’altra.

In particolare, in un caso recente mi sono ritrovato un centinaio di utenti dei quali una certa parte aveva la DocumentRoot nella propria home directory, altri invece ce l’avevano sotto /var/www/users/, cosa che io raccomando in quanto evita di avere problemi con SUEXEC nelle versioni di Apache precompilate.

Per sistemare una situazione così caotica ho deciso di mettere tutto correttamente sotto /var/www/users/ e mi si è presentata la necessità di creare automaticamente le directory mancanti e i relativi link simbolici alle varie home directory. L’ho fatto con un semplicissimo script in bash, che pubblico qui nel caso possa essere utile anche a qualcun altro. Ci ho messo anche un po’ di output per rendere il codice chiaro anche a chi è alle prima armi con la bash.

Attenzione! Alla riga 18 viene fatta la copia di un fast-cgi presente nella directory /var/www/users/ivan/. Ovvio che dovete sostituire ivan con il nome di un utente presente sul vostro server.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

#!/bin/bash
 
echo "Inizializzazione script..."
 
for i in $( ls /home/ ); do
  echo "  Sto processando '$i'"
  if [ -L /home/$i/public_html ]; then
    echo "    Il link simbolico /home/$i/public_html esiste gia' ... salto!"
  else
    echo "    Il link simbolico /home/$i/public_html non esiste: provo a crearlo ... "
    if [ -d /var/www/users/$i ]; then
      echo "La directory /var/www/users/$i esiste, non mi resta che linkarla ... "
      /bin/ln -s /var/www/users/$i /home/$i/public_html
    else
      echo "    La directory /var/www/users/$i NON esiste, ora la creo ... "
      /bin/mkdir /var/www/users/$i
      echo "    Copio il FAST-CGI ... "
      /bin/cp /var/www/users/ivan/fast-cgi /var/www/users/$i/
      echo "    Sistemo i permessi per la directory creata ... "
      /bin/chown -R $i:$i /var/www/users/$i
      /bin/chmod 700 /var/www/users/$i
      echo "    Creo il link simbolico ... "
      /bin/ln -s /var/www/users/$i /home/$i/public_html
    fi
  fi
done

In questo post riporto alcuni miei vecchi appunti su come generare e installare un certificato SSL su un web server Apache 1.3.* con il modulo mod_ssl. Per informazioni più dettagliate e complete rimando alla documentazione che si trova all’indirizzo http://www.modssl.org/docs/ e alla pagina `man` di openssl. Una versione html di quest’ultima si trova all’indirizzo http://www.openssl.org/docs/. Leggi il resto »