Archivi categoria: informatica

Samsung ES8000 – Data REcovery

Nel 2011 ho acquistato un televisore Samsung 46 pollici, modello ES8000 (ne ho già parlato, per un problema, in questo articolo). Per potere giocare con le diverse app installate, ho montato su di esso una chiavetta USB. Nel corso degli anni abbiamo registrato su di essa diverse foto e video, fatti con la camera integrata. Ad un certo punto, il buio. Chiavetta non riconosciuta. Provo ad accedere ai dati, nulla. Non viene vista da Linux nè da Windows. Ok, mi incaponisco. Questo il risultato.

Inserendo la chiavetta in un calcolatore linux, si ottengono pochissime informazioni.
sd 4:0:0:0: [sdd] 2041856 512-byte logical blocks: (1.05 GB/997 MiB)
sd 4:0:0:0: [sdd] Write Protect is off
sd 4:0:0:0: [sdd] Mode Sense: 23 00 00 00
sd 4:0:0:0: [sdd] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
sd 4:0:0:0: [sdd] Attached SCSI removable disk

Che sono comunque utili a determinare il funzionamento del dispositivo. In rete ho trovato la documentazione di un progetto “SamyGO“, che parla del filesystem di queste chiavette. Si tratta di un RFS, Robust File System, pensato proprio per le pendrive e supportato da Samsung “da sempre”. Rimane da capire come accedere ai dati, cosa che viene spiegata in questo articolo: in pratica si tratta di un filesystem FAT16 o FAT32, che può essere montato nativamente e con poco sforzo in linux. Il problema è, semmai, recuperare i dati della partizione.

Come già successo in passato, mi è venuto in aiuto il programma testdisk (lo avevo usato per recuperare i dati di “esse”) , in ambiente linux. Ho caricato il drive corrispondente alla mia chiavetta (/dev/sdd) ed ho provato a fare riconoscere la partizione: NULLA. Allora ho deciso di lavorare “senza partizioni” indicando un filesystem di tipo FAT16 ed eseguendo una “immagine della partizione”. Ho fatto lo stesso con il filesystem FAT32.
Una volta create le “immagini” mi sono messo a lavorare con queste.
testdisk image16.dd
selezionare “proceed” e quinti “non partitioned media”
associare un tipo fat16 ai dati

eseguire un “rebuild del boot sector”

Con l’opzione “list” è possibile vedere tutti i files che sono recuperabili (in grigio) e quelli persi per sempre (in rosso).

Con una sintassi molto fantasiosa (utilizzo di : e C) è possibile copiare i dati in una altra posizione e, finalmente, goderseli.
Una ultima nota: Samsung salva le immagini in formato ljpg, che è un jpg a tutti gli effetti. I video hanno estensione .vu, ma VLC li “digerisce” senza problemi in quanto sono MPEG.

Finalmente posso regalare a questa chiavetta, il riposo eterno che merita!

Odroid XU3

Da diversi anni ho installato una Odroid XU3 in uno spazio attrezzato, ove funge (essenzialmente) da piattaforma per Spyserver. Malgrado sia un oggetto piuttosto datato, lavora molto bene e non è particolarmente avida di energia.
Recentemente ho notato che tende ad essere un po’ calda, pertanto, oltre a sostituire la ventolina che non ne poteva più, ho provato a fare un po’ di hack sul controllo della rotazione.
Ho letto un interessante articolo su un forum, in cui viene spiegato in modo molto semplice come cambiare la logica di intervento della ventola. Le impostazioni che ho configurato sono un po’ aggressive: alla temperatura di 50°C la ventola gira al 50%, a 65°C si sale all’80% ed oltre i 75°C arriviamo al valore di 95%. Considerato che la ventola è inserita in un contesto piuttosto “caldo” è meglio “prevenire”.

Situazione di partenza, temperatura media 64°C

Dopo qualche giorno di lavoro, la situazione è la seguente. Tocca solo capire quanto durerà la ventola!

