Steppenwolf » 2big network lacie

LaCie 2Big Network: supporto nfs

Steppenwolf — Fri, 22 Oct 2010 16:09:33 +0000

No, I will not fix your pc.
[Detto anonimo e largamente condiviso]

Aggiornamento / Update (05/02/2012):

Per il servizio nfsd in kernelspace, guardate i commenti di questo stesso articolo.
Suggerisco di usare il servizio nfsd in kernelspace, dato che supporta il lock dei file.

For nfsd kernel space, look at the comments of this article.
I recommend to use nfs kernel space since it supports file locking.

All thanks go to Bert.

Avevo tentato precedentemente di installare il supporto nfs sul mio vecchio (v1) nas 2Big Network della LaCie ma avevo desistito per la mancanza del modulo kernel nfsd, che permette di abilitare nfs server in kernelspace.

Di recente, dopo una richiesta di aiuto da parte di un navigatore, ho riaffrontato il problema trovando una soluzione: nsf in spazio utente. Ok storco il naso anche io per l’enormità di quello che ho appena detto..
Infatti ci sono grossi handicap per nfs userspace: lo sviluppo del codice è stato completamente abbandonato (l’ultima versione è la 0.9.22 e risale al 05/01/2009), ma il problema più grave che non vi è alcun supporto per il lock dei file.

Per installare il supporto per nfs v3 sul nas c’è bisogno dei demoni unfsd e portmap, il primo è nfs stesso il secondo è un servizio ONC RPC, in esecuzione su una macchina collegata in rete, che fornisce altri servizi ONC RPC (Remote Procedure Call). (Chi è abituato a programmare sa di che sto parlando)
Per farla breve il pacchetto unfs3 dipende dal pacchetto portmap. Ai fini pratici significa che è richiesto l’installazione anche del servizio portmap per avere nfs funzionante.
Significa anche che ho dovuto scrivere due script per initng per avviare/arrestare correttamente i due demoni.

File portmap.i:

# NAME: portmap
# DESCRIPTION: DARPA port to RPC program number mapper
# WWW: 

# exec daemon = /sbin/portmap -d ${PORTMAP_OPTS};
daemon portmap {
	need = bootmisc virtual/net;
	provide = virtual/portmap;
	pid_file = /var/run/portmap.pid;
	forks;
	env PORTMAP_OPTS=;
	env_file = /etc/portmap.conf;
	exec daemon = /sbin/portmap;
}

File unfs3.i:

# NAME: unfs3
# DESCRIPTION: starts user-space NFSv3 server.
#	       UNFS3 is a user-space implementation of the NFSv3 server specification.
#	       It provides a daemon for the MOUNT and NFS protocols,
#	       which are used by NFS clients for accessing files on the server.
#	       Unlike nfs-user-server, unfs3 is capable of handling files larger than 2GB,
#              but there is currently no support for file locking.
# WWW:

daemon unfs3 {
	need = initial virtual/portmap virtual/net;
	env PID_FILE = /var/run/unfsd.pid;
	env_file = /etc/unfs3.conf;
	pid_file = ${PID_FILE};
	require_network;
	forks;
	exec daemon = /usr/sbin/unfsd -i ${PID_FILE} $DAEMON_OPTS;
	daemon_stops_badly;
}

Installazione di nfs3 server

Come premessa generale si presuppone che:

abbiate già effettuato l’hack del vostro nas (vedi articolo),
installato ssh e soprattutto con esso le librerie tcp-wrappers,
avete un account di root sul vostro nas (tutte operazioni documentate nell’articolo già citato)
e sopratutto, una buona padronanza della bash e dei sistemi linux.

Per installare nfs server dovete scaricare questi due archivi:

portmap_6.0-9_armel.tar.gz (10,6Kb)
unfs3_0.9.21_armel.tar.gz (38,2Kb)

I pacchetti sono stati scaricati della distro debian lenny e sono compilati per armtel, da entrambi gli archivi ho eliminato i man page e i doc al fine di recuperare tutto lo spazio possibile.
Ho spostato il file di configurazione di portmap nella cartella /etc e l’ho rinominato in portmap.conf.
Il demone unfsd ha in file di configurazione proprio (da non confondere con il file /etc/exports) che ho rinominato in unfs3.conf e inserito anch’esso nella cartella /etc.
Queste modifiche erano dovute dato che l’architettura del nas differisce dall’architettura di un sistema operativo debian. Gli script per initng riflettono queste modifiche per cui se cambiate posto a quei file dovrete modificare di conseguenza gli script di avvio dei demoni.

Copiate l’archivio nella vostra cartella condivisa del nas.

# cd /home/share/nome_cartella_della_vostra_condivisione
# tar -xvzf portmap_6.0-9_armel.tar.gz -C /
# tar -xvzf unfs3_0.9.21_armel.tar.gz -C /
# rm portmap_6.0-9_armel.tar.gz
# rm unfs3_0.9.21_armel.tar.gz
# cd /etc/initng/runlevel/
# echo portmap >> default.runlevel
# echo unfs3 >> default.runlevel

