Sono passati quattro anni e il movimento Fon, almeno qui in Italia, ha perso ogni impulso, almeno per quanto mi riguarda. Stefano ha abbandonato il progetto, lasciando nelle buone mani di Michelangelo la gestione dei foneros italiani e del blog.

Insomma, Fon ha perso il suo brioso spirito iniziale, ma rimane pur sempre una community che realmente ha distribuito quasi 2 milioni di router in giro per il mondo. Non ha realizzato il sogno di una rete globale wifi mantenuta dagli utenti, ma rimane sempre il miglior progetto wireless esistente.

In questo quadro generale non proprio esaltante arriva un nuovo router dopo la controversa Fonera 2.0n. Ne avevo parlato su queste pagine un anno fa, evidenziando caratteristiche decisamente superiori alle precedenti fonere, ma raccogliendo nei commenti successivi molti problemi legati al chip Ralink 3052F e ai drivers non testati per il dual SSID. I problemi sono stati poi risolti ad Aprile 2010 con il firmware 2.3.6.0.

La nuova fonera è la SIMPL

Chip Ralink RT3050F a 320Mhz, 2MB Flash(pochi!), 32 Mb RAM 1 porta WAN e 1 porta LAN, 802.11n, antenna rimovibile.

Il tutto al prezzo di lancio di 39 Euro incluse spese di spedizione. Non è ancora stata pubblicizzata nello store front di shop.fon.com, ma è ordinabile a questo link https://shop.fon.com/FonShop/shop/FPPLoginOrRegisterController?purchase=1:PRD-023

Aspetto di riceverla al più presto da Michelangelo per riportarvi le mie impressioni a riguardo.

Foto credits: Steven Leeman http://picasaweb.google.be/steven.leeman/2305E#

Può capitare di voler aggiungere qualche pacchetto, ma essendo scaduto il supporto, apt-get install non funziona più.

La soluzione è cambiare il file sources.list, elencando come target old-releases.ubuntu.com. Ecco un esempio con Gutsy 7.10  :

deb http://old-releases.ubuntu.com/ubuntu/ gutsy main restricted
deb http://old-releases.ubuntu.com/ubuntu/ gutsy-updates main restricted
deb http://old-releases.ubuntu.com/ubuntu/ gutsy universe
deb http://old-releases.ubuntu.com/ubuntu/ gutsy-updates universe
deb http://old-releases.ubuntu.com/ubuntu/ gutsy multiverse
deb http://old-releases.ubuntu.com/ubuntu/ gutsy-updates multiverse
deb http://old-releases.ubuntu.com/ubuntu/ gutsy-security main restricted
deb http://old-releases.ubuntu.com/ubuntu/ gutsy-security universe
deb http://old-releases.ubuntu.com/ubuntu/ gutsy-security multiverse

Dopo un apt-get update possiamo nuovamente aggiungere il pacchetto preferito con apt-get install.

Era il 1994 e cominciavano ad uscire sul mercato i primi telefonini senza antenna esterna.

Ricordo come fosse oggi la conversazione condita da abbondante ironia toscana tra Danilo, radioamatore di vecchia data, ed un suo amico sull’efficienza dei telefonini con antenna interna.

Amico di Danilo:” Ho letto su “Il cellulare” che questi nuovi telefonini senza antenna funzionano da dio!”
Danilo:”Come no! Ad esempio io in cantina ho un vecchio televisore, la mia casa è di quelle di un tempo con i muri spessi, sai?
ADD:” Sì, ho presente, ma che c’entra il televisore?”
D.:” Aspetta che ti dico. Insomma lì sotto c’è questo televisore, ma non gli ho attaccato l’antenna sul tetto, ho usato una di quelle antenne portatili, anzi ho aperto il pannello posteriore  e l’ho messa dentro lo chassis. Vedessi come si vede bene!”
ADD:”Mi stai prendendo per il culo?”
D.:”Fai te!”

Tutto questo per dire che :
1)anche se l’intensità del segnale è decuplicata rispetto a 10 anni fa, un telefonino rimane sempre una ricetrasmittente e quindi ha bisogno di un efficiente impianto d’antenna.
2)L’antenna va bene montata internamente ma va installata nel posto più scoperto del telefono, tipicamente a contatto del pannello posteriore vicino all’estremità superiore dell’unità.
3)Alla luce di queste considerazioni, come cazzo ti può venire in mente di posizionare l’antenna in basso a sinistra!

Finalmente ho deciso di dotarmi di una postazione di home entertainment in salotto così composta :

Tv lcd full HD 37 pollici LG 37LD428
Decoder sky HD
Asus eeebox  PC EB1501

Se ovviamente lato televisore e decoder c’è veramente poco da smanettare nel piccolo eeebox possiamo mettere le mani con soddisfazione  e creare un media center di tutto rispetto mantenendo ingombro e rumorosità sotto controllo e, cosa da non sottovalutare, senza deturpare l’arredo con “case” catafalchi e grovigli di fili.

L’eeebox EB1501 è stato scelto fra i vari nettop principalmente per tre motivi.
Il primo è che ho un’ottima stima di Asus come produttore e nessuna brutta esperienza con i suoi prodotti, il secondo è la dotazione di serie di un telecomando a raggi infrarossi e un ricevitore IR integrato, indispensabile per un mediacenter e l’ultimo perché è uno dei pochi nettop che incorpora anche il lettore DVD (sempre più raramente, ma a volte può capitare di vederne uno).

Per il resto le caratteristiche sono quelle di un comune nettop: intel atom 330 dual core, 2 Gb Ram, disco da 250 Gb, grafica Nvidia ION, porta Lan e WLAN b/g/n.

Non mi dilungo sulle valutazioni dell’hardware in quanto l’Eeebox EB1501 è ormai in commercio da un pezzo ed è stato già rivoltato come un calzino.

Vediamo come al solito passo passo come procedere all’installazione del software che si appoggerà su Ubuntu 9.10 e XBMC.

Ubuntu 9.10? Ma è uscita la 10.4 ormai da tre mesi, perché usare la release vecchia?
Vi rispondo con tre notti insonni, scandaglio totale del forum di forum.xbmc.org per far funzionare a dovere lirc(senza successo), inceppamenti del sistema e problemi al wifi.
Per il computer da salotto volevo che tutto funzionasse al volo senza troppi sbattimenti e la Lucid Lynx non è riuscita a soddisfare questa mia necessità, quindi, Karmic Koala

Installazione Ubuntu 9.10, XBMC e Drivers Nvidia

Se non siamo in possesso della vecchia iso possiamo andare a prenderla dagli archivi Ubuntu a questo indirizzo.
Colleghiamo la presa hdmi al pannello LCD e facciamo il boot da cd o da pendrive.
L’installazione procede senza nessun intoppo ed alla fine tutte le periferiche verranno riconosciute ad eccezione della scheda grafica Nvidia, della quale verrà proposto un driver “restricted” che non installeremo.

Provvederemo infatti ad installare i drivers proprietari Nvidia e le estensioni vdpau per l’offload di alcune porzioni della decodifica dei file MPEG dalla cpu verso la gpu permettendo la visione fluida di filmati a 1080p. Inoltre installeremo il mediacenter XBMC, tramite l’aggiunta della sua repository.

sudo apt-get install python-software-properties -y
sudo add-apt-repository ppa:team-xbmc
sudo add-apt-repository ppa:nvidia-vdpau/ppa
sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 91E7EE5E 318C7509

Aggiorniamo ed installiamo XBMC

apt-get update && sudo apt-get upgrade
apt-get install xbmc xinit x11-xserver-utils -y

L’installazione di XBMC sarà un po’ lunga per l’elevato numero di pacchetti necessari per soddisfare le dipendenze del nostro mediacenter.

