Il non-blog di Mario Pascucci » Linux

NFS server su Linux + client NFS su SGI IRIX = cose strane

Mario Pascucci — Thu, 25 Mar 2010 09:23:03 +0000

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 risposta 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

Tape drive LTO-3, controller HP Smart Array, Linux e problemi di velocità

Mario Pascucci — Wed, 11 Nov 2009 03:00:32 +0000

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.

Personal Fedora LIVE parte II: la mia Live su pen drive USB

Mario Pascucci — Sun, 16 Aug 2009 21:22:18 +0000

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.

Fedora 10 Release Party Roma: tutto bene

Mario Pascucci — Wed, 10 Dec 2008 13:16:32 +0000

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.

Personal Fedora LIVE: mi faccio la mia distribuzione live!

Mario Pascucci — Tue, 09 Dec 2008 04:00:36 +0000

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 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

Fedora 10 Release Party a Roma: vediamoci là!

Mario Pascucci — Mon, 01 Dec 2008 15:14:34 +0000

La data scelta è il 9 dicembre, subito dopo cena, 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.

Linux software RAID: disco rotto, GRUB e problemi di boot

Mario Pascucci — Tue, 25 Nov 2008 04:00:45 +0000

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)

NTFS, file cancellati e tool di analisi (parte II)

Mario Pascucci — Tue, 18 Nov 2008 04:00:38 +0000

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...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

NTFS, file cancellati e tool di analisi

Mario Pascucci — Mon, 03 Nov 2008 13:00:05 +0000

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:

cancella il contenuto scrivendo tutti zeri
formatta la memoria in un filesystem scelto fra FAT, Ext3 e NTFS
scrivici dei file dentro, 4 PDF e 30 immagini
smonta, fai l’immagine con dd
rimonta, cancella alcuni file, 2 PDF e 9 immagini, sempre le stesse
smonta, fai l’immagine con dd
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

Fedora e modem HSDPA ONDA MT503HS (TIM)

Mario Pascucci — Wed, 10 Sep 2008 14:59:46 +0000

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.