Dovendo gestire più di un testbed formato da macchine virtuali di numero, tipologia e topologie diverse, mi sono imbattuto in alcuni problemi. I sistemi che utilizzo sono macchine virtuali KVM e VDE per gestire la rete. Per gestirli ovviamente utilizzo Virtualbricks poiché mi semplifica, e non di poco, la vita.

Il problema

Il problema che voglio affrontare in questo articolo è un problema di semplificazione all’accesso da remoto alle varie macchine virtuali, ovvero: come fare ad accedere, utilizzando SSH, alle varie macchine virtuali utilizzando come nome degli host i nomi delle macchine virtuali che ho impostato su Virtualbricks? E soprattutto questo meccanismo può essere automatizzato, in modo che ogni macchina virtuale, appena viene lanciata, istruisca la macchina host su quale è la combinazione hostname – IP corretta per comunicare con essa?

Il primo passo: l’assegnamento degli indirizzi IP

Data la dinamicità della topologia, impostare indirizzi IP statici è di poca utilità, occorre quindi utilizzare un server DHCP per assegnare gli indirizzi, il che vuol dire che i SO delle macchine virtuali devono essere configurati per prendere l’IP automaticamente via DHCP al boot, e questo è il primo passo.

Secondo passo: il server DHCP

Il secondo passo è l’installazione del server DHCP sulla macchina host. La scelta è caduta su dnsmasq che, tra le altre cose, permette anche di associare uno script che viene lanciato subito dopo la ricezione di una richiesta DHCP al server, il che ci sarà molto utile più avanti. Per quanto riguarda il file di configurazione, esso sarà molto semplice:

interface=tap0
dhcp-range=10.0.0.100,10.0.0.200,255.255.255.0,12h
dhcp-script=/bin/add_hosts.sh

La prima riga specifica su che interfaccia si vuole restare in ascolto, il perché essa sia “tap0″ verrà spiegato più avanti. La seconda è il range di indirizzi IP e la netmask che si vuole utilizzare. Infine viene specificato lo script che deve essere lanciato.

Terzo passo: la topologia

Come indicato dalla figura, la topologia è composta da 5 componenti: tre VM, un VDE Switch e una interfaccia di tap. Quest’ultima in particolare è una interfaccia di rete simulata che funziona come punto di interconnessione tra la rete virtuale e la macchina host. Utilzzandola e assegnandole un indirizzo IP (come se fosse una normale scheda di rete) la macchina host diverrà parte integrante della rete e sarà connessa direttamente alle macchine virtuali. L’interfaccia di tap (e di conseguenza la macchina host nella rete) in questo esempio ha indirizzo 10.0.0.1.

Quarto passo: dove salvare le informazioni su come raggiungere le macchine virtuali?

Le informazioni che devo salvare sono due: hostname e indirizzo IP. Qual’è il posto migliore per salvare questo tipo di informazioni, in modo che siano prioritarie rispetto ai DNS? Ovviamente la risposta è il file /etc/hosts.

Quinto passo: che parametri vengono passati allo script dal server DHCP?

I parametri che il server DHCP invia allo script che è stato configurato per essere eseguito all’arrivo di una richiesta sono 4: il comando (add se è arrivata una richiesta di assegnazione, old se la richiesta per il dato mac address è già stata servita una volta, del per il release), il mac address, l’indirizzo IP assegnato ed l’hostname. Quest’ultimo purtroppo non è sempre inviato da tutti i client DHCP, per questo ho trovato un modo alternativo per recuperare l’hostname nei casi in cui non sia fornito.

Sesto passo: script per il salvataggio delle informazioni

E questa è la parte un po’ più complicata. Ecco a voi lo script che aggiunge automaticamente al file hosts le coppie hostname – indirizzo IP delle varie VM:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110

#!/usr/bin/python
# script created by Francesco Apollonio and released under GNU General Public License version 2
# http://www.ldlabs.org/
# script that add a VM who requests an IP address using the dhcpd to local hosts file
import sys
import subprocess
import string
import time
 
