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!

Sviluppano spesso siti web di vario genere, mi sono trovato a dover gestire un form html con Ajax. Il problema non è stato tanto per i dati testuali normali, quanto principalmente perchè dovevo trasferire un file via AJAX.

Lo strumento che ho utilizzato è JQuery Form Plugin. Tre parole per descriverlo? Semplice, rapido e funzionante!

Per prima cosa vediamo la pagina HTML (con l’annesso form per l’upload):

<html>
	<head>

		<meta http-equiv="content-type" content="text/html; charset=UTF-8">
		<script type="text/javascript" src="jquery-1.5.1.min.js" ></script>
		<script type="text/javascript" src="jquery.form.js" ></script>
		<script type="text/javascript" src="scripts.js" ></script>
		</script>
		<title>Pagina di prova</title>

	</head>
	<body>

		<form action="file_upload.php" method="post"
			enctype="multipart/form-data" id="upload">

			<label for="file">Filename:</label>
			<input type="file" name="file" id="file" /><br />
			<input type="submit" id="send_file" value="Aggiungi" />

		</form>

	</body>
</html>

Ovviamente, come si può vedere analizzando l’html, occorrono altri due file. Il primo è il file javascript che ci permetterà di gestire l’invio lato client. Il secondo è il file in PHP che ci permette di gestire l’upload dal lato server. Analizziamo il file javascript (script.js):

1
2
3
4
5

$(document).ready(function() {
	$("#upload").ajaxForm(function(resp) {
		alert(resp);
	});
});

Come si può facilmente capire il funzionamento è semplice. Basta associare l’AjaxForm all’id del form html ed il gioco è fatto. Ovviamente nella funzione di risposta si può effettuare qualsiasi operazione, utilizzando la variabile resp che contiene l’output della pagina che si occupa dell’upload lato server. Ecco il codice PHP (file_upload.php):

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<?php
// CONTROLLO DEI PARAMETRI!
$path="PERCORSO_DOVE_SALVARE_IL_FILE/";
if ($_FILES["file"]["error"] > 0) {
	echo "ERROR";
} else {
	if (file_exists($path . $_FILES["file"]["name"])) {
		echo "File already exists.";
	} else {
		move_uploaded_file($_FILES["file"]["tmp_name"], $path .  $_FILES["file"]["name"]);
		echo "OK. File uploaded.";
	}
}
?>

che semplicemente salva il file nella directory specificata e ritorna un messaggio che indica se l’operazione è andata a buon fine. Ricordatevi ovviamente, se utilizzate lo script in PHP per il vostro sito, di eseguire le operazioni di controllo dei parametri in ingresso via POST.

Come potete vedere è veramente una passeggiata, buon lavoro!

Abbiamo visto come caricare sulla scheda un firmware che già abbiamo, ma come possiamo compilarne uno noi?

Layout della board

Il primo passo è ovviamente ottenere il compilatore, chi ha letto il vecchio articolo avrà sicuramente notato, in fondo alla pagina, la presenza del link ad un compilatore ARM, è proprio quello che utilizzeremo per creare il firmware da caricare:

wget http://www.codesourcery.com/sgpp/lite/arm/portal/package8734/public/\
arm-none-eabi/arm-2011.03-42-arm-none-eabi-i686-pc-linux-gnu.tar.bz2
tar jxvf arm-2011.03-42-arm-none-eabi-i686-pc-linux-gnu.tar.bz2

Facciamo attenzione alla directory che utilizziamo per contenere il compilatore, dato che ci servirà per permetterci di raggiungerlo, infatti occorre impostare una variabile del nostro terminale con il percorso esatto. Dal terminale dove successivamente eseguiremo la compilazione digitiamo:

export CROSS_COMPILE=/PERCORSO_VERSO_IL_COMPILATORE/arm-2011.03/bin/arm-none-eabi-

In alternativa possiamo aggiungere la riga all’interno del file ~/.bashrc in modo da non doverlo riscrivere ogni volta.

