TCP Socket (af_inet)(IPv4/IPv6)(with ssl) – c language
This program is an example of programming a TCP socket in C language, using the well-known client-server programming model.
The server side is multi-threaded, but the thread is optional since the developer/designer is still responsible for deciding if he/she needs it.
The library “commv6.c” develops all the functions to create, bind, listen, and remove a socket AF_INET, and the functions to send and receive messages (using the methods read and write). It supports: IPv4/IPv6 and SSL (see commSSL.c).
The structure of a message is defined in the file “msg.h”.
- Doxygen documentation
- Source code (gpl v2)
Code tested under debian-like and arch linux platform (thanks to nignux).
Questo programma è un esempio di programmazione di un socket TCP in linguaggio C, utilizzando il ben noto paradigma di programmazione client-server.
Il lato server è multi-threaded, ma è del tutto opzionale, e sarà responsabilità dello sviluppatore decidere se ne ha bisogno.
La libreria “commv6.c” sviluppa tutte le funzioni per creare, pubblicare, rimanere in ascolto e rimuovere una socket af_inet, e le funzioni per inviare e ricevere messaggi (usando i metodi read e write). Il codice supporta socket ipv4/ipv6 e SSL (commSSL.c)
La struttura di un messaggio è definita nel file “msg.h”.
- Documentazione doxygen
- Codice sorgente (gpl v2)
Codice testato sotto piattaforma debian-like e arch linux (ringraziamenti a nignux).
| x86 | x64 | |
| sizeof(char) | 1 | 1 |
| sizeof(short) | 2 | 2 |
| sizeof(float) | 4 | 4 |
| sizeof(int) | 4 | 4 |
| sizeof(unsigned int) | 4 | 4 |
| sizeof(long) | 4 | 8 |
| sizeof(double) | 8 | 8 |
| sizeof(long unsigned int) | 4 | 8 |
| sizeof(long double) | 12 | 16 |
| sizeof(long int) | 4 | 8 |
x64
Linux 3.0.0-16-generic #28-Ubuntu SMP Fri Jan 27 17:44:39 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
x32
Linux 2.6.18-6-k7 #1 SMP Thu Aug 20 22:36:26 UTC 2009 i686 GNU/Linux
Tiscali Netbox G/N (Alcatel Thomson TG784)
If you are not paying for it, you’re not the customer; you’re the product being sold. —
Andrew Lewis MetaFilter, 26 Agosto 2010
Richard Stallman, hackmeeting Firenze, 26 Giugno 2011
La politica di ogni provider adsl che si rispetti è di lasciare fuori i propri clienti dall’amministrazione del router. Va da se che questo modo di fare cozza, completamente, con i miei ideali. Ovvero, io ho acquistato il modem, dunque, penso di avere il diritto di gestirlo come amministratore.
Parliamo di cose serie, se siete tra i fortunati possessori del router Alcatel Thomson tg784g/n che viene dato (comodato d’uso o venduto) dalla Tiscali, per chi stipula un contratto voce, allora avete un serio problema di sicurezza sulla vostra rete locale.
Questi pazzi hanno lasciato l’accesso telnet attivo e aperto verso internet, inoltre, le credenziali di accesso come amministratore sono note. In termini pratici un lamer potrebbe entrare nel vostro router, copiarne la configurazione e/o modificarla a suo vantaggio. Ovvero, chiunque può amministrare il vostro router senza che voi ve ne accorgete, esponendo la vostra rete locale ad attacchi di tipo man in the middle o al furto delle vostre credenziali di accesso alla rete adsl e voip.
Bene, mettiamoci ai ripari. Il mio suggerimento è di creare un nuovo account sul router con i privilegi di amministratore e di rimuovere l’account di default.
Consiglio: prima di continuare accedete all’interfaccia amministrativa web del vostro router, con le credenziali di accesso di amministratore, e salvatene la configurazione (File: user.ini)
Cambiate l’indirizzo ip del vostro pc con 192.168.1.34 e collegatevi all’interfaccia telnet del vostro router:
telnet 192.168.1.254 8081
Attenzione, da rete locale il router risponderà all’interfaccia telnet solo se il pc che chiede l’accesso ha l’indirizzo 192.168.1.34. Il motivo è una regola impostata nel firewall del router (estratto da user.ini):
Thomson TG 784 H:
rule add chain=sink_system_service index=1 srcintf=lan srcip=!192.168.1.34 serv=telnet log=disabled state=enabled action=deny
Thomson TG 784 N:
rule add chain=sink_fire index=1 srcintf=lan srcip=!192.168.1.34 serv=telnet log=disabled state=enabled action=deny
Loggatevi con le credenziali di accesso di root e date i seguenti comandi:
env set var=SESSIONTIMEOUT value=0 user add name = <nome> password = <password> role = root user list saveall exit
sostituite:
- <nome> col nome del vostro nuovo utente amministratore (consiglio: evitate nomi come admin, administrator, root e simili) e
- <password> con la password da voi preferita (consiglio: metteteci una password forte).
Attenzione, alcune volte il router si pianta durante la procedura di saveall. Non allarmatevi se, per più di un minuto, la console telnet non risponde, riavviate il modem usando il pulsante di accensione. Generalmente il router riesce a salvare le impostazioni anche quando si pianta.
Loggatevi nuovamente con le credenziali del nuovo utente che avete creato ed eseguite i seguenti comandi:
env set var=SESSIONTIMEOUT value=0 user list user delete name = <nome>
Sostituite <nome> con il nome dell’utente root standard del router.
Se cancellate anche l’utente della tiscali avrete eliminato la possibilità da parte dell’assistenza remota di entrare nel vostro router: a voi la scelta.
E, giacché ci siamo, abilitiamo il client ntp del router:
sntp add name=it.pool.ntp.org version=3 sntp config poll=60 pollpresync=5 sntp config state=enabled
inoltre, dato che la tiscali censura i dns, aggiungiamone due statici con priorità superiore a i dns della tiscali stessa:
dns server route add dns=208.67.222.222 metric=1 intf=Internet dns server route add dns=208.67.220.220 metric=1 intf=Internet dns server route list
I dns che vedete nell’esempio precedente sono di opendns, se non vi piacciono cambiateli con quelli che più preferite. Nel mio caso ho inserito come dns il server di casa mia considerato che ho bind ![]()
Ebbene si! In Italia esiste la censura… (lol) provate a collegarvi al sito www[dot]thepiratebay[dot]org oppure www[dot]btjunkie[dot]org, prima e dopo aver cambiato i dns.
T1scal1 censura, al momento, solo i dns, Alice e altri provider eseguono una censura a livello di pacchetto, quindi, anche cambiando i dns non vi collegherete, comunque, ai siti internet censurati. (ricordate tor è vostro amico)
Aggiornamento del 25/07. Sono spiacente di informare la censura di t1scal1 si è allineata agli altri provider adsl, censurando a livello di pacchetto e non più di solo dns…
Modifichiamo la regola del firewall per il servizio telnet del router, al fine di rendere accessibile telnet da qualsiasi pc della rete locale.
Creiamo una nuova espressione che identificherà il range degli indirizzi della nostra lan:
expr add name=personal type=ip addr=192.168.1.0/24 mask=0
Poi modifichiamo la regola (che vi avevo mostrato prima) per il telnet:
regola da usare per il modello Thomson TG 784 H:
firewall rule modify chain=sink_system_service index=1 srcintf=lan srcip=!personal serv=telnet log=disabled state=enabled action=deny
regola da usare per il modello Thomson TG 784 N:
firewall rule modify chain=sink_fire index=1 srcintf=lan srcip=!personal serv=telnet log=disabled state=enabled action=deny
Il comando “srcintf=lan” (letteralmente source interface expression) indica che la regola è valida solo per la rete locale lan. Se volete creare una regola per le connessioni internet dovete usare la parola “wan“.
Non dimenticatevi di salvare tutto prima di uscire:
saveall exit
Per maggiori informazioni sulla command line interface di questo router eseguite la ricerca “thomson tg784 cli” su g00gle e scaricate il pdf.
Ad ogni modo, eseguendo la procedura di reset fisico del router, sarà possibile riportare il router alle impostazioni standard della adsl Tiscali.
Abilitazione accesso FTP e HTTP da remoto
(Aggiornamento del 10-10-2011)
Non ho mai usato l’ftp del router… tuttavia sembra che a qualcuno faccia comodo
service system ifadd name=FTP group=wan saveall
Regola testata e NON funzionante o almeno sembra che non basti per fare funzionare l’ftp da remoto.
Analogamente per l’interfaccia web di amministrazione del modem..
(sconsiglio caldamente di abilitarla, ma a volte si sa può servire…)
service system ifadd name=HTTP group=wan saveall
[Regola testata e funzionante]
Rimozione accesso Telnet da remoto (FTP e HTTP)
Una volta per tutte, togliamo questa falla alla sicurezza del router…
Attenzione, potrete sempre accedere al router tramite telnet dalla vostra rete locale di casa vostra, ma non più da internet.
service system ifdelete name=TELNET group=wan saveall
Regola per rimuovere l’accesso FTP da remoto ..
service system ifdelete name=FTP group=wan saveall
Regola per rimuovere l’accesso remoto all’interfaccia web di amministrazione del modem.. (l’accesso remoto non è attivo come impostazione di default del modem, almeno di vostre modifiche)
service system ifdelete name=HTTP group=wan saveall
Insomma, avrete capito che service system ifadd aggiunge e service system ifdelete rimuove, mentre se volte avere una lista dei servizi del router…
service system list
Purtroppo, quella lista non ci dice nulla su quale lato (internet o lan) del router sono attivi, bisogna andare a spulciarsi il file user.ini.
Aprire le porte sul router…
Aprire le porte su questo router non è esattamente immediato.
E’ facile notare che se si utilizza una regola per servizio già presente sul router la porta viene aperta correttamente.
Potete constatare voi stessi che se si assegna un ad un pc il servizio ssh o qualsiasi altro servizio preimpostato sul router la porta risulta essere effettivamente raggiungibile dall’esterno. Ben altra cosa accade con le regole definite manualmente dall’utente.
Ho visto che ci sono alcuni navigatori che suggeriscono di disabilitare l’intrusion detection. Non è il caso. Vi faccio una metafora: è come se il vostro elettricista di fiducia per fare passare il cavo dell’antenna dal muro anziché fare un buco col trapano, ve l’ho butta giù con il martello pneumatico. Beh sicuramente il filo ci passa, ma non era esattamente quello che volevamo no?
La soluzione esiste:
- Fissate in modo statico gli indirizzi ip dei pc di casa vostra su cui volete assegnare dei servizi (Home > Home Network > Devices > …)
- Create tutte le regole che vi servono (Home > Toolbox > Game & Application Sharing > New Game or Application).
- Assegnate le regole alle vostre macchine
- Salvate il vostro file
user.ini(Home > Thomson Gateway > Configuration > Backup & Restore) sul desktop e apritelo con wordpad/gedit - Cercate la sezione “
[ service.ini ]” Es:
[ service.ini ] add name="AIM Talk" mode=client ... add name=test add name=VNC mode=server add name="Xbox Live" mode=server ... ...
Per sinteticità ho tagliato le regole presenti nel router.
La regola che ho creato per queste esempio si chiama test. La regola in questione non ha il parametro mode, per il modem è equivalente a scrivere mode=client. Risultato porta chiusa dall’esterno. Aggiungete mode=server ad ogni vostra regola creata:
add name=test mode=server
Salvate il file, ridatelo in pasto al modem e avete finito. Solo un ultimo consiglio: NON usate la porta 8080 per le vostre regole, pena la perdita dell’accesso all’interfaccia web del router.
(anche se disabilitato, sulla 8080 del router è presente il servizio di parental control)
In generale se volete avere la lista di quali porte NON si devono usare sul router perché sono in uso dallo stesso modem. Dall’interfaccia telnet date:
service system list
Aprire le porte sul router tramite telnet
Un altro metodo, che vi evita di modificare a mano il file user.ini è il seguente:
Si crea un nuovo “nome di regola”. Es:
service host add name=my_torrent mode=server
Se per caso nel vostro nome di regola sono presenti degli spazi, allora:
service host add name="my torrent" mode=server
bisogna inserire i doppi apici.
Successivamente si devono creare le vere regole per questo nuovo “nome di regola”. Es:
per il solo protocollo TCP:
service host rule add name=my_torrent protocol=tcp portrange=9020-9020
per il solo protocollo UDP:
service host rule add name=my_torrent protocol=udp portrange=9020-9020
per entrambi i protocolli:
service host rule add name=my_torrent protocol=any portrange=9020-9020
Qui, abbiamo aperto la porta 9020 del router. Si possono aggiungere molte regole ad ogni nome di regola, anche per più porte e protocolli diversi, tuttavia ogni nome di regola può essere assegnato ad un solo pc alla volta. Ad ogni modo è da evitare categoricamente la creazione di nomi di regole che aprono le stesse porte con lo stesso protocollo.
(Qui serve solo del buon senso e un po di conoscenza del concetto di NAT)
Infine bisogna assegnare la regola al pc:
service host assign name=my_torrent host=192.168.1.69 log=disabled
Modificate l’indirizzo 192.168.1.69 con quello del vostro pc e ricordatevi di settare il suo indirizzo come statico nell’interfaccia del router. (Home > Home Network > Devices > …)
Per rimuovere l’assegnamento:
service host disable name=my_torrent
Altro esempio. Assegnamo l’SSH ad un pc di casa, (la regola è già esistente sul router):
service host assign name="Secure Shell Server (SSH)" host=192.168.1.66 log=enabled
Rimozione dell’assegnamento:
service host disable name="Secure Shell Server (SSH)"
E adesso, divertiamoci con un po’ di hacking…
(Per chi non conosce le credenziali di accesso di default del router o, semplicemente, vuole sbirciare dentro il firmware di questo apparecchio.)
Prendetevi una penna usb, la più piccola che avete va bene. Se avete dei dati sul supporto usb che volete conservare salvateli perché con questa procedura la penna usb verrà formattata.
Procedura valida solo per il vecchio modello Thomson TG 784; il nuovo modello (TG784n) non riconosce il filesystem del pennino.
- Scaricate il file: tg787-sysroot.sqsh.7z (filesystem che contiene un ln -s alla root)
- Aprite una shell sotto linux (una distro live di ubuntu può fare al caso vostro se non avete linux installato sul vostro pc)
- se non l’avete già fatto, inserite la penna usb nel vostro pc ed eseguite il comando
$ mount, nella vostra shell e identificate qual’è il nome della vostra penna usb (nel mio caso/dev/sdb), ed eseguite il comando:$ sudo dd if=/dev/zero of=/dev/sdb, che cancellerà ogni dato presente nella penna (più è grande il supporto più questa operazione sarà lunga),- andate nella path dove avete scaricato il file e una volta scompattato eseguite il comando:
$ sudo dd if=sysroot.sqsh of=/dev/sdb,- a operazione terminata staccate la penna usb e inseritela nella porta usb del router
- Controllate, collegandovi all’interfaccia web del thomson, che in toolbox => content sharing sia attivo server enabled (upnp Av Media Server) (generalmente è già tutto attivato di default).
- All’indirizzo
\\192.168.1.253o nelle condivisioni di rete (winzoz) troverete un pc chiamato thomson, al cui interno c’è condiviso il firmware del vostro router. - Aprite il file
mlpuser.defche si trova in/sys/archive/xxxx/active/, per leggere le credenziali di default del vostro router.
Per il modello TG784n consiglio di dare un occhiata al file: USB-Root-Access-v1-4.7z
Tuttavia, non possedendo il nuovo modello, non sono in grado di dirvi nulla sull’efficacia della procedura.
Non sembra che questa procedura sia d’aiuto.
Qualcuno ha detto TTL?
Sembra però che bisogna anche saldare due ponticelli dietro la board del modem per fare funzionare la ttl.
A questo link c’è spiegata la procedura per il modello tg782 (estremamente simile al tg784)
Appena ho un po di tempo farò alcune prove in merito.
Sarebbe molto carino riuscire a parlare direttamente con busybox piuttosto che con la comman line interface sviluppata da thomson.
Link utili:
Installazione “Palermo a Venezia” di Alessandro Librio
Un giorno di traffico per Venezia.
Segnalo l’evento speciale “Palermo a Venezia” dell’artista Alessandro Librio che avrà luogo il 4 Giugno, giornata di apertura della 54° edizione della Biennale di Venezia.
L’installazione si terrà al n. 63 di Piazza San Marco nel cortile del Palazzo Reale, sarà inoltre possibile seguire l’evento in diretta sul sito internet dello stesso artista: http://www.alessandrolibrio.com/node/173.
L’obbiettivo che l’installazione si propone è l’unione del paesaggio sonoro della città di Palermo con quello di Venezia, infatti per ventiquattro ore i suoni/rumori del traffico palermitano verranno acquisiti e riprodotti in tempo reale a Venezia.
Per informazioni più approfondite rimando all’intervista del sito SiciliaInformazioni:
http://www.siciliainformazioni.com/giornale/cultura/125290/suoni-palermo-invadono-venezia-linstallazione-librio-apre-biennale-darte.htm
Threads pool (posix) – c language (ver 2)
Example of generalized thread pool in C language with signal handling.
rev 2: Completely revised the code of the library.
Now there is a queue of jobs, a thread is awakened when a new job is available, following the classic mechanism of producer / consumer.
You can set: the thread pool size, its signal mask and the size of the job queue, calling the poolInit function that returns a new pool. If the signal mask is null then the signal mask shall be inherited from the creating thread.
The function poolDispatcher gets three arguments the pointer to the pool; a void pointer to function (start_routine), with a single argument void arg. (very similar to pthread_create). The poolDispather when executed creates a new job that is inserted into the queue of jobs.
If you send too many jobs to the pool and the queue fills up, the poolDispatcher reject the new job and returns the error code “-5″ (to avoid DOS attacks).
The function poolDestroy, puts the pool in termination state, (the pool is no longer available to run new job), it waits for all active and pending jobs to finish; execute the join of the threads; free resources and exit.
doxygen docomuntation and source code (license GPLv2)
Esempio di pool di thread in linguaggio C generalizzato con gestione dei segnali.
E’ possibile passare a questa libreria un proprio puntatore a funzione.
La funzione verrà eseguita dal primo thread disponibile del pool di threads.
E’ facile notare come la funzione addjob esegue, nel caso in cui tutti i threads siano impegnati, attesa attiva.
La soluzione è presto detta, implementare una lista di jobs, oppure (per chi non ha voglia) aumentare opportunamente la dimensione del pool threads.
[update]
Rivisto completamente il codice della libreria.
Adesso esiste una lista di job; un thread del pool viene risvegliato quando un nuovo job è disponibile, seguendo il classico meccanismo di produttore/consumatore.
La dimensione massima della coda dei job è settabile in fase di creazione del pool.
Se si inviano troppi job al pool e la coda si riempie, la poolDispatcher rifiuterà il nuovo job ritornando il codice di errore “-5″ (evitiamo attacchi di DOS).
La funzione poolDestroy, mette il pool in fase di terminazione, (ovvero il pool non è più disponibile ad eseguire nuovi job), aspetta che tutti i job attivi e pendenti terminino; esegue la join dei threads; libera le risorse ed esce.
[update-end]
Una volta terminato il job, il thread viene reso automaticamente disponibile per un nuovo job.
La dimensione del pool e la maschera dei segnali per i threads sono passate in fase di inizializzazione del pool stesso.
E’ possibile creare infiniti pool di threads, dato che ogni struttura dati viene creata dinamicamente in fase di inizializzazione del pool stesso. La maschera dei segnali è invece opzionale.
Per commenti e info più dettagliate sul codice: documentazione html (doxygen).
E per scaricare il codice sorgente: codice sorgente (in licenza gpl v2).
LaCie 2Big Network: supporto nfs
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.
Race condition tra Upstart e Samba se nel pc è presente un interfaccia bridge
Vengo subito al dunque, dopo un recente aggiornamento del pacchetto samba ho cominciato ad avere problemi ad accedere alle mie cartelle condivise sul mio ubuntu server 10.04.
Nella mia macchina è presente un bridge di rete che collega la mia interfaccia ethernet su cavo (eth0) con quella wifi (wlan0):
router <= eth0 (0.0.0.0) => br0 (192.168.1.10) <= wlan0 (0.0.0.0) => altri pc.
Il problema si risolveva se, dopo l’avvio della macchina, riavviavo il servizio samba.
Per trovare l’origine del problema ho controllato i file di log di samba:
[2010/09/17 08:39:56, 0] lib/util_sock.c:938(open_socket_in) bind failed on port 445 socket_addr = fe80::201:2eff:fe2f:d55%br0. Error = Cannot assign requested address [2010/09/17 08:39:56, 0] smbd/server.c:457(smbd_open_one_socket) smbd_open_once_socket: open_socket_in: Cannot assign requested address [2010/09/17 08:39:56, 0] lib/util_sock.c:938(open_socket_in) bind failed on port 139 socket_addr = fe80::201:2eff:fe2f:d55%br0. Error = Cannot assign requested address [2010/09/17 08:39:56, 0] smbd/server.c:457(smbd_open_one_socket) smbd_open_once_socket: open_socket_in: Cannot assign requested address
La mia configurazione di rete di samba è la seguente:
interfaces = 127.0.0.0/8 192.168.1.0/24 br0 bind interfaces only = yes
In pratica samba pubblica le sue sockets nell’interfaccia di rete br0 e loopback.
Il problema si presenta perché upstart non aspetta che il bridge di rete sia attivo prima di avviare il servizio samba. Il bridge impiega circa 15 secondi ad avviarsi, nel mentre samba pubblica le sue sockets solo nelle interfacce di rete attive in quel momento, essendo l’interfaccia bridge ancora non attiva, samba fallisce la pubblicazione del servizio sul bridge impedendo così l’accesso da un computer remoto.
La conferma mi è stata data dal comando netstat -an.
Prima del riavvio del servizio samba:
tcp 0 0 127.0.0.1:139 0.0.0.0:* LISTEN ... tcp 0 0 127.0.0.1:445 0.0.0.0:* LISTEN
Dopo il riavvio del servizio samba:
tcp 0 0 127.0.0.1:139 0.0.0.0:* LISTEN tcp 0 0 192.168.1.10:139 0.0.0.0:* LISTEN ... tcp 0 0 127.0.0.1:445 0.0.0.0:* LISTEN tcp 0 0 192.168.1.10:445 0.0.0.0:* LISTEN
La soluzione al problema è modificare lo script di avvio di samba di upstart.
Ovvero:
sudo nano /etc/init/smbd.conf
e cambiare la linea:
start on local-filesystems
in
start on (local-filesystems and net-device-up IFACE=br0)
Ovviamente se la vostra interfaccia bridge ha un nome diverso da br0 cambiatelo opportunamente.
In questo modo obbligherete upstart ad aspettare che il bridge sia attivo prima di avviare il demone samba.
Errori simili posso verificarsi se sulla vostra macchina viene eseguito il demone dhcp3-server configurato per fornire indirizzi ip sull’interfaccia bridge.
Race condiction analogo per dhcpd
(!sic) Ho risolto il problema con il servizio dhcp3 editando il file:
sudo nano /etc/init/rc-sysinit.conf
e cambiando la linea
start on filesystem and net-device-up IFACE=lo
in
start on filesystem and net-device-up IFACE=br0
For more info about this problem see:
https://bugs.launchpad.net/ubuntu/+source/dhcp3/+bug/580319
tftpd-hpa
Problemi anche con lui. il più delle volte si avvia e pubblica le sue socket sull’interfaccia bridge correttamente, tuttavia, sporadicamente fallisce.
Quindi forziamo lo script di avvio, del servizio tftp-hpa, ad attendere la disponibilità del bridge prima di avviare il demone:
nano /etc/init/tftpd-hpa.conf
e cambiare la riga:
start on (filesystem and net-device-up IFACE!=lo)
in
start on (filesystem and net-device-up IFACE=br0)
La condizione IFACE!=lo è sicuramente più furba tra tutte la condizioni di avvio riscontrate nei precedenti file di configurazione (dhcpd e samba), tuttavia non è sufficiente se nella vostra macchina avete più di un interfaccia di rete (es. tunnel ipv6). Il bridge è un interfaccia lenta e il servizio in questione finisce col pubblicare le proprie socket sulle altre interfacce di rete attive ma non sul bridge.
Giacché sono in tema…
Dato che in internet non ho visto molti esempi corretti di configurazioni (per debian) di interfacce bridge, riporto la mia configurazione di rete:
/etc/network/interfaces auto lo iface lo inet loopback iface eth0 inet manual iface wlan0 inet manual auto br0 iface br0 inet static bridge_ports eth0 wlan0 address 192.168.1.10 network 192.168.1.0 netmask 255.255.255.0 gateway 192.168.1.1 broadcast 192.168.1.255
Per esempi di configurazione diversi e più completi vi rimando alla pagina, in inglese, della wiki di debian.
LaCie 2Big Network tweaking: deframmentazione filesystem con xfs_fsr
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.
Pulizie di fine pasqua…
Dopo un po di mesi che non aggiornavo il mio sito internet ho, in questi ultimi giorni, fatto un po di pulizie…
Ho pubblicato un progetto in linguaggio Java per il corso di programmazione di rete (BitCreek, una Content Distribution Network (CDN) ispirata a BitTorrent) compreso, come sempre, di codice, documentazione e sorgenti. Spero che possa dare uno aiuto a chi si affaccia per la prima volta alle socket tcp, tcp-ssl, udp, remote method invocation, pool di thread, ecc.. ecc.. in java.
D’altra parte ho eliminato il vecchio sito del liceo: inutile strascico di pagine obsolete. Ultima modifica, degna di nota, è la pagina di benvenuto al sito che adesso è integrata nel blog e il ripristino di alcuni collegamenti interrotti in alcuni post.
Appena ho un po di tempo pubblicherò un altro post sul nas 2big network.
LaCie 2Big Network hack: telnet, openssh, ntpd, cups and more..
Dopo le 3 del mattino, due sole categorie di persone sono al lavoro: le prostitute e i programmatori. [Anonimo].
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.)
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 ntpopenssh-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’eseguibilelsusb.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.
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.
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]\$ '
in
PS1='[\u@\h \w]\$ '
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)
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
È 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.
- 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.
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 (?!?)
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.