Installiamo ora i drivers Nvidia e Vdpau

apt-get install nvidia-glx-195 mesa-utils libvdpau1 libvdpau-dev vdpauinfo pkg-config -y

Generiamo un xorg.conf per i nostri scopi

nvidia-xconfig -s --no-logo --force-generate --output-xconfig=/etc/X11/xorg.conf

ed editiamolo a mano per una migliore performance della nostra scheda video

nano /etc/X11/xorg.conf

e aggiungiamo alla sezione “Device” le seguenti righe

Option "HWCursor" "False"        # Blinking Cursor Fix
Option "DynamicTwinView" "false" # Enable 1080p 24Hz

E alla fine del file disabilitiamo composite per una migliore performance

Section "Extensions"
         Option         "Composite" "Disable" # Disable Composite for better H264 acceleration
EndSection

A questo punto possiamo riavviare la macchina o caricare il driver Nvidia

modprobe nvidia

E far ripartire il server grafico.

Audio via HDMI

Dopo il reboot il nostro schermo dovrebbe essere settato alla corretta risoluzione di 1920×1080 a 60Hz.
Dobbiamo ancora sistemare però l’audio via HDMI che di default è azzerato.

Per far questo apriamo la shell e diamo il comando alsamixer. Con il cursore ci spostiamo a selezionare i 3 valori IEC958 e con il tasto “M” provvediamo a levare il mute sul canale.

Drivers wireless

La Ubuntu 9.10 nonostante riconosca il chip AR9285 e carichi i moduli ath9k non riesce a fornire prestazioni accettabili per il link wifi. I driver a corredo offrono un collegamento altamente instabile con disconnessioni ogni 10 secondi quando si effettua un download e non possono in definitiva essere usati.

Per ovviare dobbiamo procurarci gli ultimi driver compat wireless e compilarli per il nostro kernel. Possiamo scaricare l’ultima versione da linuxwireless.org oppure usare la release 27-06-2010 che ho installato sul mio sistema e verificato funzionare perfettamente.

Una volta scaricato il pacchetto compat-wireless-2.6.tar.bz2, dobbiamo scompattarlo e procurarci gli strumenti per compilarlo.

Installiamo i build-essential e gli header del kernel in uso

apt-get install build-essential
apt-get install linux-headers-`uname -r`

Posizioniamoci poi nella directory dove abbiamo scaricato i compat-wireless e diamo i seguenti comandi

tar xjvf compat-wireless-2.6.tar.bz2

cd compat-wireless-2.6
./scripts/driver-select ath9k
make
make install

Alla fine del processo rimpiazzeremo il modulo ath9k dello stock kernel di Ubuntu 9.10 con un nuovo perfettamente funzionante ath9k.  Dopo il reboot.

Telecomando IR

Per prima cosa procuriamoci i pacchetti di Lirc e i moduli necessari

apt-get install lirc lirc-modules-source module-assistant
dpkg-reconfigure lirc-modules-source #ridondante? 

Dovrebbe essere sufficiente per caricare all’avvio sia il demone Lirc che il modulo lirc_it87, ma sfortunatamente senza un ulteriore ritocco, non funzionerà dal momento che il dispositivo ITE8713 viene caricato all’avvio in stato disabled.

Per ovviare a questo inconveniente dobbiamo editare lo script di init di lirc inserendo alla linea 173 la seguente stringa

echo activate > /sys/devices/pnp0/00:09/resources

A questo punto dobbiamo mettere mano ai file di configurazione di lircd in modo che riconosca correttamente il nostro telecomando.

wget http://nfye.com/EB1501/hardware-german.conf -O /etc/lirc/hardware.conf
wget http://nfye.com/EB1501/lirc.conf -O /etc/modprobe.d/lirc.conf
cp /usr/share/lirc/remotes/mceusb/lircd.conf.mceusb /etc/lirc/lircd.conf
cp /usr/share/xbmc/system/Lircmap.xml ~/.xbmc/userdata

