Ricerche IT

Gestire attributo di stile height con doctype xhtml 1.0 transitional

Lorenzo — Thu, 05 Aug 2010 21:03:30 +0000

Me lo appunto qui, così magari non lo dimentico, approfittandone anche per tirar via le ragnatele da questo spazio.

In una pagina HTML, se specifico un doctype di tipo xhtml 1.0 transitional, devo prendere alcuni accorgimenti se intendo utilizzare l’attributo di stile “height”, riferito ad uno o più elementi div ed espresso in percentuale; ad esempio, se ho un codice di questo tipo:


<html>
<head>
  <style type="text/css">
    #div1
    {
    width: 100%;
    height: 15%;
    border: 2px solid blue;
    }
    #div2
    {
    width: 100%;
    height: 60%;
    border: 2px solid red;
    }
    #div3
    {
    width: 100%;
    height: 25%;
    border: 2px solid green;
    }
  </style>
  <title>TEST</title>
</head>
 
<body>
  <div id="div1">
    <h1>Contenitore 1</h1>
  </div>
  <div id="div2">
    <h1>Contenitore 2</h1>
  </div>
  <div id="div3">
    <h1>Contenitore 3</h1>
  </div>
 
</body>
</html>

posso notare come in realtà, lo spazio occupato dai tre elementi div sia quello strettamente necessario a contenere le tre intestazioni delimitate dai tag h1, come mostrato in figura 1:

Pagina html con attributo height impostato ma non funzionante

dove è possibile vedere che le percentuali che ho indicato relative all’altezza da assegnare ai tre elementi div sono state bellamente ignorate dal browser.

Per risolvere il problema, devo indicare l’altezza complessiva degli elementi html e body, e impostarla al 100%, per cui il codice precedente assume quest’aspetto:


<html>
<head>
  <style type="text/css">
    html,body
    {
    width: 100%;
    height: 100%;
    margin: 0;
    padding: 0;
    }
    #div1
    {
    width: 100%;
    height: 15%;
    border: 2px solid blue;
    }
    #div2
    {
    width: 100%;
    height: 60%;
    border: 2px solid red;
    }
    #div3
    {
    width: 100%;
    height: 25%;
    border: 2px solid green;
    }
  </style>
  <title>TEST</title>
</head>
 
<body>
  <div id="div1">
    <h1>Contenitore 1</h1>
  </div>
  <div id="div2">
    <h1>Contenitore 2</h1>
  </div>
  <div id="div3">
    <h1>Contenitore 3</h1>
  </div>
 
</body>
</html>

Il risultato dell’applicazione di questo codice è visibile in figura 2:

Pagina html con l'impostazione corretta dell'attributo height riferito ai tag html e body

A parte il fatto che in questo modo il box in fondo alla pagina deborda un po’ (a causa dell’applicazione dei bordi, la cui dimensione si va a sommare al 100% complessivo dell’altezza degli elementi div), è possibile vedere che abbiamo raggiunto lo scopo di poter gestire a piacimento l’altezza dei vari elementi div, esprimendo questi valori dell’attributo di stile height in percentuale rispetto all’altezza del 100% della pagina.

Questo problema invece non si presentava utilizzando un doctype HTML 4.0 TRANSITIONAL, che era decisamente meno rigoroso su questi aspetti.

Buone Feste!

Lorenzo — Fri, 25 Dec 2009 13:08:55 +0000

Oggi è Natale, quindi non sono proprio in anticipo, però vorrei lo stesso fare gli auguri di Buon Natale (per quel che rimane), di buone Feste, e di un sereno 2010 a tutti i lettori del blog, sia a coloro che sono più assidui, sia a coloro che arrivano qui per caso partendo da una ricerca su Google (la maggior parte).

AUGURI A TUTTI!!!

Ho a disposizione 25 inviti per Google Wave

Lorenzo — Tue, 08 Dec 2009 10:17:00 +0000

Sto giocando con testando Google Wave, lo strumento collaborativo messo a disposizione da Google. Al momento, i miei scarsissimi test me lo fanno sembrare un prodotto carino… in prospettiva.

Comunque, non è dei miei test che vorrei parlare (anche perché finirei molto presto), ma del fatto che ho 25 inviti a disposizione, per cui, chi volesse usufruirne, può lasciare un commento.

Mailbox virtuali con Postfix e Dovecot su Debian

Lorenzo — Sun, 29 Nov 2009 20:30:48 +0000

Scenario

Facendo riferimento ai due precedenti articoli su Postfix e Dovecot, dove si era vista una configurazione minimale di un server di posta e l’utilizzo di alias e domini virtuali, sempre basandoci sull’ambiente di test precedentemente illustrato, in questo articolo vedremo come utilizzare le mailbox virtuali su Postfix, e quindi come accedere a queste mailbox con Dovecot. L’utilizzo di mailbox virtuali è un passo avanti rispetto alle configurazioni precedentemente trattate, poiché con questo tipo di caselle di posta elettronica, facciamo in modo che le mailbox siano completamente distinte dagli utenti di sistema, in questo modo non saremo costretti a creare un utente Linux da utilizzare ogniqualvolta abbiamo bisogno di una casella di posta. Oltre alle mailbox, avremo anche dei domini virtuali, in tal modo potremo ospitare sullo stesso server caselle di posta elettronica riferite a diversi domini, con tutti i vantaggi del caso. Le informazioni su mailbox e domini virtuali saranno contenute in file di testo sul file system del sistema operativo.

Configurazione di Postfix

Andremo a configurare mailbox virtuali sul server Giapeto per i domini cerere.mail e saturno.mail. In questa situazione, se esistono, è bene cancellare dal file di configurazione /etc/postfix/main.cf tutte le impostazioni relative ad alias e domini virtuali, poiché queste impostazioni andranno eventualmente riscritte secondo il formato richiesto dalle mailbox virtuali. La configurazione precedentemente descritta si esplicita nelle seguenti direttive nel file di configurazione /etc/postfix/main.cf; le altre informazioni riferite ai parametri basilari di Postfix rimangono quelle descritte nell’articolo riguardante la configurazione di base di Postfix:

virtual_mailbox_domains = cerere.mail saturno.mail
virtual_mailbox_base = /var/spool/vmail
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_minimum_uid = 5000
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000
virtual_alias_maps = hash:/etc/postfix/virtual

La prima riga fa riferimento ai domini virtuali per i quali il sistema è abilitato a ricevere messaggi di posta, cioè cerere.mail e saturno.mail. La seconda riga fa riferimento alla directory di base scelta come deposito di tutta la posta ricevuta su questo server, al cui interno vi saranno le varie sottodirectory relative ai domini virtuali, e per ogni dominio virtuale vi saranno le directory riferite alle varie mailbox di quel dominio, dove verrà depositata la posta elettronica, secondo il formato di archiviazione Maildir, come vedremo di seguito. La terza riga indica il file dove vengono elencate le mailbox virtuali definite sul sistema e la loro posizione sul file system, a partire dalla directory definita in precedenza col parametro virtual_mailbox_base. La quarta riga specifica l’id minimo dell’utente utilizzato dal sistema per andare a scrivere i file rappresentanti i messaggi di posta sul file system, nella posizione indicata con il parametro virtual_mailbox_base; questo utente avrà un ID utente e un ID di gruppo, specificati con precisione nella quinta e nella sesta riga della porzione del file di configurazione specificata poco sopra. La settima e ultima riga è opzionale, e indica la posizione del file contenente gli alias virtuali delle mailbox virtuali effettive, come descritto nell’articolo precedente riguardante gli alias virtuali, anche se nell’articolo precedente gli alias si riferivano alle mailbox di sistema e non a quelle virtuali.

Modificata la configurazione di Postfix, creiamo la directory che conterrà le mailbox virtuali:

mkdir /var/spool/vmail

Ora invece dobbiamo creare la mappa che conterrà l’elenco delle mailbox virtuali definite sul sistema:

touch /etc/postfix/vmailbox

Quindi andremo ad editare il file vmailbox appena creato per definire l’elenco delle mailbox sul nostro sistema, in questo modo:

salvor.hardin@cerere.mail   cerere.mail/salvor.hardin/
hober.mallow@cerere.mail    cerere.mail/hober.mallow/
preem.palver@saturno.mail   saturno.mail/preem.palver/
stor.gendibal@saturno.mail  saturno.mail/stor.gendibal/

Questo è un tipico file di mappa di Postfix, dove nella prima colonna sono indicate le mailbox virtuali, mentre nella seconda è indicato il percorso della casella in cui andrà depositata la posta, a partire dalla “radice” che altro non è che il percorso indicato nella direttiva virtual_mailbox_base del file main.cf, come visto in precedenza; ad esempio, la posta della mailbox virtuale salvor.hardin@cerere.mail verrà depositata nella directory /var/spool/vmail/cerere.mail/salvor.hardin. Da notare lo slash (/) alla fine del percorso di ogni mailbox virtuale, il quale indica a Postfix di archiviare la posta nel formato Maildir.

Creare a questo punto la mappa in formato .db partendo dal file appena editato:

postmap /etc/postfix/vmailbox

Ora editiamo il file di mappa /etc/postfix/virtual in cui andare ad inserire gli alias per le mailbox virtuali:

postmaster@cerere.mail    salvor.hardin@cerere.mail
abuse@cerere.mail         salvor.hardin@cerere.mail
postmaster@saturno.mail   preem.palver@saturno.mail
abuse@saturno.mail        preem.palver@saturno.mail

e compiliamo quindi la mappa degli alias:

postmap /etc/postfix/virtual

Configurazione di Dovecot

Configurato Postfix, dobbiamo informare anche Dovecot delle mutate impostazioni di archiviazione della posta elettronica, per cui Dovecot dovrà essere informato della nuova posizione delle mailbox; inoltre, Dovecot non si baserà più sugli utenti di sistema per l’autenticazione sulla casella di posta, per cui andremo a fornirgli un file in cui sono elencati gli utenti ed un file in cui sono elencate le relative password, secondo lo schema stesso di Linux, basato su un file passwd dove sono indicati gli utenti, ed un file shadow dove sono elencate le password. Di seguito vediamo le impostazioni da inserire nel file di configurazione di Dovecot /etc/dovecot/dovecot.conf, fare attenzione ad aprire e chiudere le graffe, esistenti e non, all’interno del file di configurazione:

mail_location = Maildir:/var/spool/vmail/%d/%n
auth default {
  mechanisms = plain login
  userdb passwd-file {
    args = /var/spool/vmail/%d/etc/passwd
  }
  passdb passwd-file {
    args = /var/spool/vmail/%d/etc/shadow
  }
}

Nella riga 1 andiamo a specificare la posizione in cui Dovecot andrà a leggere la posta archiviata da Postfix, utilizzando delle variabili; ciò consente a Dovecot di leggere la posta di più domini, utilizzando la variabile %d, che indica la parte dopo la chiocciola dell’indirizzo di posta (il dominio), e la variabile %n, che indica la parte prima della chiocciola dell’indirizzo di posta (il nome utente): tra l’altro, ciò comporta l’accortezza di autenticarsi indicando, alla richiesta del nome utente, l’indirizzo completo di posta.

La seconda riga indica l’inizio della sezione riguardante le impostazioni di autenticazione su Dovecot, che sono evidenziate ad iniziare dalla terza riga, che indica i meccanismi di transito sulla rete delle password, che nel caso illustrato vengono trasmesse in chiaro per l’autenticazione su Dovecot; questo causa qualche problema di sicurezza, poiché le password viaggiano in chiaro sulla rete, quindi basta sniffarla il tempo necessario per carpire le password. Quarta e quinta riga indicano la posizione del file in cui sono indicati gli utenti possessori di una casella di posta, mentre settima e ottava riga indicano il percorso del file contenente il nome utente e la relativa password; da notare che anche in questo caso è stata utilizzata la variabile %d, seguita dalla directory etc/ che conterrà i due file: tale directory è stata creata semplicemente per coerenza con la struttura delle directory Linux, ma non è assolutamente necessaria.

Creazione directory, utenti e password

Ora bisogna creare gli utenti e le password sia per l’accesso di Postfix alla directory /var/spool/vmail, sia per l’autenticazione su Dovecot da parte di un qualsiasi MUA (Mail User Agent). Cominciamo creando l’utente di sistema che useremo per l’accesso alla directory in cui saranno contenute le mailbox virtuali:

useradd -d /var/spool/vmail -s /bin/false -m -U -u 5000 vmail

Con questo comando creiamo l’utente vmail, a cui assegnamo la home directory /var/spool/vmail e la shell “fasulla” /bin/false, ed a cui assegnamo l’id utente 5000, come indicato nella configurazione di Postfix; inoltre, con l’opzione –U andiamo a creare un gruppo con caratteristiche identiche all’utente appena creato. È possibile notare che la home directory assegnata all’utente vmail corrisponde alla directory indicata in Postfix come directory “root” per l’archiviazione di posta elettronica, in questo modo assegnamo subito a questo utente l’ownership (ovvero la proprietà) della directory, poiché sarà l’utente vmail che effettivamente avrà il compito di archiviare sul file system la posta elettronica.

Il passaggio successivo consiste nel creare le directory relative ai domini, ai file contenenti utenti e password, ed alle mailbox virtuali. Iniziamo con le directory relative ai domini cerere.mail e saturno.mail:

1 2	mkdir /var/spool/vmail/cerere.mail mkdir /var/spool/vmail/saturno.mail

Ora creiamo la directory etc per ogni dominio, che conterrà i file relativi ad utenti e password corrispondenti alle mailbox virtuali create per ogni dominio; gli utenti e le password verranno utilizzati da Dovecot per autenticare l’accesso alle caselle di posta virtuali:

1 2	mkdir /var/spool/vmail/cerere.mail/etc mkdir /var/spool/vmail/saturno.mail/etc

Ora andiamo a creare, per ogni dominio, il file degli utenti (passwd) e delle password (shadow), coerentemente con quanto indicato nel file di configurazione di Dovecot:

touch /var/spool/vmail/cerere.mail/etc/passwd
touch /var/spool/vmail/cerere.mail/etc/shadow
touch /var/spool/vmail/saturno.mail/etc/passwd
touch /var/spool/vmail/saturno.mail/etc/shadow

Creati i file, bisogna inserire il contenuto relativo a utenti e password, di seguito sono elencati i comandi per inserire i contenuti dei due file degli utenti passwd:

Utenti per il dominio cerere.mail

1
2

echo salvor.hardin::5000:5000::/var/spool/vmail/cerere.mail/salvor.hardin >> /var/spool/vmail/cerere.mail/etc/passwd
echo hober.mallow::5000:5000::/var/spool/vmail/cerere.mail/hober.mallow >> /var/spool/vmail/cerere.mail/etc/passwd

Utenti per il dominio saturno.mail

1
2

echo preem.palver::5000:5000::/var/spool/vmail/saturno.mail/preem.palver >> /var/spool/vmail/cerere.mail/etc/passwd
echo stor.gendibal::5000:5000::/var/spool/vmail/saturno.mail/stor.gendibal >> /var/spool/vmail/cerere.mail/etc/passwd

Dall’analisi di questi file, si può intuire che nel file viene indicato il nome utente, poi l’ID utente e di gruppo (il 5000 preso per l’utente locale vmail), quindi viene indicata la directory in cui Dovecot andrà a leggere la posta per quell’utente

Ora bisogna popolare il file shadow con le password degli utenti. Siccome voglio che le password siano criptate (ad esempio utilizzando l’algoritmo md5, anche se non è il più sicuro che esista), per generare le password dovrò utilizzare il comando dovecotpw. Ad esempio, per assegnare a tutti gli utenti la password Password00, dovrò scrivere qualcosa del genere:

Password per il dominio cerere.mail

1
2

echo salvor.hardin:$(dovecotpw –s md5 –p Password00) >> /var/spool/vmail/cerere.mail/etc/shadow
echo hober.mallow:$(dovecotpw –s md5 –p Password00) >> /var/spool/vmail/cerere.mail/etc/shadow

Password per il dominio saturno.mail

1
2

echo preem.palver:$(dovecotpw –s md5 –p Password00) >> /var/spool/vmail/saturno.mail/etc/shadow
echo stor.gendibal:$(dovecotpw –s md5 –p Password00) >> /var/spool/vmail/saturno.mail/etc/shadow

A questo punto, avendo trafficato con l’utente root all’interno della directory /var/spool/vmail, è necessario reimpostare l’ownership della directory e del suo contenuto con il comando

chown –R 5000:5000 /var/spool/vmail

Collaudo del sistema

Per testare il server di posta elettronica, è sufficiente inviare una mail ad uno degli indirizzi di posta appena creati, e Postfix, alla ricezione della mail, creerà la directory in cui depositare la posta e che rappresenterà il deposito di tutta la posta per quella determinata mailbox. Se voglio controllare cosa accade durante la ricezione della mail, sia per curiosità, sia per motivi di troubleshooting, è possibile consultare il log della posta, contenuto nel file /var/log/mail.log, che ci darà tutte le informazioni che ci necessitano. Se invece voglio controllare in tempo reale che accade, posso utilizzare un’opzione sciccosa del comando tail in questo modo:

tail –f /var/log/mail.log

che mi mostrerà appunto in tempo reale le righe che vengono eventualmente aggiunte al file /var/log/mail.log.

Conclusioni

Questa configurazione comincia ad essere un tantino più professionale rispetto alle configurazioni proposte in precedenza, infatti ora possiamo gestire con maggiore flessibilità più domini ed i relativi utenti, che non sono più utenti di sistema, per cui possiamo avere lo stesso nome utente per domini diversi. Questa configurazione però ha anche alcuni difetti, ovvero il metodo di creazione di utenti e password per l’accesso alla posta elettronica, che è un po’ macchinoso basandosi sulla riga di comando; un’altra mancanza non indifferente è rappresentata dal fatto che sostanzialmente, con questa configurazione, ci fidiamo di tutto ciò che ci arriva, poiché non vi sono restrizioni sulla posta in arrivo.

