Non una semplice LIVE

L’architettura disponibile sulle nuove distribuzioni LIVE di Fedora, a partire dalla versione 9, rende possibile la creazione di una distribuzione che fonde la comodità di un supporto avviabile praticamente ovunque (almeno sui computer non troppo vecchi), compatto e leggero, con le caratteristiche di una distribuzione regolarmente installata: aggiungere pacchetti nuovi ed aggiornare quelli installati, conservare le impostazioni e le modifiche apportate durante l’uso, conservare i propri dati nella home directory e trovarli pronti ad ogni avvio, ed infine, dalla versione 10 di Fedora, avere la possibilità di cifrare i dati conservati nella home per renderli virtualmente inaccessibili a chiunque.

Questo articolo che leggete è scritto da un eeePC 900 di ASUS, con una Fedora 10 LIVE su desktop XFCE, usando la connessione a Internet tramite il modem Momodesign MD-@, perfettamente funzionante. La distribuzione è installata su una scheda SD da 16G, e visto che l’eeePC permette il bootstrap dallo slot integrato per questo tipo di memorie, la lascio sempre inserita ed al momento dell’accensione scelgo con cosa avviare, se la Linux Xandros di serie o la Fedora Personal LIVE.

Cosa occorre

Naturalmente un pen drive USB o una scheda SD di capacità adeguata. Il pen drive si può avviare praticamente ovunque, mentre la scheda SD è utilizzabile con i computer che posseggono lo slot corrispondente e che siano un grado di avviare il sistema operativo da tale slot. Per eliminare ogni dubbio basta uno sguardo alla configurazione del BIOS. Come ho già accennato, l’ASUS eeePC 900 possiede lo slot per schede SD ed è in grado di avviare un eventuale sistema operativo contenuto sulla scheda inserita.

Il supporto può essere formattato con filesystem FAT, e consiglio caldamente di non cambiare il tipo di filesystem con cui il supporto esce di fabbrica. La ragione è che un altro tipo di filesystem potrebbe abbreviare notevolmente la vita del supporto, per ragioni che sono lunghe da spiegare. Non è necessario che il supporto sia vuoto, può contenere altri file, ad esempio foto o musica, non saranno toccati dalla procedura di installazione e rimarranno accessibili anche dalla distribuzione LIVE una volta avviata.

Creazione della Live su USB

Inserito il pen drive, il comando è questo, da impartire in un terminale come utente root:

# livecd-iso-to-disk --overlay-size-mb 2000 --home-size-mb 2000 F11-i686-Live-XFCE.iso /dev/sdc1

che andiamo a vedere nel dettaglio:

• --overlay-size-mb 2000 – è la dimensione in megabyte dello spazio disco che viene sommato alla root della distribuzione Live una volta avviata. In questo spazio vengono aggiunti o spostati i file nuovi o modificati nel filesystem root. Se ad esempio installiamo un pacchetto aggiuntivo, i suoi file andranno ad occupare questo spazio, ma saranno presenti da quel momento ad ogni avvio della Live. In pratica consente di aggiornare o installare pacchetti e di rendere permanenti le modifiche alla configurazione del sistema, proprio come un normale sistema installato. Lo spazio in overlay è in un unico file nella directory LiveOS del pen drive, della dimensione indicata, in questo caso 2000 megabyte. Reinstallando la Live o cambiando versione il file di overlay viene ricreato vuoto, per evitare conflitti, quindi tutte le eventuali modifiche fatte a file di configurazione vengono perse. In realtà non è un gran problema, perché le attuali versioni di Fedora possono svolgere gran parte del lavoro quotidiano senza toccare nulla della configurazione generale. Dalle prove che ho fatto in questi ultimi mesi, il file di overlay è superfluo, almeno per l’uso che ne faccio io, e nelle ultime installazioni su pen drive o schede SD non lo faccio neanche creare.
• --home-size-mb 2000 – è lo spazio assegnato alla partizione home, dove saranno memorizzati tutti i file dell’utente liveuser, usato nel normale impiego della Live. Detto in altro modo: se scarichiamo dei file, generiamo dei documenti, personalizziamo il desktop, tutte le modifiche ed i file generati o modificati finiranno in questa partizione, e saranno presenti ad ogni avvio, esattamente come su un sistema installato normalmente. Il tutto è sotto forma di file dal nome home.img nella directory LiveOS, della grandezza indicata, ossia 2000 megabyte. Il file rimane intatto se si installa una nuova Live, o si reinstalla la stessa, conservando dati e impostazioni personali fra gli aggiornamenti.
• F11-i686-Live-XFCE.iso – è il file ISO generato da noi con la procedura spiegata in precedenza, o la Live ufficiale di Fedora. Può essere di qualsiasi dimensione, anche un DVD, purché ci sia spazio a sufficienza nel pen drive. Unico problema è che se l’immagine ISO è più grande di 2 gigabyte non si può installare su pen drive formattati in FAT.
• /dev/sdc1 – è la partizione FAT del pen drive. Si può rilevare usando il comando mount senza parametri.