Riavviamo la macchina e controlliamo se il telecomando è stato riconosciuto correttamente con questa procedura:
1) lanciamo il comando irw
2) premiamo qualche pulsante sul telecomando
3) se tutto è andato bene dovremmo veder apparire del testo nel terminale

Il telecomando lo abbiamo sistemato.

XBMC

Il programma xbmc.bin può essere lanciato ora e a pieno schermo dovrebbe apparire la schermata di benvenuto

Proviamo a navigare con i tasti freccia del telecomando, tutto dovrebbe funzionare senza problemi. Se non riusciamo a comandare l’interfaccia tramite il telecomando qualcosa è andato storto nel setup appena descritto sopra. Possiamo perdere anche tre notti di sonno per capire cosa, vi lascio provare l’ebbrezza, io l’ho già provata

Per ritornare al desktop di gnome si può premere il tasto “\” e far girare xbmc in windowed mode e con il terminale cercare di fare del debug o editare i file di configurazione e riprovare. Tenete presente che tramite tastiera si comanda senza problemi, la parte più astiosa è la configurazione del telecomando.

Se vogliamo far partire xbmc all’avvio di ubuntu dobbiamo eseguire i seguenti passi:

1) Settare il login automatico da gdm. Da Gnome scegliere: Sistema->Amministrazione->Schermata di Accesso e scegliere Accedere come $nomeutente automaticamente

2) Disabilitare la richiesta di password del portachiavi di gnome. Sempre da Gnome scegliere: Applicazione->Accessori->Password e chiavi di cifratura. Selezionare Password:login, cliccare con il tasto destro e scegliere: Cambia password. Immettere la propria password corrente e lasciare vuoti i due campi della nuova password. Scegliere: usa archiviazione non sicura

3) Far partire XBMC all’avvio di Gnome. Da Sistema->Preferenze->Applicazioni d’avvio aggiungere xbmc alla lista dei programmi in esecuzione automatica.

A questo punto se tutto è andato liscio al reboot dovremmo avere direttamente la schermata di XBMC all’avvio del computer ed essere in grado di comandare il mediacenter unicamente con il telecomando IR, compreso lo spegnimento e l’accensione tramite il tasto “power”.

Alto utilizzo della cpu

Grazie alle API Vdpau XBMC è in grado di riprodurre filmati a 1080p senza nessuno sforzo, fluidi e ben definiti, con un impegno di cpu attorno al 5%!

La cosa che però salta subito all’occhio è l’elevato uso di CPU quando XBMC è in idle mode, mostrando unicamente la sua interfaccia. E’ un comportamento bizzarro ma che ha la sua spiegazione. Quando non viene invocato nessun player infatti l’interfaccia viene renderizzata a 60 frame al secondo, impegnando di conseguenza la cpu del sistema.

Per ovviare a questo inconveniente è necessario impostare al posto di dim on idle, black on idle, facendo in modo che dopo tre minuti di inattività la gui venga oscurata completamente invece che adombrata.

Sperando che questo post vi possa essere stato d’aiuto, mi pongo come al solito all’ascolto dei vostri commenti per eventuali correzioni, migliorie, insulti etc etc.

Credits:
Xbmc Wiki (parte 1)
Xbmc Wiki (parte 2)
Xbmc Forum

It’s happened to all of us. The night starts off innocently enough with a little gin and tonic, maybe a mojito, then next thing you know you’re doing tequila shots with the bartender and the girl from Brazil and you find yourself thinking it would be a treMENdous idea to call up your ex and see how they’re doing and perhaps impress them with your newfound wit.

We’ve got the cure. Now, instead of drunk dialing random friends, lovers, and acquaintances one at a time, what if you could dial your blog and talk to the whole world at once? It’d be like something out of Star Trek.