Per la definizione delle mappe delle mailbox virtuali e degli alias, nonché per la definizione di utenti e password per Dovecot, vedremo in seguito una configurazione in cui Postfix e Dovecot utilizzano MySQL al posto delle tecniche trattate finora, mentre per spam e antivirus verranno analizzati alcuni strumenti come greylist e blacklist, e ClamAV come sistema di scansione antivirus della posta elettronica. Rimane fondamentale una corretta configurazione di Postfix per impedire che il nostro MTA funga da open relay, ciò dipende essenzialmente, per quanto visto finora, da ciò che si inserisce nel parametro mynetworks, come illustrato negli articoli precedenti.

Link di riferimento

How to configure PostFix and Dovecot for Virtual Users with out a Database

Strategie aziendali

Lorenzo — Mon, 09 Nov 2009 21:46:06 +0000

Stasera, cazzeggiando un po’ per la blogosfera, che non ho voglia di dedicarmi a cose “serie”, mi sono imbattuto in questo post di Gaspar Torriero, in cui viene descritto un intervento che egli ha fatto al Venezia Camp (già svoltosi) insieme a Marco Massarotto, in cui, da quanto leggo dal blog di Gaspar Torriero, e se non ho capito male, si è parlato da due punti di vista differenti rispetto all’opportunità per le aziende di fare promozione tramite il Web, o qualcosa di simile.

Gaspar Torriero è scettico, e porta a sostegno della propria opinione alcuni esempi, tra cui questo thread del Bertuccia Forum. Il thread, a mio parere, è qualcosa di assolutamente esilarante. Astenersi dalla lettura se l’argomento “regolarità intestinale” è causa di qualsivoglia turbamento.

Fare il binding di IIS 6 su un solo indirizzo IP

Lorenzo — Sun, 08 Nov 2009 22:10:09 +0000

Scenario

Si prenda in considerazione un server Windows Server 2003 con Internet Information Services 6 con installato almeno un sito Web; il server in questione ha due o più schede di rete, oppure una scheda di rete con definiti due o più indirizzi IP, ad esempio, il nostro server ha due indirizzi IP, 172.16.1.1 e 172.16.1.10. Questo server ha un’installazione di IIS predefinita, con uno o più siti Web installati. In tale situazione, IIS rimane in ascolto sulla porta 80 su tutti gli indirizzi IP definiti sulla macchina.

Ora esaminiamo l’ipotesi di dover far girare sulla stessa macchina un altro server Web, che deve anch’esso rimanere in ascolto sulla porta 80: in questo caso, bisogna fare in modo che i siti di IIS rimangano in ascolto, invece che su entrambi gli indirizzi IP, su un solo indirizzo IP; nel nostro caso scegliamo l’indirizzo 172.16.1.1, in modo da lasciare “libero” l’indirizzo 172.16.1.10 per l’altro server Web.

A prima vista, la soluzione sembrerebbe semplice, cioé configurare il sito (o i siti) Web per rimanere in ascolto solamente sull’indirizzo 172.16.1.1, come mostrato in figura 1:

Purtroppo però questa soluzione non funziona, IIS continua a rimanere in ascolto sulla porta 80 su tutti gli indirizzi IP della macchina, com’è possibile vedere col comando netstat:

netstat -noa | find ":80"

il cui output risulta essere questo:

TCP    0.0.0.0:80             0.0.0.0:0              LISTENING       2548

che indica appunto che IIS si appropria della porta 80 su tutti gli IP disponibili.

Configurazione di IIS

Con i normali strumenti messi a disposizione dalla console di gestione di IIS, che io sappia non c’è modo di superare questa limitazione; per risolvere il problema, possiamo utilizzare l’utility httpcfg, contenuta nel pacchetto Windows Server 2003 Support Tools, che consente di svolgere questo e altri compiti su IIS.

Il primo passo consiste nel verificare su quali porte sta in ascolto IIS, col comando

httpcfg query iplisten

che, nel mio caso, restituisce questo output:

HttpQueryServiceConfiguration completed with 1168

Ciò significa che IIS segue l’impostazione predefinita, ovvero rimane in ascolto su tutti gli IP disponibili sulla macchina. Con httpcfg posso cambiare questa impostazione, istruendo IIS per rimanere in ascolto solamente sull’IP 172.16.1.1:

httpcfg set iplisten -i 172.16.1.1

il quale restituisce questo messaggio che conferma la corretta esecuzione del comando:

HttpSetServiceConfiguration completed with 0

La conferma è utile, ma è meglio controllare se la configurazione è corretta, digitando di nuovo il comando

httpcfg query iplisten

il cui output stavolta è differente:

      IP                      : 172.16.1.1
------------------------------------------------------------------------------

La configurazione è avvenuta correttamente, per renderla attiva è necessario riavviare il servizio HTTP e i servizi dipendenti, HTTP SSL e World Wide Web Publishing Service:

net stop http /y

L’opzione /y riavvia http e i servizi dipendenti da questo senza attendere la conferma dell’utente; procediamo ora all’avvio dei servizi fermati:

net start http
net start w3svc

Dopo aver riavviato i servizi, verifichiamo con netstat che IIS si sia piegato al nostro volere:

netstat -noa | find ":80"

ora l’output del comando netstat è quello “giusto”:

TCP    172.16.1.1:80          0.0.0.0:0              LISTENING       3928

Conclusioni

httpcfg è un’utility che consente di ovviare a quella che è una “curiosa” mancanza della GUI di IIS; una volta che se ne conosce l’esistenza e le modalità d’utilizzo, è abbastanza semplice arrivare al risultato desiderato, ma il sysadmin che si trova per la prima volta di fronte ad un problema simile può perdere anche parecchio tempo prima di risolvere il problema, e ciò secondo me è negativo e soprattutto poco sensato.

Link di riferimento

http://technet.microsoft.com/en-us/library/cc786389%28WS.10%29.aspx

Sniffing del traffico di rete con Cisco ASA 5505

Lorenzo — Tue, 03 Nov 2009 22:00:53 +0000

Panoramica

Può capitare, alle volte, di trovarci nella necessità di dover fare troubleshooting sulla nostra rete in conseguenza di un qualche malfunzionamento (software o hardware che sia); in alcuni casi, può essere estremamente utile “sniffare” il traffico di rete, cioé avere in una qualche forma comprensibile all’essere umano l’insieme (o, più spesso, un sottoinsieme) delle comunicazioni che avvengono sulla rete.

Per sniffare il traffico su una rete locale (o solo su alcuni hosts della stessa), bisogna innanzitutto avere uno switch che consenta tale attività (cioé uno switch managed), quindi utilizzare un software che consenta l’attività di sniffing vera e propria: il più famoso di questi è senza dubbio Wireshark.

Può succedere però che si debba verificare se il traffico transita o meno sul nostro firewall; in tal caso, è necessario che l’operazione di sniffing avvenga direttamente sul firewall, e a meno che il firewall non sia una macchina Windows o Linux, non è possibile utilizzare Wireshark o tcpdump. Se il firewall è un Cisco ASA, è possibile utilizzare IOS per poter sniffare il traffico, oppure è possibile utilizzare ASDM (ovvero l’interfaccia web di amministrazione), che non ho la più pallida idea di come funzioni; in genere sui firewall Cisco si utilizza la riga di comando.

Sniffing del traffico

Per i miei test su questa funzionalità dell’ASA, ho ripreso l’ambiente di test descritto nel precedente articolo riguardante la VPN IPSEC tra due ASA 5505.

Come prima prova, effettuerò lo sniffing del traffico ICMP dal client su LAN1 al firewall ASA-1. Per farlo dovrò utilizzare il comando capture di IOS; sia questo comando, sia i successivi, vengono eseguiti in privileged mode:

capture traffic_asa1_inside interface inside

dove capture indica il comando da utilizzare per istruire l’ASA sulla cattura del traffico di rete, traffic_asa1_inside è un nome da dare a piacere che indica la singola operazione di sniffing (serve perché potrei voler utilizzare diversi processi di cattura per diversi scopi), interface inside indica l’interfaccia del firewall sulla quale avviene il monitoraggio del traffico; da notare che dando queste indicazioni, viene catturato tutto il traffico di rete.

Fatto questo, pingo, dal client su LAN1, il firewall ASA-1, quindi dovrò vedere sul dispositivo se la cattura avviene correttamente; a questo scopo, devo digitare il seguente comando sull’ASA (dopo aver pingato il firewall, ovviamente):

show capture traffic_asa1_inside

una parte dell’output del comando sarà simile al seguente:

14: 11:36:14.393961 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request
15: 11:36:14.394190 802.1Q vlan#1 P0 192.168.1.254 > 192.168.1.3: icmp: echo reply
16: 11:36:15.399072 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request
17: 11:36:15.399210 802.1Q vlan#1 P0 192.168.1.254 > 192.168.1.3: icmp: echo reply
18: 11:36:16.412881 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request
19: 11:36:16.413018 802.1Q vlan#1 P0 192.168.1.254 > 192.168.1.3: icmp: echo reply
20: 11:36:17.426812 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request
21: 11:36:17.426949 802.1Q vlan#1 P0 192.168.1.254 > 192.168.1.3: icmp: echo reply