Il procedimento dura qualche minuto, in funzione della dimensione della ISO, della grandezza dei file di overlay e home, e naturalmente della velocità del pen drive. A questo proposito, se si intende usare una scheda Secure Digital (SD) conviene acquistarne una di classe 6, che garantisce una velocità accettabile, col minimo garantito di 6 megabyte al secondo sostenuti in scrittura (vedere a tale proposito la pagina sulle schede Secure Digital in Wikipedia). Durante la preparazione, se abbiamo scelto di avere la partizione di home persistente, ci verrà chiesto di scegliere ed inserire una password per la cifratura dei dati su questa partizione. Se non ci interessa cifrare i dati, basta aggiungere al comando visto sopra il parametro --unencrypted-home e non ci sarà chiesta nessuna password. Al termine della preparazione abbiamo nel pen drive due directory aggiunte: LiveOS e syslinux. Nella prima ci sono il contenuto della ISO, i file di overlay e la home persistente, sulla seconda c’è il necessario per l’avvio. Siamo pronti per avviare la nostra Live da pen drive.

Messaggi di errore

Durante l’operazione di preparazione potremmo ricevere uno di questi errori:

• /dev/sdc1 is mounted, please unmount for safety – Significa che la partizione su cui vogliamo installare la Live è montata o abbiamo indicato il device sbagliato. Per smontare il pen drive basta selezionare “Smonta” dal menu di contesto dell’icona del pen drive stesso.
• Partition isn’t marked bootable! – Questo accade con i pen drive nuovi. Basta usare fdisk o parted o gparted per aggiungere il flag di “avviabile” alla partizione scelta per l’installazione, o all’unica presente.
• MBR appears to be blank. Do you want to replace the MBR on this device? – anche questo avviene con un pen drive o una scheda SD nuovi. Basta rispondere di sì.
• Can’t have a home overlay greater than 2048MB on VFAT – questo succede se si indica una dimensione troppo grande dei file di overlay o di home per il filesystem del pen drive. Basta ridurre le nostre pretese o cambiare il tipo di filesystem del pen drive, cosa che sconsiglio.
• ERROR: Requested keeping existing /home and specified a size for /home Please either don’t specify a size or specify –delete-home – Questo errore appare se il pen drive è già impostato come Live ed esiste un file di home.img, ma noi abbiamo specificato di nuovo il parametro --home-size-mb. Cancellare il file home.img, se non ci interessa conservare i dati dell’installazione precedente, direttamente o con il parametro --delete-home, o togliere il parametro --home-size-mb
• Already set up as live image. Deleting old OS in fifteen seconds… – avvertimento che appare se il pen drive è già impostato come Live avviabile. Ignorare se intendiamo aggiornare o cambiare il sistema installato.

Problemi e fastidi

Nei mesi in cui ho utilizzato Fedora Live sul mio eeePC 900 ho riscontrato questi problemi:

• In un caso l’overlay della partizione root si è rovinato, e non partiva più. E’ bastato cancellarlo per riuscire a ripartire, naturalmente perdendo tutte le impostazioni ed i pacchetti installati.
• Capita a volte che la partizione di home presenti degli errori al mount durante l’avvio (per vederli basta premere il tasto Esc quando appare il logo di Fedora). In qualche caso non si monta più e ci si accorge del problema quando il desktop diventa quello di default, perdendo tutte le nostre impostazioni. Basta passare in single user mode con il comando init 1, e forzare un fsck del device /dev/loop5, di solito usato per la partizione di home.
• Se la partizione di home è cifrata, i problemi sono più frequenti.

Questo almeno con Fedora 9 e 10. La versione 11 la sto sperimentando da qualche giorno, per cui non ho ancora dati sufficienti. In ogni caso, i problemi citati si hanno soltanto in presenza delle partizioni persistenti, per cui se non si necessita di overlay e partizione home persistente, si possono omettere i rispettivi parametri: il resto del pen drive, accessibile dalla Live avviata in /mnt/live, può essere utilizzato per archiviare file e documenti.
I difetti riscontrati, peraltro, sono frutto della relativa novità, e probabilmente scompariranno con l’uscita delle nuove versioni dei tool.

Il locale era carino e con una atmosfera famigliare, che ha facilitato la socializzazione. La mancanza del necessario per proiettare la presentazione delle novità di Fedora 10, invece di essere un problema, ha reso più informale l’evento, che tale voleva essere: un incontro fra persone che condividono un interesse genuino per il free software e la libera circolazione delle informazioni.

Marco Palazzotti ha fatto una breve presentazione, poi si è passato subito alla parte più interessante: creare le “chiavette” USB con la LIVE di Fedora 10, distribuire i DVD di installazione, mostrare Fedora 10 installata in funzione.

Molto interesse c’è stato sulla virtualizzazione, con domande sull’interfaccia di gestione Virt-Manager, sui due principali ambienti disponibili, QEMU e Xen, con dimostrazione in diretta dell’installazione di una Fedora 10 “virtuale” dentro una Fedora 10 “reale”.

Alle 23 ho dovuto abbandonare la scena per l’arrivo di un fastidioso ed indesiderato attacco di febbre, che mi sta devastando tuttora, ma molte persone erano ancora in piena attività e le discussioni fervevano.

Insomma, valeva la pena esserci.

Appena riemergo dal coma scarico le foto e le pubblico.

Alla prossima release di Fedora.

Il kit per creare versioni LIVE