Vebbè Matt, io l’ho provato ed è meraviglioso, anche se dissento dal tuo esempio di utilizzo di questa nuova feature

Il costo del post varia da operatore, dal momento che bisogna chiamare un numero USA (con tre 0.25 € al minuto) ma è un prezzo accettabile considerata l’immediatezza dello strumento: chiami il numero, inserisci il codice, registri il messaggio, premi # ed il post viene immediatamente pubblicato.

Awesome!

Ho cercato in rete se esisteva già qualche setup, ma ho trovato solo una guida per zeroshell e alcune discussioni su forum che però non erano pienamente esaustive.

Partendo quindi dal semplice concetto che per effettuare uno switch al volo occorre testare il default gateway e nel caso fallisca attivare il gateway su rete cellulare e il masquerading  attraverso esso, ho buttato giù questo accrocchio immondo in shell script.

Il meccanismo si basa su quattro script chiamati pingeth1, killpingeth1, pingppp0, killpingppp0.

Lo script principale è pingeth1

#/bin/bash
ping -I eth1 -c3 151.99.29.203 > result.tst;
ALERT=`grep -c "3\ received" result.tst`
if [ $ALERT = 1 ] ; then
echo "ok"
else
wvdial &
sleep 10
/usr/local/bin/killpingeth1
/sbin/shorewall clear
/sbin/iptables  -t  nat  -A  POSTROUTING  -o  ppp0 -j  MASQUERADE
/sbin/route add default gw 10.64.64.64 dev ppp0
fi
rm result.tst
exit 0

Esaminiamo nel dettaglio quanto sopra:

Vengono lanciati 3 ping attraverso eth1 (porta wan collegata al router adsl) verso il nodo p-t-p della connessione (151.99.29.203) e il risultato viene scritto nel file temporaneo result.tst

Viene introdotta la variabile ALERT ottenuta greppando e contando l’occorrenza del termine “3\ received” dal file temporaneo result.tst.

Se il valore di ALERT è uguale ad 1, lo script si limita a stampare la scritta OK, se il valore di ALERT è diverso da 1 viene nell’ordine:

1)lanciato wvdial in backgroud
2)inserito un sleep di 10 secondi per permettere a wvdial di alzare correttamente la connessione
3)invocato lo script killpingeth1 (che vedremo più sotto)
4)resettate le regole del firewall in essere
5)inserita una nuova regola di iptables per il masquerading attraverso l’interfaccia ppp0
6)aggiunta la nuova default gateway attraverso l’interfaccia ppp0

Viene infine rimosso il file temporaneo result.tst.

Pingeth1 va eseguito ogni minuto da cron, per cui occorre creare un nuovo cronjob

crontab -e
*/1 * * * * /usr/local/bin/pingeth1 >/dev/null

Esaminiamo ora lo script killpingeth1

#/bin/bash
crontab -l >CRON_TEMP
awk '$0!~/pingeth1/ { print $0 }' CRON_TEMP >CRON_NEW
echo "*/1 * * * * /root/pingppp0 >/dev/null" >>CRON_NEW
crontab CRON_NEW
/etc/init.d/cron restart
rm CRON_TEMP;
rm CRON_NEW;
exit 0

La funzione primaria di killpingeth1 è quella di cambiare lo schedulatore, rimuovendo la programmazione di pingeth1 ed inserendo la nuova programmazione di pingppp0 (che vedremo più sotto).

Invocato unicamente in caso di mancata risposta del gateway primario killpingeth1 esegue i seguenti passaggi:

1)Elenca il contenuto del crontab e lo scrive in un file temporaneo CRON_TEMP
2)verifica la presenza della stringa pingeth1 sul file temporaneo CRON_TEMP e se presente la elimina scrivendo un nuovo file CRON_NEW
3)appende alla fine del file CRON_NEW la nuova schedula di pingppp0
4)installa il nuovo cronjob
5)rimuove i file temporanei CRON_NEW e CRON_TEMP

