HowTo test netsukuku daemon on real hardware

On Linux

Dependencies

The following commands have been tested in a Ubuntu environment.

Open a terminal and give these commands:

luca@luca-laptop:~$ sudo apt-get update
luca@luca-laptop:~$ sudo apt-get install build-essential
luca@luca-laptop:~$ sudo apt-get install swig
luca@luca-laptop:~$ sudo apt-get install openssl libssl-dev
luca@luca-laptop:~$ sudo apt-get install xsltproc tinc

Now, we install Stackless Python.

luca@luca-laptop:~$ wget http://www.stackless.com/binaries/stackless-262-export.tar.bz2
luca@luca-laptop:~$ tar xf stackless-262-export.tar.bz2
luca@luca-laptop:~$ cd stackless-2.6.2
luca@luca-laptop:~/stackless-2.6.2$ mkdir -p /opt/stackless
luca@luca-laptop:~/stackless-2.6.2$ ./configure --prefix=/opt/stackless
luca@luca-laptop:~/stackless-2.6.2$ make
luca@luca-laptop:~/stackless-2.6.2$ sudo make altinstall
luca@luca-laptop:~/stackless-2.6.2$ cd

Now, we install M2Crypto

luca@luca-laptop:~$ wget http://pypi.python.org/packages/source/M/M2Crypto/M2Crypto-0.20.1.tar.gz
luca@luca-laptop:~$ tar xf M2Crypto-0.20.1.tar.gz 
luca@luca-laptop:~$ cd M2Crypto-0.20.1/
luca@luca-laptop:~/M2Crypto-0.20.1$ /opt/stackless/bin/python2.6 setup.py build
luca@luca-laptop:~/M2Crypto-0.20.1$ sudo /opt/stackless/bin/python2.6 setup.py install
luca@luca-laptop:~/M2Crypto-0.20.1$ cd

Now, we install dnspython.

luca@luca-laptop:~$ wget http://www.dnspython.org/kits/1.7.1/dnspython-1.7.1.tar.gz
luca@luca-laptop:~$ tar xf dnspython-1.7.1.tar.gz
luca@luca-laptop:~$ cd dnspython-1.7.1
luca@luca-laptop:~/dnspython-1.7.1$ /opt/stackless/bin/python2.6 setup.py build
luca@luca-laptop:~/dnspython-1.7.1$ sudo /opt/stackless/bin/python2.6 setup.py install
luca@luca-laptop:~/dnspython-1.7.1$ cd

Get netsukuku

Get from the svn repository the current code of Netsukuku.

luca@luca-laptop:~$ svn co http://dev.hinezumi.org/svnroot/netsukuku/sandbox/lukisi/branches/multipleip netsukuku

So that ~/netsukuku/pyntk contains the current python version of netsukuku.

Now we install andns.

luca@luca-laptop:~$ cd ~/netsukuku/ANDNS/andns
luca@luca-laptop:~/netsukuku/ANDNS/andns$ make
luca@luca-laptop:~/netsukuku/ANDNS/andns$ sudo make install
luca@luca-laptop:~/netsukuku/ANDNS/andns$ cd ~/netsukuku/ANDNS/pyandns
luca@luca-laptop:~/netsukuku/ANDNS/pyandns$ /opt/stackless/bin/python2.6 setup.py build
luca@luca-laptop:~/netsukuku/ANDNS/pyandns$ sudo /opt/stackless/bin/python2.6 setup.py install
luca@luca-laptop:~/netsukuku/ANDNS/pyandns$ cd

Dopo va installato ntkresolv.
Dall'interno della macchina virtuale diamo questi comandi (supponendo di aver scaricato la versione di sviluppo di netsukuku sulla nostra macchina host e averla linkata a ~/netsukuku):

pc1:~# cp -a /hosthome/netsukuku/ntkresolv .
pc1:~# cd ntkresolv/
pc1:~/ntkresolv# make
pc1:~/ntkresolv# make install
pc1:~/ntkresolv# cd

Non installiamo netsukuku; potremo avviare il demone dalla directory di lavoro del nostro sistema host.

Dovremo comunque preparare la sua configurazione.
Dall'interno della macchina virtuale diamo questi comandi (supponendo di aver scaricato la versione di sviluppo di netsukuku sulla nostra macchina host e averla linkata a ~/netsukuku).