Occorre il solo pacchetto livecd-tools, che una volta installato si “tira dietro” tutti i pacchetti necessari tramite le dipendenze, tra cui syslinux, mkisofs e pykickstart. Nel pacchetto sono compresi alcuni file di esempio per creare versioni LIVE identiche a quelle già presenti nei mirror di Fedora, da usare anche come base per creare le proprie versioni personalizzate (in Fedora 10 ve ne è uno solo, da usare come base, con una installazione minima).

Un po’ di documentazione

La prima sorgente da cui attingere è il Fedora LiveCD HowTo, che elenca le capacità del tool di creazione e ne spiega il processo a grandi linee. Da leggere, di contorno, la documentazione riguardante il file di kickstart, usato per automatizzare le installazioni di Fedora.

Cosa si può fare

Creare la propria immagine Live di Fedora, con il software voluto, scelto dai depositi di Fedora al completo, compresi i nuovi depositi RPM Fusion, che comprendono i precedenti depositi Livna, con l’aggiunta di Freshrpms e Dribble.

Si può personalizzare a livello di singolo pacchetto cosa debba essere installato, senza preoccuparsi delle dipendenze, che verranno risolte al momento della creazione dell’immagine ISO.

Si possono eseguire script automatizzati, ad esempio per inserire software non compresi fra i pacchetti “standard” di Fedora.

Si possono inserire script di avvio personalizzati. Al termine del processo si ottiene una immagine ISO masterizzabile, con i pacchetti più nuovi, dato che vengono usati quelli degli aggiornamenti.

L’immagine ISO è anche installabile su disco nel computer, o volendo si può installare su un pen drive di capacità adeguata, usando il tool livecd-iso-to-disk, che non cancella i dati preesistenti sul drive, naturalmente a patto che vi sia spazio sufficiente. Pensate che comodità: un pen drive da 4Gbyte con Fedora Live pronta per l’uso e tutti i nostri dati, accessibili da Fedora.

Prima fase: il file di definizione

Tutto il processo è governato da un singolo file di kickstart, che contiene tutte le istruzioni per arrivare all’immagine ISO pronta per l’uso. Si può crearlo a mano, utilizzando come base uno degli esempi forniti in /usr/share/livecd-tools/ (in Fedora 10 è /usr/share/doc/livecd-tools-020/), oppure usare il tool grafico contenuto nel pacchetto system-config-kickstart.

Il tool grafico di creazione di file kickstart

Il file così come generato dal tool non è utilizzabile direttamente per creare una live, conviene invece prendere il file di esempio che crea una LIVE minima, chiamato livecd-fedora-minimal.ks, e copiarci la sola parte relativa alla selezione dei pacchetti del file creato col tool grafico, prendendola dalla sezione dei pacchetti, che vedremo fra poco. Il tool è comunque molto utile per fare la selezione dei pacchetti, che vengono scelti da tutti i depositi installati sulla macchina da cui si avvia il tool stesso, per cui se abbiamo installato anche i depositi RPM-Fusion, di cui parlavo prima, potremo selezionare pacchetti anche da lì.

Il file è diviso in sezioni:

• Le opzioni principali
• La selezione dei depositi
• La selezione dei pacchetti da includere/escludere
• Script/azioni da eseguire prima di iniziare
• Script/azioni da eseguire dopo l’installazione, ad esempio per installare software aggiuntivo

Andiamo a vedere le più importanti.

Le opzioni principali

Nelle opzioni principali si può scegliere la lingua, il tipo di tastiera, se avviare il desktop grafico all’avvio e cose simili. Alcune delle opzioni sono obbligatorie, altre opzionali. Per sapere quali basta riferirsi al manuale di Anaconda, citato sopra.

Ecco un esempio da un mio esperimento:

lang it_IT.UTF-8
keyboard it
timezone Europe/Rome
auth --useshadow --enablemd5
selinux --disabled
firewall --disabled
xconfig --startxonboot
part / --size 2048
services --disabled=network,sshd,NetworkManager,bluetooth

La riga con services --disabled=... indica quali servizi, pur installati, devono essere tenuti spenti. Quella invece con part / --size 2048 indica quanto deve essere grande il filesystem su cui verrà fatta l’installazione. Dato che il filesystem finale, ossia l’immagine ISO, sarà compresso e comprenderà solo lo spazio effettivamente occupato, possiamo anche abbondare, lo spazio effettivo lo vedremo al termine della creazione della LIVE, guardando l’immagine ISO.

La selezione dei depositi

Segue l’elenco dei depositi da cui verranno prelevati i pacchetti. Si possono specificare quanti e quali vogliamo, con l’accortezza, naturalmente, di sapere cosa stiamo facendo. Ad esempio, i depositi devono appartenere tutti alla stessa versione di Fedora; occorre stare attenti nell’includere depositi con pacchetti duplicati o in conflitto. Inserendo solo i depositi ufficiali ed eventualmente quelli di RPMFusion non dovrebbero esserci problemi di sorta.

Ecco come includere un deposito:

repo --name=undeposito --mirrorlist=url

Basta cambiare undeposito e url con i valori appropriati, presi ad esempio dai file di configurazione di yum, reperibili in /etc/yum.repos.d/. Non dimenticheremo di includere anche i depositi degli aggiornamenti, per avere a disposizione le ultime versioni dei pacchetti scelti.