Da questo momento la connessione è instradata attraverso ppp0, però con un monitor sempre attivo sull’interfaccia principale, in modo che, se la connessione dovesse essere ripristinata, si ritorni in modo automatico alle condizioni di lavoro predefinite.

Il controllo dell’interfaccia eth1 viene demandato allo script pingppp0 che abbiamo inserito nel nuovo cronjob.

Vediamolo in dettaglio

#/bin/bash
/sbin/route del default gw 192.168.0.1 dev eth1
/sbin/route add default gw 192.168.0.1 dev eth1
ping -I eth1 -c 3 151.99.29.203 > result.tst;
ALERT=`grep -c "3\ received" result.tst`
if [ $ALERT = 1 ] ; then
killall wvdial
/usr/local/bin/killpingppp0
/sbin/shorewall restart
else
echo "ancora su linea backup"
/sbin/route del default gw 192.168.0.1 dev eth1
fi
rm result.tst
exit 0

Lo script pingppp0 viene eseguito ogni minuto e compie la seguente routine:

Cancella ed aggiunge la default gateway su eth1 (workaround orrendo, ma senza questo passaggio il ping di controllo non riusciva a passare dall’interfaccia eth1, se qualcuno ha una soluzione può integrare e migliorare questo passaggio)

Esegue i soliti 3 ping verso il nodo p-t-p della connessione (151.99.29.203) e il risultato viene scritto nel file temporaneo result.tst

Introduce la variabile ALERT ottenuta greppando e contando l’occorrenza del termine “3\ received” dal file temporaneo result.tst.

Se il valore di ALERT è uguale ad 1 viene nell’ordine:

1)abbattuto il processo wvdial facendo così cadere la connessione 3G
2)invocato lo script killpingppp0 ( che vedremo più sotto)
3)fatto ripartire il firewall

Se il valore di ALERT è diverso da 1 si limita a stampare la stringa “ancora su linea backup” e cancella la default gateway su eth1, rimuovendo come ultimo comando il file temporaneo result.tst.

Rimane da prendere in esame l’ultimo script killpingppp0 che si prende cura di ripristinare il corretto cronjob su pingeth1

Ecco lo script:

#/bin/bash
crontab -l >CRON_TEMP
awk '$0!~/pingppp0/ { print $0 }' CRON_TEMP >CRON_NEW
echo "*/1 * * * * /root/pingeth1>/dev/null" >>CRON_NEW
crontab CRON_NEW
/etc/init.d/cron restart
rm CRON_TEMP
rm CRON_NEW
exit 0

Lo script è del tutto analogo a killpingeth1 e quindi esegue nell’ordine i seguenti passaggi:

1)Elenca il contenuto del crontab e lo scrive in un file temporaneo CRON_TEMP
2)verifica la presenza della stringa pingppp0 sul file temporaneo CRON_TEMP e se presente la elimina scrivendo un nuovo file CRON_NEW
3)appende alla fine del file CRON_NEW la nuova schedula di pingeth1
4)installa il nuovo cronjob
5)rimuove i file temporanei CRON_NEW e CRON_TEMP

Questa catena di script si intesta in un loop che switcha in maniera accettabilmente veloce la connessione tra la linea adsl e 3G, senza nessun intervento manuale da parte dell’amministratore di sistema.

Vista la ruvidità del procedimento non è possibile avere tutte le funzionalità avanzate del router come transparent proxy e vpn, ma credo che il compromesso per essere sempre online anche dopo la caduta del link primario sia accettabile.

I vostri commenti, insulti e migliorie sono come al solito più che apprezzati.

Feedly è un’estensione per Mozilla Firefox, Google Chrome e Safari che si interfaccia al nostro account Google Reader e tramite una serie di javascript ridisegna il layout dell’aggregatore rendendolo del tutto simile ad una pagina web stile magazine.