pc1:~# mkdir /etc/netsukuku
pc1:~# ln -s /hosthome/netsukuku/pyntk/setup/etc/netsukuku/tinc /etc/netsukuku

Fermiamo la macchina virtuale dando il comando:

pc1:~# halt

Dopo che si è chiusa la finestra, vediamo che nel nostro sistema, nella directory da cui abbiamo avviato la macchina virtuale, si trova ora un file pc1.disk

Apportare le modifiche sul file modello

Le macchine virtuali che si usano in Netkit hanno un disco virtuale. Tale disco è rappresentato da un file "modello" che non viene alterato, e da un altro file che contiene solo le differenze rispetto al modello.

Il file modello usato si trova nella directory di installazione di netkit ($NETKIT_HOME) nella sottodirectory "fs" e si chiama "netkit-fs". In effetti esso è un link simbolico al file netkit-fs-i386-F5.1.

A partire dal file modello e dal file delle differenze si può creare un nuovo file "modello".

Dal terminale del nostro sistema, diamo il comando:

luca@luca-laptop:~/prepare-ntk$ uml_moo -b $NETKIT_HOME/fs/netkit-fs-i386-F5.1 pc1.disk $NETKIT_HOME/fs/newbacking

uml_moo è parte del software User Mode Linux.
Il primo file passato a parametro nella riga sopra è il file modello iniziale che stiamo usando.
Il secondo è il file differenziale prodotto avviando la macchina virtuale "pc1". Queste differenze rappresentano le installazioni appena fatte.
Il terzo è il nome di un nuovo file che potremo in seguito usare come modello delle nostre macchine virtuali.

Rimuoviamo il file pc1.disk che usava il vecchio modello e anche la directory creata per questo lavoro preliminare.

luca@luca-laptop:~/prepare-ntk$ cd
luca@luca-laptop:~$ rm -rf prepare-ntk

Prima di usare il nuovo file come modello generico, dobbiamo apportare alcune modifiche all'interno del file system in esso contenuto.
Verifichiamo l'offset della partizione con questa procedura.

luca@luca-laptop:~$ cd $NETKIT_HOME/fs
luca@luca-laptop:~/netkit/fs$ sudo losetup /dev/loop0 newbacking 
luca@luca-laptop:~/netkit/fs$ sudo fdisk -ul /dev/loop0

Disk /dev/loop0: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders, total 20971520 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000

      Device Boot      Start         End      Blocks   Id  System
/dev/loop0p1   *          64    20964824    10482380+  83  Linux

L'ultima riga mostra il settore di partenza (Start) della nostra partizione. Più in alto si legge il numero di bytes per ogni settore (Units).
Nell'esempio abbiamo la partizione al settore 64 e i settori di 512 bytes. Quindi un offset di 32768 bytes.
Montiamo il filesystem contenuto nella partizione, specificando questo offset al comando losetup.

luca@luca-laptop:~/netkit/fs$ sudo losetup -d /dev/loop0
luca@luca-laptop:~/netkit/fs$ sudo losetup --offset 32768 /dev/loop0 newbacking 
luca@luca-laptop:~/netkit/fs$ DIR_NEWBACKING=$(mktemp -d)
luca@luca-laptop:~/netkit/fs$ sudo mount /dev/loop0 $DIR_NEWBACKING
luca@luca-laptop:~/netkit/fs$ cd $DIR_NEWBACKING

Apportiamo queste modifiche. Rimuoviamo l'attuale hostname (nel nostro esempio "pc1") dal file hosts e rimuoviamo il file /etc/vhostconfigured.
In particolare, l'assenza del file /etc/vhostconfigured indica a Netkit che il filesystem va, in un certo senso, inizializzato per una nuova macchina virtuale.

luca@luca-laptop:/tmp/tmp.KEQzWMiIht$ cd etc
luca@luca-laptop:/tmp/tmp.KEQzWMiIht/etc$ cat hosts | grep -v $(cat hostname) > hosts.new
luca@luca-laptop:/tmp/tmp.KEQzWMiIht/etc$ sudo rm hosts
luca@luca-laptop:/tmp/tmp.KEQzWMiIht/etc$ sudo cp hosts.new hosts
luca@luca-laptop:/tmp/tmp.KEQzWMiIht/etc$ sudo rm hosts.new
luca@luca-laptop:/tmp/tmp.KEQzWMiIht/etc$ sudo rm vhostconfigured
luca@luca-laptop:/tmp/tmp.KEQzWMiIht/etc$ cd $NETKIT_HOME/fs