Dopo la cura!

Data Recovery

Situazione: un conoscente, che per convenzione e privicy chiameremo “esse”, crea per errore un “supporto per l’installazione di windows 10” sul disco dei backup. Windows, vede uno disco da 1TB e decide di formattarlo. Esse mi chiama dicendo che il disco che si chiamava “pippo”, ha cambiato nome e dentro ci sono solo files di windows.
In passato avrei detto “pace è andato tutto”. Questa volta mi sono incaponito e forse sono riuscito a recuperare un po’ di dati. Ho lavorato solo in ambiente Linux (Ubuntu).

Step zero: non avere fretta. Il data recovery è un processo lungo, lunghissimo. La fretta aumenta il numero di dati che vengono persi.

Primo step: non si lavora MAI sul disco originale. Pertanto ho preso un disco da 2TB (ex videosorveglianza, lentissimo), e lo ho installato nella mia WS. Ho fatto una immagine del disco originale con “dd” e ho messo in un cassetto il dispositivo. Da questo momento in poi ho lavorato SOLO sulla immagine, per preservare i dati e la meccanica del disco originale.

Secondo step: cercare di recuperare la tabella delle partizioni vecchia. Per questo mi sono avvalso del tool testdisk, usando la funzione di “deep search”. Una volta ricostruita la tabella delle partizioni, il problema è stato: come recupero i dati da un filesystem compromesso? I tool nativi di Linux, come ntfsrecover, non sono riusciti a fare nulla in quanto richiedevano l’uso di chkdsk. Ho provato montare la partizione recuperata in windows, usando losetup per creare un loop device e qemu-image per creare un file qcow2 relativo solo alla partizione ntfs: nulla, windows si rifiuta di collaborare.

Terzo step: cercando in rete mi sono imbattuto in un paio di programmini davvero interessanti. Non avendo fretta (step zero) ho deciso di provare. Il primo si chiama scrounge-ntfs ed è attualmente al lavoro. Richiede pochi input (start-end) della partizione NTFS e una cartella di appoggio. Attualmente ha recuperato 378GB di materiale, organizzando tutto in una unica directory.
L’altro software si chiama scalpel e mi sembra maggiormente orientato al data recovery in ambito forense, soprattutto in presenza di dati intenzionalmente cancellati.

Il processo è ancora in corso (sono passate solo 24 ore). Prima o poi finirà.

Portatile UPGRADE!

Da qualche anno sono felice possessore di un laptop DELL Latitude 5491, equipaggiato con un ottimo i7 di ottava generazione. Malgrado il dispositivo nasca già ben “corazzato”, sono riuscito a fare qualche upgrade:
– aumentata la ram a 32GB;
– installazione del secondo HD.
Questo ultimo punto mi è venuto in mente guardando l’interno del portatile e notando che era presente un connettore JSATA1 non popolato.

Connettore JSATA

Cercando in rete ho trovato diverse risorse utili:
pagina del supporto DELL
instructables
thewichitacomputerguy
Ho quindi acquistato il cavetto di collegamento su ebay ad un prezzo ragionevole (13 euro) e deciso che avrei installato un SSD. Leggendo su un forum infatti, ho scoperto che le dimensioni EFFETTIVE di un Samsung EVO 870 sono ridicole. In effetti, una volta aperto il disco SSD (richiede dei cacciaviti TORX pentalobati, come quelli che si usano per smontare i MAC) il circuito è davvero minuscolo e entra perfettamente nello spazio libero presente accanto allo storage originale.
Una volta isolato un po’ il disco (non troppo altrimenti le capacità parassite lo bloccano), lo ho installato e tutto sembra funzionare alla perfezione. Le macchine virtuali sono molto più veloci e reattive, ho recuperato un sacco di spazio sul disco principale e vivo “meglio”.

Disco installato

Alcune criticità:
– il disco scalda, nella zona in cui è installato si sente calore dalla tastiera.
– la batteria dura di meno, un SSD è piuttosto “affamato” di corrente.