La selezione dei pacchetti

La lista dei pacchetti deve essere compresa fra le parole chiave %packages e %end.
Per selezionare un pacchetto basta inserire il nome “ufficiale” nella lista, un pacchetto per riga, mentre per escluderlo basta farlo precedere da un segno meno. Si possono usare i jolly, ad esempio se inseriamo:

samba-*
-firefox

installeremo tutti i pacchetti del servizio Samba, ed escluderemo il Browser Firefox. Si possono installare anche gruppi di pacchetti, facendo precedere il nome del gruppo dal carattere ‘@’, ad esempio:

@base
@editors
@XFCE

andremo ad installare tutti i pacchetti che fanno parte del gruppo Base, Editors e XFCE. Dato che i pacchetti ed i gruppi sono realmente tanti, per questo passo conviene utilizzare il tool grafico e poi fare un copia/incolla della sola parte compresa fra i due tag.

L’esclusione dei pacchetti serve solo per non far installare quelli che vengono come predefiniti dentro un gruppo, altrimenti non serve: la logica è di installare solo ciò che è esplicitamente richiesto e le sue dipendenze. Torno a ripetere che se usiamo il tool grafico non dovremo occuparci di questi dettagli.

Gli script pre e post installazione

Chiusi rispettivamente fra i tag %pre / %end e %post / %end, sono normali script shell da eseguire prima di avviare l’installazione dei pacchetti e dopo aver installato il tutto, subito prima che il tool di creazione generi l’immagine ISO.

Un possibile uso è nel file di esempio riportato in fondo. Ho modificato uno degli script per evitare che all’avvio su un PC su cui c’è installato Linux venga attivata ed usata la partizione di swap, impedendo così qualsiasi modifica al disco locale del computer. Per far usare una eventuale partizione di swap presente sul computer in cui viene avviata la LIVE, occorre fermare il bootloader ed aggiungere la stringa useswap alla riga di avvio del kernel.

E’ evidente che l’uso di queste funzioni è destinato a chi sa dove mettere le mani.

La creazione della immagine ISO

Il comando da impartire è il seguente, da utente root:

livecd-creator -f MyLive --config=mylive.ks --cache=/home/cache

dove:

• -f MyLive è il nome che avrà l’immagine ISO
• --config=mylive.ks indica quale sia il file di kickstart da usare per generare l’immagine ISO della LIVE. Quello che abbiamo appena creato, insomma.
• --cache=/home/cache indica dove posizionare la cache dei pacchetti scaricati. E’ estremamente utile impostare una cache, perché ci eviterà di dover riscaricare da Internet tutti i pacchetti per ogni tentativo o modifica al file di kickstart e successiva rigenerazione della immagine ISO. Ad ogni tentativo verranno scaricati solo gli eventuali pacchetti aggiunti o quelli che nel frattempo dovessero essere stati aggiornati. Naturalmente, diminuiremo anche il traffico verso i depositi di Fedora, cosa che non fa mai male.

Al termine del processo, piuttosto lungo (possono volerci anche ore se occorre scaricare tutti i pacchetti da Internet), avremo una immagine ISO dal nome MyLive.iso pronta per l’uso.

Il test della nostra LIVE

Naturalmente, pensare di masterizzare un CD ogni volta è impensabile, per cui possiamo usare la virtualizzazione, ad esempio con QEMU. Per lanciare una macchina virtuale con la nostra LIVE il comando sarà:

qemu-kvm -m 256 -boot d -cdrom MyLive.iso

In breve avremo la nostra LIVE pronta per tutti i test del caso.

La LIVE appena creata dentro QEMU

Ora abbiamo tutte le informazioni per procedere alla creazione della nostra LIVE personalizzata: buon divertimento.

Riferimenti

• Un precedente scritto sulla virtualizzazione in Fedora con QEMU
• Il file kickstart di esempio che genera una LIVE con XFCE (molto rudimentale e con un sacco di difetti, ma funziona)
• Il Fedora LiveCD HowTo
• La documentazione riguardante il file di kickstart

Cosa potremo fare:

• Conoscere il progetto Fedora
• Scoprire le novità in Fedora 10
• Conoscere persone che usano Fedora per lavorare, giocare, progettare…
• Portare il vostro computer ed installare Fedora 10
• Risolvere (o almeno tentare di risolvere) i problemi di installazione/configurazione di Fedora sul vostro computer
• Portare un pen drive (vuoto) ed avere in pochi secondi una Fedora Live pronta per l’uso
• Fare due chiacchiere con i Fedora Ambassador (Marco, Gianluca ed Andrea).
• Conoscere di persona gli amici “remoti”

Anche stavolta darò una mano ad organizzare la festa. Il posto è molto centrale, vicinissimo alle fermate San Giovanni e Re di Roma della metro A.

Tutti i dettagli sulla pagina del Fedora 10 Release Party Roma.

Dato che il bootloader e GRUB sono completamente installati solo sul disco sda, la sua sostituzione con un disco vuoto toglie la possibilità di fare il boot. Come risolvere?

Si può operare in due modi: a cose fatte, ossia col disco già guasto e computer riavviato, oppure prima di spegnere il computer, o meglio prima che il disco si guasti, ossia al momento dell’installazione.