Adesso dovete configurare il file exports che indica al demone nfs quali cartelle deve condividere nella vostra rete locale:

# vi /etc/exports

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, “ESC”+“:q!” per forzare l’uscita dal file senza salvare le modifiche apportate.

La configurazione del file in questione la lascio alla vostra esperienza personale, se state installando nfs sul nas si presuppone che sappiate quello che state facendo. Vi informo tuttavia che questa versione di nfs (unfs3) non supporta nfs v4 ne nfs v2, inoltre non supporta nemmeno alcuni tag di configurazione come sync.

Non ho voluto implementare il supporto per nfs v2 perché assolutamente obsoleto, infatti un client nfs presuppone che, se non diversamente specificato, il protocollo, che deve usare per condividere in locale una cartella esportata da una macchina remota, sia nfs v3. Per finire nfs v2 non supporta file di dimensione superiore a i 2Gb.

Una volta configurato il file exports potete riavviare la macchina o se preferite avviare manualmente i demoni con i comandi:

# ngc -u portmap
# ngc -u unfs3

Per maggiori informazioni su ngc, digitate:

# ngc -h

E dire che questo nas non lo uso neanche più…

Aggiornamento.

Ho modificato nuovamente lo script unfs3.i inserendo la riga require_network a causa dell’avvio immediato del demone unfsd da parte di initng (prima ancora che l’interfaccia di rete lan fosse attiva). Il demone unfsd non pubblicava la socket sull’indirizzo di rete locale impedendo l’accesso da remoto.

La clausola require_network impone ad initng di attendere che l’interfaccia di rete della lan sia attiva prima di avviare il server unfsd: problema risolto.

Rsync

Script di avvio per rsync. (Il programma è già incluso nel nas)
File rsyncd.i:

#!/sbin/itype

# Short-Description: fast remote file copy program daemon
# Description: rsync is a program that allows files to be copied to and
# from remote machines in much the same way as rcp.
# This provides rsyncd daemon functionality.

daemon rsyncd {
       need = bootmisc virtual/net;
       require_network;
       env RSYNC_CONFIG_FILE=/etc/rsyncd.conf;
       env_file = ${RSYNC_CONFIG_FILE};
       exec daemon = /usr/bin/rsync --daemon --no-detach --config ${RSYNC_CONFIG_FILE};
       daemon_stops_badly;
}

Per maggiori informazioni su rsync vedere nei commenti di questo stesso articolo.

Articoli correlati:

LaCie 2Big Network tweaking: deframmentazione filesystem con xfs_fsr

Steppenwolf — Wed, 14 Apr 2010 18:48:10 +0000

It’s not a bug, it’s a feature. [Anonimo]

Chi ha già eseguito l‘hack del proprio nas avrà sicuramente notato che la partizione contenente i dati dell’utente è formattata con il filesystem xfs. Questo ottimo filesystem ha la brutta abitudine, con l’uso, di frammentarsi deteriorando così le sue prestazioni.

Per vedere lo stato di frammentazione del proprio filesystem:

# xfs_db -c frag -r /dev/md4

Vedrete qualcosa del tipo:

actual 3144, ideal 3135, fragmentation factor 0.29%

Per deframmentare il nas abbiamo bisogno dell’utility xfs_fsr, che non è installata sul nas.
Ho recuperato il programma dal pacchetto xfsdump della distro debian lenny compilato per armtel, quindi compatibile con il nas. Ho rimosso dal pacchetto tutti i file strettamente non necessari riducendolo a 14kb.

Scaricate il file xfsdump_2.2.48-1_armel.tar.gz
Copiate l’archivio nella vostra cartella condivisa del nas.
# cd /home/share/nome_cartella_della_vostra_condivisione
# tar -xvzf xfsdump_2.2.48-1_armel.tar.gz -C /
# xfs_fsr -v

Potete anche andare a farvi un caffè, la prima esecuzione del programma ha impegnato più di 4 ore per finire.

Per chi non si fosse informato, recentemente è uscito un aggiornamento del firmware del nas ver 2.2.6.
Se vi chiedete che fine hanno fatto le versioni 2.2.4 e 2.2.5… bhe della 2.2.4 non so dirvi molto ma la versione 2.2.5 del firmware è stata un flop totale. Il processo di installazione, che consisteva in due file da caricare sul nas, si piantava al caricamento del secondo file.

Ho testato l’hack su questa nuova versione del firmware, nei seguenti modi:

nas con firmware 2.2.3 bucato e aggiornato successivamente alla ver 2.2.6
aggiornato il nas alla versione 2.2.6 e successivamente bucato

in entrambi i casi è stato possibile bucare il nas.

Articoli correlati:

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

Steppenwolf — Wed, 18 Nov 2009 21:43:31 +0000

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

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.

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)

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.

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

Articoli correlati: