Ho ancora per le mani un paio di server Silicon Graphics Origin 200 (roba del 2000, che va ancora senza il minimo problema).
Nell’impianto dove sono impiegati, questi due server montano via NFS uno spazio disco condiviso da un server SUNFire 6800.

Arrivato il momento della pensione per il SunFire (le macchine SGI ci andranno a fine anno), è stato sostituito da un server DL380 di HP, con 5Tb di disco, con installato CentOS.

A metà della procedura di sostituzione, controllando che i servizi che girano sul Origin 200 operassero regolarmente, è saltato fuori un problema veramente curioso. Supponiamo che la macchina CentOS esporti una directory chiamata alfa, con dentro due directory beta e gamma. La macchina SGI avrà nel file /etc/fstab una riga tipo questa:

centos:/alfa  /puntodimount   nfs  defaults 0 0

Fin qui nulla di strano. L’anomalia salta fuori se si entra nella directory /puntodimount, e di usa il comando pwd:

# cd /puntodimount
# pwd
/
#

la riosposta dovrebbe essere invece /puntodimount, ossia viene “eliminato” percorso di mount dalla directory corrente. Naturalmente in questo frangente tutti i servizi che controllano dove si trovano prima di operare non funzionano più, perché se vogliono andare dentro /puntodimount/beta, al controllo di “dove sono” (pwd), si vedono dentro /beta.

Dopo un paio di passaggi con Google ne sono venuto a capo: è un bug noto di IRIX 6.5.12 e precedenti, il numero 815265, la cui criptica definizione è: IRIX not liking file handles of less than 32 bytes. Il bug è risolto nella versione 6.5.13, ma, naturalmente, non è possibile fare alcun aggiornamento della macchina IRIX, meno che mai un aggiornamento di sistema operativo, che porterebbe ben altri problemi.

La soluzione è di usare l’opzione vers=2 nel file /etc/fstab del client IRIX, in questo modo:

centos:/alfa  /puntodimount   nfs  defaults,vers=2  0 0

Risolto questo problema, naturalmente, è uscito fuori quello che stava sotto, più grande: le prestazioni pietose. Per capirci, creando un file da 100M dalla macchina SGI sul server NFS Linux, questo è stato il risultato:

# time dd if=/dev/zero of=/LGCACHE/provamario bs=1024000 count=100
100+0 records in
100+0 records out
0.0u 2.0s 5:56 0% 0+0k 3+6250io 0pf+0w

Tradotto, 5 minuti e 56 secondi per creare il file, ossia 280kb/sec, roba che neanche con una rete a 10 mbit.

Facendo il solito giro, stavolta sui newsgroup, ho trovato un paio di messaggi che spiegano perché e come risolvere. In breve: mentre l’implementazione di SUN del server NFS lavora bene con l’impostazione synchronous writes, ossia il server risponde “ho scritto” ad ogni richiesta solo dopo che ha effettivamente scritto sul disco i dati, lasciando in attesa il client, l’implementazione in Linux lavora meglio con l’impostazione asynchronous writes, dove il server risponde immediatamente “ho scritto” alla corretta ricezione dei dati. L’effetto è che le scritture su disco, in Linux, vengono accumulate ed eseguite a gruppi, eliminando di fatto l’attesa per il client.
Aggiungendo nel server Linux alla riga di definizione della share NFS nel file /etc/exports il parametro async si ottiene questo risultato, con lo stesso test di scrittura:

# time dd if=/dev/zero of=/LGCACHE/provamario1  bs=1024000 count=100
100+0 records in
100+0 records out
0.0u 1.7s 0:11 15% 0+0k 1+6255io 0pf+0w

solo 11 secondi, pari a 9,3Mb/sec, un risultato ben diverso da prima.

Riferimenti

• Il Linux NFS HOWTO, al paragrafo 8.5.2, dove nomina questo problema specifico, ma tutti i link riportati sono “rotti”, quindi non forniscono soluzioni
• Linux NFS FAQ su Sourceforge, al punto E3 riporta la soluzione.
• Il messaggio nel newsgroup comp.protocols.nfs che spiega il perché delle lentezze della accoppiata Linux/SGI con NFS
• Il messaggio nel newsgroup comp.os.linux.development.system che mostra un test di confronto su server NFS Linux con e senza l’opzione async

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Ho per le mani un server nuovo di zecca, con una discreta dotazione hardware. In particolare il pezzo degno di nota è un drive per nastri di tipo LTO-3.