Debian – Invalid Signatures

Questa mattina avrei voluto aggiornare uno dei miei sistemi basati su Debian Stretch ma, all’esecuzione di apt-get update ho ottenuto il seguente errore:
root@intranet:~# apt-get update
(...)
Err:5 https://packages.sury.org/php stretch InRelease
The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key deb@sury.org
Fetched 1457 kB in 1s (1150 kB/s)
Reading package lists… Done
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://packages.sury.org/php stretch InRelease: The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key deb@sury.org
W: Failed to fetch https://packages.sury.org/php/dists/stretch/InRelease The following signatures were invalid: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key deb@sury.org
W: Some index files failed to download. They have been ignored, or old ones used instead.

Il problema sembra causato dalla coesistenza di chiavi valide e scadute, come ampiamente riportato qui.

Dal post precedente ho tratto ispirazione per una serie di comandi che hanno risolto il prolema:
root@intranet:~# apt-key list
/etc/apt/trusted.gpg
pub rsa4096 2014-09-09 [SC]
DF3D 585D B8F0 EB65 8690 A554 AC0E 4758 4A7A 714D
uid [ unknown] CZ.NIC Labs Archive Automatic Signing Key ftpmaster@labs.nic.cz
pub rsa3072 2019-03-18 [SC] [expired: 2021-03-17]
1505 8500 A023 5D97 F5D1 0063 B188 E2B6 95BD 4743
uid [ expired] DEB.SURY.ORG Automatic Signing Key deb@sury.org
sub rsa4096 2014-09-09 [E]

Il problema è quindi nel file /etc/apt/trusted.gpg, che deve essere cancellato e la chiave corrispondente deve essere rimossa:
root@intranet:~# rm /etc/apt/trusted.gpg

Per rimuovere la chiava è sufficiente prendere nota della parte finale della sua signature: 95BD 4743
root@intranet:~# apt-key del 95BD4743
OK

UNa volta completata questa operazione è necessario scaricare la nuova chiave:

root@intranet:~# wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg
--2021-03-22 09:01:41-- https://packages.sury.org/php/apt.gpg
Resolving packages.sury.org (packages.sury.org)… 172.67.182.150, 104.21.18.148, 2606:4700:3030::ac43:b696, …
Connecting to packages.sury.org (packages.sury.org)|172.67.182.150|:443… connected.
HTTP request sent, awaiting response… 200 OK
Length: 1769 (1.7K) [application/octet-stream]
Saving to: '/etc/apt/trusted.gpg.d/php.gpg'
/etc/apt/trusted.gpg.d/php.gpg 100%[=================================================>] 1.73K --.-KB/s in 0s
2021-03-22 09:01:41 (12.4 MB/s) - '/etc/apt/trusted.gpg.d/php.gpg' saved [1769/1769]

Verifica delle chiavi:
root@intranet:~# apt-key list
(…)
/etc/apt/trusted.gpg.d/php.gpg
pub rsa3072 2019-03-18 [SC] [expires: 2024-02-16]
1505 8500 A023 5D97 F5D1 0063 B188 E2B6 95BD 4743
uid [ unknown] DEB.SURY.ORG Automatic Signing Key deb@sury.org
sub rsa3072 2019-03-18 [E] [expires: 2024-02-16]
root@intranet:~#

A questo punto il processo di update può essere completato senza errori.

Nuovo server, considerazioni.

Alcuni giorni addietro, ho scritto un posto sul “nuovo” serve domestico, ricavato da un portatile Dell XPS 1340. A distanza di due giorni, ho analizzato i dati raccolti dall’ottimo LibreNMS.

La macchina ha in esecuzione un web server (utilizzato prevalentemente in locale), un database MariaDB (immagazzina tutti i dati meteo e dei sensori che raccolgo in casa), LibreNMS (chi non ha un sistema di network management system in casa?) e, da poco, una istanza di rtl_433.

