|
Size: 11258
Comment:
|
Size: 6130
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 16: | Line 16: |
| Line 29: | Line 28: |
| Line 40: | Line 38: |
| Line 51: | Line 48: |
| Line 59: | Line 55: |
| Line 72: | Line 67: |
| Line 75: | Line 69: |
| Dopo va installato {{{ntkresolv}}}. <<BR>> 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): |
Now we install {{{ntkresolv}}}. |
| Line 79: | Line 71: |
| pc1:~# cp -a /hosthome/netsukuku/ntkresolv . pc1:~# cd ntkresolv/ pc1:~/ntkresolv# make pc1:~/ntkresolv# make install pc1:~/ntkresolv# cd |
luca@luca-laptop:~$ cd ~/netsukuku/ntkresolv luca@luca-laptop:~/netsukuku/ntkresolv$ make luca@luca-laptop:~/netsukuku/ntkresolv$ sudo make install luca@luca-laptop:~/netsukuku/ntkresolv$ cd |
| Line 86: | Line 77: |
| Non installiamo netsukuku; potremo avviare il demone dalla directory di lavoro del nostro sistema host. Dovremo comunque preparare la sua configurazione. |
We do not install netsukuku; we'll launch the daemon from its directory. |
| Line 90: | Line 79: |
| 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). | But we have to configure it. |
| Line 92: | Line 81: |
| pc1:~# mkdir /etc/netsukuku pc1:~# ln -s /hosthome/netsukuku/pyntk/setup/etc/netsukuku/tinc /etc/netsukuku |
luca@luca-laptop:~$ sudo mkdir -p /etc/netsukuku luca@luca-laptop:~$ sudo ln -s $HOME/netsukuku/pyntk/setup/etc/netsukuku/tinc /etc/netsukuku |
| Line 96: | Line 85: |
| 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. <<BR>> Il primo file passato a parametro nella riga sopra è il file modello iniziale che stiamo usando. <<BR>> Il secondo è il file differenziale prodotto avviando la macchina virtuale "pc1". Queste differenze rappresentano le installazioni appena fatte. <<BR>> 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. <<BR>> 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). <<BR>> Nell'esempio abbiamo la partizione al settore 64 e i settori di 512 bytes. Quindi un offset di 32768 bytes. <<BR>> 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}}}. <<BR>> 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. <<BR>> Possiamo farlo in 2 modi. Il primo è quello di aggiungere questi 2 parametri ogni volta che avviamo una macchina virtuale: <<BR>> {{{ -m /path/to/file/backing}}} <<BR>> {{{ --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 == |
=== Start pyntk === |
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
Now we install ntkresolv.
luca@luca-laptop:~$ cd ~/netsukuku/ntkresolv luca@luca-laptop:~/netsukuku/ntkresolv$ make luca@luca-laptop:~/netsukuku/ntkresolv$ sudo make install luca@luca-laptop:~/netsukuku/ntkresolv$ cd
We do not install netsukuku; we'll launch the daemon from its directory.
But we have to configure it.
luca@luca-laptop:~$ sudo mkdir -p /etc/netsukuku luca@luca-laptop:~$ sudo ln -s $HOME/netsukuku/pyntk/setup/etc/netsukuku/tinc /etc/netsukuku
Start pyntk
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
\ /
\ /
pc3Possiamo 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.