Come soluzione ho trovato puppy linux. Si tratta di una piccola distribuzione linux che si può mettere su una penna USB e che si avvia in tempi rapidissimi, inoltre ha degli ottimi tool per la configurazione del sistema.

L’ho messa sulla mia pennina usb, al primo avvio mi chiede alcune impostazioni (tipo di tastiera, risoluzione dello schermo …), ho configurato la rete, installato Firefox 3 con foxmarks per avere i miei bookmarks ed ecco pronto un sistema estremamente rapido e snello per navigare in internet e controllare le email. Per la cronaca sul mio pc si avvia in 45 secondi, ma credo si possa scendere ancora dato che ho visto un’opzione per congelare la configurazione dell’hardware disabilitando la ricerca automatica ad ogni avvio.

Volendo Fastweb ti da anche un indirizzo pubblico ma se lo fa pagare. Visto che l’unica mia esigenza di avere l’indirizzo pubblico è per fare ssh dall’ufficio sulla mia macchina a casa, ho provato a pensare a qualche soluzione alternativa all’ip pubblico. Direi che la cosa più ovvia è che invece di essere la macchina esterna a collegarsi verso quella di casa deve essere quest’ultima ad avviare la connessione verso l’esterno.

Ho trovato alcune soluzioni già pronte per fare circa quello che volevo ma, visto che avevo voglia di divertirmi un po’, non le ho usate e mi sono messo a pensare ad una soluzione più immediata possibile e senza l’utilizzo di programmi specifici.

Per comunicare al mio computer di casa cosa deve fare ho deciso di utilizzare una pagina web, su un server prefissato, della quale posso modificare i contenuti. Il computer di casa ricaricherà regolarmente questa pagina per capire cosa deve fare (in pratica se e a chi collegarsi).

Quello che ho deciso di usare è:

• Qualche semplice script di shell.
• l’utility netcat.

Sul server di casa (H) metto uno script che fa queste operazioni:

1. carica la pagina web prefissata per capire l’host esterno a cui collegarsi
2. se non esiste un host esterno a cui collegarsi, aspetta un po’ e ricomincia da 1
3. apre la connessione sia verso l’host esterno che verso il demone ssh locale e associa queste due connessioni
4. terminate le connessioni ricomincia da 1

Il punto 3 si realizza con netcat attraverso un comando come questo:

nc hostremoto porta -c "nc locahost 22"

In realtà ho avuto un problema con l’opzione -c che faceva i capricci per passare i parametri al secondo comando nc. Ho risolto facedo uno script “tossh” con dento “nc localhost 22″ e richiamato questo script nell’opzione -c.

Su l’host remoto (R) c’è il client ssh che vuole fare la connessione, ma che invece deve riceverla. L’accoppiamento fra connessione entrante (dal computer di casa) e uscente (dal client ssh) la realizziamo di nuovo attraverso netcat:

nc -lp portalocale -c "nc -lp porta" &
ssh -p portalocale -u utente localhost

dove porta è lo stesso numero di porta utilizzato nel comando sul computer di casa. Per come ho strutturato il primo comando bisogna che queste istruzioni vengano eseguite entrambe prima che il server di casa tenti di collegarsi.

Ora ho un problema che mi impedisce di determinare quando la sessione ssh è terminata. I comandi netcat non chiudono mai la connessione TCP ma terminano solo quando è l’host remoto a chiuderla. Terminare il netcat su (R) non è un problema (in realtà invertendo l’utilizzo di porta e portalocale i comandi terminano da soli). Il problema è su (H) dove rimane la connessione TCP fra un netcat e il demone ssh.

Se qualcuno vuole aiutarmi a risolvere il problemuccio si faccia avanti …

Lo script ancora incompleto che gira su H è questo:

#!/bin/sh
WEBS='www.xyz.it'
WEBA='path/to/test'
ADDR="http://$WEBS/$WEBA"
PARAM=`echo GET $ADDR | nc $WEBS 80`
while [ "$PARAM" == "" ]
do
   sleep 5
   PARAM=`echo GET $ADDR | nc $WEBS 80`
done
nc -ve "tossh" $PARAM