E’ compatibile con le shortcuts di Greader, è impreziosito da AJAX ed ha tutti gli strumenti per la condivisione su social network, offline reading (tramite Instapaper) e mille altre fighetterie.

Insomma il feed reader definitivo, secondo me.

Quello che però lo rende instabile, almeno su Google Chrome, è il costante aggiornamento di release. Ogni giorno viene infatti caricata una nuova versione che purtroppo, a partire dalla 2.15.x, sembra aver tralasciato una delle features per me più importanti e che l’ha reso per me inutilizzabile: la navigazione con i tasti N e P.

Nella schermata qui sotto è riprodotto il mio uso tipico di feedly: L’apertura di una categoria di feed, un’occhiata d’insieme alla pagina, uso del tasto N per selezionare l’articolo che ritengo possa essere interessante e tasto invio per espandere il post.

Nel cerchio si può notare l'ombreggiatura che notifica all'utente che l'articolo è stato selezionato

Ebbene, dalla versione 2.15.x di Feedly l’ombreggiatura che indica all’utente quale articolo è stato selezionato tramite i tasti N o P è sparita, rendendo di fatto impossibile usare Feedly tramite tastiera, almeno per quanto mi riguarda.

Mi sono chiesto quindi come poter effettuare un downgrade, come poter tornare alla versione 2.14.x che funzionava secondo me in maniera perfetta. Ho cercato di trovare qualche repository con lo storico dell’estensione cercando con Google e sulla pagina Get Satisfaction di Feedly, ma invano.

Ieri, per caso, ho acceso una virtual machine con Ubuntu 10.4, Chrome e Feedly che non usavo da circa un mese. Prontamente ho disattivato l’accesso ad internet per evitare l’update automatico delle estensioni ed ho recuperato Feedly 2.14.267.

Immediatamente l’ho salvato ed ho provveduto ad aggiornare tutte le mie installazioni di Chrome seguendo questa procedura:

1. Ho disinstallato Feedly dal pannello estensioni di Chrome
2. Ho copiato la cartella 2.14.267 in una directory nascosta (Linux) chiamata .feedlyext
3. Ho aperto nuovamente il pannello estensioni di Google Chrome e scelto carica estensione non pacchettizzata
4. Ho scelto il path della directory nascosta precedentemente creata e ricaricato la mia estensione preferita che, non essendo pacchettizzata, non è più soggetta ad update automatico.

La procedura è analoga anche per Windows e MacOS 10 .

Se anche voi avete riscontrato questi problemi, ho approntato per il download un file zip con la versione 2.14.267 pronto per essere scompattato ed installato secondo la procedura appena descritta.

Il file può essere prelevato qui.

Inizieremo con la preparazione di un file immagine per ospitare il sistema windows e con la creazione dell’immagine Iso per l’installazione.

Immagine Iso d’installazione e creazione disco virtuale

Probabilmente il sistema operativo windows da installare sarà memorizzato su un dvd o su un cdrom. Per maggiore comodità creiamo un’immagine iso per poi usarla come sorgente dell’installazione.

Sotto windows possiamo creare l’immagine tramite tools adatti allo scopo (imgburn e forse un altro centinaio), con linux usiamo dd con questo semplice comando

dd if=/dev/sr0 of=/tmp/winimage.iso

A questo punto dobbiamo creare una partizione o una  directory, se abbiamo a disposizione un discreto spazio disco, dentro la quale ospitare i file immagine delle macchine virtuali. Nei nostri esempi ho creato una directory /machines.

Creiamo la struttura delle directory:

mkdir /machines/xen
mkdir /machines/xen/domains
mkdir /machines/xen/domains/srv2k8

Spostiamo l’immagine iso del cd d’installazione precedentemente creato in /tmp

mv /tmp/winimage.iso /machines/xen/domains/srv2k8/

E creiamo un disco virtuale sparse da 12Gb

dd if=/dev/zero of=/machines/xen/domains/srv2k8/disk.img bs=1M count=0 seek=12288

