Sysadmin

Periferica USB: Cosa fare quando Windows XP la rileva ma non funziona?

Ricetta definitiva per l'USB

Ricetta definitiva per l'USB

Nelgi ultimi anni mi sono imbattuto frequentemente in computer con Windows XP che non rilevavano correttamente alcune periferiche USB. Al collegamento della periferica si sente il classico suono bitonale che avverte che windows ha rilevato la periferica, ma poi questa non funziona correttamente. Su altri computer la stessa periferica funzionava correttamente.

Nella maggior parte dei casi il problema era che la periferica era stata collegata prima di installare i suoi driver. E’ importante leggere le istruzioni prima di collegare tali periferiche perchè la maggior parte richiede l’installazione dei driver prima del collegamento ma alcune preferiscono la procedura inversa.

Quindi prima di installare una stampante, una fotocamera, una videocamera, una scheda sonora USB, un telefono USB, un dispositivo di acquisizione dati, etc, leggete le istruzioni!

Se, invece, avete già fatto il danno, questa è la procedura che in molti casi (ma non in tutti) mi ha portato a risolvere il problema.

La procedura è complicata e può danneggiare il sistema operativo, quindi fate il backup dei dati e seguitela solo se pensate di potervela cavare. L’unica alternativa provata a questa procedura è la reinstallazione di Windows XP.

Passo 1: Preparativi

  1. Scollegare tutte le periferiche USB (ad eccezione di tastiera e mouse)
  2. Avviare XP in modalità provvisoria (premendo F8 durante l’accensione del computer).

Passo 2: Rimuovere tutti i dispositivi “nascosti”

  1. Cliccare Avvio, Esegui. Digitale cmd e premere OK.
  2. Appare una schermata nera per il prompt dei comandi
  3. Scrivere “set DEVMGR_SHOW_DETAILS=1” (senza apici) e premere INVIO.
  4. Scrivere “set DEVMGR_SHOW_NONPRESENT_DEVICES=1” (senza apici) e premere INVIO.
  5. Scrivere “start devmgmt.msc” (senza apici) e premere INVIO.
  6. Cliccare su “Visualizza” “Mostra i disposibivi nascosti” (non ricordo la digitura esatta, non ho XP sotto mano)
  7. Clicca “+” per espandere i vari gruppi e rimuovere tutto ciò che ha a che fare con l’ “USB” ed eventualmente ciò che riporta nomi che hanno a che fare con Hi-Pro.

Spesso in questo frangente smette dik funzionare il mouse: in quei casi bisognerebbe riuscire a copletare la procedura con la sola tastiera
la cosa richiedere un uso sapiente delle scorciatoie di windows, ne elenco alcune:

CTRL-ESC apre il menu di avvio,
TAB e le frecce permettono di muovere la selezione,
INVIO di cliccare ciò che è selezionato,
ALT di aprire il menu della finestra attiva.
ALT-TAB di cambiare la finestra attiva

Passo 3: Rimozione di tutti i file oem*.inf

  1. Cliccare Avvio, Esegui e digitare “cmd” (senza apici)
  2. Nel prompt dei comandi eseguire questi comandi premendo invio dopo ognuno:
    cd \windows\inf
    ren infcache.1 *.old
    ren oem*.inf *.old
    del C:\windows\setupapi.log
    exit

Passo 4: Rimozione chiavi di registro di HKEY_LOCAL_MACHINE/Enum/USB che cominciano con VID

La rimozione delle chiavi VID dal registro farà si che i dispositivi vengano rilevati nuovamente al riavvio.

In questo punto bisognerebbe fare attenzione a non rimuovere i VID di tastiera e mouse USB ma a memoria non mi ricordo come riconoscerli.

  1. Cliccare Avvio, Esegui. Digitare “regedit” (senza apici) e cliccare oK. Si aprirà l’editor del registro di sistema.
  2. Navigare l’albero fino a HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\USB
  3. Evidenziare e canellare tutte le chiavi che cominciano per VID_

Nel caso venga dato un errore di permessi insufficienti o impossibilità di eliminare le voci:

  1. Tasto destro del mouse sulla chiave da cancellare e click su “Permessi” (vado sempre a memoria). Aprirà la finestra dei permessi.
  2. Con “Everyone” (forse si chiama “Tutti” in italiano) selezionato nella casella utenti e gruppi, selezionare “Controllo completo” nella lista permessi.
  3. Cliccare “Applica” e poi OK.