I dati di utilizzo delle CPU non sono molto incoraggianti. Il sistema è piuttosto “carico”, soprattutto a causa di rtl_433 che, lavorando con un sample rate di 1024k, fa sudare un po’ la cpu.

Carico delle CPU (core 1 e core 2).

Nulla di preoccupante, visto che non prevedo di installare altri servizi molto impegnativi (farci girare uno spyserver sarebbe follia), solo che “speravo in migliori performances”. Ciò che mi preoccupa è la temperatura di lavoro della CPU: un portatile rispetto ad un server ha una circolazione di aria meno efficiente, in quanto non è previsto che sia accesso 24×7. Pertanto le temperature sono elevate:

Andamento della temperatura per Core, nel tempo.

Questo dato mi preoccupa, soprattutto in vista dell’estate. Il server sarà posizionato in soffitta, dove l’aria è molto calda in estate. Rischio la frittura, ma correrò il rischio, dotando il portatile di una importante supporto alla dissipazione di calore: una bella ventola a 220V. Il flusso di aria investirà il portatile completamente in modo da rimuovere calore da ogni parte. Se poi le cose andranno male, valuterò la possibilità di dotarmi di un calcolatore tipo HP8300elite, magari con 16GB di ram. Intanto… run baby run!

Aggiornamento @home!

Gli eventi del mese di dicembre sono stati veramente importanti per la mia vita. Ma questo è un blog in cui non tratto molto volentieri le mie vicende personali. Pertanto… la permanenza a casa ha comportato che io mi sia finalmente reso conto che l’attuale “server” di casa è arrivato alla frutta.

Attualmente il sistema domestico “gira(va)” su una Cubieboard 2, un aggeggio hardware poco documentato e meno supportato. Dopo lunghe peripezie sono riuscito a farlo funzionare “bene” con notevoli difficoltà per utilizzare in modo dignitoso le GPIO. Ultimamente il dispositivo ha dimostrato una certa instabilità: il web server restituisce “connection refused” e, dopo il riavvio, non viene caricata la shell. Probabile che anche la SD sia arrivata alla frutta, ma anche le risorse di sistema sono allo stremo. Il database con gli eventi meteo è sempre più grande, vorrei implementare anche un ricevitore per i sensori che operano a 433 MHz (vedi altro post). Non è possibile andare avanti con questo hardware, pertanto ho preso una decisione drastica: nuovo server.

