Archivi tag: centos 5

Varnish + httpd su CentOS 5: logging del vero IP sorgente

Per ottimizzare i tempi di risposta dei server Web possono essere utilizzati degli accelleratori http (i quali svolgono principalmente operazioni di caching). Uno di questi prende il nome di varnish, software open source piuttosto diffuso ed altamente performante.

cache, varnish, httpd, apache, centos 5, http accelerator, caching, logging, source IP

Ora, poichè dal punto di vista legislativo è necessario che vengano loggati gli IP sorgenti delle richieste http, è indispensabile che il demone httpd sia in grado di individuarli e registrarli correttamente. Con una configurazione standard del suddetto demone ciò non è possibile, in quanto l’IP sorgente sarà sempre e comunque quello del server varnish che gli ha inoltrato la richiesta.

Per aggirare tale problematica occorre operare sulla configurazione di varnish e di httpd.

Per prima cosa, modifichiamo il file /etc/varnishd/defaul.vcl aggiungendo la seguente entry:

sub vcl_recv {
if (req.http.x-forwarded-for) {
    set req.http.X-Forwarded-For =
    req.http.X-Forwarded-For ", " client.ip;
  } else {
    set req.http.X-Forwarded-For = client.ip;
  }
}

In questo modo il campo http.X-Forwarded-For presente nell’header http verrà popolato con il vero IP sorgente della richiesta.

A questo punto dobbiamo semplicemente dire al demone httpd come interpretare le informazioni ricevute da varnish:

[root@bqweb1 varnish]# nano /etc/httpd/conf/httpd.conf

LogFormat "%{X-Forwarded-For}i %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i"" varnishcombined

e come CustomLog utilizzeremo la seguente direttiva:

CustomLog logs/access_log varnishcombined

Riavviamo sia varnish che httpd ed il gioco è fatto.

Alla prossima.

NFS + fstab su centOS 5: problemi di mount automatico all’avvio

Dopo aver configurato NFS ho fatto in modo che le directory in sharing venissero montate automaticamente durante l’avvio dei client.

In questo modo, anche dopo un reboot, i client avrebbero potuto usufruire automaticamente delle risorse messe in condivisione dal server.

nfs, centos 5, fstab, mount, rc.d, runlevel, mount problem

Per ottenere tale funzionalità ho lavorato sui file /etc/fstab dei suddetti client, aggiungendo le entry:

192.168.12.1:/var/www/html/dir1    /var/www/html/dir1    nfs    hard,intr,rw,sync 0 0
192.168.12.1:/var/www/html/dir2    /var/www/html/dir2    nfs    hard,intr,rw,sync 0 0

dove 192.168.12.1 è l’indirizzo IP (locale) del server NFS.

Inutile dire che dopo N reboot, nonostante tali modifiche, le directory in sharing non venivano montate automaticamente.

Ho dunque deciso di vederci chiaro ed ho esaminato i vari scrip presenti nella directory /etc/rc3.d (dove il 3 indica il runlevel attivo sui client NFS). Un ls mi ha sbolognato tutta una serie di scrip, ma solo due hanno attirato la mia attenzione, ovvero K75netfs e S96netfs.

Il primo si occupa dell’inizializzazione dei volumi NFS, il secondo tira su le interfacce di rete.

Poichè gli scrip vengono eseguiti in ordine alfabetico, è chiaro che l’avvio di K75netfs prima di S96netfs causa il mancato mount delle risorse in sharing.

E’ dunque bastato eseguire il comando:

[root@client1 rc3.d] mv K75netfs S96netfs

e successivamente un reboot.

Infatti, a riavvio completato, un mount mi ha mostrato correttamente le risorse di rete condivise:

[root@bqweb1 ~]# mount

192.168.12.1:/var/www/html/dir1 on /var/www/html/dir1 type nfs (rw,sync,hard,intr,addr=192.168.12.1)
192.168.12.1:/var/www/html/dir2 on /var/www/html/dir2 type nfs (rw,sync,hard,intr,addr=192.168.12.1)

Enjoy.

PS: in aleternativa si potrebbe modificare opportunamente il file rc.local che regola l’esecuzione di comandi custom durante l’avvio del sistema operativo.

Ad esempio, si potrebbe inserire nel suddetto file la seguente direttiva:

mount -t nfs -o rw,sync,hard,intr 192.168.12.1:/var/www/html/dir1 192.168.12.1:/var/www/html/dir1