Recupero di una pendrive USB

E' capitato ancora una volta. Qualcuno ha una pendrive che all'improvviso risulta vuota e Windows chiede se sia il caso di formattarla.

No! Alt! Stop!
Niente panico, proviamo a recuperare il contenuto
Se il danno hardware non è esteso (e spesso non lo è, anzi, mi è sempre capitato il caso che ad essere "persa" è stata la parte di disco relativa al boot sector/partition table/FAT) è possibile recuperare se non tutto almeno buona parte dei files presenti.
Ma procediamo con ordine.

1. Scopriamo su quale device è presente la pendrive (che ovviamente non viene montata, non potendo trovare alcun filesystem valido al suo interno).
   Per prima cosa inseriamo il pendrive in una porta USB e poi da terminale diamo:
   [tuxmal@work ~]# dmesg
   ottenendo:
   usb 1-6: new high speed USB device using ehci_hcd and address 7
   usb 1-6: New USB device found, idVendor=0457, idProduct=0151
   usb 1-6: New USB device strings: Mfr=0, Product=2, SerialNumber=3
   usb 1-6: Product: USB Mass Storage Device
   usb 1-6: SerialNumber: 73971bc79344b6
   usb-storage 1-6:1.0: Quirks match for vid 0457 pid 0151: 80
   scsi5 : usb-storage 1-6:1.0
   scsi 5:0:0:0: Direct-Access                               1.0  PQ: 0 ANSI: 2
   sd 5:0:0:0: Attached scsi generic sg3 type 0
   sd 5:0:0:0: [sdc] 983808 512-byte logical blocks: (503 MB/480 MiB)
   sd 5:0:0:0: [sdc] Write Protect is off
   sd 5:0:0:0: [sdc] Mode Sense: 00 00 00 00
   sd 5:0:0:0: [sdc] Assuming drive cache: write through
   sd 5:0:0:0: [sdc] Assuming drive cache: write through
    sdc: unknown partition table
   sd 5:0:0:0: [sdc] Assuming drive cache: write through
   sd 5:0:0:0: [sdc] Attached SCSI removable disk
   quindi il device è sdc. Alternativamente avremmo potuto leggere queste info con:
   [tuxmal@work ~]# tail /var/log/messages
   
2. Creiamo un file contenente i dati del pendrive, per le varie prove di recupero (pendrv è il nome del file utilizzato per i test), l'opzione bs specifica la grandezza dell'intero pendrive (in questo caso 512MB):
   [tuxmal@work ~]# dd bs=512M if=/dev/sdc of=./pendrv
3. Copiamo il file appena creato (per sicurezza, potremo ritornare sui nostri passi senza più toccare il pendrive, che anzi, rimuoviamo dalla porta USB):
   [tuxmal@work ~]# cp pendrv pendrv.bkup
4. Adesso, passiamo all'azione, controlliamo se si riesce a leggere qualcosa all'interno del pendrive:
   [tuxmal@work ~]# parted ./pendrv
   Nel caso in esame non risulta presente alcuna partizione. Possiamo provare ancora così:
   [tuxmal@work ~]# fdisk ./pendrv
   e, poiché non otteniamo alcun risultato interessante, ancora:
   [tuxmal@work ~]# fdisk -u -l ./pendrv
   oppure
   [tuxmal@work ~]# fdisk -l ./pendrv