L’ideale sarebbe stato prendere un computer refurbished (tipo HP 8300) come quello che sto usando (da un anno) in ufficio. Grandi prestazioni, ottima robustezza, grande silenziosità. Solo che adesso 200 euro per un simile sistema non li voglio spendere. Pertanto l’idea: utilizzare il vecchio portatile Dell XPS13 (1340) del 2009. Il monitor è praticamente andato (funziona solo tenendo lo schermo aperto a 95,33°, ma la cpu funziona bene, ha 8GB di ram e 2 USB 2.0. La CPU è un dual core, non ci farò sicuramente virtualizzazione ma per lo scopo è ottimo. Ingredienti: un nuovo alimentatore ed un pacco batteria.

Proprio ieri sera ho terminato la migrazione dei sistemi, con qualche grattacapo per fare funzionare mailutils. Adesso devo trovare un modo per aggiungere delle GPIO al portatile, in modo da potere controllare dei relè ed avere degli ingressi analogici e digitali magari consultabili in Python. Ci sto lavorando… piano piano!

Linux: ciclo for su nomi con spazi

Mi è successo di dovere eseguire delle operazioni su una lunga serie di files contenuti in una directory condivisa con samba. Per semplificarmi la vita (ricordo che non sono un programmatore…) ho deciso di popolare un array con il path dei files e di scorrerlo per eseguire le operazioni su di essi.

I primi problemi sono nati in fase di parsing dei nomi dei files: se sono presenti degli spazi samba li esporta inserendo i nomi tra “apici singoli”. Inoltre, quando il nome viene processato, ogni sezione del nome tra due spazi è considerata come un elemento dell’array.

Ho trovato delle indicazioni piuttosto interessanti su questo sito: si parla di ridefinizione del Internal field separator ($IFS). Si tratta di una variabile di sistema che definisce il carattere o i caratteri che sono utilizzati per separare una stringa in sottostringhe. Tipicamente è impostato come “spazio” o “tab” o “newline”. In ambiente Linux è impostato a “spazio”. Ridefinire questa variabile consente di istruire il sistema a non considerare lo spazio come separatore. 

Una volta che la variabile è stata ridefinita, lo spazio non è un separatore ed i nomi files non vengono “spezzettati” in tanti frammenti. Importante ricordare che la variabile deve essere reimpostata al valore originale prima che lo script termini.

SAVEIFS=$IFS
IFS=$(echo -en “\n\b”)
for i in `ls -ld $MOUNT_POINT1/* | awk ‘{ print substr($0, index($0,$9)) }’ `
do
ARRAY_FOLDER[ARRAY_INDEX_FOLDER]=$i
ARRAY_INDEX_FOLDER=$[ $ARRAY_INDEX_FOLDER+1]
done
IFS=$SAVEIFS

Un disco nuovo… quasi

Nel 2015 ho acquistato un bellissimo NAS della QNAP che monta dei dischi WDC fabbricati nel gennaio 2015. Non ho MAI avuto un problema sui dischi, tutto lo S.M.A.R.T. è a posto, non ci sono errori o cali di prestazioni.

Visto che la capacità del sistema è agli sgoccioli e che i dischi hanno “girato” per 3 anni, ho deciso di rimpiazzare le unità. La strategia prevede di acquistare un disco ogni 4-6 mesi, in modo che non siano perfettamente coevi.

Ordino il disco su Amazon, da un venditore del quale non farò il nome. Arriva l’unità perfettamente imballata. La monto, faccio il rebuild dell’array e tutto va bene.

Oggi mi arriva una mail minacciosa del NAS: il disco nell’unità 1 ha un valore smart non corretto e viene marcato come anomalo. Si tratta proprio del disco “nuovo”. Poco male, impreco una buona 40ina di minuti, avvio la procedura di reso sul sito e metto il disco vecchio che (intelligentemente) avevo conservato nel cassetto.

Il disco che mi hanno venduto… è vecchio (più vecchio di quelli che ho installato).

Mai più hard disk tramite Amazon: si va in negozio e si contratta!

Impazzire con la mail

Ho diversi sistemi linux-based sparsi in giro per la provincia. In tutti ho uniformato la configurazione del sistema di gestione della posta elettronica, impostando un funzionamento come “satellite” ed usando gmail per il lavoro “sporco”.

Uno dei miei sistemi, con sistema operativo Debian 9.4 si è sempre rifiutato di inviare la mail a “se stesso”. L’errore che ho sempre ottenuto è:

DNS Error: 21091730 DNS type ‘mx’ lookup of linuxade responded with code NXDOMAIN Domain name not found: linuxade

Ho controllato l’output del comando:
root@linuxade:/etc# exim4 -bP primary_hostname
primary_hostname = localhost

Ho provato un sacco di strade diverse. L’unica azione che ha risolto il problema è stata la riconfigurazione di /etc/hosts nella sezione ipv6 passando dalla prima alla seconda versione. La prima scrittura penso sia stata una configurazione temporanea per fare qualche prova.

# The following lines are desirable for IPv6 capable hosts
::1  localhost ip6-localhost ip6-loopback linuxade

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback

Cambiato il contenuto del file, riavviato exim4, adesso il comando viene eseguito correttamente:
root@linuxade:/etc# exim4 -bP primary_hostname
primary_hostname = linuxade

Finalmente mi arrivano le email con gli errori dovuti all’esecuzione degli script!