A questo punto dovrebbe essere possibile cancellare la chiave. Ripetere per tutte le chiavi poi spegnere il computer.

Passo 5: Riavvio e reinstallazione drivers

Al riavvio il computer dovrà reinstallare i driver per tutte le periferiche e potrebbe chiedere CD di windows e dei driver.
Installare i driver delle periferiche *prima* di collegare i dispositivi e riavviare il computer dopo aver collegato ed installato una periferica prima di collegare quella successiva.

Tags: , , ,

lunedì, giugno 29th, 2009 Sysadmin 5 Comments

Cluster@OVH: Basculare gli IP Failover di OVH via API

Nei cluster tradizionali con IP condiviso una macchina per diventare primaria deve assicurarsi che la secondaria sia offline e poi autoassegnarsi l’IP.

In OVH questa cosa non è sufficiente poichè spesso le macchine sono in classi C differenti e separate da router. E’ necessario quindi comunicare ad OVH che vogliamo “oscillare” un IP failover da un server ad un altro così che OVH possa aggiornare le regole di routing interne.

Normalmente questa operazione viene fatta dall’interfaccia web del manager OVH, ma è possibile farla anche tramite le API che OVH mette a disposizione con il protocollo SOAP.

Gestione IP Failover su Manager v3 OVH

Gestione IP Failover su Manager v3 OVH

Requisiti

Le api vengon utilizzate via SOAP e quindi quasi tutti i linguaggi di programmazione che dispongono di una libreria client SOAP possono essere utilizzati.

Nel mio piccolo ho provato python 2.4 con la libreria SOAPpy e PHP 5.1.6 con il SoapClient integrato ed ho riscontrato problemi con entrambe.

Sembra che il SoapClient di PHP abbia un bug critico che gli impedisce di funzionare con il wsdl di OVH. Il bug sembra corretto in PHP 5.2.6 che però non posso utilizzare.

Procedo quindi con python così da non interferire con PHP che è già presente nel sistema e configurato correttamente.

Questi i pacchetti presenti nella mia Centos 5.3:
SOAPpy-0.11.6-5.el5 e python-2.4.3-24.el5

Esempio e Problema

Prendendo ad esempio il generatore di codice client di OVH generiamo il codice python per vedere l’elenco dei failover associati

#!/usr/bin/python
import pprint
from SOAPpy import WSDL

soap = WSDL.Proxy('https://www.ovh.com/soapi/soapi-re-1.3.wsdl')
#login
session = soap.login('###NIC###-ovh', '###PASS###', 'it', 0)
print "login successfull"
#dedicatedFailoverList
result = soap.dedicatedFailoverList(session, '###NOMEDEDICATO###')
print "dedicatedFailoverList successfull"
pp = pprint.PrettyPrinter(indent=4)
pp.pprint(result) # your code here ...
#logout
soap.logout(session)
print "logout successfull"

ottenendo però questo risultato inaspettato:

login successfull
Traceback (most recent call last):
File "./example.py", line 13, in ?
result = soap.dedicatedFailoverList(session, '###NOMEDEDICATO###')
File "/usr/lib/python2.4/site-packages/SOAPpy/Client.py", line 453, in __call__
return self.__r_call(*args, **kw)
File "/usr/lib/python2.4/site-packages/SOAPpy/Client.py", line 475, in __r_call
self.__hd, self.__ma)
File "/usr/lib/python2.4/site-packages/SOAPpy/Client.py", line 379, in __call
p, attrs = parseSOAPRPC(r, attrs = 1)
File "/usr/lib/python2.4/site-packages/SOAPpy/Parser.py", line 1006, in parseSOAPRPC
t = _parseSOAP(xml_str, rules = rules)
File "/usr/lib/python2.4/site-packages/SOAPpy/Parser.py", line 985, in _parseSOAP
parser.parse(inpsrc)
File "/usr/lib/python2.4/site-packages/_xmlplus/sax/expatreader.py", line 109, in parse
xmlreader.IncrementalParser.parse(self, source)
File "/usr/lib/python2.4/site-packages/_xmlplus/sax/xmlreader.py", line 123, in parse
self.feed(buffer)
File "/usr/lib/python2.4/site-packages/_xmlplus/sax/expatreader.py", line 216, in feed
self._parser.Parse(data, isFinal)
File "/usr/lib/python2.4/site-packages/_xmlplus/sax/expatreader.py", line 363, in end_element_ns
self._cont_handler.endElementNS(pair, None)
File "/usr/lib/python2.4/site-packages/SOAPpy/Parser.py", line 234, in endElementNS
kind = (self._prem[kind[:i]], kind[i + 1:])
KeyError: u'typens'