Vorrei porre l’attenzione sul fatto che tutte le righe iniziano con un numero, ma questo numero, nel mio caso, non parte da 1, ma da 14. Questo avviene perché, prima delle mie richieste ICMP, viene loggata l’attività che svolgo sul firewall, in quanto sono loggato allo stesso via SSH, di conseguenza, il comando capture così indicato sniffa tutto il traffico di rete, rendendo più complicata la lettura dell’output restituito. Per ovviare a questo inconveniente, devo limitare il traffico catturato, interrompendo prima di tutto lo sniffing del traffico, con il comando:

no capture traffic_asa1_inside

in questo modo al firewall viene indicato di interrompere la cattura del traffico. Per poter limitare lo sniffing dei pacchetti di rete a determinati protocolli, è necessario utilizzare delle access-list che indichino il tipo di traffico da monitorare, per poi essere utilizzate col comando capture, come mostrato di seguito:

configure terminal
access-list test_icmp extended permit icmp any interface inside
exit
capture icmp_asa1_inside access-list test_icmp interface inside

le righe che ci interessano sono la 2 e la 4 (se il significato delle altre due righe non è conosciuto, consultare il precedente articolo riguardante la configurazione di base di un Cisco ASA), in particolare, la riga 2 rappresenta il comando per creare la access list chiamata test_icmp che consente il traffico ICMP tra la rete locale e l’ASA, mentre la riga 4 è la ripetizione del comando capture, con in più l’indicazione di monitorare esclusivamente il traffico consentito dall’access list test_icmp. Se dal mio PC vado a pingare il firewall ASA-1, posso poi dare il comando show capture per verificare il traffico ICMP sull’interfaccia inside:

show capture icmp_asa1_inside

il cui output è questo:

1: 12:41:30.148582 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request
2: 12:41:31.151572 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request
3: 12:41:32.154365 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request
4: 12:41:33.155280 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request

In questo caso vedo solamente le richieste ICMP e non le relative risposte, ciò dipende dall’impostazione che ho dato precendentemente all’access-list; se voglio vedere anche le risposte alle richieste ICMP, modificherò l’access-list in questo modo:

configure terminal
access-list test_icmp extended permit icmp 192.168.1.0 255.255.255.0 192.168.1.0 255.255.255.0
no access-list test_icmp extended permit icmp any interface inside
exit

Per testare il funzionamento dello sniffing basato sulla access-list cambiata, è meglio pulire tutti i risultati della cattura raccolti fino ad ora:

clear capture icmp_asa1_inside

ora, se pingo il firewall e digito di nuovo il comando show capture mostrato in precedenza, avrò questo output:

1: 12:48:34.685541 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request
2: 12:48:34.685770 802.1Q vlan#1 P0 192.168.1.254 > 192.168.1.3: icmp: echo reply
3: 12:48:35.687037 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request
4: 12:48:35.687220 802.1Q vlan#1 P0 192.168.1.254 > 192.168.1.3: icmp: echo reply
5: 12:48:36.688593 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request
6: 12:48:36.688730 802.1Q vlan#1 P0 192.168.1.254 > 192.168.1.3: icmp: echo reply
7: 12:48:37.690989 802.1Q vlan#1 P0 192.168.1.3 > 192.168.1.254: icmp: echo request
8: 12:48:37.691141 802.1Q vlan#1 P0 192.168.1.254 > 192.168.1.3: icmp: echo reply

In questo caso è decisamente semplice interpretare l’output mostrato dal firewall Cisco, ma se mi trovo a dover sniffare il traffico di diversi protocolli su un link di rete piuttosto trafficato, potrei trovarmi in difficoltà nel capire ciò che avviene. In tal caso, il Cisco ASA ci viene incontro con una simpaticissima funzionalità, che consiste nel poter scaricare un file rappresentante la cattura del traffico visualizzabile con Wireshark. Per poter sfruttare questa funzionalità, è necessario avere il server web abilitato; nel caso non lo fosse, bisogna indicare questi comandi:

configure terminal
http server enable
http 192.168.1.0 255.255.255.0 inside
exit

dove la riga 2 rappresenta il comando per abilitare il server web (che rimane in ascolto in modo predefinito in modalità https), mentre la riga 3 indica gli host che possono connettersi via https al firewall e su quale interfaccia, nel nostro caso, gli hosts della rete 192.168.1.0/24 sull’interfaccia inside.

Ora possiamo connetterci tramite un browser all’indirizzo

https://192.168.1.254/capture/icmp_asa1_inside/pcap

dove al posto di icmp_asa1_inside andremo a mettere il nome che abbiamo assegnato alla cattura del traffico tramite il comando capture. Essendo la connessione di tipo https, verrà segnalata l’inaffidabilità del certificato, possiamo proseguire ignorando tranquillamente la segnalazione, dopodiché ci verranno richiesti nome utente e password, ed a quel punto bisogna inserire la password per entrare in privileged mode, senza indicare il nome utente; fatti questi passaggi, ci verrà richiesto di salvare il file pcap, a cui daremo un nome a scelta con estensione .pcap, visualizzabile direttamente con Wireshark. Nei miei test (decisamente poco esaustivi), ho notato come Wireshark mi apra perfettamente i file generati dall’ASA, escludendo però l’ultima riga e restituendo questo errore all’apertura del file .pcap: “The capture file appears to have been cut short in the middle of a packet”; questo errorino comunque non pregiudica una corretta visualizzazione del traffico sniffato.

Conclusioni

La funzionalità di sniffing integrata nel Cisco ASA può risultare molto utile quando si tratta di effettuare troubleshooting su determinate connessioni di rete. In questo articolo ho fatto alcuni test connettendomi al firewall via SSH, ma nel mondo reale, secondo me è caldamente raccomandabile sniffare il traffico connettendosi all’ASA direttamente in console, questo per evitare che eventuali comunicazioni di rete tra il proprio host e il firewall si vadano a sovrapporre al traffico vero e proprio che si vuole monitorare.

Link di riferimento

http://www.cisco.com/en/US/products/ps6120/products_tech_note09186a00807c35e7.shtml

VPN Site to Site IPSEC con Cisco ASA 5505

Lorenzo — Mon, 24 Aug 2009 21:29:20 +0000

Scenario

Si prenda in esame un’azienda con due sedi distinte e ad una certa distanza tra loro.

In questo caso, potrebbe non essere conveniente fare una connessione dedicata tra le due sedi aziendali, per cui, è possibile sfruttare la rete Internet per interconnettere le due sedi tra di loro; in tale situazione, si pongono ovvi problemi di sicurezza, poiché i dati transitano su una rete pubblica, e sono quindi tranquillamente sniffabili da chiunque sia un po’ troppo “curioso”. Per ovviare a questi problemi, è necessario criptare il traffico di rete fra le due sedi aziendali, anche se questo comporta un leggero calo delle prestazioni: tutte queste caratteristiche sono comprese in un tipo di connessione chiamato VPN (Virtual Private Network), che, come dice il nome, stabilisce un canale privato virtuale (tunnel) sulla rete pubblica (Internet).

Una VPN può essere di diversi tipi, in questa situazione, dovendo interconnettere tra loro due intere reti LAN distinte tra di loro, la VPN prende il nome di “site to site”; inoltre, una VPN può essere realizzata con diversi protocolli, in questo caso, utilizzeremo il protocollo IPSEC con due firewall Cisco ASA 5505 in un ambiente di test.

Ambiente di test

Per simulare la situazione prospettata nello scenario, ho creato un piccolo ambiente di test con due firewall Cisco ASA 5505, in cui, nella parte LAN, è collegato un notebook su entrambi i lati per simulare le due reti LAN (rispettivamente, LAN1 – 192.168.1.0/24 e LAN2 – 192.168.2.0/24), mentre la rete Internet è simulata utilizzando uno switch HP 1700-8, a cui sono collegate le due interfacce WAN (WAN1 – 172.16.3.1/24 e WAN2 – 172.16.3.2) del firewall. I due firewall prendono il nome rispettivamente di ASA-1 e ASA-2. Queste connessioni sono mostrate nello schema di rete in Figura 1.

Figura 1 - Ambiente di test per VPN IPSEC con Cisco ASA 5505

Cenni teorici su VPN IPSEC su Cisco ASA5505

Una connessione VPN IPSEC viene instaurata tra due apparati che supportano questo tipo di VPN in cinque passaggi. Il primo passaggio, consiste nel transito di “traffico interessante” tra i due firewall Cisco, dove per traffico interessante si intende quel tipo di traffico che deve essere protetto tramite IPSEC. A questo punto, avviene una negoziazione dei due apparati Cisco, i quali, a negoziazione avvenuta, instaurano una security association (SA) tra i due lati della VPN, utilizzando il protocollo IKE (chiamato anche ISAKMP).

La negoziazione di una SA avviene in due fasi (passaggio due e tre), Phase 1 e Phase 2: la Phase 1 stabilisce un primo tunnel che protegge i successivi messaggi di negoziazione ISAKMP, mentre la Phase 2 stabilisce il secondo tunnel che si occupa della cifratura vera e propria dei dati. Durante la Phase 2 bisogna specificare un transform set, cioè il livello di protezione richiesto per la sessione IPSEC, il quale combina un metodo di protezione ed un metodo di autenticazione; è importante che i parametri impostati con un transform set siano gli stessi su entrambi gli apparati responsabili della comunicazione sicura tra le due reti.