Creazione file di configurazione HVM e installazione sistema operativo

Ora scriviamo il file di configurazione per la nuova macchina virtuale HVM. In /etc/xen creiamo un file chiamato srv2k8.cfg e scriviamo quanto segue.

kernel = '/usr/lib/xen-3.2-1/boot/hvmloader'
builder = 'hvm'
memory = '1024'
device_model='/usr/lib/xen-3.2-1/bin/qemu-dm'

# Disks
disk = [ 'tap:aio:/machines/xen/domains/srv2k8/disk.img,hda,w',
'tap:aio:/machines/xen/domains/srv2k8/winimage.iso,hdc:cdrom,r'
]

# Hostname
name = 'srv2k8'

# Networking
vif = ['mac=00:16:3E:3C:F7:28,bridge=eth0']

# Behaviour
boot='d'
vnc=1
vncviewer=1
sdl=0
acpi=1
localtime=1

Siamo pronti quindi per iniziare l’installazione di windows. Dalla shell lanciamo la nuova macchina virtuale con xm create srv2k8.cfg.

Qui si presenta subito un problema: come faccio ad interagire con il display della macchina virtuale? Semplice, nel file di configurazione sopra abbiamo specificato il parametro vnc=1 che farà in modo che sul nostro host principale venga lanciata una sessione vnc al fine di poter monitorare ed interagire con la nostra installazione.

Quindi è sufficiente collegarsi tramite un viewer vnc alla porta 5900 del nostro hypervisor ed eseguire un’installazione di windows come faremmo con un host fisico.

monitorare ed interagire con le macchine virtuali via vnc

Una volta portata a termine l’installazione impostiamo l’accesso remoto via rdp al nuovo host windows, settiamo un indirizzo ip fisso per poter facilmente ricollegare la nostra macchina virtuale via remote desktop e infine effettuiamo lo shutdown windows.

Nuovamente nella shell di Dom0 andiamo ad editare il file di configurazione /etc/xen/srv2k8.cfg cambiando i parametri di boot e rimuovendo il dispositivo tap:aio del cdrom.

# Disks
disk = [ 'tap:aio:/machines/xen/domains/srv2k8/disk.img,hda,w',
]
# Behaviour
boot='c'

Rifiniture

Riavviato il nuovo host windows, sempre con xm create srv2k8.cfg e collegati via dektop remoto, scarichiamo i GplPV drivers per windows. Questi drivers permettono di usare direttamente il backend di controller scsi e scheda ethernet di Dom0, incrementando le performance della nostra macchina virtuale.

Possiamo scaricare i drivers da http://www.meadowcourt.org/downloads/ scegliendo quello adatto alla versione di windows installata.

I drivers vengono identificati secondo questo criterio :
gplpv_(chk/fre)_(platform)_(arch)_(version).msi

chk è una build per sviluppatori con strumenti di debug, free è la versione senza strumenti di debug.

platform indica la versione di windows: wxp=Windows Xp, wnet=Windows Server 2003, wlh=Vista/Server2008.

arch potrà essere o AMD64 o x86.

version è la release dei drivers.

Qui sotto una schermata di esempio nella quale si può notare che la versione wlh di gplpv si installa egregiamente anche su Windows Seven.

Abbiamo terminato. Non ci resta che creare il link simbolico dentro Dom0 in /etc/xen/auto

cd /etc/xen/auto
ln -sf /etc/xen/srv2k8.cfg srv2k8.cfg

In questo modo la DomU HVM windows si avvierà all’avvio dell’hypervisor e, grazie ai GplPV drivers, effettuerà un corretto shutdown quando verrà arrestato il sistema.

I prossimi passi saranno:
Installazione di Xen 4.0 su Debian Lenny + Libvirt + Virt-manager
Realizzazione di un HA Xen con DRBD e Heartbeat

Serie di posts Xen no frills guide:
Parte 1
Parte 2
Parte 3