Segnalando il problema a bugkillers@ml.ovh.net mi viene risposto velocemente che si tratta di un bug della libreria SOAP di Python (SOAPpy) presente fino alla versione 0.20 compresa. Da notare che mentre scrivo l’ultima release di SOAPpy è la 0.19 e risale al 2005. Si trovano alcuni rpm della 0.20 che probabilmente si riferiscono alla rc1 rilasciata nel 2007 ma anche questi contengono il bug di cui sopra!

L’unica è quindi utilizzare la versione di sviluppo che scarichiamo e della quale facciamo un tarball:

svn export https://pywebsvcs.svn.sourceforge.net/svnroot/pywebsvcs/trunk/SOAPpy/ SOAPpy-0.12.0
tar -zcf SOAPpy-0.12.0-dev.tar.gz SOAPpy-0.12.0
rm -rf SOAPpy-0.12.0
mv SOAPpy-0.12.0-dev.tar.gz /usr/src/redhat/SOURCES

A questo punto inseriamo il file spec appositamente creato e facciamo il build dei pacchetti (sorgente e binario) e installiamo il pacchetto appena creato.

cd /usr/src/redhat/SPECS
wget http://digg.it/wp-content/uploads/2009/06/SOAPpy-0.12.0.spec
rpmbuild --define="dist .el5" --define "centos 5" -ba SOAPpy-0.12.0.spec
rpm -Uvh /usr/src/redhat/RPMS/noarch/SOAPpy-0.12.0-dev.el5.noarch.rpm

Il pacchetto risultante lo trovate qui: SOAPpy-0.12.0-dev.el5.noarch.rpm

Altri problemi

Un ulteriore inconveniente del metodo API utilizzabile è che per basculare un IP dobbiamo prima sapere a quale server è assegnato in questo momento.

La mia necessità, invece, è quella che un server, in autonomia e senza conoscenze esterne possa richiedere un IP failover ed ottenerlo.

Per far questo quindi ho creato uno script che una volta loggato sulle API richiede l’elenco dei dedicati associati al cliente e cerca l’IP specificato in tutti i server. Se lo trova già associato al server giusto non fa nulla, se invece lo trova associtato ad un altro server effettua la chiamata per oscillarlo verso se stesso.

Conclusioni

Lo script creato lo trovate qui: getfailover.py

E’ abbastanza spartano ma per ora fa quello che mi serve. Utilizzo questo script in combinazione con heartbeat per permettere al mio cluster OVH di oscillare automaticamente in caso di problemi.

Tags: , , , , ,

mercoledì, giugno 24th, 2009 Sysadmin Nessun commento

Analizzare il carico dei processi con Munin

Munin, come ho scritto ieri, è uno strumento di monitoring molto potente e flessibile ed esistono centinaia di plugin per gestirne il comportamento.

Dopo aver cercato un po’ mi sono accorto che non esiste un plugin che può monitorare il carico dei singoli processi in esecuzione su una macchina. Alcuni plugin permettono di creare un grafico specifico per un determinato processo ma nessuno lo fa in maniera aggregata per tutti i processi contemporaneamente.

Così, vista la semplicità con cui è possibile scrivere un plugin munin, ho deciso di crearne uno che facesse al caso mio.

Questo è il risultato che ho ottenuto con poco sforzo:

Uso della CPU per processo

Uso della CPU per processo

Oltre al carico di CPU ho deciso di monitorare anche i minor-faults e i major-faults. I minor faults avvengono ogni qual volta un processo cerca di scrivere in una pagina di memoria protetta da scrittura, mentre i major faults avvengono quando questa operazione richiede anche una o più operazioni di I/O (e.g: swap). L’analisi dei minor/major faults può essere utile durante l’indagine di un problema di performance di un sistema.

Questo, ad esempio, è il grafico dei minor-faults corrispondente al precendete grafico di carico CPU per la stessa macchina:

Errori di pagina "minori" per processor

Errori di pagina "minori" per processor

I plugin, da copiare nella cartella /etc/munin/plugins sono questi:
processes_cpu
processes_minorfaults
processes_majorfaults

Dopo aver copiato i plugin, è necessario riavviare il munin-node:

sh# service munin-node restart

Possibili migliorie

Purtroppo i colori devo necessariamente lasciarli gestire a munin automaticamente.

Non ho idea di come si potrebbe fare a mettere in legenda solo quei processi che hanno usato almeno un 1% della CPU o funzionalità del genere.

Se lo stesso plugin viene installato in più macchine i processi vengono colorati diversamente per ogni macchina, rendendo di fatto poco intuitivo il confronto. Forse decidere il colore in base ad un hash calcolato dal nome del processo permettere stabilità ma potrebbe capitare che i processi più importanti abbiano poi un colore identico e siano indistinguibili.

Tags: , ,

mercoledì, maggio 20th, 2009 Sysadmin 2 Comments

Analizzare il traffico dei VirtualHost di Apache con Munin

apache-vhost-monitoring-munin-cbandPrerequisiti

Questo articolo prevede l’uso di Fedora Core 10 con Apache 2 installato e funzionante. Altre distribuzioni potrebbero richiedere la compilazione dei pacchetti che invece su FC10 sono già disponibili.

Installare CBand

Fortunatamente anche per il modulo cband esiste un pacchetto precompilato per FC10 e quindi l’installazione è molto rapida:

sh# yum install mod_cband

Installato il mod_cband aggiungiamo alla definizione di ogni VirtualHost che vogliamo monitorare la configurazione di cband:

<IfModule mod_cband.c>
CBandLimit 600G
CBandExceededURL http://www.google.com
CBandScoreboard /var/run/httpd/cband_scoreboard-#DOMINIO#
CBandPeriod 1W
</IfModule>

Da notare che ho impostato un limite di 600GB in 1 settimana, che nel mio caso corrisponde praticamente a non limitare, poichè il traffico è molto minore. E’ però necessario imporre un limite (seppur irraggiungibile) per far si che cband conteggi l’utilizzo di banda.

Fatto questo per ogni VH possiamo testare che la configurazione sia corretta, riavviare apache e vedere la pagina delle statistiche di cband:

sh# httpd -t
sh# service httpd restart

Aprendo http://localhost/cband-status vedremo una pagina simile a questa:

La pagina delle statistiche di cband

La pagina delle statistiche di cband

Impostare Classi in Cband

cband permette di definire fino a 3 classi di utenti in base all’IP. Con un po’ di lavoro possiamo quindi identificare i bot dei motori di ricerca, magari tenendo separato google che ci interessa più degli altri, e le classi di IP locali, per evitare che alcune macchine che effettuano richieste automatizzate possano inficiare le statistiche.

Queste sono le mie configurazioni messe in /etc/httpd/conf.d/mod_cband.conf

<CBandClass googlebot_class>
CBandClassDst 66.249.64/20
</CBandClass>

<CBandClass local_class>
CBandClassDst XXX.XXX.XXX.XXX
CBandClassDst 127.0.0.1
</CBandClass>

<CBandClass bots_class>
# Yanga
CBandClassDst 91.205.124.3/22
# Exabot
CBandClassDst 193.47.80.0/24
# Slurp
CBandClassDst 72.30.0.0/16
CBandClassDst 74.6.0.0/16
CBandClassDst 67.195.114.0/24
CBandClassDst 67.195.37.0/24
CBandClassDst 202.160.178.0/20
# Yandex
CBandClassDst 77.88.22.0/21
CBandClassDst 93.158.146.0/23
# Jyxobot
CBandClassDst 195.113.214.197
# DotBot
CBandClassDst 208.115.111.0/24
# libwww-perl
CBandClassDst 195.210.89.0/24
# MSN con referrer di ricerca
# CBandClassDst 65.55.104.0/21
# Twiceler
CBandClassDst 216.129.119.1/24
CBandClassDst 64.1.215.1/24
CBandClassDst 208.36.144.1/24
CBandClassDst 38.99.13.1/24
CBandClassDst 38.99.44.1/24
# AskJeeves
CBandClassDst 66.235.124.0/24
# majestic12
CBandClassDst 85.23.64.207
CBandClassDst 212.50.134.32
CBandClassDst 85.16.151.236
CBandClassDst 85.113.244.201
CBandClassDst 68.192.9.221
CBandClassDst 85.178.109.63
# Wikio Feed
CBandClassDst 84.55.184.91
# Turnitin
CBandClassDst 65.98.224.7
# MSN
# CBandClassDst 65.55.208.0/24
# CBandClassDst 65.55.51.0/24
CBandClassDst 65.55.0.0/16
CBandClassDst 219.142.53.0/24
# Gaisbot
CBandClassDst 122.147.76.64/28
CBandClassDst 210.66.69.128/26
CBandClassDst 219.87.182.128/27
CBandClassDst 220.228.152.64/27
</CBandClass>

In questo modo il calcolo del traffico avverrà separatamente per “classe”. Potremo conoscere il traffico degli “utenti normali” per differenza, sottraendo dal traffico totale le classi local_class, bots_class, googlebot_class.

Installare Munin

Munin è uno strumento di monitoring con un meccanismo di estendibilità a plugin estremamente semplice ed intuitivo (rispetto a MRTG) che permette di monitorare uno o più server.

Munin si divide infatti in due pacchetti: munin e munin-node.

Mentre munin-node è necessario in ogni server che intendiamo controllare il pacchetto munin serve solamente nella macchina che aggregherà le statistiche per creare dei grafici tramite il noto strumento rrdtool.

Su Fedora Core 10 installare munin è molto semplice:

sh# yum install munin munin-node

Una delle peculiarità di munin è l’autoconfigurazione: i plugin infatti possono verificare l’ambiente in cui sono installati per stabilire se sono “applicabili” all’ambiente o meno. Per verificare l’autoconfigurazione possiamo lanciare questo comando:

sh# munin-node-configure --shell

L’output di questo comando conterrà l’elenco dei comandi da impartire alla shell per installare i plugin che dichiarano la loro compatibilità.

Creare un plugin munin per mod_cband

A questo punto non ci resta che creare un plugin munin che legga la pagina /cband-status e permetta così a munin di visualizzare il grafico degli accessi diviso per vhost.

Questo è un esempio del plugin munin che richiede la pagina e ne estrae i dati:

#!/bin/sh

URL="http://localhost/cband-status?refresh=15&unit=K";
WGET=`which wget`;
WGET_FLAGS="-Yoff";

# Settigs required for autoconf
#%# family=manual
#%# capabilities=autoconf

if [ "$1" = "autoconf" ]; then
echo no
exit 0
fi

if [ "$1" = "config" ]; then

echo 'graph_title CBandwith Usage '
echo 'graph_args -l 0'
echo 'graph_category apache'
echo 'graph_info This graph shows per virtual host traffic from the cband module.'
echo 'graph_vlabel Kbytes per ${graph_period}'

wget -q $WGET_FLAGS "$URL" -O - | grep -A 3 http |grep "^<td .*http" |sed -e 's^.*http://\(.*\)".*^\1^' | while read site; do
metricname=$(echo $site | sed -e 's/\.//g')
#echo $metricname $site
echo $metricname'.label '$site
echo $metricname'.info Traffic generated on '$site'.'
echo $metricname'.min 0'
echo $metricname'.type DERIVE'
done;
exit 0
fi

if [ -x $WGET ]; then
SITES=$(wget -q $WGET_FLAGS "$URL" -O - | grep -A 3 http |grep "^<td.*http" |sed -e 's^.*http://\(.*\)".*^\1^')
$WGET -q $WGET_FLAGS "$URL" -O - | grep -A 3 http |grep "^<td.*\(color\|http\)" | while read v; do
echo -n $v | sed -e 's^.*http://\(.*\)".*^\1^' | sed -e 's/\.//g'
echo -n '.value '
read v;
echo $v | sed -e 's^.*\/\(.*\)KB.*^\1^'
done;
exit 0
fi

exit 0

E questo è il risultato:

Traffico generato da Google su ogni VHost

Traffico generato da Google su ogni VHost

I plugin munin che ho creato sono molto spartani ma utili e controllano il traffico totale, quello di google, quello degli altri bots, e il traffico utente (il totale meno i robot e meno la classe locale).

Conclusioni

Il modulo cband, nonostante non più aggiornato dal 2006, non sembra pesare sulle performance e la stabilità di apache2 e dopo un mesetto di utilizzo ne sono soddisfatto.