Quando si vuole stabilire una negoziazione ISAKMP tra due firewall, bisogna configurare su ogni dispositivo una policy ISAKMP, cioè un insieme di impostazioni che indicano come instaurare una SA; in particolare, una policy ISAKMP è composta da:

un metodo di autenticazione, che serve per identificare l’identità dei peer; l’autenticazione può avvenire tramite preshared key (una sorta di password) oppure con l’utilizzo di certificati;
un metodo di cifratura dei dati, usato per cifrare i dati in transito nel tunnel VPN;
un algoritmo di hash usato per assicurare l’integrità dei dati;
un tipo di gruppo Diffie-Hellman, che serve per scambiarsi in sicurezza la chiave segreta condivisa su un canale insicuro;
un limite di tempo oltre il quale la SA deve essere ristabilita (un timeout, in parole povere), che prende il nome lifetime.

Ogni firewall invia le proprie policy ISAKMP all’altro firewall, e se le policy sono le stesse su entrambi i dispositivi, allora viene stabilita la SA, anche se per avere una connessione VPN funzionante sono necessari altri passaggi, come vedremo tra poco.

Instaurata una SA, su entrambi gli apparati deve essere presente una access list (ACL) che consenta il transito del traffico interessante che dalla rete LAN1 va verso la rete LAN2 e viceversa, sfruttando il canale instaurato tramite la VPN. Definita la ACL, deve essere presente anche una mappa (chiamata crypto map) che assembla i seguenti elementi della SA instaurata con i passaggi precedenti:

quale traffico deve essere protetto con IPSEC (traffico interessante), definito dalla ACL di cui sopra;
l’indirizzo IP pubblico dell’altro lato della VPN al quale inviare il traffico tramite IPSEC (peer);
quale tipo di sicurezza IPSEC è richiesto per questo traffico, definito dal transform set specificato precedentemente;
a quale interfaccia dell’ASA va applicata la mappa.

Infine va definito un tunnel group su ognuno dei due apparati, dove per una connessione VPN Site to Site può essere sufficiente specificare il tipo di connessione (Lan to Lan) e il metodo di autenticazione.

Definiti questi parametri, e ammesso che tutto funzioni, le due reti sono connesse tra di loro a livello IP, per cui ogni protocollo che si poggia su IP può transitare tramite il tunnel e quindi viaggiare da una rete all’altra, posto che sia configurato il corretto instradamento sugli host di ogni rete.

Configurazione degli apparati

La configurazione dei parametri TCP/IP di base dei due apparati, secondo lo schema di Figura 1, è stata effettuata secondo le indicazioni fornite in un precedente articolo, per cui la diamo per scontata.

Come descritto in precedenza, per configurare la VPN IPSEC su ognuno dei due ASA bisogna impostare una ACL per consentire il traffico tra le due LAN, una policy ISAKMP, un transform set, una mappa crypto map e un tunnel group; la configurazione va effettuata su entrambi gli apparati perché il peer VPN IPSEC è unidirezionale.

Per prima cosa, impostiamo la ACL per il traffico IPSEC, in modo da abilitare il transito dalla rete LAN1 alla rete LAN2, e viceversa:

ASA-1

access-list lantolan extended permit ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0

ASA-2

access-list lantolan extended permit ip 192.168.2.0 255.255.255.0 192.168.1.0 255.255.255.0

Ora configuriamo il transform set, in cui andremo ad impostare un transform set che avrà come metodo di protezione la crittografia AES 128 bit, e come metodo di autenticazione esp-sha-hmac:

ASA-1

crypto ipsec transform-set VPNTest esp-aes esp-sha-hmac

ASA-2

crypto ipsec transform-set VPNTest esp-aes esp-sha-hmac

dove VPNTest è il nome dato arbitrariamente al transform set, esp-aes è il metodo di protezione e esp-sha-hmac è il metodo di autenticazione.

Adesso bisogna configurare la crypto map, secondo questa sintassi:

ASA-1

crypto map vpnTest 1 match address lantolan
crypto map vpnTest 1 set peer 172.16.3.2
crypto map vpnTest 1 set transform-set VPNTest
crypto map vpnTest interface outside

ASA-2

crypto map vpnTest 1 match address lantolan
crypto map vpnTest 1 set peer 172.16.3.1
crypto map vpnTest 1 set transform-set VPNTest
crypto map vpnTest interface outside

La configurazione, ovviamente, è praticamente identica in tutti e due i firewall. In questo caso, vpnTest è il nome assegnato alla mappa, identico per tutte e quattro le righe di configurazione della mappa; nella riga 1, indico qual è il traffico interessante per il mio peer IPSEC, identificato dalla ACL chiamata lantolan configurata in precedenza, nella riga 2 indico l’indirizzo del dispositivo col quale voglio instaurare il peer (nel mondo reale, l’IP pubblico del firewall posto sull’altro lato da collegare tramite VPN), nella riga 3 specifico il nome del transform set indicato in precedenza, in modo da specificare le impostazioni di protezione e autenticazione, ed infine nella riga 4 indico a quale interfaccia applicare la mappa.

Nelle righe da 1 a 3, la mappa vpnTest viene identificata col numero 1, che è un numero chiamato sequence number, utilizzato in caso si debbano applicare più mappe alla stessa interfaccia in presenza di più VPN sullo stesso apparato.

Configurata la mappa, bisogna impostare le policy ISAKMP in questo modo:

ASA-1

crypto isakmp enable outside
crypto isakmp policy 1
authentication pre-share
encryption aes
hash sha
group 2
lifetime 43200

ASA-2

crypto isakmp enable outside
crypto isakmp policy 1
authentication pre-share
encryption aes
hash sha
group 2
lifetime 43200

Com’è evidente, la configurazione è assolutamente identica su tutti e due i firewall, ed a parte l’impostazione del parametro lifetime, che può essere diverso su ognuno dei firewall, tutto deve essere identico su entrambi gli apparati, pena il mancato funzionamento della VPN.

La riga 1 indica l’abilitazione di isakmp sull’interfaccia outside, la riga 2 indica la configurazione dei parametri che compongono una policy isakmp identificata dal numero 1; indicando questo comando, si aprirà una nuova modalità di configurazione che riguarda l’impostazione della policy isakmp indicata, modalità che comporta anche il cambiamento del prompt, che assume una forma del tipo:

ASA-1(config-isakmp-policy)

La riga 3 indica il tipo di autenticazione (in questo caso preshared key, il tipo più semplice di autenticazione), la riga 4 rappresenta il metodo di protezione (crittografia AES), la riga 5 indica l’algoritmo di hash, la riga 6 indica il tipo di gruppo Diffie-Hellman, mentre la riga 7 indica il timeout della connessione IPSEC, trascorso il quale la SA deve essere rinegoziata.

Infine, rimane da configurare il tunnel group in questo modo:

ASA-1

1
2
3

tunnel-group 172.16.3.2 type ipsec-l2l
tunnel-group 172.16.3.2 ipsec-attributes
pre-shared-key ChiaveCondivisa

ASA-2

1
2
3

tunnel-group 172.16.3.1 type ipsec-l2l
tunnel-group 172.16.3.1 ipsec-attributes
pre-shared-key ChiaveCondivisa

La riga 1 indica a quale indirizzo connettersi per instaurare la connessione VPN e il tipo di connessione IPSEC (nel nostro caso l2l che sta per LAN to LAN), la riga 2 indica il comando per specificare gli attributi della connessione IPSEC, che sono indicati dai comandi successivi (anche in questo caso, cambia il prompt), nel nostro caso, l’unico parametro da digitare riguarda la riga 3 che rappresenta la preshared key che consente di autenticarci sull’altro dispositivo. Penso sia ovvio a questo punto che le preshared key indicate nei due firewall debbano essere identiche.

Aggiornamento 25/08/2009

Ho dimenticato di specificare una cosa. Perché i pacchetti transitino tra una rete e l’altra, se è applicato il natting sul firewall (come accade molto spesso, visto che in genere questi firewall non si occupano solo di fare da endpoint per la VPN), è necessario che il traffico interessante non venga nattato. Per evitare questa cosa, è necessario specificare questo comando su entrambi gli ASA:

nat (inside) 0 access-list lantolan

Se tutto è andato bene, è possibile provare a testare la connettività tra i due portatili con il comando ping. Se la VPN funziona, è possibile che il primo pacchetto vada perso a causa del tempo necessario ad instaurare la SA, ma i pacchetti successivi dovrebbero arrivare correttamente; inoltre, in caso di VPN correttamente funzionante, dovrebbe accendersi il led VPN posto in posizione frontale sull’ASA 5505.

Troubleshooting di base sulle connessioni VPN IPSEC

In caso di mancato funzionamento, è possibile effettuare un po’ di troubleshooting cercando di capire per quale motivo la VPN non funziona; in questi casi, può essere utile digitare i due comandi indicati di seguito:

debug crypto ipsec
debug crypto isakmp

Con questi due comandi, in caso di problemi compaiono un sacco di messaggi sullo schermo, sta a noi isolare quei messaggi che possono realmente aiutarci a capire che sta avvenendo. Quando i messaggi diventano troppi (ed in genere succede presto), è possibile interrompere il logging a video coi comandi

no debug crypto ipsec
no debug crypto isakmp

oppure, più semplicemente, col comando