Nel primo caso occorre usare la modalità “Rescue” messa a disposizione da Fedora, avviare il server dal DVD di installazione ed operare come se si fosse perso il bootloader, come spiegato nella guida di installazione di Fedora nell’apposito capitolo.

Nel secondo caso si può operare in anticipo, o anche appena prima di spegnere il server per sostituire il disco guasto. Cosa andiamo a fare: installiamo GRUB anche sul secondo disco con tutto il necessario per far eseguire il boot anche da questo.

Da un terminale dove siamo root entriamo nella console di comando di GRUB:

# grub

    GNU GRUB  version 0.97  (640K lower / 3072K upper memory)

 [ Minimal BASH-like line editing is supported.  For the first word, TAB
   lists possible command completions.  Anywhere else TAB lists the possible
   completions of a device/filename.]

grub>

Per prima cosa vediamo se è tutto installato come ci serve, ossia se i file necessari a GRUB sono su tutti e due i dischi:

grub> find /grub/stage1
 (hd0,0)
 (hd1,0)

GRUB risponde nella sua notazione con l’indicazione delle partizioni dove sono i suoi file. Normalmente dovrebbero essere su tutti e due i dischi, tranne naturalmente il caso in cui uno dei due sia guasto, ma a quel punto ci interessa che siano installati sul disco ancora funzionante. Annotiamo la partizione per il secondo disco (hd1), in questo caso la 0, e procediamo ad installare:

grub> device (hd0) /dev/sdb

Con questo abbiamo detto a GRUB di considerare il secondo disco come primario. Serve perché al boot con il disco principale guasto, GRUB considererà il secondo disco come primo, per cui i comandi devono essere impartiti considerando quella ipotesi. Naturalmente dovremo sostituire adeguatamente i device per adattarli al nostro caso.

grub> root (hd0,0)
 Filesystem type is ext2fs, partition type 0xfd

Con questo abbiamo detto a GRUB quale sarà la partizione di avvio, ossia la root. Attenzione che può non essere la root del filesystem, ma è la partizione dove è posizionata la directory di boot con i file di GRUB. Nel mio caso avevo una partizione separata di boot, la prima sul disco.

grub> setup (hd0)
 Checking if "/boot/grub/stage1" exists... no
 Checking if "/grub/stage1" exists... yes
 Checking if "/grub/stage2" exists... yes
 Checking if "/grub/e2fs_stage1_5" exists... yes
 Running "embed /grub/e2fs_stage1_5 (hd0)"...  15 sectors are embedded.
succeeded
 Running "install /grub/stage1 (hd0) (hd0)1+15 p (hd0,0)/grub/stage2 /grub/grub.conf"... succeeded
Done.

Con questo abbiamo installato tutto il necessario per il boot. Possiamo spegnere il server, sostituire il disco guasto e riavviarlo, ricordando che occorre dire al BIOS del server o del controller di avviare dal secondo disco e non dal primo.

Riferimenti

• La documentazione di GRUB
• Una guida illuminante dalla mailing list DELL
• La documentazione sul RAID software di Linux (non aggiornatissima, ma sempre utile)

options usbserial vendor=0x19d2 product=0x0002

Se per qualche motivo la procedura con “Espelli” non dovesse funzionare, basta aprire un terminale ed usare il comando:

$ eject /dev/scd1

dove scd1 è il CDROM simulato creato alla connessione della chiavetta. Se non avete un CD/DVD-ROM può essere scd0 oppure se ne avete due sarà scd2, insomma viene posizionato come ultimo device CD/DVD-ROM del computer.

Altre informazioni su come impostare la connessione e altre cosucce su Fedora si trovano nella procedura per Momodesign MD-@ e qui.

Il problema è che all’inserimento del modem nella presa USB viene riconosciuto come memoria di massa (come CDROM per la precisione), e montato come tale.

Ho fatto qualche tentativo pasticciando con udev, ma non sono molto esperto in ciò, ed il massimo che ho ottenuto è di non far montare la memoria flash all’inserimento nella presa USB, ma niente di più.

Viene riconosciuto un device USB che ha come identificativo vendor 0x1a8d e come product 0×1000. Viene rilevato come CDROM e come tale montato. Puntando l’icona che appare sul desktop col tasto destro del mouse e selezionando la voce “Espelli”, il dispositivo viene smontato e succede la magia: appare un altro device USB con lo stesso ID vendor, 0x1a8d, ma con identificativo di prodotto pari a 0×1007, e qui il tutto si ferma.

Ho fatto vari test, ed il dispositivo appare solo e solo se si lascia montare automaticamente lo pseudo-CDROM e poi si smonta da interfaccia grafica. Se si va a smontarlo con il comando umount non apparirà l’altro device, come non appare se si inserisce una regola di udev per far ignorare l’evento di inserimento del CDROM simulato.

Inoltre ho fatto dei test con il programma usb_modeswitch, che pare funzionare con l’eeePC e altri modem USB di questo tipo, ma niente. Pur ottenendo il messaggio di commutazione avvenuta, in realtà non succede nulla.

Insomma l’unico modo è quello di lasciar montare il CDROM e smontarlo a mano da interfaccia grafica. A questo punto però occorre una piccola modifica al file /etc/modprobe.conf. Aggiungendo questa riga:

options usbserial vendor=0x1a8d product=0x1007

e poi eseguendo il comando depmod -a per far leggere le modifiche al file, al successivo ciclo di inserimento/mount del CDROM simulato/umount verranno riconosciuti e configurati tre dispositivi seriali: /dev/ttyUSB0, /dev/ttyUSB1 e /dev/ttyUSB2. Il primo ed il terzo sembrano identici, mentre il secondo appare inerte.

Ebbene, usando come dispositivi il primo o il terzo, il modem Itelco funziona perfettamente. Si può seguire la procedura mostrata per il Momodesign MD-@, naturalmente sostituendo il device /dev/ttyACM0 con /dev/ttyUSB0 quando necessario.

L’unica cosa da fare da ora in poi è che quando si inserisce il modem nella presa USB occorre “espellere” a mano il CDROM simulato, dopodiché si può usare come un normale modem.

Se qualcuno trova come configurare udev o altro per aggirare questa manovra manuale, me lo faccia sapere. Io non ci sono riuscito, ma come ho detto non sono molto pratico in questo campo.

Se si opera da una shell, e non si ha a disposizione Zenity o un display X, lo script lavora totalmente da terminale, altrimenti passa in modalità GUI.

Per funzionare richiede che l’utente da cui viene eseguito abbia i diritti di scrittura sul device del modem. In Fedora basta assegnare all’utente anche il gruppo di sistema uucp, usando l’utility in Sistema, Amministrazione, Utenti e gruppi, oppure col comando:

# usermod -G uucp nomeutente

dato da root. Ricordo che per far valere le variazioni di permessi e gruppi ad un utente occorre terminare la sessione desktop e rientrare, altrimenti i nuovi gruppi non saranno attivi per l’utente.

E’ utile per capire se siamo agganciati all’operatore giusto e quanto segnale abbiamo senza fare strane manovre o digitare stringhe impossibili nel terminale.

Naturalmente, lo script non funziona se il modem è attivo, ossia stiamo connessi a Internet. Va lanciato prima di connettersi per controllare appunto la rete a cui siamo agganciati, ed evitare salassi al portafogli.

Lo script è qui:
ck3g (click col tasto destro e “salva con nome”). Ricordatevi di dargli i permessi di esecuzione con un chmod a+x ck3g, altrimenti non viene eseguito e lamenta un “permesso negato”. Non c’è nessun bisogno di eseguirlo da utente root.

L’utilità? Nessuna, è solo un esercizio di programmazione che mostra alcune tecniche per scrivere e leggere dai dispositivi con uno script shell, oltre all’uso di alcune funzioni di Zenity, di cui avevo già parlato in passato.

Riferimenti

• Fedora e modem USB Momodesign HSDPA.
• I precedenti articoli su Zenity: Zenity #1, Zenity #2, Zenity #3.

Appena collegata la “chiavetta” USB andiamo a controllare che sia rilevata e con quale device sia raggiungibile. Per questo basta il comando:

$ dmesg
...
...
usb 4-2: new full speed USB device using uhci_hcd and address 2
usb 4-2: configuration #1 chosen from 1 choice
usb 4-2: New USB device found, idVendor=05c6, idProduct=3100
usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 4-2: Product: H3G USB HSDPA Modem
usb 4-2: Manufacturer: H3G , Incorporated
cdc_acm 4-2:1.0: ttyACM0: USB ACM device
usbcore: registered new interface driver cdc_acm
drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters

L’output del comando mostra alcune informazioni, la più importante è il nome del device, in questo caso ttyACM0. Vuol dire che il modem è disponibile ed utilizzabile dalle applicazioni usando il file speciale /dev/ttyACM0 (attenzione a maiuscole e minuscole, sono significative, l’ultimo carattere è uno zero).

Per configurare la connessione a Internet, andiamo nel menù Sistema, Amministrazione e scegliamo la voce Rete. Ci viene chiesta la password di root oppure il pannello di autorizzazione di PolicyKit, dopodiché arriviamo all’interfaccia di gestione delle connessioni di rete. Scegliamo “Nuovo”, selezioniamo “Collegamento del modem” e nel pannello successivo troviamo i parametri del modem già impostati, come in figura qui sotto.

Se nella casella “Dispositivo Modem” non c’è il device trovato prima, oppure otteniamo un messaggio di “modem non trovato”, lo digiteremo noi, rispettando maiuscole e minuscole.

Nel pannello successivo imposteremo il numero da chiamare, che in questo tipo di connessione è quasi sempre lo stesso: *99#. Come nome provider metteremo un nome significativo per noi, mentre come nome di login e password, dato che non dovrebbero essere significativi, possiamo inserire ad esempio guest. In ogni caso ci riferiremo ai parametri forniti dal provider.

Subito dopo arriviamo alla configurazione del protocollo IP, che va lasciato con i valori predefiniti, mostrati in figura.

Un riepilogo con tutte le informazioni inserite è nel pannello finale.

Siamo pronti per connetterci a Internet.

Optional di serie

Per rendere le cose più comode, possiamo usare una delle piccole applet del pannello di Gnome messe a disposizione da Fedora, chiamata Modem Lights.