Dovrei migliorare il plugin configurando meglio le impostazioni dei grafici (usare il min/max/avg, stili di linea differenti.

Troubleshooting

Se cband non vi funziona bene probabilmente si tratta di un problema di ordine di caricamento dei files nella /etc/httpd/conf.d . Questi files vengono caricati in ordine alfabetico, quindi se le definizioni dei virtualhost le avete qui assicuratevi che vengano il ordine alfabetico dopo al mod_cband.conf

Io, per convenzione, li chiamo vh-dominio.conf

Tags: , , ,

martedì, maggio 19th, 2009 Sysadmin 2 Comments

Trasloco di siti, propagazione DNS e Reverse Proxy

testimone

Lo spostamento di un sito/servizio web da un IP ad un altro può essere molto problematica. I grattacapi principali sono dovuti al tempo di propagazione del DNS, durante il quale i visitatori potrebbero approdare sia sul vecchio che sul nuovo IP in funzione di quale server DNS utilizzano e lo stato della cache.

Per ridurre al minimo questo problema è buona norma ridurre l’expire della cache di un dominio prima di un’operazione di trasloco di questo tipo, ma questa soluzione riduce solo il problema senza rimuoverlo.

Il problema fondamentale consiste nel fatto che a volte non possiamo permetterci che i due servizi su i 2 IP diversi ricevano richieste contemporaneamente perchè queste richieste potrebbero modificare lo stato di entrambi i server creando una divergenza non più sincronizzabile. Basta pensare ad un blog ed il fatto che alcuni utenti potrebbero commentare sul primo IP mentre altri sul secondo, con la conseguente perdita di dati che si avrebbe a transizione completata.

Una soluzione spesso adottata è quella di far rispondere il nuovo (www.dominio.com) sito ad una nuova URL tipo nuovo.dominio.com, sincronizzare il database, modificare la configurazione del webserver per far si che qualunque richiesta a www.dominio.com venga rediretta (302, temporary redirect) a nuovo.dominio.com e poi aggiornare il DNS. Questa soluzione però, oltre a non essere completamente trasparente per l’utente finale, potrebbe creare problemi nel caso in cui l’applicazione che dobbiamo spostare non sia indipendente dal nome. Potremmo infatti avere già dei cookie impostati per quel detterminato l’hostname o potremmo avere dei punti del codice che controllano quale sia l’hostname attuale.

Per questo motivo la mia soluzione preferita è quella di utilizzare un reverse proxy. In pratica si configura il sito nuovo, si sincronizza il db, poi si configura il vecchio non più per fare un redirect ma piuttosto per andare a chiedere la stessa pagina al sito nuovo e fornirla al navigatore.

Per fare questo con apache2 è sufficiente abilitare il mod_proxy in /etc/httpd/conf/httpd.conf togliendo il # dalle due righe:

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so

ed aggiungere al virtualhost che stiamo spostando le seguenti istruzioni:

ProxyRequests Off
ProxyPreserveHost On
ProxyPass / http://[IP-NUOVO-SERVER]/

Con questa configurazione facciamo sì che le richieste fatte a quel sito vengano gestite non più dal server locale, ma piuttosto apache2 si preoccuperà di andarle a fare sull'[IP-NUOVO-SERVER]. ProxyPreserverHost ci serve così da poter mantenere l’Host nella richiesta e fare in modo che il server di destinazione riceva la richiesta come se l’avesse ricevuta dall’utente originale.

ProxyPass dice che tutte le pagine vengono “girate” al nuovo IP, ma potremmo anche decidere di fare questa operazione solo con alcune sottodirectory.

Esiste però ancora un problema legato a questa tecnica, e cioè che il nuovo server vedrà tutte le richieste venire dall’IP del vecchio server e non conoscerà più l’IP originale. Questo significa che i log avranno l’IP del “proxy” e che alcuni script potrebbero non funzionare bene.

Per questo viene d’aiuto un altro modulo apache chiamato mod_extract_forwarded che permette di estrarre l’IP presente nell’header X-Forwarded-For (aggiunto dal mod_proxy) e sostituirlo al remote address usato da apache.

Se il vostro nuovo server è una fedora core 10, come la mia, allora potete installare il modulo direttamente:

shell# yum install mod_extract_forwarded.i386

Il file di configurazione del modulo è in /etc/httpd/conf.d/mod_extract_forwarded.conf . E’ sufficiente aprirlo e modificare la riga MEFaccept inserendo l’elenco degli IP dei “proxy” fidati:

MEFaccept [IP-VECCHIO-SERVER]

E’ importante specificare questa opzione solo per gli IP dei proxy fidati perchè l’header X-Forwarded-For è un semplice header HTTP e di conseguenza è falsificabile molto semplicemente. Basti pensare che esiste una estensione Firefox che permette di impostare tale header a piacimento.

Ecco fatto, sia i log che tutte le applicazioni mostreranno l’IP originale e non quello del “proxy”.

Tags: , , , ,

venerdì, aprile 17th, 2009 Sysadmin 1 commento