|
Size: 20516
Comment:
|
Size: 16477
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 9: | Line 9: |
| Installiamo la versione più recente di Netkit (core version 2.6 - file system 5.0 - kernel version 2.7) | Installiamo la versione più recente di Netkit (core version 2.7 - file system 5.1 - kernel version 2.8) |
| Line 13: | Line 13: |
| Diamo i comandi: {{{ luca@luca-laptop:~$ cd luca@luca-laptop:~$ mkdir ~/downloads-netkit luca@luca-laptop:~$ cd ~/downloads-netkit/ luca@luca-laptop:~/downloads-netkit$ wget http://wiki.netkit.org/download/netkit/netkit-2.7.tar.bz2 luca@luca-laptop:~/downloads-netkit$ wget http://wiki.netkit.org/download/netkit-filesystem/netkit-filesystem-i386-F5.1.tar.bz2 luca@luca-laptop:~/downloads-netkit$ wget http://wiki.netkit.org/download/netkit-kernel/netkit-kernel-i386-K2.8.tar.bz2 luca@luca-laptop:~/downloads-netkit$ cd luca@luca-laptop:~$ tar -xjSf downloads-netkit/netkit-2.7.tar.bz2 luca@luca-laptop:~$ tar -xjSf downloads-netkit/netkit-filesystem-i386-F5.1.tar.bz2 luca@luca-laptop:~$ tar -xjSf downloads-netkit/netkit-kernel-i386-K2.8.tar.bz2 luca@luca-laptop:~$ }}} Applichiamo una patch per risolvere un bug. {{{ luca@luca-laptop:~$ cd netkit luca@luca-laptop:~/netkit$ patch -p1 <<EOF diff -ur netkit/bin/script_utils netkit_patch/bin/script_utils --- netkit/bin/script_utils 2009-11-25 12:33:54.000000000 +0100 +++ netkit_patch/bin/script_utils 2009-11-30 19:53:19.161183943 +0100 @@ -268,7 +268,7 @@ '{printf \"%s %15s %25s %s\n\", CURRENTDATE, USER, SWITCHNAME, \\\$0}' > \${HUB_LOG} &" if [ ! -S "\$1" ] || ! someOneUses "\$1"; then # Either socket does not exist yet or it is still unused - if [ "\$USE_SUDO" == "yes" ]; then + if [ "\$USE_SUDO" = "yes" ]; then # Default sudo configuration resets environment variables for security # reasons (depends on the configuration in sudoers, and may happen even # when using -E) EOF luca@luca-laptop:~/netkit$ cd luca@luca-laptop:~$ }}} Se la nostra shell è la bash, diamo questi comandi per completare l'installazione di Netkit e "riavviare" la nostra shell. {{{ luca@luca-laptop:~$ cat <<EOF >>.bashrc export NETKIT_HOME=${HOME}/netkit export MANPATH=\${MANPATH}:\${NETKIT_HOME}/man export PATH=\$NETKIT_HOME/bin:\$PATH . \$NETKIT_HOME/bin/netkit_bash_completion EOF luca@luca-laptop:~$ exec bash luca@luca-laptop:~$ }}} |
|
| Line 17: | Line 65: |
| Dobbiamo anche fare in modo di avere abbastanza spazio nel disco virtuale. === Aumentare lo spazio disco della macchina virtuale === 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.0. <<BR>> {{{ luca@luca-laptop:~$ cd $NETKIT_HOME/fs luca@luca-laptop:~/netkit/fs$ ls -l netkit-fs lrwxrwxrwx 1 luca luca 2 2009-09-11 22:52 netkit-fs -> netkit-fs-i386-F5.0 }}} La dimensione del disco rappresentato da questo file è di 1 GB. Troppo poco per i nostri bisogni. Vediamo come ampliarla. Copiamo, per sicurezza, il file originale. <<BR>> Con il comando "ls -ls" vediamo sia la dimensione dichiarata che lo spazio effettivo su disco. <<BR>> I 2 valori differiscono per i cosidetti sparse-file, come le immagini di disco che non sono "piene". {{{ luca@luca-laptop:~/netkit/fs$ cp netkit-fs-i386-F5.0 backing luca@luca-laptop:~/netkit/fs$ ls -ls backing 1048584 -rw-r--r-- 1 luca luca 1073741824 2009-09-10 15:46 backing }}} Aumentiamo le dimensioni "dichiarate" del file a 2 GB. {{{ luca@luca-laptop:~/netkit/fs$ dd if=/dev/zero of=backing bs=1 count=1 seek=2G 1+0 records in 1+0 records out 1 byte (1 B) copied, 9.9803e-05 s, 10.0 kB/s luca@luca-laptop:~/netkit/fs$ ls -ls backing 1048588 -rw-r--r-- 1 luca luca 2147483649 2009-09-10 15:47 backing }}} Espandiamo la partizione che si trova all'interno di questa immagine di disco virtuale. {{{ luca@luca-laptop:~/netkit/fs$ sudo losetup /dev/loop0 backing luca@luca-laptop:~/netkit/fs$ sudo fdisk /dev/loop0 The number of cylinders for this disk is set to 66576. There is nothing wrong with that, but this is larger than 1024, and could in certain setups cause problems with: 1) software that runs at boot time (e.g., old versions of LILO) 2) booting and partitioning software from other OSs (e.g., DOS FDISK, OS/2 FDISK) }}} Il comando u dice che vogliamo vedere come unità il settore e non il cilindro. {{{ Command (m for help): u Changing display/entry units to sectors }}} Il comando p mostra le informazioni del disco. {{{ Command (m for help): p Disk /dev/loop0: 2147 MB, 2147483648 bytes 1 heads, 63 sectors/track, 66576 cylinders, total 4194304 sectors Units = sectors of 1 * 512 = 512 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/loop0p1 * 64 2097143 1048540 83 Linux }}} Notiamo che la partizione attualmente inizia al settore 64. Dovremo usare in seguito questo valore. <<BR>> Cancelliamo la partizione e la ricreiamo più grande. <<BR>> Useremo 64 come inizio e il default come fine. <<BR>> d per cancellare, n per creare, p per primaria, 1 come partition number, 64 come inizio, invio quando ci chiede la fine. {{{ Command (m for help): d Selected partition 1 Command (m for help): n Command action e extended p primary partition (1-4) p Partition number (1-4): 1 First sector (63-4194303, default 63): 64 Last sector, +sectors or +size{K,M,G} (64-4194303, default 4194303): Using default value 4194303 }}} Il comando p mostra le informazioni del disco. {{{ Command (m for help): p Disk /dev/loop0: 2147 MB, 2147483648 bytes 1 heads, 63 sectors/track, 66576 cylinders, total 4194304 sectors Units = sectors of 1 * 512 = 512 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/loop0p1 64 4194303 2097120 83 Linux }}} Il comando a rende la partizione bootable, come era prima. {{{ Command (m for help): a Partition number (1-4): 1 Command (m for help): p Disk /dev/loop0: 2147 MB, 2147483648 bytes 1 heads, 63 sectors/track, 66576 cylinders, total 4194304 sectors Units = sectors of 1 * 512 = 512 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/loop0p1 * 64 4194303 2097120 83 Linux }}} Il comando w salva ed esce. {{{ Command (m for help): w The partition table has been altered! Calling ioctl() to re-read partition table. WARNING: Re-reading the partition table failed with error 22: Invalid argument. The kernel still uses the old table. The new table will be used at the next reboot. Syncing disks. }}} Possiamo ignorare quel warning. Ora rimuoviamo l'associazione a /dev/loop0 {{{ luca@luca-laptop:~/netkit/fs$ sudo losetup -d /dev/loop0 }}} Ora facciamo un calcolo. La nostra partizione inizia al settore 64 e ogni settore (come visualizzato da fdisk) è di 512 bytes. <<BR>> Quindi la partizione inizia ad un offest di 64*512=32768 bytes. <<BR>> Associamo a /dev/loop0 questa partizione con il seguente comando. {{{ luca@luca-laptop:~/netkit/fs$ sudo losetup --offset 32768 /dev/loop0 backing }}} Un fschk, un resize e un nuovo fschk servono per rendere effettiva la nuova allocazione. {{{ luca@luca-laptop:~/netkit/fs$ sudo e2fsck -f /dev/loop0 e2fsck 1.41.4 (27-Jan-2009) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 3A: Optimizing directories Pass 4: Checking reference counts Pass 5: Checking group summary information nkfs-i386-F5.0: ***** FILE SYSTEM WAS MODIFIED ***** nkfs-i386-F5.0: 39840/65536 files (2.2% non-contiguous), 725259/1048540 blocks luca@luca-laptop:~/netkit/fs$ sudo resize2fs -f /dev/loop0 resize2fs 1.41.4 (27-Jan-2009) Resizing the filesystem on /dev/loop0 to 2097120 (1k) blocks. The filesystem on /dev/loop0 is now 2097120 blocks long. luca@luca-laptop:~/netkit/fs$ sudo e2fsck -f /dev/loop0 e2fsck 1.41.4 (27-Jan-2009) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information nkfs-i386-F5.0: 39840/131072 files (2.2% non-contiguous), 742160/2097120 blocks }}} Di nuovo rimuoviamo l'associazione a /dev/loop0 {{{ luca@luca-laptop:~/netkit/fs$ sudo losetup -d /dev/loop0 }}} Il file backing 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.0 e creare un nuovo link al nostro nuovo file. {{{ luca@luca-laptop:~/netkit/fs$ rm netkit-fs luca@luca-laptop:~/netkit/fs$ ln -s backing netkit-fs }}} In questo caso entrambi i parametri si possono omettere. Nel resto del documento supponiamo che si sia scelto questo secondo metodo. |
|
| Line 226: | Line 67: |
| Assicuriamoci di avere la password di root del nostro sistema. Non si tratta della password nostra con la quale possiamo usare "sudo"; ma della password associata a root. <<BR>> Per accertarci, diamo il comando "su -" che ci richiede appunto la password di root. <<BR>> Dopo aver verificato, usciamo dalla shell di root e torniamo nella shell del nostro utente. |
|
| Line 236: | Line 71: |
| luca@luca-laptop:~/netkit/fs$ cd | |
| Line 241: | Line 75: |
| Viene richiesta la password di root. | Ci viene richiesta la nostra password per alcune operazioni che richiedono i privilegi di root. |
| Line 244: | Line 78: |
E' possibile che sia necessario eseguire anche i seguenti comandi, sempre dal terminale del nostro sistema, per fare in modo che il sistema ospite (virtuale) esca su Internet. {{{ luca@luca-laptop:~/prepare-ntk$ sudo ifconfig nk_tap_$(whoami) 10.0.0.1 netmask 255.255.255.0 up luca@luca-laptop:~/prepare-ntk$ sudo iptables -t nat -A POSTROUTING -s 10.0.0.2 -j MASQUERADE luca@luca-laptop:~/prepare-ntk$ sudo iptables -A FORWARD -i nk_tap_+ -j ACCEPT }}} |
|
| Line 302: | Line 129: |
| pc1:~# apt-get install xsltproc | |
| Line 316: | Line 144: |
| Dall'interno della macchina virtuale diamo questi comandi. | Sempre dall'interno della macchina virtuale diamo questi comandi. |
| Line 330: | Line 158: |
| Sempre dall'interno della macchina virtuale diamo questi comandi. | Dall'interno della macchina virtuale diamo questi comandi. |
| Line 352: | Line 180: |
| Dopo va installato {{{andns}}}. <<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): {{{ pc1:~# cp -a /hosthome/netsukuku/ANDNS . pc1:~# cd ANDNS/ pc1:~/ANDNS# cd andns/ pc1:~/ANDNS/andns# make pc1:~/ANDNS/andns# make install pc1:~/ANDNS/andns# cd .. pc1:~/ANDNS# cd pyandns/ pc1:~/ANDNS/pyandns# /opt/stackless/bin/python2.6 setup.py build pc1:~/ANDNS/pyandns# /opt/stackless/bin/python2.6 setup.py install pc1:~/ANDNS/pyandns# cd }}} 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): {{{ pc1:~# cp -a /hosthome/netsukuku/ntkresolv . pc1:~# cd ntkresolv/ pc1:~/ntkresolv# make pc1:~/ntkresolv# make install pc1:~/ntkresolv# cd }}} |
|
| Line 354: | Line 209: |
| Dovremo comunque preparare la sua configurazione. <<BR>> Dall'interno della macchina virtuale diamo questi comandi. {{{ pc1:~# mkdir /etc/netsukuku }}} |
|
| Line 362: | Line 224: |
| 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. |
|
| Line 366: | Line 232: |
| luca@luca-laptop:~/prepare-ntk$ uml_moo -b $NETKIT_HOME/fs/backing pc1.disk $NETKIT_HOME/fs/newbacking | luca@luca-laptop:~/prepare-ntk$ uml_moo -b $NETKIT_HOME/fs/netkit-fs-i386-F5.1 pc1.disk $NETKIT_HOME/fs/newbacking |
| Line 370: | Line 236: |
| Il primo file passato a parametro nella riga sopra è il file backing che stiamo usando. Se abbiamo seguito tutto questo documento, si tratta del file ampliato a 2 GB che abbiamo messo nella directory netkit/fs. | Il primo file passato a parametro nella riga sopra è il file modello iniziale che stiamo usando. |
| Line 384: | Line 250: |
| Verifichiamo l'offset della partizione con la stessa procedura di prima. | Verifichiamo l'offset della partizione con questa procedura. |
| Line 390: | Line 256: |
| Disk /dev/loop0: 2147 MB, 2147483648 bytes 1 heads, 63 sectors/track, 66576 cylinders, total 4194304 sectors |
Disk /dev/loop0: 10.7 GB, 10737418240 bytes 255 heads, 63 sectors/track, 1305 cylinders, total 20971520 sectors |
| Line 396: | Line 262: |
| /dev/loop0p1 * 64 4194303 2097120 83 Linux }}} Di norma dovremmo ancora avere la partizione al settore 64 e i settori di 512 bytes. Quindi un offset di 32768 bytes. <<BR>> Montiamo il filesystem contenuto nella partizione. |
/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}}}''. |
| Line 426: | Line 294: |
| Di nuovo, ora che abbiamo il nuovo modello che ha 2 GB a disposizione e con le installazioni che ci servono, possiamo usarlo come modello in 2 modi: aggiungendo i 2 parametri ogni volta: <<BR>> {{{ -m /path/to/file/newbacking}}} |
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}}} |
| Line 431: | Line 301: |
| <<BR>> oppure sostituendo il link simbolico "netkit/fs/netkit-fs" con un nuovo link al nostro nuovo file. |
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. |
| Line 437: | Line 307: |
| Nel resto del documento supponiamo che si sia scelto questo secondo metodo. | In questo caso entrambi i parametri si possono omettere. Nel resto del documento supponiamo che si sia scelto questo secondo metodo. |
| Line 507: | Line 377: |
| Una pagina che spiega nel dettaglio l'uso di queste script è in lavorazione [[../ScriptsWithNetkit|qui]]. | [[../ScriptsWithNetkit|Questa pagina]] spiega nel dettaglio l'uso di queste script. |
HowTo test netsukuku daemon using NetKit
Un modo di provare il funzionamento di Netsukuku (se non si dispone di una variegata infrastruttura di reti e di un numero cospicuo di computer) può essere l'uso di NetKit.
Lo scopo di questa pagina è quello di raccogliere le informazioni che possono aiutare i nuovi arrivati a preparare un ambiente in cui simulare una arbitraria topologia di rete i cui nodi sono in grado di eseguire il demone ntkd.
Preparare una macchina virtuale per eseguirci ntkd
Installiamo la versione più recente di Netkit (core version 2.7 - file system 5.1 - kernel version 2.8)
Per istruzioni vedere http://wiki.netkit.org/index.php/Main_Page.
Diamo i comandi:
luca@luca-laptop:~$ cd luca@luca-laptop:~$ mkdir ~/downloads-netkit luca@luca-laptop:~$ cd ~/downloads-netkit/ luca@luca-laptop:~/downloads-netkit$ wget http://wiki.netkit.org/download/netkit/netkit-2.7.tar.bz2 luca@luca-laptop:~/downloads-netkit$ wget http://wiki.netkit.org/download/netkit-filesystem/netkit-filesystem-i386-F5.1.tar.bz2 luca@luca-laptop:~/downloads-netkit$ wget http://wiki.netkit.org/download/netkit-kernel/netkit-kernel-i386-K2.8.tar.bz2 luca@luca-laptop:~/downloads-netkit$ cd luca@luca-laptop:~$ tar -xjSf downloads-netkit/netkit-2.7.tar.bz2 luca@luca-laptop:~$ tar -xjSf downloads-netkit/netkit-filesystem-i386-F5.1.tar.bz2 luca@luca-laptop:~$ tar -xjSf downloads-netkit/netkit-kernel-i386-K2.8.tar.bz2 luca@luca-laptop:~$
Applichiamo una patch per risolvere un bug.
luca@luca-laptop:~$ cd netkit
luca@luca-laptop:~/netkit$ patch -p1 <<EOF
diff -ur netkit/bin/script_utils netkit_patch/bin/script_utils
--- netkit/bin/script_utils 2009-11-25 12:33:54.000000000 +0100
+++ netkit_patch/bin/script_utils 2009-11-30 19:53:19.161183943 +0100
@@ -268,7 +268,7 @@
'{printf \"%s %15s %25s %s\n\", CURRENTDATE, USER, SWITCHNAME, \\\$0}' > \${HUB_LOG} &"
if [ ! -S "\$1" ] || ! someOneUses "\$1"; then
# Either socket does not exist yet or it is still unused
- if [ "\$USE_SUDO" == "yes" ]; then
+ if [ "\$USE_SUDO" = "yes" ]; then
# Default sudo configuration resets environment variables for security
# reasons (depends on the configuration in sudoers, and may happen even
# when using -E)
EOF
luca@luca-laptop:~/netkit$ cd
luca@luca-laptop:~$ Se la nostra shell è la bash, diamo questi comandi per completare l'installazione di Netkit e "riavviare" la nostra shell.
luca@luca-laptop:~$ cat <<EOF >>.bashrc
export NETKIT_HOME=${HOME}/netkit
export MANPATH=\${MANPATH}:\${NETKIT_HOME}/man
export PATH=\$NETKIT_HOME/bin:\$PATH
. \$NETKIT_HOME/bin/netkit_bash_completion
EOF
luca@luca-laptop:~$ exec bash
luca@luca-laptop:~$ Una volta installato, le macchine virtuali avranno un sistema operativo basato su Debian.
Potremo quindi usare apt-get per installare al loro interno il software di cui abbiamo bisogno. E' necessario che il nostro computer sia collegato a Internet.
Installazione pacchetti da Internet
Nel terminale del nostro sistema, ci posizioniamo su una directory vuota creata per questi test.
Diamo il comando:
luca@luca-laptop:~$ mkdir prepare-ntk luca@luca-laptop:~$ cd prepare-ntk/ luca@luca-laptop:~/prepare-ntk$ vstart pc1 --eth0=tap,10.0.0.1,10.0.0.2 --mem=128
Ci viene richiesta la nostra password per alcune operazioni che richiedono i privilegi di root.
Questo modo di avviare la macchina virtuale consente di accedere dalla macchina virtuale a Internet. Inoltre anche la memoria a 128 MB si rende necessaria per qualche installazione.
Ci serve un DNS server per il sistema ospite. Possiamo usare opendns (208.67.222.222) se non sappiamo quale usare. Dentro il sistema ospite modificare il file /etc/resolv.conf per inserire la riga
nameserver 208.67.222.222
A questo punto dovremmo essere in grado di "navigare" dal sistema ospite. Possiamo provare con "ping www.ubuntu.com".
Se tutto funziona diamo i seguenti comandi per installare alcuni pacchetti necessari.
pc1:~# apt-get update
Se durante l'update si riceve un messaggio del tipo:
W: GPG error: http://ftp.it.debian.org unstable Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 9AA38DCD55BE302B W: You may want to run apt-get update to correct these problems
significa che apt non ha la chiave pubblica con quel identificativo.
La parte importante sono le ultime 8 cifre esadecimali, ad esempio 55BE302B.
Dare i seguenti comandi, sostituendo le ultime 8 cifre:
pc1:~# gpg --keyserver keyserver.ubuntu.com --recv-keys 55BE302B gpg: directory `/root/.gnupg' created gpg: new configuration file `/root/.gnupg/gpg.conf' created gpg: WARNING: options in `/root/.gnupg/gpg.conf' are not yet active during this run gpg: keyring `/root/.gnupg/secring.gpg' created gpg: keyring `/root/.gnupg/pubring.gpg' created gpg: requesting key 55BE302B from hkp server keyserver.ubuntu.com gpg: /root/.gnupg/trustdb.gpg: trustdb created gpg: key 55BE302B: public key "Debian Archive Automatic Signing Key (5.0/lenny) <ftpmaster@debian.org>" imported gpg: no ultimately trusted keys found gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) pc1:~# gpg --export --armor 55BE302B | apt-key add - OK
e poi ripetere l'update.
pc1:~# apt-get update
Proseguiamo con le installazioni.
NOTA: l'installazione di build-essential richiede qualche interazione con l'utente. Le risposte di default dovrebbero andare bene.
pc1:~# apt-get install build-essential pc1:~# apt-get install swig pc1:~# apt-get install openssl libssl-dev pc1:~# apt-get install xsltproc
Le prossime istruzioni creano alcuni link simbolici necessari alle prossime installazioni.
pc1:~# cd /usr/lib pc1:/usr/lib# ln -s libcrypto.so.0.9.8 libcrypto.so.0 pc1:/usr/lib# ln -s libssl.so.0.9.8 libssl.so.0 pc1:/usr/lib# cd /sbin pc1:/sbin# ln -s /usr/sbin/ip pc1:/sbin# cd
Dopo va installato Stackless Python.
Sempre dall'interno della macchina virtuale diamo questi comandi.
pc1:~# wget http://www.stackless.com/binaries/stackless-262-export.tar.bz2 pc1:~# tar xf stackless-262-export.tar.bz2 pc1:~# cd stackless-2.6.2 pc1:~/stackless-2.6.2# mkdir -p /opt/stackless pc1:~/stackless-2.6.2# ./configure --prefix=/opt/stackless pc1:~/stackless-2.6.2# make pc1:~/stackless-2.6.2# make altinstall pc1:~/stackless-2.6.2# cd
Dopo va installato M2Crypto
Dall'interno della macchina virtuale diamo questi comandi.
pc1:~# wget http://pypi.python.org/packages/source/M/M2Crypto/M2Crypto-0.20.1.tar.gz pc1:~# tar xf M2Crypto-0.20.1.tar.gz pc1:~# cd M2Crypto-0.20.1/ pc1:~/M2Crypto-0.20.1# /opt/stackless/bin/python2.6 setup.py build pc1:~/M2Crypto-0.20.1# /opt/stackless/bin/python2.6 setup.py install pc1:~/M2Crypto-0.20.1# cd
Dopo va installato dnspython.
Dall'interno della macchina virtuale diamo questi comandi.
pc1:~# wget http://www.dnspython.org/kits/1.7.1/dnspython-1.7.1.tar.gz pc1:~# tar xf dnspython-1.7.1.tar.gz pc1:~# cd dnspython-1.7.1 pc1:~/dnspython-1.7.1# /opt/stackless/bin/python2.6 setup.py build pc1:~/dnspython-1.7.1# /opt/stackless/bin/python2.6 setup.py install pc1:~/dnspython-1.7.1# cd
Dopo va installato andns.
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/ANDNS . pc1:~# cd ANDNS/ pc1:~/ANDNS# cd andns/ pc1:~/ANDNS/andns# make pc1:~/ANDNS/andns# make install pc1:~/ANDNS/andns# cd .. pc1:~/ANDNS# cd pyandns/ pc1:~/ANDNS/pyandns# /opt/stackless/bin/python2.6 setup.py build pc1:~/ANDNS/pyandns# /opt/stackless/bin/python2.6 setup.py install pc1:~/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.
pc1:~# mkdir /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 LinuxL'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
\ /
\ /
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.