no debug all

Tenere presente che, se ci sono dei problemi, spesso accade che le policy isakmp non sono identiche su entrambi i firewall.

Può anche accadere che la configurazione dei due ASA sia corretta ma che il traffico non arrivi a destinazione, in questi casi bisogna verificare che l’instradamento dei pacchetti verso l’altra rete avvenga correttamente, impostando il corretto router negli host della rete locale oppure utilizzando le opportune route statiche.

Link di riferimento

https://www.cisco.com/web/learning/le31/le46/cln/qlm/CCNP/iscw/Site-to-Site-IPsec-VPN-Operation_3/player.html

http://www.openskill.info/infobox.php?ID=806

http://www.assint.org/content/view/71/44/

L’importanza di essere prudenti

Lorenzo — Sun, 23 Aug 2009 21:02:27 +0000

Ho appena terminato di (ri)leggere Contact di Carl Sagan, un grandioso (secondo me) libro di fantascienza, in cui sintentizzando brutalmente, si narra del “contatto”, sotto forma di un “Messaggio” proveniente da Vega, della civiltà terrestre con una civiltà extraterrestre, che si rivelerà estremamente più progedita delle nostra; durante questo contatto, i Cinque che hanno il privilegio di “colloquiare” con la cività extraterrestre, vengono a conoscenza di un ulteriore Messaggio contenuto all’interno dei decimali del pi greco e di altri numeri trascendenti (e ciò mi fa rimpiangere di aver dimenticato in modo pressoché completo tutta la matematica studiata alle superiori), cosa che fa pensare ad un intervento “divino” nella creazione celato in una cosa fondamentale come la matematica. La protagonista principale, Eleanor Arroway, riesce infine a scoprire dove si cela il messaggio, scoprendo una prova tangibile, a differenza di qualsiasi testo sacro di una qualsiasi religione, dell’esistenza del Creatore dell’Universo.

Tra le varie cose che mi hanno colpito in questo libro, vi è il personaggio di Sol Hadden, il quale è un geniale “inventore”, che si pone e cerca di risolvere il problema dell’immortalità, prima creando una sorta di “hotel spaziale”, poiché si presuppone che a gravità zero si possa vivere più a lungo, quindi, decide di fare un viaggio interplanetario facendo “catapultare” la propria astronave da Giove fino ad attraversare, con gli anni, vari sistemi solari, proseguendo il proprio viaggio ibernato (anche grazie al fatto che nelle profondità dello spazio la temperatura è di poco superiore allo zero assoluto) e aspettando di essere “scongelato” da una civiltà extraterrestre sufficientemente evoluta. Inizialmente Hadden aveva pensato di farsi catapultare dall’orbita di Saturno, ma mentre Giove poteva essere raggiunto in due anni, Saturno avrebbe richiesto quattro anni di viaggio, perché, “se si sta inseguendo l’immortalità, bisogna stare molto attenti”.

Questo accenno alla prudenza come strategia primaria per vivere a lungo, mi ha fatto tornare in mente Lazarus Long, l’affascinante personaggio descritto da Robert Heinlein (del quale ho ancora letto poco, in verità), grande autore della golden age della fantascienza americana. Anche Lazarus Long era una persona prudente, anche se sapeva correre dei rischi quando ne valeva la pena, e ciò gli ha consentito, oltre alle proprie peculiarità genetiche, di vivere per millenni. L’analogia della necessità della prudenza, che è una cosa allo stesso tempo frutto di un intelligente ragionamento e di un ancestrale senso pratico, mi ha fatto venire voglia di mettermi a leggere qualcosa di nuovo di Heinlein.

Abilitare upload di file con FCKEditor su Drupal

Lorenzo — Fri, 21 Aug 2009 20:57:10 +0000

Nell’articolo precedente, avevo scritto relativamente all’installazione del modulo Wysiwyg per poter integrare degli editor visuali per inserire contenuti sul CMS Drupal. In particolare, la mia attenzione si è focalizzata sull’editor FCKEditor, che avevo già usato in precedenza e col quale mi ero trovato bene.

Abilitando il modulo e quindi l’editor, si ha una buona integrazione dell’editor con il CMS, si ha però un problema, che consiste nell’impossibilità di effettuare l’upload di file e immagini con FCKEditor, poiché nell’inserimento di link e immagini non compaiono proprio pulsanti e schede per caricare i file.

Il problema è dovuto ad un misto di parametri da sistemare sia su FCKEditor, sia Wysiwyg. Per prima cosa, sistemiamo le impostazioni di FCKEditor, andando ad editare il file /root-del-sito/sites/all/libraries/fckeditor/editor/filemanager/connectors/php/config.php, dove le seguenti tre righe dovranno avere questo contenuto:

$Config['Enabled'] = true ;
$Config['UserFilesPath'] = '/sites/default/files/' ;
$Config['UserFilesAbsolutePath'] = '/percorso/assoluto/del/sito/sites/default/files/' ;

In particolare è importante la terza riga, in cui il contenuto non va lasciato vuoto, salvo ottenere un messaggio di errore quando si tenta di effettuare l’upload come indicato qui; in questa riga, va inserito il percorso assoluto della directory scelta per ospitare i file caricati dagli utenti, stessa cosa per la seconda riga dove però va inserito il percorso relativo e non quello assoluto. Dopo aver salvato il file config.php, mi ero aspettato che l’upload di file funzionasse… ma non è così.

Per abilitare il caricamento di file sul nostro sito gestito con Drupal, bisogna abilitare l’upload anche nelle impostazioni di FCKEditor memorizzate nel file di configurazione specifico per il modulo Wysiwyg; editare quindi il file /root-del-sito/modules/wysiwyg/editors/fckeditor.inc e impostare in questo modo le seguenti righe (che dovrebbero comparire poco dopo la riga 100):

'LinkBrowser' => TRUE,
'LinkUpload' => TRUE,
'ImageBrowser' => TRUE,
'ImageUpload' => TRUE,
'FlashBrowser' => TRUE,
'FlashUpload' => TRUE,

Io, a dire il vero, ho lasciato le impostazioni relative a Flash a FALSE, poiché non c’è pericolo che utilizzi animazioni Flash…

Dopo aver salvato il file (e magari svuotato la cache del browser per sicurezza), è possibile testare la corretta configurazione del modulo provando ad inserire un contenuto al cui interno caricare un file, e verificare se l’upload di file e immagini funziona.

Link di riferimento

Wysiwyg and fckeditor - problems with image upload and browse server

Installare il modulo Wysiwyg su Drupal

Lorenzo — Thu, 20 Aug 2009 18:00:31 +0000

Sto continuando a giocare con Drupal, in particolare, per creare contenuti, esiste solo un editor di testi assolutamente spartano, che si riduce ad una semplice casella di testo (textarea) in cui inserire il testo del nostro contenuto. Se vogliamo utilizzare con Drupal un editor visuale più o meno evoluto, è possibile installare un modulo ad hoc, Wysiwyg, che consente di poter scaricare ed installare diversi editor visuali da integrare in Drupal.

L’installazione è molto semplice, basta installare il pacchetto dalla pagina dedicata a Wysiwyg, quindi va scompattato nella directory modules, assicurandoci che il contenuto vada a finire nella cartella wysiwyg. Se si ha a disposizione sul server web una shell Linux, basta posizionarci nella directory modules dell’installazione di Drupal e digitare i seguenti comandi:

wget http://ftp.drupal.org/files/projects/wysiwyg-6.x-2.0.tar.gz
tar -xzf wysiwyg-6.x-2.0.tar.gz

dove al posto di wysiwyg-6.x-2.0.tar.gz va indicata la versione corrente del pacchetto (che è quella indicata sopra al momento della stesura dell’articolo).

Scompattato il file, andare sul pannello di amministrazione di Drupal alla voce Amministra, Configurazione del sito, Wysiwyg, dopodiché scorrere l’elenco e scegliere l’editor visuale preferito tra quelli elencati, che sono, ovviamente, tutti supportati, quindi cliccare sul link Download a fianco del nome dell’editor e scaricare il relativo pacchetto compresso, nel mio caso FCKEditor, e scompattarlo all’interno della directory sites/all/libraries (se non esiste, va creata), avendo cura di controllare che la directory creata che contiene i file scompattati, abbia il nome corretto dell’editor senza numeri di versione (nel mio caso, fckeditor), come indicato chiaramente nelle istruzioni di installazione di Wysiwyg; avendo a disposizione la shell, posizionarsi all’interno della directory sites/all/libraries e digitare:

wget http://downloads.sourceforge.net/project/fckeditor/FCKeditor/2.6.4.1/FCKeditor_2.6.4.1.tar.gz
tar -xzf FCKeditor_2.6.4.1.tar.gz

Fatto ciò, tornare su Drupal, sempre nella pagina del modulo Wysiwyg, quindi selezionare l’editor appena installato sia per il formato input Full HTML che Filtered HTML, salvare le modifiche e verificare che l’editor funzioni correttamente. Eventualmente, tornare nella pagina di Wysiwyg e, tramite i link Modifica a fianco di Full HTML e Filtered HTML, modificare le impostazioni dell’editor predefinito.

Installare la traduzione italiana su Drupal