L’altro giorno ho scoperto un tool di debian che risolve questa situazione. Si chiama auto-apt. Il lavoro che svolge è abbastanza semplice ma di estrema utilità: tiene traccia di tutti i file presenti nei pacchetti disponibili nelle varie sorgenti apt; attraverso auto-apt si esegue il comando che ci interessa controllare, appena quest’ultimo tenta di accedere ad un file che non esiste, auto-apt lo sospende, verifica se esiste un pacchetto che ci fornisce tale file e in tal caso ci chiede se vogliamo installarlo prima di continuare l’esecuzione del comando.

Direi tanto semplice quanto comodo in situazioni come quella che ho indicato sopra.

Le immagini del kernel preferisco ricompilarle, anche se quelle disponibili funzionano bene e includono tutti i moduli di cui si può aver bisogno, a contrario delle immagini precompilate disponibili sul sito di XenSource.

Lo script per l’installazione del sistema guest è comodo e si occupa di creare i file o i volumi lvm, formattarli con il fylesystem preferito, installare la versione di debian desiderata (stable, testing, unstable) e creare il file di configurazione per il nuovo dominio xen.

Oltre a guadagnare in scalabilità dei filesystem mi sono anche liberato di quel fastidioso elenco di nomi indecifrabili di partizioni nel file fstab, anche se la cosa poteva essere ovviata tramite le etichette del filesystem avere dei device con nomi che richiamano in qualche modo il contenuto è molto meglio.

I concetti alla base sono semplici, abbiamo tre entità:

• Volumi fisici – le partizioni e i dischi utilizzati per allocare lo spazio.
• Volume Group – una sorta di "disco virtuale" a cui assegnamo i volumi fisici per memorizzare i dati.
• Volumi logici - sui volume group si creano i volumi logici, sono l’equivalente delle partizioni di un disco fisico; su questi andremo a creare i filesystem.

Il bello è che:

•  I volume group e i volumi logici possono essere ridimensionati a piacimento. Per creare e ridimensionare i volumi logici mi devo preoccupare solo che il volume group abbia abbastanza spazio e per aumentare quest’ultimo basta solo assegnargli nuovi volumi fisici.

• Il nome che gli assegnamo è usato per il nome del device. Ad esempio se creo il gruppo dati e su questo metto i volumi logici home e www ho i dispositivi /dev/dati/home e /dev/dati/www (o /dev/mapper/dati-home e /dev/mapper/dati-www).

Altre funzionalità interessanti che voglio sperimentare sono gli snapshot e il COW (Clone On Write), utili ad esempio per i backup e per l’utilizzo con XEN.

La soluzione è piuttosto specifica per la mia situazione e non va bene per realizzare un bridge in generale fra una lan via cavo e una cella wireless.

Il problema che devo risolvere è di far raggiungere agli host wireless il modem router sulla lan via cavo. Il server-bridge che ho realizzato non riesce ad operare in quanto la sua scheda wi-fi non cattura il traffico wireless non destinato esplicitamente a se.

Visto che sul lato via cavo è presente una sola macchina (il router), ho pensato di realizzare un NAT degli indirizzi MAC. Quando una macchina sul lato wireless manda una richiesta ARP per ottenere il MAC address del router, il server-bridge la intercetta e risponde con il MAC address della propria interfaccia WiFi. In questo modo gli host wireless, senza saperlo, invieranno il traffico per il firewall al server-bridge.

Il server-bridge dovrà avere delle altre regole per fare in modo di inoltrare al router i pacchetti ip che gli arrivano ma i cui indirizzi ip di destinazione non gli appartengono.

Per realizzare tutto questo ho utilizzato ebtables, l’equivalente di iptables che lavora a livello 2 anziché a livello 3.

Ecco le regole che ho usato:

Come si intuisce questo meccanismo non può essere generico perché bisogna scrivere esplicitamente delle regole per ogni macchina presente sulla LAN via cavo. Di buono questa soluzione ha che può essere implementata anche con la più schifosa delle schede wifi purché funzioni con linux.

Ho indagato la questione ed ho concluso che il bridge non ha nulla che non va, semplicemente l’interfaccia wireless non lavora in modalità promiscua, cioè riceve i frame ethernet indirizzati a lei o in multicast/broadcast ma non intercetta quelli inviati ad indirizzi MAC di altri host.