debug_file="/var/log/add_hosts.log"
 
def debug(message):
   message = time.strftime("%d %b %Y %H:%M:%S") + " " + message
   print message
   fd = open(debug_file, "a")
   fd.write(message + "\n")
   fd.close()
 
text=""
for arg in sys.argv:
   text = text +" "+arg
debug(text)   
 
action=sys.argv[1]
ip=sys.argv[3]
mac=sys.argv[2]
hosts="/etc/hosts"
 
# if del action is called exit from this script
if action == "del":
   fd=open(hosts, "r")
   hosts_lines=fd.readlines()
   fd.close()
 
   fd=open(hosts, "w")
   for line in hosts_lines:
      if ip not in line:
         fd.write(line)
 
   debug( "Ok, %s deleted from %s file" % (name, hosts))
   sys.exit(0)      
 
# add address to local hosts file
 
if len(sys.argv) == 5:
   name = sys.argv[4]
   debug("host name from parameters: "+name)
else:
   command = "ps ax | grep /usr/bin/kvm"
   process = subprocess.Popen(command, stdout=subprocess.PIPE, shell=True)
   found = None
   for line in process.stdout.readlines():
      pid=line.split(" ")
      pid = pid[1]
      fd_c = open("/proc/"+pid+"/cmdline", "r")
      lines=fd_c.readlines()
      fd_c.close()
      if len(lines)>0:
         line=lines[0]
         line=string.replace(line, "-", " -")
         line=string.replace(line, "\x00", " ")
      else:
         continue
      if mac in line and "add_host" not in line:
         found = line
         break
   if found is None:
      debug("Ops, no VM with %s found" % mac)
      sys.exit(1)
   parms = found.split(" -")[1:]
   name=False
 
   for par in parms:
      if par.strip().startswith("name"):
         name = par.strip().split(" ")[1]
 
if name is False:
   debug("Ops, VM name not found")
   sys.exit(2)
 
fd=open(hosts, "r")
 
hosts_lines=fd.readlines()
fd.close()
already=False
for line in hosts_lines:
   if name in line:
      already=line
      break
change=False
if already is not False:
   if ip in line:
      debug("Ok, VM already in hosts file")
      sys.exit(0)
   else:
      change=True
 
if change is False:
   fd=open(hosts, "a")
   fd.write(ip + "\t\t" + name +"\n")
else:
   fd=open(hosts, "w")
   for line in hosts_lines:
      if name in line:
         line = ip + "\t\t" + name + "\n"
      fd.write(line)
 
fd.close()
 
debug( "Ok, %s added to %s file" % (name, hosts))

Il funzionamento è abbastanza semplice. In caso di comando “add” o “old” ricevuto dal server DHCP, lo script prima controlla se l’hostname è stato fornito dalla richiesta DHCP,  e in questo caso procede direttamente al salvataggio. Se invece l’hostname non è stato fornito, lo script scansiona la lista dei processi KVM che sono in esecuzione. Poi si procura la command line completa con le quali le macchine virtuali sono state eseguite leggendola dall’apposito file nella cartella /proc (in una prima versione usavo direttamente l’output di ps per ottenere queste informazioni, ma, in determinate circostanze, la command line veniva tagliata, rendendo inutilizzabile lo script, per questo ho optato per recuperare le informazioni da /proc). Una volta ottenuta la command line il gioco è fatto: estraggo il nome della macchina virtuale impostato in Virtualbricks, apro il file hosts controllo che non ci sia già una voce per la macchina virtuale che ha richiesto l’indirizzo; se esiste allora semplicemente aggiorno l’indirizzo IP, se invece non esiste aggiungo una nuova voce.
Per quanto riguarda “del”, invece, apro il file hosts e se vi è l’indirizzo ip specificato, elimino la linea che lo contiene.

Parte sette: conclusioni e sviluppi futuri

Bene l’architettura funziona più che bene (la utilizzo quotidianamente). Questa è ovviamente solo una applicazione per poter creare una “rete di controllo” che permetta una più semplice gestione di un numero variabile di macchine virtuali. Per i prossimi sviluppi restate in ascolto

