Feeds:
Posts
Comments

Posts Tagged ‘Tesi’

VirtualBox, 4 istanze

VirtualBox, 4 istanze

Screenshot spettacolare, fresco fresco di giornata…

Quattro istanze di VirtualBox stanno girando contemporaneamente con distribuzioni Debian (minimali, meno di 1 GB di spazio occupato in macchine con 64 MB di RAM), e formano una rete locale con il PC principale; il tutto sta facendo funzionare l’applicativo Erlang che ho sviluppato per la tesi, cui dedicherò un post prossimamente.

Era una bella immagine da prendere 🙂

Advertisements

Read Full Post »

Mi sembra giusto pubblicare uno pseudo-mini howto su come configurare VirtualBox affinchè si crei una rete interna tra le macchine virtuali, e contemporaneamente tale rete sia raggiungibile dal sistema host esterno (e solo da lui); tutti i test sono stati effettuati con la versione 3.1.6 su Ubuntu 9.10 (sia guest che host).

Dopo una discussione avuta qualche giorno fa con Sante e Massimo riguardo l’esistenza di questa possibilità, che io personalmente non avevo trovato, ho deciso di esplorare a fondo la questione. La mia necessità, per un lavoro che sto facendo per la tesi, è quella di avere un tot di macchine virtuali connesse tra loro, e che a loro volta siano in rete locale con la macchina host; l’unica possibilità che conoscevo io per fare questo era di utilizzare la cosiddetta “scheda con bridge”, la quale tuttavia richiede che l’interfaccia di rete host sia attiva (ovviamente, qualcuno potrebbe dire): soluzione impraticabile se sto creando questa rete locale solo col mio computer, senza un router esterno.

L’opzione giusta da scegliere è “scheda solo host”, su tutte le macchine virtuali: a quel punto, appena avvierete la prima macchina, l’interfaccia vboxnet0, presente nel sistema host, verrà attivata con un IP del tipo 192.168.56.1, di fatto facendo capire che la rete locale che stiamo per creare è sulla sottorete 56.

Dopo aver effettivamente verificato della possibilità di assegnare un altro IP (ad esempio 56.2) ad una macchina virtuale, e che il ping rispondeva correttamente, ho aggiunto un altro tassello: è possibile infatti installare il pacchetto dhcp3-server, che altri non è che il famigerato server DHCP, nel sistema host; una configurazione banale come la seguente (/etc/dhcp3/dhcpd.conf):

default-lease-time 600;
max-lease-time 7200;
log-facility local7;
subnet 192.168.56.0 netmask 255.255.255.0 {
range 192.168.56.2 192.168.56.254;
}

fa sì che tale server assegni indirizzi da 2 a 254 sulla sottorete di cui sopra; un’altra semplice modifica a /etc/default/dhcp3-server per aggiungere la riga

INTERFACES="vboxnet0"

che indica su quale interfaccia restare in ascolto, quindi via anche al server tramite /etc/init.d/dhcp3-server start ed il gioco è fatto!

P.S.: verificate, prima di avviare il demone, che vboxnet0 sia attiva; in caso contrario, avviate la macchina virtuale con cui volete creare la rete, e l’interfaccia si attiverà automaticamente.

Read Full Post »

Ho finalmente iniziato a programmare un po’ in Erlang, in vista di quando dovrò iniziare a scrivere codice seriamente per la tesi (di cui parlerò più avanti, ora siamo parecchio agli inizi), ed oggi ho fatto un test estremamente semplice per giocare un po’ con il codice mobile.

Premesso infatti che Erlang favorisce il codice distribuito e la comunicazione tra nodi e processi remoti, mi sono chiesto se era possibile far muovere non solo dati (quindi variabili, anche se forse il termine variabile in questo contesto non è del tutto adatto, dato che sono immutabili), ma anche codice vero e proprio, in particolare funzioni e closure. E la risposta, naturalmente (e sorprendentemente), è stata: sì.

Modulo

Modulo

Il modulo qui sopra, dal comportamento piuttosto scontato, esporta un’unica funzione che riceve due parametri: una funzione (o meglio, una fun) F ed un valore Value, e non fa altro che invocare la prima passando il secondo; se F non è una funzione, il programma va democraticamente in crash, altrimenti ritorna il risultato di F (Erlang non richiede alcuna parola chiave return).

Questo modulo, debitamente compilato, è stato copiato in due computer diversi, che ho chiamato big e little, principalmente perchè il primo è il notebook ed il secondo è il netbook 🙂

Nodo big

Nodo big

Questa è la console del notebook: assegnato un nome di rete completo al nodo ed un cookie (e segato il firewall, forse ho sbagliato ad aprire la porta giusta per far comunicare Erlang), ho lanciato l’interprete e l’ho lasciato lì: il codice visto sopra non ha bisogno, infatti di essere in alcun modo avviato (ho anche creato una versione server, lievemente più complessa, ma il risultato è lo stesso anche con 2 righe 2 di codice), basta assicurarsi che l’interprete sappia dove trovare il file compilato, se ne avrà bisogno (ovvero se mai qualcuno dovesse richiedere una delle sue funzioni): nel caso più semplice basta lanciare l’interprete erl dalla cartella dove si trova tale file.

Nodo little

Nodo little

E qui, sul nodo little, avviene il bello: anche qui è necessario assegnare un nome di rete e lo stesso cookie di cui sopra (e lanciare l’interprete sempre dalla directory contente il file compilato, debitamente copiato dal primo nodo); a questo punto, ho dichiarato una funzione Double, che altro non fa che ricavare il quadrato del parametro, lanciarla in locale e successivamente in remoto, tramite la chiamata ad rpc:call(). Ed ha funzionato!

Cos’è successo

In pratica, nel secondo nodo è stata creata una fun, ovvero una funzione anonima assegnata ad una variabile; essendo la funzione appunto anonima, il suo codice non era a priori conosciuto dal primo nodo, dato che la sua implementazione (X*X) non era situata nel modulo presentato più sopra (che costituiva l’unico listato comune ai due nodi), bensì salvata in qualche modo direttamente nella variabile Double.

Quando tale variabile è stata inviata al nodo remoto, essa ha portato con sè tale implementazione, così che il nodo remoto è stato in grado di eseguirla e restituire al chiamante il risultato (4). Spettacolare!

Read Full Post »