Questa applet si piazza nel pannello e si presenta con un pulsante, un riquadro nero e due indicatori rotondi (figura sotto).

Deve ovviamente essere configurata, i parametri predefiniti non funzionano. Basta cliccarvi sopra col tasto destro del mouse e scegliere “Preferenze”. Abbiamo tre pannelli. Il primo riguarda le impostazioni generali, vediamo le singole voci.

Abbiamo, partendo dall’alto: l’intervallo di aggiornamento della visualizzazione dei dati di traffico (un secondo), l’indicazione del tempo di connessione e della banda utilizzata in quel momento, se il pulsante deve indicare lampeggiando l’avvio di una connessione. Sono configurazioni opzionali e non necessarie per il normale funzionamento.

Di seguito abbiamo i comandi di avvio e fermo della connessione, che vanno cambiati rispetto al valore predefinito: il comando di avvio sarà /sbin/ifup ppp0 mentre quello di terminazione sarà /sbin/ifdown ppp0. Questo ovviamente supponendo di avere una singola connessione modem configurata, altrimenti occorre vedere il nome assegnato dal pannello di configurazione di rete, raggiungibile dal menù Sistema, Amministrazione, Rete. Normalmente è pppN dove N è un numero progressivo.

L’opzione “Confirm connection” serve a far comparire una domanda di conferma ogni volta che premiamo il pulsante di connessione. Personalmente lo ritengo inutile, visto che ho già dato una conferma premendo appunto il pulsante.

Il pannello successivo permette di definire i colori di presentazione dell’applet.

Quelli mostrati sono i miei colori preferiti, ma naturalmente non sono obbligatori. Partendo dall’alto abbiamo il colore del grafico dei dati ricevuti (verde su nero), quello dei dati trasmessi (rosso su nero), i colori dell’indicatore dentro il pulsante (rosso connesso, giallo in avvio connessione, nero quando inattivo), infine i colori con cui viene mostrato il valore della banda occupata al momento e del tempo di connessione (sono simili a dei display a LED, va indicato il colore da acceso, quello da spento, outline, e lo sfondo).

L’ultimo pannello contiene i dati di gestione del device.

Deve essere configurato come mostrato, in particolare è importante il device (nel mio caso ppp0), il nome del lock file (/var/lock/LCK..ttyACM0, l’ultima parte deve essere uguale al nome del device seriale, come visto sopra) e la verifica del lock file, per evitare false indicazioni dell’applet.

Possiamo accettare la configurazione, siamo pronti per utilizzare la nostra connessione quando serve, senza problemi e con un singolo click del mouse. Qui sotto possiamo vedere l’applet in funzione.

Note dolenti

Non è, naturalmente, tutto così semplice. Nel caso del modem in oggetto la configurazione di fabbrica dovrebbe essere pronta per l’uso, e soprattutto evitare brutte sorprese. Ma non si sa mai, così penso sia il caso di riportare qualche avvertenza e consiglio.

Nel contratto è prevista la possibilità di roaming su reti di altri gestori in caso di mancanza di connettività del fornitore. Questa possibilità è fonte di rovina economica, visto che il roaming sarebbe solo in modalità GPRS, il cui costo è in decine di centesimi al megabyte, contando sia quelli inviati che quelli ricevuti, un vero salasso anche solo per leggere un messaggio di posta elettronica.

Abbiamo varie possibilità: la prima è di impostare il modem utilizzando l’interfaccia di configurazione in Windows, che permette appunto di selezionare l’operatore predefinito, ma, naturalmente, occorre Windows. In alternativa si può inserire una particolare stringa di inizializzazione che dovrebbe costringere il modem ad accettare solo la rete dell’operatore scelto. Per far questo, apriamo il pannello di configurazione della rete, dal menù Sistema, Amministrazione, Rete. Scegliamo la connessione modem, e premiamo il pulsante “Modifica”. Nel pannello “Avanzato” abbiamo una casella di testo denominata “Stringa di inizializzazione del modem”. In questa casella digiteremo: at+cops=1,0,H3G. Traducendo, il comando appena inserito cambia il modo di registrazione del modem alla rete 3G, passando in modo manuale e indicando la rete del fornitore.

Abbiamo un effetto collaterale indesiderato (non chiedetemi come sia possibile, ma succede). Alla connessione ci verranno assegnati come indirizzi per la risoluzione dei nomi DNS 10.11.12.13 e 10.11.12.14, totalmente inutili. Per poter navigare abbiamo bisogno di due DNS validi, per cui inseriremo o quelli di OpenDNS, o quelli che il nostro provider di comunica. Nel caso di Tre Italia, i DNS sono di solito 62.13.171.4 e 62.13.171.5. Per inserirli e renderli operativi, dobbiamo aprire il pannello di gestione rete (Sistema, Amministrazione, Rete), selezionare la connessione, premere il pulsante Modifica. Nel pannello “Generale”, toglieremo la spunta a “Ottieni le informazioni DNS automaticamente dal provider”. Chiudiamo questo pannello ed andiamo alla voce “DNS” della configurazione generale di rete ed inseriamo i DNS desiderati.