Utilizzando macchine (virtuali e non) remote, mi capita spesso di dover utilizzare VNC per avere accesso al desktop, talvolta serve anche un ambiente grafico. Sono venuto a conoscenza qualche giorno fa di Guacamole, programma che permette di accedere al desktop VNC attraverso un normalissimo browser web che supporti però il tag canvas di HTML5.

Desktop remoto con Guacamole nel browser

Il programma funziona benissimo e velocemente, l’unica cosa un po’ complicata è l’installazione. Per prima cosa occorre installare Tomcat6. Infatti il cuore che permette il tutto è un applicazione in Java che invia al browser le informazioni per poter visualizzare il desktop. Eseguiamo l’installazione:

# apt-get install tomcat6 libvncserver0

Ora che il web server è installato, occorre scaricare il programma da questo link. Dopo aver scompattato l’archivio, quello che ci troviamo davanti sono alcuni file xml (file di configurazione) ed un war (archivio contenente l’applicazione vera e propria). Questa è la procedura d’installazione:

# cp guacamole-users.xml /etc/tomcat6/
# mkdir -p /var/lib/guacamole
# cp guacamole.war /var/lib/guacamole/
# cp guacamole.xml /etc/tomcat6/Catalina/localhost/

I file sono ora installati nel webserver ma occorre configurarli. In particolare in /etc/tomcat6/guacamole-users.xml troviamo la coppia user:password che ci viene chiesta all’apertura dell’applicazione, non si tratta della password di VNC ma di una password propria dell’applicazione. Nel file /etc/tomcat6/Catalina/localhost/guacamole.xml invece sono contenute l’informazioni del server VNC:

<Parameter name="host" value="localhost"/>
<Parameter name="port" value="5901"/>
<Parameter name="password" value="PASSWORD"/>

I parametri che ci interessano sono questi tre elencati sopra, e vanno riempiti con i dati del server VNC. In particolare per calcolare la porta, occorre ottenere il numero desktop virtuale avviato (:1 ad esempio) e sommarlo a 5900. In questo caso quindi il server a cui ci connettiamo è :1. Per avviare un nuovo server VNC ovviamente digitiamo il comando:

$ vncserver
New 'X' desktop is home:1

Se è la prima volta che avviamo un server VNC, ci verrà chiesta la password per l’accesso (non è obbligatorio inserirla), quella che deve essere inclusa nel file guacamole.xml. Ora riavviamo il server web:

# service tomcat6 restart

e colleghiamoci all’applicazione tramite il nostro browser (occhio ad utilizzare uno compatibile con il tag CANVAS di HTML5, chromium/chrome o Firefox 5 vanno benissimo) utilizzando il link:

http://localhost:8080/guacamole/

ci verrà prima richiesto di effettuare l’autenticazione del programma. Se non avete cambiato guacamole-users.xml l’username è ‘guacamole‘ e la password ‘changeme‘, ovviamente è fortemente consigliato cambiarla. Dopo aver inserito anche la password del server VNC (se ovviamente è stata impostata):

Ecco fatto ora accedere al vostro server VNC sarà molto più semplice, infatti impostando ad esempio come porta di Tomcat la 80, potrete accedere al desktop remoto in tranquillità anche in presenza di proxy non troppo permissivi!

Buon lavoro!

Quello di trovarsi a scrivere da un altra parte, perchè il mouse s’è spostato “da solo”, è un fastidiosissimo problema.

Può essere semplicemente risolto avviando il demone synaptic tramite il comando:

$ syndaemon -d -t -i 2

Dove -i2 è il tempo d’attesa dopo la pressione di un tasto per riabilitare il mouse (in questo caso 2 secondi). Si può anche bloccare il movimento del mouse (e non solo il tapping e lo scrolling) togliendo il parametro -t. Si possono ignorare la pressione di tasti speciali o di combinazioni di essi tramite le opzioni -k e -K.

Bene, ora posso tornare a scrivere