Ora non ci resta che trovare qualcosa da compilare. Per i miei esperimenti utilizzo il mini-sistema operativo creato da Alessandro Rubini per processori Cortex-M3 che si può scaricare da questo indirizzo. Questo sistema è un buon inizio per inziare a muovere i primi passi con la board (sto inziando anche io con questo), infatti permette di avere un sistema che si avvia e sul quale è possibile effettuare delle aggiunte. Una volta scaricato e scompattato, occorre prima effettuare una modifica al main.c:

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

#include <stdint.h>
#include "io.h"
 
void main(void)
{
 volatile int i;
 int on = 0;
 
 /*
 * Call the mimmo application. Turn this if to false if you want to
 * run the older code that just flashes leds
 */
 if (0) {
 extern void do_mimmo(void);
 do_mimmo();
 }
 
 /* Older led-toggling application */
 *(volatile uint32_t *)0x50038000 = 0xf; /* port C: all 4 out */
 
 while (1) {
 puts("stuff\n");
 if (++on & 1)
 *(volatile uint32_t *)0x5003003c = 0xf;
 else
 *(volatile uint32_t *)0x5003003c = 0;
 for (i = 0; i < 1000*1000; i++)
 ;
 }
}

In particolare occorre modificare la riga 13, non facendo entrare il programma all’interno dell’if, cambiano quindi l’1 in 0. Dopo aver salvato il file, non ci resta che lanciare il comando

make

dalla cartella estratta per eseguire la compilazione. Come si può leggere dal pdf allegato ai sorgenti, vengono creati due file bin, uno per l’esecuzione da ROM e uno per l’esecuzione da RAM. Dato che per programmare la RAM è necessario usare UART, quello che interessa a noi e che quindi dobbiamo trasferire sulla board è il file m3c.rom.bin:

mdel c:firmware.bin
mcopy m3c.rom.bin c:new.bin

Per chi non capisse cosa sono questi ultimi due comandi, consiglio la lettura del precedente articolo che spiega, tra l’altro, come configurare mtools per permettere il riconoscimento della board. Dopo aver resettato la board (togliere il jumper dai piedini JMP BLD_E e premere il tasto di Reset) il nuovo programma appena compilato e caricato verrà eseguito, facendo lampeggiare 4 led.

La prossima volta vedremo come accedere ai registri di configurazione e accendere dei led a piacere.

Avevo la necessità di utilizzare il programma per il cellulare ufficiale Nokia, che ovviamente gira solo su Windows. Perchè non farlo tramite macchina virtuale e con il cellulare collegato all’host?

L’operazione è molto semplice, dopo aver collegato il cellulare all’host digitare lsusb per capire idVendor e idProduct del dispositivo:

$ lsusb
Bus 004 Device 013: ID 0421:02ba Nokia Mobile Phones

Apriamo ora il file /etc/udev/rules.d/55-udev-user.rules ed aggiungiamo:

SUBSYSTEM=="usb", ATTR{idVendor}=="0421", ATTR{idProduct}=="02ba", GROUP="kvm", MODE="0666"

dovete anche posizionare dopo idVendor e idProduct i valori corretti del vostro dispositivo. In questo modo assegnerete i privilegi sul device agli utenti del gruppo kvm, al quale dovete far parte per poter lavorare tramite la macchina virtuale sul device usb.

Dopo aver riavviato o il computer o udev, colleghiamo il cellulare e successivamente digitiamo il comando seguente cercando la linea simile a quella qui visualizzata:

$ dmesg | tail
[38743.556863] usb 4-1.4.3: new full speed USB device number 15 using ehci_hcd

In particolare ci serve quel numero (15 nel mio caso) perchè successivamente:

ls -la /dev/bus/usb/004/ | grep 15
crw-rw-r-- 1 root kvm  189, 398 27 giu 19.18 015

ci serve per controllare che effettivamente il gruppo del device sia kvm. Ora avviate la macchina virtuale KVM e premete ctrl+alt+2 per passare alla console di Qemu (o da virtualbricks premete con il tasto destro sul brick attivo e selezionate console). Qui scrivete:

usb_add host:0421:02ba

e magicamente il cellulare verrà magicamente riconosciuto dalla vostra macchina virtuale!

Ecco fatto, semplice vero?