Il server è un HP DL380 di sesta generazione, e monta un controller dedicato per il drive a nastro, uno SmartArray P212 con interfaccia di tipo SAS.

Il primo problema è stato che il drive non è rilevato all’avvio del sistema operativo, ma questo è facile da risolvere: i controller di tipo Smart Array sono in grado di accettare e controllare dispositivi a nastro, naturalmente a patto che l’interfaccia sia corretta, ossia SAS o SCSI. Il supporto per i dispositivi SCSI che non siano dischi è normalmente disabilitato nel modulo kernel corrispondente, che per la cronaca si chiama cciss, e può essere abilitato senza problemi e senza riavviare niente. Basta usare l’interfaccia /proc di accesso ai parametri del kernel.
Occorre prima individuare a quale controller sia connesso il drive a nastro, se ce ne sono più di uno. Basta andare a guardare nella directory /proc/driver/cciss: in questa directory vi sono tanti file quanti sono i controller, con il nome ccissX dove X è il numero “logico” del controller. Guardando dentro i singoli file con un cat si individua il controller giusto, nel mio caso è cciss1, il cui contenuto è:

cciss1: HP Smart Array P212 Controller
Board ID: 0x3241103c
Firmware Version: 1.66
IRQ: 178
Logical drives: 0
Sector size: 2048
Current Q depth: 0
Current # commands on controller: 0
Max Q depth since init: 0
Max # commands on controller since init: 1
Max SG entries since init: 0
Sequential access devices: 1

Per individuarlo, nel mio caso, ho cercato il modello di controller, ma si può usare ad esempio la presenza o meno di dischi, se il controller è condiviso fra dischi e nastro, cosa sconsigliata a priori.
Trovato il controller giusto, basta dare questo comando, da utente root:

# echo "engage scsi" > /proc/driver/cciss/cciss1

sostituendo a cciss1 il file giusto, e magicamente appare il drive a nastro, come si può verificare dai messaggi del kernel, visibili col comando dmesg:

scsi0 : cciss
  Vendor: HP        Model: Ultrium 3-SCSI    Rev: Q24D
  Type:   Sequential-Access                  ANSI SCSI revision: 05
scsi 0:0:0:0: Attached scsi generic sg0 type 1

Per trovare il device, occorre prima caricare a mano il modulo kernel st, oppure riavviare, ed a quel punto avremo disponibile il device /dev/st0 ed il device /dev/nst0 per accedere al nastro: il primo riavvolge il nastro automaticamente all’inizio quando si termina una operazione di scrittura (alla chiusura del device, ossia quando ad esempio il comando tar termina), mentre il secondo lascia il nastro dov’è.
Per rendere permanenti le modifiche ed avere il drive disponibile fin dall’avvio, ho inserito il comando nel file /etc/rc.local, che nelle distribuzioni RedHat e derivate (Fedora, CentOS), come pure in Debian, è destinato appunto questo scopo. Come effetto collaterale avremo che il modulo kernel st sarà caricato automaticamente all’avvio.

La velocità

Il primo test è a dir poco deludente: meno di 3 megabyte al secondo. Ma l’effetto peggiore è un altro, a lungo termine: il drive, non avendo dati alla velocità giusta, è costretto a fermarsi, aspettare dati a sufficienza, tornare indietro e ripartire. Questo ciclo di start-stop-rewind è in grado di distruggere un drive in pochi mesi. Se invece i dati arrivano costantemente e in quantità adeguata, il drive scrive a velocità costante per tutto il tempo senza fermarsi mai, se non alla fine del lavoro.
Ebbene, il problema è a vari livelli. La facciamo breve:

• disattivare la compressione del drive, ed usare quella del software
• impostare la dimensione del blocco sul nastro a 64k (65536 bytes)
• assegnare al modulo kernel st almeno 2 megabyte di buffer

dopo questi interventi la velocità in scrittura è passata a 30 megabyte/sec, ben dieci volte, e soprattutto niente più start-stop.

Ecco i comandi da impartire, partiamo dalla compressione:

# mt -f /dev/st0 compression off

dove mt è una utility per la gestione dei drive a nastro, disponibile nel pacchetto mt-st.

Per la dimensione del blocco, si può utilizzare sia il comando:

# mt -f /dev/st0 setblk 65536

che con le opzioni proprie del programma usato per scrivere su nastro. Ad esempio tar ha l’opzione -b a cui devono essere indicati quanti blocchi da 512 byte per impostare la lunghezza del segmento dati da leggere o scrivere. Per 64k l’opzione è -b 128.

Per il buffer del modulo kernel st invece occorre aggiungere questa riga al file /etc/modprobe.conf (o l’equivalente della distribuzione in uso):

options st buffer_kbs=4096

e per attivare le modifiche basta scaricare il modulo, eseguire un depmod -a e ricaricare il modulo st. Se la configurazione è corretta, nel log del kernel deve apparire qualcosa del genere:

st: Version 20070203, fixed bufsize 4194304, s/g segs 256
st 0:0:0:0: Attached scsi tape st0
st0: try direct i/o: yes (alignment 512 B)
st0: Block limits 1 - 16777215 bytes.

Notare il messaggio: “fixed bufsize 4194304?.

La cura è piuttosto efficace, questo è il risultato di un test eseguito dopo le impostazioni mostrate:

# time dd if=/dev/zero of=/dev/st0 bs=64k count=100000
100000+0 records in
100000+0 records out
6553600000 bytes (6,6 GB) copied, 212,13 seconds, 30,9 MB/s

real	3m32.133s
user	0m0.040s
sys	0m1.049s

Riferimenti

• Il manuale del modulo st, contenuto nel pacchetto kernel-doc, o nei sorgenti del kernel, in Documentation/scsi/st.txt.
• Il manuale del modulo cciss, sempre nel pacchetto della documentazione del kernel, in Documentation/cciss.txt.
• Un vecchio articolo della knowledge base di RedHat sui controller Smart Array.

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Nella prima parte abbiamo visto come si può creare la propria distribuzione LIVE di Fedora, sfruttando i livecd-tools messi a disposizione dal team del progetto Fedora. Ora vediamo di rendere le cose ancora più “appetitose” mostrando come si può trasferire la nostra distribuzione LIVE personalizzata su un pen drive USB o su una scheda SD per poterla utilizzare come se fosse installata su un normale disco magnetico.

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.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Ieri sera c’è stato il Release Party per l’arrivo della versione 10 di Fedora.

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.

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Da tempo nel progetto Fedora esistono dei tool, semplici ed efficaci, per creare immagini LIVE della distribuzione, da usare a piacimento. Ecco una breve panoramica su cosa serve e come si procede.

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 termina 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, ho modificato lo script di avvio per evitare che succeda. 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

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

La data scelta è il 9 dicembre, alle ore 21, presso l’associazione La Civetta sul comò, che ringraziamo per l’ospitalità.

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.

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Situazione: un server con due dischi in RAID1 software, ossia in mirroring, con Linux. I dischi sono SCSI, se fossero IDE o SATA il problema non cambierebbe. Il disco di avvio è sda, ed è “specchiato” con sdb. Si guasta il disco sda, ed occorre sostituirlo. Si spegne il server, si sostituisce con uno nuovo, si riaccende il server. Risultato: Non system disk or disk error. Il server non riparte.

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)

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Non potevo accontentarmi di lasciare perdere l’argomento, trattato qualche giorno fa, rimanendo con un punto interrogativo. Quindi eccomi di nuovo qui a riprendere il discorso sui file cancellati in NTFS e sui tool forensi.

Ho condotto ulteriori analisi, in particolare sulle due immagini disco generate con Windows XP ed ho scoperto cose interessanti, lavorando però di dump esadecimale.

Ho estratto il file $MFT da entrambe le immagini, ne ho fatto il dump esadecimale e li ho messi a confronto usando gvimdiff, la versione grafica del noto editor Vim nella variante per mostrare le differenze fra due file.

Il file è la Master File Table del filesystem e contiene praticamente tutte le informazioni per mettere insieme i pezzi del filesystem. La struttura è molto complessa, ma per quello che ci serve cercheremo di limitarci all’essenziale per capire come stanno le cose, a scapito dell’estremo dettaglio, che in questo specifico caso non ci interessa.