È stata appena rilasciata la nuova versione di Virtualbricks, la 0.4.276.

È principalmente una release di bugfix. Molte novità possono essere invece trovate nel branch.

Potete scaricarla da launchpad dove ovviamente potete anche lasciare i vostri feedback.

Avevo bisogno in una applicazione di salvare una password nel wallet di kde tramite python utilizzando il modulo keyring.

Utilizzo debian sid ed ho installato il pacchetto python-keyring versione 0.5.1-1 (quello presente nei repository), dove è presente un bug.
Infatti se apriamo la python shell:

1
2
3
4

import keyring.backend
kdewallet = keyring.backend.KDEWallet()
kdewallet.supported()
-1

anche la set_password da un eccezione.
Dopo un po’ di ricerche mi sono imbattuto in questa pagina: https://bitbucket.org/kang/python-keyring-lib/issue/41/kdewallet-not-working-anymore dove già dal titolo era chiaro che non ero l’unico ad avere questo problema!

Per far rifunzionare il modulo occorre scaricare la versione in sviluppo (occorre aver installato il pacchetto mercurial-git):

1
2
3

hg clone https://bitbucket.org/kang/python-keyring-lib
cd python-keyring-lib
sudo python setup.py install

Ora tutto ritorna a funzionare benissimo infatti possiamo settare la password con

1

kdewallet.set_password(SERVIZIO, USER, PASSWORD)

ottenerla con

1

kdewallet.get_password(SERVIZIO, USER)

Tutto risolto!

Ho ricevuto alcune visite in questi giorni collegate a VirtualBricks e dato che è stato anche citato in una nota rivista Gnu/Linux, meglio spiegare un po’ meglio cos’è questo software.

VirtualBricks è un software, nato a Dicembre 2010 dalla fusione tra VirtualNetmanager e Qemulator, che si propone di creare un frontend per macchine virtuali Qemu/KVM e componenti VDE.

È possibile scaricare il software dalla pagina launchpad: https://launchpad.net/virtualbrick. L’ultima release rilasciata è la 0.2 ed è mancante di molte caratteristiche. Essa infatti è stata sviluppata per avere una demo da poter mostrare all’ultimo FOSDEM tenutosi a Bruxelles a Febbraio. Da allora le modifiche apportate sono molte e, come potete leggere sul sito, in questi giorni verrà rilasciata una nuova release la 0.3, vediamo insieme alcune delle caratteristiche di questo software:

• Esso è composto da due parti una parte con GUI ed una parte che è utilizzabile da terminale. Ognuna di queste due parti permette di configurare “Brick”, cioè oggetti con parametri, che corrispondo ai vari componenti utilizzabili (macchine virtuali, VDE Switch, VDE Wirefilter, etc).
• Permette di configurare ed eseguire macchine virtuali Qemu e KVM.
• Connettere più macchine virtuali insieme tramite i componenti VDE, creando topologie complesse.
• Connettere una macchina virtuale all’host.
• Creare tunnel VPN tra più host (e quindi connettere tramite un canale cifrato più reti virtuali su host differenti).
• Completa interfaccia di configurazione per i vari componenti.

In questo articolo tratteremo il funzionamento basilare del programma, spiegando come effettuare alcune tra le operazioni disponibili.

INSTALLAZIONE

Abbiamo bisogno di un paio di librerie python:

apt-get install python-pygraphviz python-imaging

Ora aprite un terminale e, per scaricare i sorgenti della versione in sviluppo, digitate:

bzr branch lp:virtualbrick

Entrate nella cartella ed avviate lo script di installazione:

cd virtualbrick
sudo ./install.sh

Lanciate il comando virtualbricks per far partire il programma.

UTILIZZO

Come si è detto in precedenza il programma è composta da una parte da terminale ed una con GUI. Verrà per ora tralasciata la parte da terminale; essa è comunque perfettamente funzionante, basta digitare help per avere una lista completa di tutti i comandi. Analizzeremo invece passo passo le più importanti caratteristiche disponibili tramite la GUI.