Naturalmente i valori impostati qui valgono per tutte le connessioni del computer, per cui ci troveremo questi DNS anche per le connessioni Wireless o Ethernet. Non dovrebbero comunque esserci problemi dato che in questi ultimi casi dovrebbe essere invece attiva l’opzione di usare i DNS forniti al momento della connessione, ed i DNS impostati dovrebbero essere ignorati, per usare quelli specificati al momento della negoziazione della connessione di rete.

Per i veri tecnici

Possiamo anche tentare una esplorazione a mano dell’area in cui siamo, senza impostare connessioni o variare configurazioni. Dobbiamo prima installare una particolare utility, cu, contenuta nel pacchetto uucp. Questa utility consente di inviare direttamente comandi al modem via seriale e vederne i risultati. Non si deve usare minicom, il programma che di solito si impiega per connettersi alle BBS (clone del Telix dei bei tempi andati), perché minicom invia dei comandi di testa sua e pretende alcuni segnali specifici del modem prima di funzionare correttamente. Il rischio è che, oltre a non funzionare, i comandi inviati vadano ad “inquinare” il comportamento del modem prima del nostro intervento. Quindi, niente minicom. Apriamo una finestra terminale e digitiamo il comando:

# cu -l /dev/ttyACM0
Connected.

Se otteniamo questo messaggio:

cu: open (/dev/ttyACM0): Permission denied
cu: /dev/ttyACM0: Line in use

vuol dire che stiamo usando un utente che non ha diritto di scrittura sulle porte seriali. Due soluzioni: aggiungere l’utente anche al gruppo uucp, oppure operare da root.

Abbiamo a disposizione i seguenti comandi:

at+cops?
+COPS: 0,0,"H3G",2

OK

Questo controlla con quale operatore telefonico è attualmente registrato il modem. Il primo numero indica la modalità di registrazione (zero per automatica, uno per manuale). Il secondo numero indica il formato in cui è mostrato/accettato l’identificativo dell’operatore, lo zero sta per stringa completa. La stringa è appunto il nome dell’operatore. Se vediamo il nome del nostro possiamo stare tranquilli. Se ne vediamo un altro, non è proprio il caso di partire con una connessione, andremmo in roaming con tutto quello che comporta. Il comando per “bloccare” su un operatore è quello che abbiamo visto prima: at+cops=1,0,H3G. Se invece digitiamo il comando in questo modo:

at+cops=?
+COPS: (2,"H3G","3ITA","22299",2),(1,"Telecom Italia M","TIM","22201",2),
(1,"Wind Telecomunic","WIND","22288",2),
(1,"Omnitel Pronto I","OMNITEL","22210",2),,
(0,1,3,4,5),(0,1,2)

OK

dopo una breve pausa otteniamo la lista delle reti “visibili” dal nostro modem.

Se vogliamo sapere l’intensità del segnale (quante “tacche” abbiamo di segnale in antenna), il comando è:

at+csq
+CSQ: 23,99

OK

Il primo numero può andare da 1 (minimo segnale) a 31 (massimo). Il secondo numero è la misura del BER (tasso di errore della trasmissione), e 99 vuol dire non misurabile.

Altro comando utile è quello per la gestione dell’APN che tanto mi ha fatto penare con L’ASUS eeePC:

at+cgdcont?
+CGDCONT: 1,"IP","datacard.tre.it","0.0.0.0",0,0

OK

qui vediamo la configurazione per un abbonamento Tre solo dati. Per selezionare l’APN il comando è:

at+cgdcont=1,"IP",datacard.tre.it
OK

La stringa IP va scritta con le virgolette.

Ce ne sono molti altri di comandi, possiamo riferirci ai manuali indicati poco sotto, nella sezione Riferimenti.

Altro fastidio può venire dal PIN, ossia il codice segreto di quattro cifre che serve a sbloccare la SIM. Al momento dell’acquisto la SIM è configurata per chiedere il codice di sblocco, ed occorre fornirlo ad ogni accensione, pena il rifiuto di attivare qualsiasi funzione propria della rete 3G o GSM che sia. Possiamo sia disabilitare la richiesta del PIN, usando l’interfaccia fornita con Windows, sia fornire il PIN usando la connessione con l’utility cu nel momento in cui andiamo a collegare il modem al computer:

at+cpin? – chiede lo stato del PIN. Se la risposta è SIM PIN il modem attende il PIN per sbloccare tutte le funzioni.

at+cpin=PIN – dove PIN è il nostro codice a quattro cifre. Sblocca la SIM e rende disponibili tutte le funzioni del modem.

Termino qui. Come sempre, le cose in apparenza semplici difficilmente lo rimangono quando si va appena un po’ sotto la superficie. Per la cronaca, sono due mesi che uso la connessione con il modem Momodesign, con tre differenti sistemi operativi (Fedora 8 e 9, Xandros/eeePC e Windows), da almeno tre regioni differenti d’Italia, in movimento e da fermo, senza alcun problema. La connessione funziona, è comoda e non ha un costo eccessivo. Occorre un po’ di lavoro all’inizio per far funzionare il tutto, ma dopo ci si dimentica di essere con un modem.

Riferimenti

• Un manuale modem con il set di comandi molto simile al Momodesign (cioè il cui modulo interno è costruito dalla Qualcomm)
• Le specifiche TS 27.007 del consorzio 3GPP (DOC PDF)
• Il sito del consorzio 3GPP.

Ci sono anche io.