Lorenzo — Wed, 19 Aug 2009 14:33:35 +0000

Ieri ho cominciato a giocare un po’ con Drupal, un noto CMS open source, quindi, dopo averlo installato seguendo le indicazioni dell’esaustiva documentazione a riguardo, mi sono trovato di fronte al problema della lingua, poiché avevo installato Drupal in inglese, mentre avrei gradito avere l’area amministrativa ed il sito in lingua italiana.

Per raggiungere lo scopo, dopo aver installato Drupal (tenere presente che è possibile installare la traduzione italiana durante l’installazione di Drupal, io ho preferito farlo dopo l’installazione), bisogna abilitare il modulo Locale, andando, nell’interfaccia di amministrazione, sul menu di sinistra alla voce Administer, Site Building, Modules, quindi, spuntare la voce Locale e cliccare su Save configuration per salvare le modifiche.

A questo punto, è possibile scaricare due tipi di traduzioni, io ho scelto di scaricare il file monolitico con la traduzione in italiano chiamato drupal-all-it.po dal sito di Drupalitalia.org invece della traduzione “completa”, suddivisa in più directory e file; scaricato il file, andare, tramite il menu sulla sinistra, alla voce Administer, Site building, Translate interface, poi, su questa pagina, cliccare sul menu in alto la voce Import, si aprirà una pagina in cui si trova il campo Language file, dove vado a selezionare il file drupal-all-it.po scaricato precedentemente, ed il campo Import into, dove selezionare la lingua corrispondente al pacchetto di traduzione (nel mio caso, Italian), e poi cliccare sul pulsante Import, che importerà il file drupal-all-it.po ed aggiungerà la lingua italiana a Drupal.

Giunti qui, andare, tramite il menu di navigazione del pannello di amministrazione, sulla voce Administer, Site configuration, Languages, dove si trovano le due lingue installate, cioè English e Italian, selezionare la casella Default in corrispondenza della riga Italian e quindi cliccare su Save configuration; il nostro sito comparirà tradotto in italiano sia nel pannello di amministrazione, sia nel sito vero e proprio.

Non vengono sincronizzati i nuovi messaggi di posta con Exchange ActiveSync

Lorenzo — Thu, 23 Jul 2009 16:35:40 +0000

Scenario

Su una rete con un dominio Microsoft Windows Server 2003, con un’organizzazione Exchange Server 2003, è stato abilitato il Push Direct per la sincronizzazione di un dispositivo mobile (PDA, Smartphone, ecc…) tramite Exchange ActiveSync. Nella situazione che ho affrontato, il client ActiveSync è un Nokia N73 con installato MailForExchange, anche se in questa situazione il client utilizzato non ha nessuna importanza.

Problema

Lo scenario sopra riportato, funziona perfettamente, tranne che per un piccolissimo dettaglio: le mail nuove, non ancora lette, non vengono sincronizzate con il client, ovvero, Nokia MailForExchange non sincronizza i messaggi fino a quando questi non sono letti in un altro modo, cioé tramite Outlook oppure OWA; dal punto di vista dell’utente non è molto comodo. La configurazione di Exchange e di MailForExchange è stata rivista e rivoltata fino allo sfinimento, senza trovare una soluzione funzionante, anche perché, alla fine, non era lì il problema…

Soluzione

Non essendoci problemi nella configurazione, rimane qualcosa di esterno alle applicazioni utilizzate; infatti, una volta disabilitato Trend Micro ScanMail for Exchange, la sincronizzazione dei messaggi funziona in tutte le situazioni, sia con i vecchi che con i nuovi messaggi. Una volta individuato il responsabile, bisogna metterlo in condizione di non nuocere, ma a quel punto, la ricerca della soluzione al problema diventa abbastanza semplice; grazie a Google, ho potuto verificare che il problema consiste nell’aggiornamento di Trend Micro ScanMail for Exchange dalla versione 7 alla versione 8, il quale lascia una voce di registro chiamata VirusScanProactiveScanning in queste chiavi (i numeri dopo Private- e Public- sono puramente indicativi):

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\\Private-3484c833-f074-4793-97a0-0bbbcdbb7c75

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\\Public-a785d57d-8a08-44ce-86c4-04bfea4691e5

per eliminare il problema basta cancellare la voce di registro incriminata e riavviare i servizi di ScanMail, a questo punto, il problema è risolto e possiamo goderci la nostra mail push sul telefonino.

Link di riferimento

http://social.technet.microsoft.com/Forums/en-US/exchangesvrmobility/thread/f37095ac-3e52-474e-9467-46872242469e

Configurare indirizzo IP e porte d’ascolto di Apache

Lorenzo — Tue, 21 Jul 2009 20:27:33 +0000

Lo appunto qui così non mi dimentico.

E’ possibile configurare Apache 2 sotto Debian Lenny per fare rimanere il web server in ascolto su determinate porte e su determinati indirizzi IP, tramite la direttiva Listen. Questa direttiva (o più direttive Listen), in Debian è presente nel file di configurazione /etc/apache2/ports.conf, che viene richiamato tramite una direttiva include dal file principale di configurazione di Apache, /etc/apache2/apache2.conf.

Ad esempio, avendo un server web Debian Lenny con Apache 2, con due indirizzi IP come indicato di seguito:

IP1: 192.168.1.1
IP2: 5.6.7.8

se voglio che il server rimanga in ascolto su tutti e due gli indirizzi sulla porta 80, mi basta lasciare la direttiva predefinita indicata come di seguito:

Listen 80

la quale indica che Apache rimane in ascolto su tutte le interfacce di rete sulla porta 80. Se invece desidero che Apache rimanga in ascolto solamente sull’IP2 sulla porta 80, il contenuto del file ports.conf sarà il seguente:

Listen 5.6.7.8:80

Se invece ho l’esigenza di avere Apache in ascolto su entrambi gli indirizzi IP, ma su porte diverse, il file ports.conf si presenterà così:

Listen 192.168.1.1:80
Listen 5.6.7.8:8080

Dopo ogni modifica al file ports.conf, devo far ripartire Apache con il comando

/etc/init.d/apache2 restart

per applicare le modifiche effettuate.

Similitudini ardite

Lorenzo — Wed, 17 Jun 2009 21:18:21 +0000

Alcuni giorni fa, ho finito di rileggere per l’ennesima volta Dune (attenzione, contiene la trama del libro), in cui, in un passaggio del libro, Paul Muad’Dib - Usul, risvegliatosi dal coma dopo aver bevuto l’Acqua della Vita, pretende dalla madre Jessica di poter vedere quel luogo interiore dove le Reverende Madri non possono accedere, e la cui visione è consentita solamente allo Kwisatz Haderach, quale è Paul. Dopo aver giocoforza “condotto” Paul in quel luogo, Jessica spaventata si ritira e le Reverende Madri (o meglio, la loro memoria presente in Jessica) che l’hanno preceduta, sconvolte, si chiedono: “Che cosa è stato? Che cosa è accaduto?“.

Questo passaggio mi è venuto in mente ieri, quando ho appreso che, a causa di un intervento maldestro di un sedicente tecnico, il quale, montando un server in un armadio rack ed un UPS, ha collegato l’UPS a valle di un altro UPS preesistente, che, sottoposto a carico troppo elevato, ha fatto il botto, per cui, tra le altre cose, si è spento un server VMWare ESXi con installate quattro macchine virtuali.

Al riavvio del server, si trattava di far partire le macchine virtuali, ed è stato lì che ho pensato che le quattro macchine virtuali, una volta avviate potessero dire: “Che cosa è stato? Che cosa è accaduto?“.

Ho bisogno di ferie.

Ricerche IT secondo classificato a Miglior Blog Tecnico

Lorenzo — Tue, 16 Jun 2009 21:19:23 +0000

Dopo lungo silenzio, dovuto a diversi impegni, ritorno a scrivere sul blog nel segno della più sfrenata autoreferenzialità, per segnalare che ieri sono stati proclamati i vincitori della competizione Miglior Blog Tecnico, ed ho appreso, con somma sorpresa, di essere arrivato secondo nella valutazione della giuria! Gli altri classificati sono Levysoft di Antonio Troise, che ha vinto la competizione, e Google Analytics in 30 secondi di Marco Cilia, che si è classificato al terzo posto, a cui faccio i miei complimenti!

Per me è un risultato assolutamente inaspettato, che penso sia arrivato soprattutto per l’originalità dei contenuti che ho voluto proporre, come era indicato chiaramente nei criteri di valutazione della competizione, così come penso sia stato per gli altri blog primi classificati.

Devo anche dire che tempo fa, avevo dato un’occhiata ad alcuni blog che si erano iscritti alla competizione, e purtroppo alcuni di questi, secondo me molto validi, non hanno indicato i post in competizione, ed è un peccato perché penso avrebbero potuto insidiare le prime posizioni.

Un po’ a me dispiace non avere qualche dettaglio in più sulle valutazioni espresse, soprattutto per capire, per ciò che mi riguarda, cosa è piaciuto di più e cosa meno dei post oggetto di valutazione, ma posso comprendere la scelta della giuria, che si troverebbe probabilmente a dover rispondere ad una marea di domande, e forse ad esporsi a qualche polemica, di cui immagino i giurati non sentano proprio il bisogno.