Iniziamo con la finestra Preferenze, alla quale si può accedere tramite il menù in alto, Impostazioni->Preferenze:

Configurazione - Fig 1

• Direttorio Mattoni: dove VB salva le impostazioni e la lista dei brick creati
• Percorso binari VDE: se si vogliono utilizzare i componenti VDE, specificando questa directory verrà effettuato un check dei componenti installati ed eventuali mancanze verranno segnalate
• Percorso binari Qemu/KVM: Dove sono reperibili gli eseguibili di Qemu e KVM; anche in questo caso saranno effettuati dei test per controllare l’effettiva presenza di tutti gli eseguibili necessari ed eventualmente verrano segnalate le mancanze.
• Repository per le immagini disco: la directory di default che contiene le immagini dei dischi virtuali delle VM
• Usa KVM: Se utilizzare o meno KVM per le macchine virtuali (se questa check non è selezionata, sarà possibile usare solo Qemu per le VM)

Creazione immagine-> Crea nuova immagine: Pannello che permette di creare nuove immagini da utilizzare per le macchine virtuali.

In VB sono presenti 4 tab (Mattoni, Eventi, Componenti in esecuzione, Topologia). Fermiamoci ora su Mattoni, essa è una lista di tutti i brick creati e che è possibile utilizzare:

Tab Mattoni - Fig. 2

È possibile creare un nuovo Brick premendo su tasto Nuovo Mattone, selezionando il tipo e inserendo un nome. Non appena fatte queste operazioni il nuovo brick apparirà nella lista come mostrato nella Fig. 2. Creiamo ad esempio un Nuovo Mattone Macchina Virtuale e chiamiamolo ‘Linux’, una volta aggiunto nella lista, premiamo con il tasto destro sul nostro nuovo mattone e premiamo poi su Configura:

Configurazione dischi - Fig. 3

La prima cosa da configurare è l’immagine del disco per la macchina virtuale, quindi premiamo sul selettore file accanto alla scritta hda a destra e selezioniamo il file immagine da utilizzare come disco primario (notiamo che è possibile inserire svariati dischi). La check COW Privato permette di non salvare le modifiche effettuate sul disco durante l’esecuzione direttamente sul file selezionato, esse verranno salvate su di un file secondario che utilizzerà l’immagine selezionata come base (equivalente di qemu-img -b file1.qcow2 file1_pvt.cow). La check Modalità Snapshot farà perdere definitivamente qualsiasi modifica effettuata al disco durante l’esecuzione dopo la chiusura della VM.

Scheda Sistema:

Tab Sistema - Fig. 4

I parametri configurabili in questa sezione sono molto intuitivi, qui possiamo impostare: KVM abilitando l’apposita check o eventualmente scegliere achitettura, cpu e tipo di macchina, se si vuole scegliere Qemu (deselezionando la check KVM), dimensione della RAM della macchina virtuale, e molto altro.

Scheda Rete: qui è possibile scegliere che tipo di rete configurare, se connettere più componenti tramite VDE oppure la normale connessione all’host dataci da Qemu, per semplicità ora scegliamo di effettuare quest’ultima:

Tab Rete - Fig. 5

Premiamo sul radio button Connetti alla rete, selezioniamo dalla combo Connetti a “Host-only ad hoc network” e premiamo sul tasto Aggiungi una scheda di rete, essa ora apparirà nella lista sinistra.

Infine selezioniamo una immagine per la nostra nuova macchina virtuale tramite la scheda Configura Mattone:

Tab Configura Mattone - Fig. 6

Premiamo ora sul tasto Ok in basso in modo da non perdere le modifiche effettuate alla configurazione.

Una volta ritornati nella nostra lista dei bricks, facciamo ora click con il tasto destro del mouse sul brick appena creato e clickiamo su Avvia Mattone, la macchina virtuale partirà:

Macchina virtuale avviate - Fig. 7

Passiamo ora alla scheda Componenti in esecuzione: questa tab contiene tutti i componenti lanciati, e tramite il menu di configurazione è possibile eseguire alcune operazioni:

• Apri terminale di controllo: apre in una nuova finestra la console di configurazione della macchina Qemu
• stop job: invia al processo della macchina virtuale un segnale di stop
• continue job: invia al processo della macchina virtuale un segnale di continua ad eseguire (solo se prima è stato bloccato tramite il precedente comando)
• Sospendi Qemu: sospendi la macchina virtuale sul disco immagine
• Invia poweroff ACPI: invia un il power off alla macchina virtuale (equivalente di premere il tasto di spegnimento su una macchina reale), la VM quindi si spegne correttamente
• Invia hard reset ACPI: invia un reset alla macchina virtuale (equivalente di premere il tasto reset su una macchina reale)
• reset job: kill del processo e riavvio della macchina virtuale
• kill job: kill del processo

Scheda Topologia:

La topologia è una visuale grafica di come i vari bricks son collegati tra loro, è possibile effettuare alcune operazioni direttamente da questa tab come Avvia/Ferma, Cancella, Configura, Crea una copia, Sospendi VM.

Scheda Eventi: gli eventi sono degli automatismi che si possono inserire nelle configurazioni; se si vuole simulare ad esempio che dopo N secondi una VM si spenga è possibile inserire un apposito evento in questa tab. È possibile inserire come eventi qualsiasi comando presente nella shell. Questa caratteristica è molto utile ad esempio se si vogliono eseguire alcuni test e, magari utilizzando l’emulatore di canale VDE Wirefilter, cambiare la banda disponibile tra due VM automaticamente dopo N secondi.

CONCLUSIONI

In questa rapida carrellata sono state analizzate solo alcune delle caratteristiche principali di questo software, in pentola ci sono molte altre feature; se volete avere un idea più completa vi consiglio di guardare la sezione Blueprint dello spazio launchpad del progetto, alcune delle caratteristiche in sviluppo sono:

• Miglioramento della shell con il supporto per l’autocompletamento
• Gestione remota di brick creati su host remoti
• Live migration
• Salvataggio e ripristino di progetti (topologie e liste di brick differenti)

Vi voglio ricordare che il progetto ha solo 3 mesi di vita, aiutateci e segnalateci tutti i bug e, perchè no, eventuali caratteristiche aggiuntive.

Vi ripeto i contatti: https://launchpad.net/virtualbrick e http://www.virtualbricks.eu/ provatelo e fatemi sapere cosa ne pensate!

Mi serviva un modo per testare uno scriptino in javascript al volo e mi sono imbattuto in questa pagina:

Script carino e soprattutto molto utile in caso di emergenza!

Da annotare!

Visitate questo link: VirtualBricks – GUI per la configurazione di macchine Qemu/KVM e componenti VDE.

Molto spesso ho bisogno di sincronizzare i file del mio netbook con quelli del fisso, ecco che m’aiuta questo script che ho realizzato.

Sfruttando ssh e l’autenticazione a chiave pubblica/privata il programma, leggendo dal file toSynchronize.list le cartelle da sincronizzare, controlla quali file sono più aggiornati e, se richiesto, effettua l’aggiornamento.

Lo script ha una semplice gui Qt4 che permette anche la configurazione di base.

Per il funzionamento lo script richiede le librerie python-paramiko.

Potete scaricare la versione 0.2 da qui.

If kde panel override  vlc’s fullscreen, you need to install vlc 1.0.4.
How to install vlc-1.0.4 in debian squeeze (64b)  from sid packages:

Remove old version:

apt-get remove vlc-nox

Get packages:

wget http://ftp.dk.debian.org/debian/pool/main/v/vlc/vlc-nox_1.0.4-2_amd64.deb
wget http://ftp.hu.debian.org/debian/pool/main/v/vlc/vlc_1.0.4-2_amd64.deb

Install dependencies:

apt-get install libxcb-keysyms1

Install new packages:

dpkg -i vlc-nox_1.0.4-2_amd64.deb vlc_1.0.4-2_amd64.deb