5. Se ancora non si hanno riscontri positivi, come nel mio caso, proviamo con:
   [tuxmal@work ~]# gpart -g -i ./pendrv
   che continua a visualizzare partizioni errate:
         Begin scan...
       Possible partition(DOS FAT), size(486mb), offset(0mb)
       End scan.
   
       Checking partitions...
   
       * Warning: partition(Primary 'big' DOS (> 32MB)) starts beyond disk end.
       Partition(Primary 'big' DOS (> 32MB)): invalid primary
       Ok.
   
       Guessed primary partition table:
       Primary partition(1)
         type: 000(0x00)(unused)
         size: 0mb #s(0) s(0-0)
         chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
   
       Primary partition(2)
         type: 000(0x00)(unused)
         size: 0mb #s(0) s(0-0)
         chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
   
       Primary partition(3)
         type: 000(0x00)(unused)
         size: 0mb #s(0) s(0-0)
         chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
   
       Primary partition(4)
         type: 000(0x00)(unused)
         size: 0mb #s(0) s(0-0)
         chs:  (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
   
6. Proviamo comunque   a montare il nostro pendrive:
   [tuxmal@work ~]# mount -t vfat -o loop ./pendrive /mnt/usbdrv/
   Se nulla si è risolto, otterremo ancora errori del genere:
     mount: tipo fs errato, opzione non valida, superblocco su /dev/loop0 danneggiato,
            codepage o programma ausiliario mancante, o altro errore
            In alcuni casi si possono trovare informazioni utili in syslog. Provare
            ad esempio 'dmesg | tail'
   # dmesg | tail
     FAT: invalid media value (0x01)
     VFS: Can't find a valid FAT filesystem on dev loop0.
     FAT: invalid media value (0x01)
     VFS: Can't find a valid FAT filesystem on dev loop0.
     FAT: invalid media value (0xa5)
     VFS: Can't find a valid FAT filesystem on dev loop0.
     FAT: invalid media value (0xa5)
     VFS: Can't find a valid FAT filesystem on dev loop0.
     FAT: invalid media value (0xa5)
     VFS: Can't find a valid FAT filesystem on dev loop0.
   
7. Proviamo ad utilizzare, allora,
   [tuxmal@work ~]# testdisk ./pendrive
   seguendo i menù riusciremo a correggere boot sector e partition table ed a visualizzare i file (menù [Advanced]). Proprio da quest'ultimo menù, tramite [Image Creation], creo una nuova immagine del pendrive (dal nome di default image.dd).
8. Adesso proviamo a vedere dentro il pendrive recuperato:
   [tuxmal@work ~]#mount -t vfat -o loop ./image.dd /mnt/usbdrv/ -o codepage=850,iocharset=utf8
   montando l'immagine ottenuta, questa volta riuscimo a leggere tutti i file presenti. Per una corretta visualizzazione dei nomi dei file è stato necessario specificare le opzioni
     codepage=850,iocharset=utf8
   poiché le operazioni sono state svolte su di una linuxbox che usa UNICODE come charset di default.

Fonti

Partition-Rescue HOWTO

Per una occhiata veloce sul problema.

"Invalid or incomplete multibyte or wide character" Issue

Mi ha ispirato per inserire le opzioni di mount relative al set di caratteri.

Powered by ScribeFire

Continua...

Calc, OpenOffice.org e l'annoso problema delle righe da ripetere in stampa

Da più di un anno un noiosissimo bug in Calc di OpenOffice.org mi rendeva la vita difficile nel produrre elenchi formattati: l'impossibilità di impostare le righe da ripetere su ogni foglio in stampa.
Andando alla funzione Formato -> Aree di stampa -> Modifica, nella casella Riga da ripetere sia digitando manualmente i valori che  selezionando la riga del foglio da stampare tramite l'apposito tasto posto all'estrema desta, il risultato era sempre lo stesso: cliccando sul tasto Ok si otteneva sempre il messaggio Riferimento foglio non valido.
Più di una volta ho cercato si Google senza trovare nulla, ma oggi mi sono imbattuto in un post sul forum di OpenOffice.org che mi ha risolto una volta e per sempre il problema! In soldoni, come riporta l'utente sbaturzio:

Allora: ho risolto facendo così:
* Menu -> Strumenti -> Opzioni -> OpenOffice.org Calc->Formula
* Attivo Usa nomi di funzione Inglesi
* premo Ok
Da questo momento in avanti la funzionalità Riga da ripetere lavora correttamente senza errori.
Posso anche riportare la checkbox Usa nomi di funzione Inglesi allo stato originale senza che Riga da ripetere torni a dare errori.

Posso testimoniare che la cosa ha funzionato anche sul mio OpenOffice.org 3.2.1 (OOO320m15 (Build:9492) 3.2.1.4).

Powered by ScribeFire.

Continua...

InAcceptabile comportamento di IE[5-8]

Un utente si lamentava che una delle nuove funzionalità di OPTA, viste in funzione sul mio PC, non funzionavano correttamente. Alla richiesta di visionare l'elenco dell'organico, invece di aprire la pagina con l'elenco, veniva sempre ed inesorabilmente scaricato l'elenco in formato CSV (opzione presente con un link nella pagina, assieme a quello analogo per ottenerlo come PDF).

Inizio l'indagine constatando che la segnalazione proveniva da un'utente che usa IE8 (su Windows, of course), mentre con Firefox 3.6 (su Linux, obviously) tutto andava liscio come l'olio. Provo immediatamente con Firefox e con Chrome anche su Windows, ma lo strano comportamento non si presenta e l'elenco si visualizza correttamente.
Collego subito il problema con la gestione della respond_to del controller Rails relativo alla pagina: il codice, però, è scritto correttamente e poi: perché scarica proprio il CSV e non PDF?
Cerco un po' di documentazione in giro, mentre nel controller disabilito la gestione del formato CSV e faccio una nuova prova. Magicamente IE8 si comporta di nuovo normalmente. Mi risulta naturale cercare un tool (su Windows) per visionare le request inviata da IE8 al server. Trovo l'ottimo Fiddler (che potete vedere, figura precedente, nella parte alta della schermata).
Usandolo, noto come IE8 invii, nell'intestazione Accept, una marea di formati, fra cui application/vnd.ms-excel. Sembro essere sulla buona strada: ripristino la gestione del file CSV nel controller Rails e con l'aiuto di Fiddler forgio una request in cui elimino la voce application/vnd.ms-excel. Ora anche in IE8 ottengo l'elenco in formato HTML, come ci si sarebbe aspettato che fosse fin dall'inizio.
Nel frattempo le ricerche su internet mi avevano portato a questo articolo, Unacceptable Browser HTTP Accept Headers (Yes, You Safari and Internet Explorer) che mi apre la mente: la mia applicazione in Rails serve ad IE8 sempre prima il fomato CSV, semplicemente perché IE8 non invia il MIME-type text/html nell'Accept (provare per credere)!
Ulteriore conferma la ebbi leggendo il post Ruby on Rails and IE 8 - respond_to and HTTP accept headers.
Per la soluzione ho quindi inserito il seguente codice nelle viste Rails, al momento di creare il link:
par.merge!({:format => :html}) if request.env['HTTP_USER_AGENT'] =~ /MSIE/
dove par è l'hash utilizzato per la creazione dell'URI. In questo modo, per IE8 si forza esplicitamente il formato (HTML) richiesto, postponendo .html all'URI standard generato con Rails.

Powered by ScribeFire.

Continua...

Su Apache, ODT, PDF e unoconv

Da tempo in ufficio si utilizza una applicazione web, da me scritta, per la creazione di fax per la richiesta di visite fiscali alle ASL. Sebbene l'idea di partenza fosse quella di utilizzare direttamente Hylafax per l'invio dei fax, alla fine, per problemi puramente burocratici (firma "manuale" da apporre al documento e mancanza di una linea telefonica da utilizzare verso l'esterno), si è optato per la generazione di un file PDF da far stampare all'utente.

Tutto il servizio è basato su di una macchina virtuale GNU/Linux Mandriva 2009.1 su cui gira l'applicazione Rails per mezzo di Mongrel e Apache: ciò perché sussisteva già un'altra applicazione Rails che girava appoggiandosi al solo Mongrel. Impostando Apache in modalità revese proxy ero riuscito a far funzionare entrambe le applicazioni web come se fossero una sola.La generazione dei file avveniva in maniera alquanto macchinosa: si partiva da un modello in formato RTF, che veniva "riempito" con i dati presi da un database e convertito in PDF (tramite una antidiluviana applicazione, ted); il file risultante, a sua volta, veniva sovrapposto ad un altro contenente l'intestazione ed il piè di pagina con il necessario logo (tramite il mitico pdftk). Inoltre, per non appesantire troppo la macchina virtuale, ciascuna applicazione web girava in una singola istanza di Mongrel, invece che in cluster.
Morale della favola, vuoi per problemi di virtualizzazione (VMware), vuoi per problemi di carico su Mongrel, a volte al posto del PDF richiesto veniva mostrato un poco simpatico 504 Gateway Timeout.
Per risolvere il problema avevo pensato dunque di fare un doppio passaggio:

• utilizzare Phusion Passenger al posto di Mongrel per le applicazione web;
• sostituire i macchinosi script per la creazione del PDF con documatic (vedi pure su github per una versione più aggiornata) e unoconv.

Phusion Passenger
il passaggio a Phusion Passenger è stato alquanto semplice: è bastato installare la gem passenger (ora alla versione 2.2.11) e seguire le istruzioni per la corretta installazione dell'applicazione web.
Passaggio a Documatic ed unoconvL'utilizzo di Documatic è stato un po' più problematico per la fase di installazione dell'applicazione. Come prima, installiamo la gem documatic e assicuriamoci che sulla macchina server sia installato OpenOffice (attenzione, potrebbe essere necessario installare anche un desktop manager!). Predisponiamo anche unoconv ad essere eseguito ponendolo nella cartella /usr/bin od equivalente, purché sia nel path di root.
A questo punto il problema è che unoconv si rifiuta di funzionare, sebbene usandolo stand alone tutto sia a posto! Per risolverlo, è necessario un passaggio che ho scovato sul blog Blog of a LAMP Developer based near Guildford, Surrey, scorrendo il post Converting a Doc to PDF, txt or HTML using PHP and Linux, scritto per l'utilizzo di unoconv con PHP, si scopre che bisogna creare una home anche per l'utente apache:
[root@localhost home]# mkdir /home/apache
[root@localhost home]#chown apache:apache /home/apache
[root@localhost home]#usermod -d /home/apache apache
[root@localhost home]#chmd 755 /home/apache
In questo modo il funzionamento è assicurato.
Quello che non sono riuscito a fare, è predisporre un istanza di unoconv come listener e lanciare dalla applicazione web la connessione a quest'ultimo, in quanto dopo un po' di tempo (variabile di volta in volta) il listener sembrava fermarsi da solo, con unoconv che ti avvisava di andare in funzione in modalità stand-alone.

Powered by ScribeFire.

Continua...

urpmi: downgrade di pacchetti.

A seguito di un aggiornamento di KDE che non mi aveva del tutto soddisfatto (per la cronaca, da 4.3.2 a 4.4.2, non ancora ufficialmente supportata in Mandriva) , mi sono trovato nella condizione di di dover fare un downgrade alla precedente versione. Ovviamente non è bastato eliminare le fonti da cui avevo tratto l'aggiornamento, in quanto il successivo

# urpmi task-kde4

mi rispondeva dicendo che avevo già installato un pacchetto più aggiornato di quello presente nel repository :-(.

Neanche le maniere dure sono bastate:

# urpme task-kde4
# urpmi task-kde4

ha sì reinstallato il buon vecchio KDE 4.3.2, ma non tutte le dipendenze sono state risolte correttamente. Cosicché parecchi pacchetti erano rimasti ancora "troppo" aggiornati!
Per reinstallarli (ad uno ad uno!) mentre durate l'uso ne scovavo qualcuno, diventava impossibile eliminarli tramite urpme poiché ogni volta si rischiava di dover cancellare tutto KDE con successiva reistallazione; pura follia.
Dopo un attimo di spavento, ho ravanato un po' fra Google e Mandrivaitalia.org
, alla ricerca di un metodo per effettuare un downgrade correo di ciascun singolo pacchetto. Alla fine la soluzione trovata e testata è:

# rpm -e --nodeps <nomepacchetto>
# urpmi <nomepacchetto>

per ciascun pacchetto da di cui effettuare il downgrade.

Continua...

Ruby Best Practices di Gregory Brown

Dal creatore e principale manutentore di Prawn, ecco un interessante libro sulle "best practices" in Ruby, derivanti dal suo lavoro con questo linguaggio.
La versione versione open source dell'intero libro è disponibile all'interno del post Full Book Now Available For Free! sul suo blog.
L'indirizzo da cui prelevare il libro è http://sandal.github.com/rbp-book/pdfs/rbp_1-0.pdf, ma penso davvero che possa essere interessante visitare il blog di Gregory.

Buona lettura!

Powered by ScribeFire.

Continua...

CUPS 1.4.1 ed un baco malefico risolto

Con CUPS 1.4.1 ho avuto modo di imbattermi in un malefico bug con le stampanti condivise con SaMBa.
Il baco consiste nella richiesta continua delle credenziali per l'accesso alla stampante, anche se si è configurato correttamente l'accesso ad un dominio Windows da GNU/Linux.
Questo baco, molto sottile consiste nel fatto che CUPS 1.4.1 imposta (e reimposta dopo ogni stampa), nel file /etc/cups/printers.conf  l'attributo

AuthInfoRequired username,password

La soluzione al problema consiste nel commentare nel file tal riga e nel rendere tale file non modificabile: a tal fine non basta usare

[me@mybox]# chmod a-x /etc/cups/printers.conf

, in quanto CUPS riesce a reimpostare anche tali permessi, ma usare il meno noto (almeno a me)

[me@mybox]# chattr -i /etc/cups/printers.conf

Ecco di seguito tutto quello che c'è da fare:

[me@mybox]$ su
Password:
[me@mybox]# chattr -i /etc/cups/printers.conf
[me@mybox]# /etc/init.d/cups stop
[me@mybox]# vim -i /etc/cups/printers.conf
editare il file, ad es.
<defaultprinter theprinter="">
#AuthInfoRequired username,password
...
# eliminare la password e l'username quando il baco di CUPS 1.4.1 sparira'
DeviceURI smb://me:mypwd@MYDOMAIN/windoze/theprinter
...
</defaultprinter>
e poi
[me@mybox]# chattr +i /etc/cups/printers.conf
[me@mybox]# /etc/init.d/cups start

Powered by ScribeFire.

Continua...