A quanto pare non è una cosa insolita che le interfaccie wireless non possano funzionare in modalità promiscua.

Ho elaborato una soluzione che permette di risolvere il problema, l’ho già provata e funziona, la sto utilizzando proprio in questo momento. Vi scrivo dal mio pc che via wireless comunica con il server a 20 cm di distanza  a sua volta collegato con un cavo allo switch e poi al router ADSL.

Rimando al prossimo post la descrizione nei dettagli e le considerazioni.

Purtroppo le prime prove non hanno dato esito positivo.

Realizzare il bridge è stato piuttosto facile. Dopo aver ricompilato il kernel per abilitare il bridging, ho installato le bridge-utils e con i seguenti comanti ho creato il bridge e inserito le 2 interfacce:

  brctl addbr br0

  brctl addif eth0

  brctl addif eth1 

Infine ho configurato un indirizzo ip per la nuova interfaccia di rete br0, visto che non posso più utilizzare  direttamente eth0 e eth1.

Tutto è pronto, da una verifica il server bridge riesce a comunicare sia sugli host collegati attraverso eth0, sia su quelli collegati atraverso eth1 (la rete wireless). Purtroppo gli host su un lato del bridge non comunicano con quelli sull’altro lato.

Il bridge non funziona, dovrò indagare il perché. Intanto ho deciso di spostare le mie prove in ambiente virtuale usando vmware, visto che sono impazzito ad attaccare e staccare cavi di rete e monitor.

I precedenti post:

• primo post
• secondo post

Ho installato una debian su un’unica partizione formattata con ext3. Inizialmente ho provato il filesystem ReiserFS ma dopo il boot mi rimaneva montata in sola lettura, comunque questo è un problema di installazione della debian e non centra con Xen.

Di per sé, la configurazione di Xen non presenta particolari difficoltà. Le difficoltà si possono presentare nella preparazione delle immagini dei dischi che contengono il sistema operativo guest installato. Come dicevo nel precedente post, non posso usare il CD di boot di una distribuzione per installare il S.O. guest (almeno non normalmente). Brevemente per la debian si tratta di preparare il disco, montarlo, installare la base del sistema con debootstrap, poi fare un chroot e finire l’installazione con base-config. Purtroppo non è tutto così lineare in quanto bisogna editare alcuni file di configurazione a mano ed eseguire varie operazioni.

Le fasi successive saranno fare alcuni test di utilizzo e preparare un documento dove illustro le operazioni effettuate.

Mi sono studiato un po’ come funziona Xen e la cosa principale che ho capito è che non si tratta di un virtualizzatore di PC (almeno non completamente). Questo vuol dire che non crea dei veri e propri PC virtuali dove installare un sistema operativo, piuttosto è un sistema che permette a più sistemi operativi, adattati per funzionare con Xen, di essere eseguiti in parallelo sulla stessa macchina. L’ambiente in cui gira il S.O. viene chiamato dominio. Il primo dominio eseguito da Xen è il dominio 0 che ha dei privilegi particolari, l’accesso completo all’hardware della macchina e la gestione degli altri domini.

Tornando alle mie prove, avevo iniziato installando la Fedora Core 5 e i suoi pacchetti di Xen, poi ho deciso di ricominciare da capo e di provare la versione scaricata dal sito ufficiale  di Xen, sia i binari precompilati che i sorgenti. Installare il dominio 0 alla fine risulta piuttosto semplice, si trattta di adattare il sistema operativo già installato cambiando la configurazione del boot loader in modo da fargli caricare prima xen e poi una nuova immagine del kernel specifica per Xen.

Invece un po’ più complicato è installare gli altri sistemi guest (i domini successivi). Non si può usare un boot CD, ma bisogna preparare prima quello che sarà il disco col sistema operativo installato (può essere una partizione, un file, ecc…), poi l’immagine del kernel da utilizzare, ed infine assemblare il tutto in un file di configurazione di Xen.

Quest’ultima è la fase che mi sta dando problemi. Sto cercando di installare una debian come Guest, ho preparato tutto ma ad un certo punto, duranti il boot, si blocca. Nei prossimi giorni cercherò di capire perché …