Da quanto ho letto, sembra si terrà prossimamente un’altra edizione della competizione, che a me sembra molto utile per far emergere blog “piccoli” e meno piccoli che propongono contenuti molto interessanti anche se un po’ di nicchia.

Alla prossima edizione!

Gestire alias e domini virtuali con Postfix

Lorenzo — Sun, 25 Jan 2009 14:16:58 +0000

Panoramica

Nel precedente articolo riguardante la posta elettronica su Linux (le cui avvertenze valgono anche per il presente post), è stato creato un mail server in grado di gestire un unico dominio di posta. Accade però piuttosto spesso di dover gestire più domini di posta, per cui, o si installa un mail server per ogni dominio (cosa che avrebbe un senso solo in caso di alto traffico), oppure, si fanno convivere sullo stesso server di posta più domini, che in caso di realtà medio-piccole è la soluzione ideale. Un’altra casistica non contemplata nel precedente articolo riguarda le liste di distribuzione, cioé la possibilità di avere un indirizzo di posta che recapiti il messaggio ricevuto su più caselle postali. Per questi test faremo riferimento all’ambiente di test descritto in precedenza, dove verrà utilizzato il mail server di test Titano, il quale gestisce il dominio urano.mail; tenere presente che dobbiamo creare le zone DNS relative ai domini virtuali utilizzati nel server DNS Windows Server 2003 DCServer.

Alias e domini virtuali

Per poter gestire la posta di più domini, è necessario definire, oltre al già citato urano.mail (indicato nella direttiva mydestination del file di configurazione /etc/postfix/postfix.conf) che sarà il dominio locale, anche i cosidetti domini virtuali, che corrispondono ai domini che dovremo gestire. A questo punto, è utile distinguere i domini locali dai domini virtuali: nel nostro caso, abbiamo un dominio locale, urano.mail, in cui, ad ogni utente creato sul sistema, corrisponde una casella di posta elettronica; in questo contesto, l’utilizzo di un dominio virtuale, ci consente di definire degli indirizzi di posta con dominio diverso da quello locale, che vengono mappati su una casella di posta elettronica del dominio locale, e che vengono quindi definiti alias virtuali.

Supponiamo, ad esempio, che il nostro mail server debba gestire i domini virtuali miranda.mail, ariel.mail e umbriel.mail; per farlo, dovremo dire a Postfix che intendiamo agire da server SMTP anche per questi domini, come mostrato di seguito:

virtual_alias_domains = miranda.mail ariel.mail umbriel.mail

Ora, dobbiamo inserire nel file di configurazione di Postfix (main.cf) il percorso del file in cui è contenuta la mappa con gli alias virtuali, in cui, ad una casella di posta locale, corrispondono uno o più indirizzi appartenenti ai domini virtuali definiti poc’anzi:

virtual_alias_maps = hash:/etc/postfix/virtual

Definito il file della mappa degli alias virtuali, dobbiamo creare il file stesso ed editarlo:

touch /etc/postfix/virtual
nano /etc/postfix/virtual

Il file va creato seguendo uno stile preciso, come mostrato di seguito:

h.mallow@miranda.mail       hober.mallow@urano.mail
s.hardin@ariel.mail         salvor.hardin@urano.mail
p.palver@umbriel.mail       preem.palver@urano.mail
s.gendibal@umbriel.mail     stor.gendibal@urano.mail

Come si può vedere, nella colonna sinistra del file mettiamo gli alias virtuali, mentre nella colonna di destra, indichiamo a quale utente di sistema va recapitata la posta indirizzata a quello specifico alias virtuale. Ora dobbiamo creare la mappa vera e propria, tramite la “compilazione” in formato binario del file /etc/postfix/virtual, con il comando postmap:

postmap /etc/postfix/virtual

che creerà il file /etc/postfix/virtual.db che sarà quello effettivamente usato da Postfix per l’interrogazione degli alias virtuali.

Così facendo, se spediamo ad esempio una mail a s.hardin@ariel.mail, questa verrà depositata fisicamente nella casella di posta salvor.hardin@urano.mail; ciò in alcune situazioni può andare bene, ma in altre situazioni, questo stato di cose potrebbe non andarci a genio, come in quei casi in cui vogliamo che le caselle di posta dei domini virtuali siano trattate come mailbox a sé stanti, e non legate agli utenti di sistema. Postfix permette di gestire anche queste casistiche, tramite le mailbox virtuali, che verranno esaminate in un articolo successivo.

Liste di distribuzione tramite alias virtuali

Tramite gli alias virtuali è possibile creare anche liste di distribuzione, ovvero indirizzi di posta elettronica virtuali che servono per reindirizzare i messaggi ricevuti dall’alias virtuale stesso agli indirizzi di posta specificati come destinatari del messaggio.

Vediamo un esempio: aggiungiamo una riga al file /etc/postfix/virtual come mostrato di seguito:

oratori@umbriel.mail        p.palver@umbriel.mail, s.gendibal@umbriel.mail

Come già specificato, sulla sinistra compare l’alias virtuale, sulla destra compaiono gli indirizzi di posta a cui vogliamo reindirizzare i messaggi ricevuti sull’indirizzo oratori@umbriel.mail; da notare che i diversi indirizzi devono essere separati da una virgola, e che, in questo caso i membri della lista di distribuzione sono a loro volta alias virtuali, ma potrebbero essere tranquillamente utenti di sistema.

Salvato il file, dobbiamo ricompilare il file /etc/postfix/virtual in questo modo:

postmap /etc/postfix/virtual

Ora possiamo testare il corretto funzionamento della lista di distribuzione, e se tutto va bene, inviando un messaggio all’indirizzo oratori@umbriel.mail, il messaggio arriverà ai due indirizzi p.palver@umbriel.mail e s.gendibal@umbriel.mail, i quali, essendo alias, non hanno una propria casella di posta e quindi il messaggio finirà effettivamente nelle caselle di posta preem.palver@urano.mail e stor.gendibal@urano.mail.

Conclusioni

In questo articolo abbiamo apportato qualche miglioramento al nostro server di posta basilare, ora possiamo gestire più domini sulla stessa macchina e possiamo gestire liste di distribuzione all’interno della nostra organizzazione. I metodi utilizzati possono essere utilizzati in piccole realtà, ma per ambienti più complessi, è bene utilizzare altre metodiche per raggiungere gli stessi risultati, che verranno illustrate in altri articoli sull’argomento.

Integrare bookmarks di Delicious in pagina Wordpress

Lorenzo — Tue, 06 Jan 2009 17:12:08 +0000

Fino ad oggi, avevo sul blog una pagina in cui avevo raccolto alcuni collegamenti ipertestuali a pagine con documentazione varia relativa alle tematiche di questo spazio. Questi link li ho tenuti aggiornati per un po’, dopodiché ho mollato lì la cosa, anche perché nel frattempo mi sono arrangiato con Google Reader, impostando i tag e le stelle agli articoli dei blog che seguo per poterli poi ritrovare in caso di bisogno. Ma i blog del feed reader non sono la mia unica fonte di conoscenza, alle volte, cercando cose che mi interessano, mi imbatto in articoli interessanti che non meritano l’oblio, quindi ho deciso di aprire un account su Delicious, dove, alla bisogna, inserisco i bookmarks che ritengo meritevoli.

Oggi ho pensato ad una cosa: perché non sostituire i link utili nella pagina del blog con la lista dei bookmarks su Delicious? Bene, mi sono messo quindi alla ricerca di un plugin per Wordpress che mi permettesse di inserire la lista dei miei bookmarks di Delicious, peccato che la ricerca non abbia fornito l’esito sperato, infatti ciò che ho trovato io (ma può essere che mi sia sfuggito qualcosa) non risponde alla mia semplice esigenza, poiché ho letto solamente di plugin che permettono di inserire un certo numero di bookmarks in un widget sulla sidebar, cosa che ho provato a fare ma che ho levato subito con un moto di ribrezzo, poiché i link di quel tipo nella sidebar mi paiono decisamente inutili.

Cerca che ti ricerca, ho pensato di andare direttamente alla base, cioé sul sito di Delicious, dove ho trovato una simpatica pagina coi tools relativi a Delicious, tra cui vi sono Linkrolls e Tagrolls. Linkrolls consiste in un semplice script JavaScript, personalizzabile in base a vari parametri, con cui elencare un numero a piacere di bookmarks relativi al proprio account. Ciò era proprio quel che mi serviva, quindi lo provo e vedo che funziona alla perfezione, ma mi rendo subito conto che questa pletora di collegamenti ipertestuali è decisamente dispersiva.

A questo punto, rivolgo la mia attenzione su Tagrolls, che elenca la lista (o la tag cloud) dei tag utilizzati per categorizzare i propri bookmarks. Anche in questo caso, si tratta di uno script JavaScript che possiede diversi parametri personalizzabili (come l’ordinamento e l’aspetto); lo provo, e verifico che pure questo tool funziona perfettamente, ottenendo il risultato voluto.

Tutto bene quindi? Non proprio, perché, trattandosi di uno script JavaScript, chi naviga tenendo disabilitato l’interprete JavaScript, non visualizza un bel niente. Per risolvere il problema, ho pensato di fornire un contenuto alternativo tramite il tag