Ho da poco acquistato (da OLIMEX) una LPC-P1343, board poco costosa (circa 15€) e ottima per iniziare a lavora con la programmazione embedded.

La board ha un microcontrollore LPC1343 (Cortex-M3), connettore UEXT, USB, otto led, due tasti utilizzabili per le proprie applicazioni, una area di prototipazione e molto altro (scheda completa).

La board LPC-P1343

In questo primo articolo si vedrà come programmare la board, scrivendo la flash tramite l’USB.

Layout della board

Come si può vedere dall’immagine qui sopra, la scheda ha due pin cortocircuitabili con un jumper (indicati come JMP BLD_E). Normalmente, con i pin non connessi, la scheda prende dall’USB solo l’alimentazione ed esegue il programma caricato al suo interno. Chiudendo i piedini, la board passa in modalità programmazione e il computer rileverà una nuova unità disco.

Teoricamente bastebbe copiare il  firmware compilato all’interno di questa unità disco per programmare la board. Ma ovviamente non sempre la vita è così semplice…

Questa scheda in particolare è stata implementata utilizzando le specifiche di un file system di tipo DOS. Quindi ci si presentano due problemi:

• il nome del file deve essere nel formato 8.3 caratteri (e:. nuovo.bin, firmware.bin, etc)
• in windows i blocchi sono allocati in maniera sequenziale al contrario di quanto avviene in sistemi Linux

Per ovviare a quest’ultimo problema, occorre utilizzare mtools, strumenti per la manipolazione di file system di tipo DOS. L’installazione è semplice (apt-get install mtools in sistemi debian-like), subito dopo occorre  modificarne la configurazione, editando il file /etc/mtools.conf aggiungendovi il nostro device driver:

drive c: file="/dev/disk/by-id/usb-NXP_LPC134X_IFLASH_ISP000000000-0:0" exclusive

Da ora si possono utilizzare i comandi mdir, mdel, mcopy per (rispettivamente) visualizzare i file contenuti, cancellarli o copiarli. Ad esempio:

mdel c:firmware.bin
mcopy nuovo.bin c:nuovo.bin

Una volta copiato il nuovo firmware, disconnesso i pin (togliendo il jumper) e resettata la board (tramite il tasto di reset), il programma appena caricato verrà eseguito al posto di quello standard.

NOTE: È consigliabile salvare il firmware di default prima di scriverci un altro, in modo da poterlo ripristinare all’occorrenza (mcopy c:firmware.bin orig.bin). Una volta caricato il nuovo firmware il file verrà comunque rinominato in firmware.bin, quindi quello da cancellare prima di copiare il nuovo file è sempre firmware.bin.

Questo è giusto un anticipo, non appena avrò il tempo di iniziare a giocarci vedrete un po’ quello che si può fare. Vi allego comunque un po’ di link utili.

A presto.

Scheda della board:
http://olimex.com/dev/lpc-p1343.html
Vari file (pdf scritti da Alessandro Rubini):
http://www.gnudd.com/wd/cortex-m3.pdf
http://gnudd.com/wd/thos.pdf
Compilatore ARM:
http://www.codesourcery.com/sgpp/lite/arm/portal/package8734/public/arm-none-eabi/arm-2011.03-42-arm-none-eabi-i686-pc-linux-gnu.tar.bz2
Microcontrollore (dal sito del produttore):
Datasheet
User Manual
File Esempio

Utilizzando Debian Unstable a 64 bit, flashplugin-nonfree ed un qualsiasi browser che lo supporti (chromium, google-chrome, iceweasel, firefox), l’audio di alcune applicazioni flash risulta essere molto disturbato con fruscii, echi e molti altri rumori.

Il bug è legato ad un cattivo utilizzo della memcpy. La soluzione più semplice è precaricare la libreria, lanciando il browser con il seguente comando:

LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libc/memcpy-preload.so iceweasel

Ovviamente potete utilizzare iceweasel o un qualsiasi altro browser prima citato.
Altre informazioni sul bug possono essere trovate qui (in inglese).

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

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!

Video tutorial che mostra come connettere due macchine virtuali tra di loro utilizzando un vde switch, il tutto tramite Virtualbricks!