Riassumo il problema: nella directory docs sono stati cancellati due dei quattro file PDF presenti (pdf2.pdf e pdf4.pdf), e solo uno risulta presente e recuperabile (pdf2.pdf), l’altro pare svanito nel nulla. Tutti i tool forensi provati mostrano questo risultato, sia open source che commerciali.

Confrontando i dump esadecimali delle due MFT si trova il problema. La directory è un file come tutti gli altri, che in questo caso viene memorizzato all’interno della MFT stessa, nello stesso record, vista la ridotta dimensione, condizione in cui il file viene chiamato “residente”. Da qui partono i puntatori agli altri record che rappresentano i singoli file presenti nella directory. Nella MFT dell’immagine con tutti i file prima della cancellazione il record è posizionato nella entry numero 29, all’offset 0×7400 del file. I file sono invece posizionati come segue:

• pdf1.pdf – entry 33
• pdf2.pdf – entry 31
• pdf3.pdf – entry 32
• pdf4.pdf – entry 30

cosa verificabile con Autopsy nella sezione dei metadati. La struttura dati della directory è lunga 464 bytes, sempre secondo la MFT.

Nell’immagine con i file cancellati la struttura della directory è lunga solo 256 bytes, indice che è stata “accorciata”, fra poco vedremo il perché. Le entry di prima contengono:

• pdf1.pdf – entry 33
• pdf2.pdf (deleted) – entry 31
• pdf3.pdf – entry 32
• images/Thumbs.db – entry 30

andando a vedere la struttura della directory nella MFT si nota questo:

00007590:  0803 7000 6400 6600 3100 2E00 7000 6400    ..p.d.f.1...p.d.
000075A0:  6600 0000 0000 0000 2000 0000 0000 0100    f....... .......
000075B0:  6800 5200 0000 0000 1D00 0000 0000 0100    h.R.............
000075C0:  96D8 C62C C323 C901 00D0 106D 741D C901    ...,.#.....mt...
000075D0:  00D0 106D 741D C901 F03A C92C C323 C901    ...mt....:.,.#..
000075E0:  0094 0200 0000 0000 E493 0200 0000 0000    ................
000075F0:  2000 0000 0000 0000 0803 7000 6400 0800     .........p.d...
00007600:  3300 2E00 7000 6400 6600 0000 0000 0000    3...p.d.f.......
00007610:  0000 0000 0000 0000 1000 0000 0200 0000    ................
00007620:  FFFF FFFF 8279 4711 2E4F BD2C C323 C901    .....yG..O.,.#..
00007630:  0003 BA45 741D C901 0003 BA45 741D C901    ...Et......Et...
00007640:  5275 3E14 5B24 C901 009E 0200 0000 0000    Ru>.[$..........
00007650:  D99D 0200 0000 0000 2000 0000 0000 0000    ........ .......
00007660:  0803 7000 6400 6600 3400 2E00 7000 6400    ..p.d.f.4...p.d.
00007670:  6600 0000 0000 0000 0000 0000 0000 0000    f...............
00007680:  1000 0000 0200 0000 FFFF FFFF 8279 4711    .............yG.
00007690:  2E4F BD2C C323 C901 0003 BA45 741D C901    .O.,.#.....Et...
000076A0:  0003 BA45 741D C901 5275 3E14 5B24 C901    ...Et...Ru>.[$..
000076B0:  009E 0200 0000 0000 D99D 0200 0000 0000    ................
000076C0:  2000 0000 0000 0000 0803 7000 6400 6600     .........p.d.f.
000076D0:  3400 2E00 7000 6400 6600 0000 0000 0000    4...p.d.f.......
000076E0:  0000 0000 0000 0000 1000 0000 0200 0000    ................
000076F0:  FFFF FFFF 8279 4711 0000 0000 0000 0000    .....yG.........

che nella MFT prima della cancellazione è invece così:

00007590:  0803 7000 6400 6600 3100 2E00 7000 6400    ..p.d.f.1...p.d.
000075A0:  6600 0000 0000 0000 1F00 0000 0000 0100    f...............
000075B0:  6800 5200 0000 0000 1D00 0000 0000 0100    h.R.............
000075C0:  E213 C22C C323 C901 8037 4114 741D C901    ...,.#...7A.t...
000075D0:  8037 4114 741D C901 3C76 C42C C323 C901    .7A.t...<v.,.#..
000075E0:  0034 0200 0000 0000 3C33 0200 0000 0000    .4......<3......
000075F0:  2000 0000 0000 0000 0803 7000 6400 6600     .........p.d.f.
00007600:  3200 2E00 7000 6400 6600 0000 0000 0000    2...p.d.f.......
00007610:  2000 0000 0000 0100 6800 5200 0000 0000     .......h.R.....
00007620:  1D00 0000 0000 0100 96D8 C62C C323 C901    ...........,.#..
00007630:  00D0 106D 741D C901 00D0 106D 741D C901    ...mt......mt...
00007640:  F03A C92C C323 C901 0094 0200 0000 0000    .:.,.#..........
00007650:  E493 0200 0000 0000 2000 0000 0000 0000    ........ .......
00007660:  0803 7000 6400 6600 3300 2E00 7000 6400    ..p.d.f.3...p.d.
00007670:  6600 0000 0000 0000 1E00 0000 0000 0100    f...............
00007680:  6800 5200 0000 0000 1D00 0000 0000 0100    h.R.............
00007690:  2E4F BD2C C323 C901 0003 BA45 741D C901    .O.,.#.....Et...
000076A0:  0003 BA45 741D C901 E213 C22C C323 C901    ...Et......,.#..
000076B0:  009E 0200 0000 0000 D99D 0200 0000 0000    ................
000076C0:  2000 0000 0000 0000 0803 7000 6400 6600     .........p.d.f.
000076D0:  3400 2E00 7000 6400 6600 0000 0000 0000    4...p.d.f.......
000076E0:  0000 0000 0000 0000 1000 0000 0200 0000    ................
000076F0:  FFFF FFFF 8279 4711 0000 0000 0000 0000    .....yG.........

Proviamo a riassumere. La directory è stata compattata per conservare i dati di soli due file invece di quattro e nella operazione le entry dei file pdf3.pdf e pdf4.pdf vanno a soprascrivere quella del file pdf2.pdf, poi viene accorciata, perdendo le indicazioni relative al file pdf4.pdf. Tutte queste informazioni si perdono e solo andando di dump esadecimale diretto sul file $MFT si possono vedere.
La entry 30, riguardante il file pdf4.pdf viene soprascritta autonomamente da Windows: nel momento in cui sono andato dalla directory docs alla directory images è passato alla modalità “visualizzatore di immagini”, creando e scrivendo il file delle thumbnail (Thumbs.db), soprascrivendo di fatto la entry del file pdf4.pdf. Il file pdf2.pdf è recuperabile perché, anche se eliminato dalla struttura dati della directory, è ancora presente la sua entry nella MFT, mentre il file pdf4.pdf, pur se ancora presente nella entry della directory docs, non è all’interno di alcuna struttura dati valida, e la sua entry è stata soprascritta da un altro file. Ecco perché il file pdf4.pdf è “sparito”.

Insomma, alla fine niente di strano o preoccupante in sé, solo normali operazioni del filesystem e le sue decisioni autonome relative all’efficienza ed al mantenimento della coerenza interna. Se non mi fossi posto il dubbio, e non avessi operato in questo modo, non avrei mai notato le discrepanze e la “scomparsa” dei file cancellati. Lavorando solo con i tool non si ottiene “tutta la verità”. Occorre come sempre competenza ed un pizzico di scetticismo, che non guasta mai.

Quindi, a maggior ragione
Trust no one

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Come spesso mi succede, quando sto lavorando a qualcosa mi imbatto in comportamenti inattesi che, per mia sfortuna, mi distraggono dal mio compito principale fino a quando la mia curiosità, un tantino patologica, non è soddisfatta.

Qualche settimana fa stavo lavorando su un set di memorie flash di vario tipo (pen drive, SD, Memory Stick, CompactFlash) per verificare alcune ipotesi per uno studio di cui forse parlerò in altra occasione. Le operazioni erano banali, più o meno sintetizzabili in questa sequenza:

1. cancella il contenuto scrivendo tutti zeri
2. formatta la memoria in un filesystem scelto fra FAT, Ext3 e NTFS
3. scrivici dei file dentro, 4 PDF e 30 immagini
4. smonta, fai l’immagine con dd
5. rimonta, cancella alcuni file, 2 PDF e 9 immagini, sempre le stesse
6. smonta, fai l’immagine con dd
7. analizza le immagini per verificare che i dati siano sul supporto e che siano recuperabili con vari tool, anche per uso forense

I tool utilizzati erano Foremost e lo Sleuthkit.

Ebbene, la stranezza rilevata è questa: nel primo supporto in cui ho provato con il filesystem NTFS (un pen drive da 1 gigabyte, acquistato in un centro commerciale) le nove immagini cancellate erano totalmente recuperabili, mentre dei due PDF cancellati, secondo Sleuthkit, non vi era traccia, nel senso che non erano neanche fra i file cancellati e non recuperabili. Non solo, erano segnate come cancellate e non recuperabili 4 copie dell’immagine numero 4 e 5 copie dell’immagine numero 5, che naturalmente non avevo toccato.

Usando Foremost, come atteso, i file erano tutti recuperabili, senza problemi.

Questa cosa, in prima battuta, mi ha fatto pensare ad un mio errore di manovra, per cui ho rifatto il test con un altro supporto, una scheda SD da un gigabyte. Stessa storia, unico cambiamento è stato che uno dei due file PDF risultava fra i cancellati e recuperabile, l’altro era sparito, mentre venivano segnate 5 copie dell’immagine numero 4 e 6 copie dell’mmagine numero 5 cancellate e non recuperabili. Foremost, al solito, recuperava tutto.

Ho cambiato le condizioni del test, pensando a qualche stranezza nella gestione dei dischi removibili, ed ho avviato una macchina virtuale con Windows XP Professional SP2 tramite Qemu, a cui ho “collegato” un disco virtuale da 80 megabyte, formattato NTFS. Stesse operazioni, stessa storia: i due PDF cancellati non risultano da nessuna parte, secondo Sleuthkit, mentre le immagini sono tutte recuperabili e c’è sempre la coppia di immagini segnalate fra le cancellate più volte e non recuperabili.

Sempre più perplesso ne ho parlato con i “colleghi di lista” di CFItaly. Ne è nata una discussione che ritengo estremamente fruttuosa, e che provo a riassumere.

Sono state proposte varie spiegazioni, a partire dalla interferenza della virtualizzazione, cosa che ho scartato, verificando su un computer con installato Windows XP Professional SP2: il mio notebook dell’ufficio, a cui ho leggermente ristretto la partizione di ripristino e ne ho ricavato 80 megabyte per creare un disco da formattare in NTFS. Il risultato è stato analogo ai precedenti. Allora è stata fatta l’ipotesi che la partizione fosse troppo esigua, cosa che ho escluso allargando la partizione nel notebook a 350 megabyte, e trovando ancora gli stessi risultati.

A questo punto ho posto io il dubbio che fosse Sleuthkit ad avere dei problemi ed a “mancare” alcune informazioni critiche. Test fatti da colleghi di lista che avevano a disposizione prodotti commerciali, nomi noti nel campo, escludevano anche questa ipotesi: i tool commerciali restituiscono lo stesso identico risultato dello Sleuthkit.

Quello che ho potuto verificare è che il numero e la posizione dei file che “spariscono” dopo la cancellazione, secondo lo Sleuthkit, e che invece sono completamente recuperabili da Foremost, cambia in funzione dell’ordine in cui avvengono le operazioni e dagli intervalli di tempo fra le stesse.

In conclusione, il risultato è che il filesystem NTFS può “nascondere” dati importanti, a causa di qualcosa nel metodo di gestione dei file cancellati, e che l’elenco non solo dei file recuperabili, ma anche quello dei file cancellati in generale, può contenere dati fuorvianti, o incompleti.

Se avete voglia di cimentarvi, ho preparato tre pacchetti zip:

• il primo con le immagini del disco “virtuale” collegato alla macchina Windows XP con Qemu. Uno dei file è quello dove i file sono stati solo cestinati, il secondo dove invece sono stati direttamente cancellati, il nome è “parlante”. NB: queste due sono immagini del disco completo, con tanto di tabella delle partizioni
• Il secondo contiene due immagini ottenute con dd della partizione “rimediata” dal mio notebook, la prima con i file appena messi e la seconda con i file appena cancellati.
• La terza contiene una sola immagine, sempre ricavata dalla partizione del notebook, dove ho semplicemente cambiato qualcosa nell’ordine di cancellazione e nei tempi, attendendo un po’ prima di cancellare dell’altro.

A questo punto ci sta anche bene:
Trust no one

Popularity: unranked [?]

Puoi visualizzare il post originale qui.

Anche questo modem USB funziona con Fedora senza particolari sbattimenti. La procedura è identica a quella dell’Itelco ITM22, solo che la stringa magica da inserire nel file /etc/modprobe.conf è questa:

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.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Mi è capitato per le mani questo modem USB che, a differenza del Momodesign MD-@, non ha la commutazione manuale fra memoria flash con i driver e modem vero e proprio.

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 0×1a8d 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, 0×1a8d, 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.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Ho giocato un po’ con le quattro cose del titolo, stimolato da un commento di Matteo Moro, questo. Il risultato è uno script shell molto semplice che chiede a quale porta è connesso il modem USB e mostra operatore a cui è connesso sulla rete GSM/3G ed il livello di segnale.

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.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Come promesso, ecco la procedura per connettersi a Internet con Fedora via HSDPA con l’adattatore USB Momodesign MD-@, di cui ho già parlato qui.

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.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Eccolo qui.

Ci sono anche io.

Popularity: 1% [?]

Puoi visualizzare il post originale qui.

Dovendo garantirmi una connessione a Internet anche in luoghi palesemente privi di prese LAN, ho fatto qualche indagine fra amici e Internet, e grazie anche ad un articolo molto dettagliato (ripreso qui), ho deciso di prendere un abbonamento solo dati con annesso modem USB, questo.

Poi, grazie al mio amico spacciatore di hardware, mi sono convinto a prendere l’Asus eeePC 900 con Linux. Appena ho potuto li ho accoppiati, e il tutto funziona egregiamente, a patto di fare qualche piccola modifica alle configurazioni.

La procedura è abbastanza semplice. Una volta connesso il modem USB all’Asus, basta andare nel menù Internet, selezionare l’icona Rete e creare una nuova connessione UMTS/HDSPA (figura sotto).

Al pannello seguente selezionare il modem H3G (figura sotto).

Poi arriva la selezione dell’operatore, necessaria per evitare salassi in bolletta. L’elenco è inizialmente vuoto, ed occorre premere il pulsante Cerca per ottenere l’elenco degli operatori a portata d’antenna (figura sotto).

Il pannello successivo permette di scegliere il gestore, e l’elenco comprende praticamente tutti quelli presenti in Italia (figura sotto).

Nell’esempio mostrato ho selezionato l’operatore H3G Italia, ed automaticamente viene inserito come APN (Access Point Name) il valore tre.it.

Ebbene, se come me avete scelto un abbonamento “solo dati”, l’APN è sbagliato. Quello inserito vale per le normali SIM abilitate sia al traffico dati che voce. Quello per le connessioni solo dati è datacard.tre.it come specificato qui.

Il problema è che se l’APN è sbagliato, la connessione non verrà effettuata ed il messaggio d’errore sarà del tutto fuorviante, lamentando apparentemente un “Protocol-Reject for ‘Compression Control Protocol’ (0×80fd) received” (figura sotto).

In realtà non c’entra nulla. Ho fatto delle prove con praticamente tutte le combinazioni di configurazione del protocollo con Fedora (successivamente ci sarà un articolo anche per questa distribuzione) ed alla fine, pur non avendo più un messaggio di “Protocol-Reject” la connessione veniva abbattuta immediatamente dal server remoto. Inserendo l’APN giusto è andata al primo colpo.

Quindi, inseriremo l’APN giusto, se abbiamo un abbonamento “solo dati” (vedi figura sotto).

Proseguendo, daremo un nome qualsiasi alla connessione, ci viene presentato un riepilogo delle impostazioni, e siamo pronti per navigare. La connessione partirà al primo tentativo senza problemi.

Popularity: 2% [?]

Puoi visualizzare il post originale qui.