Smontiamo il filesystem e rilasciamo il file.

luca@luca-laptop:~/netkit/fs$ sudo umount /dev/loop0
luca@luca-laptop:~/netkit/fs$ sudo losetup -d /dev/loop0

Il file newbacking così ottenuto può essere usato come "modello" per le macchine virtuali che avviamo in Netkit.
Possiamo farlo in 2 modi. Il primo è quello di aggiungere questi 2 parametri ogni volta che avviamo una macchina virtuale:
  -m /path/to/file/backing
  --append=root=98:1

Una alternativa è rimuovere il link simbolico "netkit-fs" al file originale netkit-fs-i386-F5.1 e creare un nuovo link al nostro nuovo file.

luca@luca-laptop:~/netkit/fs$ rm netkit-fs
luca@luca-laptop:~/netkit/fs$ ln -s newbacking netkit-fs

In questo caso entrambi i parametri si possono omettere. Nel resto del documento supponiamo che si sia scelto questo secondo metodo.

Avviare delle macchine virtuali e testare ntkd

In seguito, quando lanciamo una macchina virtuale, non avremo bisogno di una interfaccia di rete virtuale collegata ad Internet, ma di una o più interfacce virtuali collegate ad un "dominio di collisione" virtuale.

Creiamo una nuova directory e, dal suo interno, avviamo una macchina virtuale.

luca@luca-laptop:~/netkit/fs$ cd
luca@luca-laptop:~$ mkdir test-ntk
luca@luca-laptop:~$ cd test-ntk
luca@luca-laptop:~/test-ntk$ vstart pc1 --eth0=A --eth1=B --mem=64

Questa sintassi avvia una macchina virtuale con due schede virtuali (eth0 ed eth1) collegate a 2 domini diversi, uno chiamato "A" e l'altro "B".

Queste interfacce non vengono affatto inizializzate dal sistema operativo caricato nelle macchine virtuali di netkit. Questa quindi è la situazione ottimale per verificare che il demone ntkd le renda effettivamente utilizzabili.

Una semplice topologia di rete

Supponiamo di voler provare questa topologia di rete:

                    Collision Domain
                           A
                           |
                           V

                 pc1 ------------- pc2
                    \             /
                     \           /
Collision Domain      \         /      Collision Domain
             B ---->   \       /  <-----  C
                        \     /
                         \   /
                          pc3

Possiamo farlo con questi comandi:

luca@luca-laptop:~/test-ntk$ vstart pc1 --eth0=A --eth1=B --mem=64
luca@luca-laptop:~/test-ntk$ vstart pc2 --eth0=A --eth1=C --mem=64
luca@luca-laptop:~/test-ntk$ vstart pc3 --eth0=B --eth1=C --mem=64

Si avviano 3 macchine virtuali le cui console appaiono in 3 finestre.

Scarichiamo nel nostro sistema da svn la versione corrente di Netsukuku.
Mettiamo un link simbolico nella nostra home.

luca@luca-laptop:~/test-ntk$ cd
luca@luca-laptop:~$ mkdir -p sviluppo/netsukuku
luca@luca-laptop:~$ cd sviluppo/netsukuku
luca@luca-laptop:~/sviluppo/netsukuku$ svn co http://dev.hinezumi.org/svnroot/netsukuku/trunk .
luca@luca-laptop:~/sviluppo/netsukuku$ cd
luca@luca-laptop:~$ ln -s sviluppo/netsukuku netsukuku

Quindi ~/netsukuku/pyntk è la directory che contiene la versione python di netsukuku.

Dalla console di ogni macchina virtuale che abbiamo avviata diamo questi comandi:

pc1:~# cd /hosthome/netsukuku/pyntk
pc1:/hosthome/netsukuku/pyntk# /opt/stackless/bin/python2.6 ntkd -i eth0 eth1 -vvvv

Ora si hanno le basi per provare il funzionamento di netsukuku.
Ci sono anche delle scripts nel repository che aiutano a preparare ambienti complessi. In questo modo è possibile riprodurre automaticamente una certa situazione per fare debug o produrre dei log che possono aiutare a trovare anomalie o punti critici.
Questa pagina spiega nel dettaglio l'uso di queste script.