Dato che non sempre le modifiche fatte vanno a buon fine, può succedere che il nostro Iomega StorCenter IX2-200 non riesca a riavviarsi e quindi l'unica possibilità, se non si vuole procedere alla formattazione e reinstallazione del firmware, è quella di collegare il disco ad un PC con linux e procedere all'accesso fisico ai dati.
Prima di tutto c'è da dire che i dischi sono in modalità raid e collegandolo vedrete una sola singola partizione; il sistema di partizionamento è di tipo EFI e la partizione è identificata come tipo GPT, inoltre viene utilizzato LVM per la gestione del disco, quindi le operazioni per accedervi non sono "classiche" e veloci, ma è necessario ragionarci sopra e fare più passi per accedere ai dati. Se utilizzate una distribuzione di tipo Debian like dovrete aver installato i pacchetti necessari con i seguenti comandi:
apt-get install mdadm
apt-get install lvm2
Ora possiamo procedere utilizzando i comandi necessari per l'accesso fisico ai file... prima di tutto dobbiamo procedere al riconoscimento del sistema raid:
mdadm --assemble --scan
A questo punto dobbiamo verificare il physical volume presente, probabilmente non sarà in modalità "disponibile" e quindi la dobbiamo cambiarepre rendere accessibili i device /dev/md0 e /dev/md1:
pvs -a
vgchange -ay
pvs
Osservando l'output dei comandi possiamo notare che md0 ed md1 sono dei volume group e per poterne visualizzare il contenuto dobbiamo eseguire i comandi riportati, così scopriremo che al loro interno sono presenti diversi logical volume (BFDlv, vol1 e lv1430e500) e ne visualizzeremo le caratteristiche:
lvdisplay md0_vg
lvdisplay 2e26c579_vg
In base all'output del precedente comando gli ultimi passi che ci rimangono sono quelli per montare i volume group:
mkdir /media/raid0
chmod 777 /media/raid0
mount /dev/md0_vg/BFDlv /media/raid0
mkdir /media/raid1
chmod 777 /media/raid1
mount /dev/md0_vg/vol1 /media/raid1
mkdir /media/raid2
chmod 777 /media/raid2
mount /dev/2e26c579_vg/lv1430e500 /media/raid1
Ora non ci resta che andare a cercare i file che abbiamo modificato prima che smettesse di funzionare... dato che normalmente i problemi legati all'impossibilità di riavvio del dispositivo sono legati a modifiche fatte all'interno del file che viene montato tramite l'interfaccia di loopback, dobbiamo ripetere la stessa procedura per montarlo nuovamente con i seguenti comandi:
cd /media
mkdir apps
chmod 777 apps
mount -o loop,rw /media/raid0/images/apps /media/apps
Ora siete in grado di rimuovere le modifiche che avete fatto e che impedivano il corretto avvio del dispositivo... quindi potete ripartire con il vostro progetto, sperando che la prossima volta funzioni!
Forse con questo abbiamo concluso il ciclo di tutorial di approfondimento, implementazione di nuove funzionalità e risoluzione dei problemi che possono derivare dalle modifiche fatte allo Iomega StorCenter IX2-200, quindi è molto probabile che la prossima puntata tratterà qualcosa di nuovo che avrà attirato la mia attenzione... a presto!
lunedì 29 ottobre 2012
giovedì 25 ottobre 2012
Iomega StorCenter IX2-200: modifiche per utente root
Ci ho provato, ma non avere una home è molto scomodo e dato che mi piace poter amministrare il sistema in maniera semplice ho deciso di studiarmi qualcosa per rendere /root persistente, in maniera da potervi mantenere degli script, conservare la history, avere file di avvio personalizzati e tutto quello che è possibile avere di default sui sistemi tradizionali.
Quindi anche questa volta ci sarà da inventarsi uno stratagemma... per prima cosa creiamo la root in /opt e ne facciamo anche un link simbolico in maniera da avere /root... in seguito procediamo con la creazione dei vari file con le impostazioni che ci interessano (riporto alcuni esempi):
mkdir -pm 750 /opt/root;
ln -sf /opt/root /
vi /root/.bashrc # ad esempio il file può contenere "export PATH=$PATH:$HOME/bin:/opt/bin:/opt/sbin"
mkdir -pm 700 /root/.ssh
vi /root/.ssh/authorized_keys
chmod 600 /root/.ssh/authorized_keys
Ora che abbiamo eseguito le impostazioni desiderate dobbiamo creare uno script che prepari l'ambiente e lo configuri in maniera che sia funzionante dopo ogni riavvio... partiamo quindi con lo script /opt/bin/roothome.sh:
#!/bin/bash
# Create symbolic link to have homedir of user root available and persistent between reboot.
chown -R root.root /opt/root
chmod -R o-rwx /opt/root
ln -sf /opt/root /
Per poter eseguire questo script ad ogni riavvio dobbiamo di nuovo ricorrere alla modifica del file che stabilisce i servizi ed i demoni da eseguire all'avvio, quindi editiamo il file /tmp/apps/usr/local/cfg/sohoProcs.xml ed aggiungiamo alla sezione Group 2:
<Program Name="roothome" Path="/bin/bash">
<Args>/opt/bin/roothome.sh</Args>
<SysOption MaxMem="16M"/>
</Program>
A questo punto ad ogni riavvio la vostra home directory dovrebbe essere disponibile e se utilizzate le chiavi per l'accesso ssh non dovrete neanche più digitare la password.
Direi che anche per questa volta è tutto.
A presto!
Quindi anche questa volta ci sarà da inventarsi uno stratagemma... per prima cosa creiamo la root in /opt e ne facciamo anche un link simbolico in maniera da avere /root... in seguito procediamo con la creazione dei vari file con le impostazioni che ci interessano (riporto alcuni esempi):
mkdir -pm 750 /opt/root;
ln -sf /opt/root /
vi /root/.bashrc # ad esempio il file può contenere "export PATH=$PATH:$HOME/bin:/opt/bin:/opt/sbin"
mkdir -pm 700 /root/.ssh
vi /root/.ssh/authorized_keys
chmod 600 /root/.ssh/authorized_keys
Ora che abbiamo eseguito le impostazioni desiderate dobbiamo creare uno script che prepari l'ambiente e lo configuri in maniera che sia funzionante dopo ogni riavvio... partiamo quindi con lo script /opt/bin/roothome.sh:
#!/bin/bash
# Create symbolic link to have homedir of user root available and persistent between reboot.
chown -R root.root /opt/root
chmod -R o-rwx /opt/root
ln -sf /opt/root /
Per poter eseguire questo script ad ogni riavvio dobbiamo di nuovo ricorrere alla modifica del file che stabilisce i servizi ed i demoni da eseguire all'avvio, quindi editiamo il file /tmp/apps/usr/local/cfg/sohoProcs.xml ed aggiungiamo alla sezione Group 2:
<Program Name="roothome" Path="/bin/bash">
<Args>/opt/bin/roothome.sh</Args>
<SysOption MaxMem="16M"/>
</Program>
A questo punto ad ogni riavvio la vostra home directory dovrebbe essere disponibile e se utilizzate le chiavi per l'accesso ssh non dovrete neanche più digitare la password.
Direi che anche per questa volta è tutto.
A presto!
mercoledì 24 ottobre 2012
Iomega StorCenter IX2-200: servizi al boot
Come detto già in precedenza, le modifiche fatte in /etc sullo Iomega StorCenter IX2-200 non sono persistenti ed a ogni riavvio vengono perse... questo impedisce di poter gestire il dispositivo come una normale distribuzione linux, qui dobbiamo considerare che abbiamo a che fare con una gestione di tipo optware.
Cercando all'interno del file system troviamo un file molto interessante che contiene l'elenco di tutti i servizi che vengono avviati al boot: /mnt/apps/usr/local/cfg/sohoProcs.xml, ma se proviamo a modificarlo vediamo che il file è read only... dobbiamo quindi approfondire e capire da dove arriva quel file...
Con l'aiuto dei comandi df e losetup -a cerchiamo di trovarne l'origine e vediamo che proviene dall'interfaccia di loopback collegata al file /sysroot/boot/images/apps:
/dev/loop0: [fd00]:81927 (/sysroot/boot/images/apps) <--- /dev/loop0 <--- /mnt/apps
/dev/loop1: [fd00]:81922 (sysroot/boot/images/config)
/dev/loop2: [fd00]:81924 (/sysroot/boot/images/oem)
A questo punto dobbiamo montare il file interessato configurando un nuovo loopback in modalità read/write per eseguire le modifiche volute... dato che questa procedura probabilmente la utilizzeremo più volte ed io odio riscrivere gli stessi comandi più volte, conviene scrivere uno script che riassuma tutte le operazioni in /opt/bin/service2boot.sh (e ne approfitteremo anche per fare il backup del file prima delle modifiche):
#!/bin/bash
#
# Crea un loopback device per poi montarlo in scrittura
if [ -e /dev/loop3 ]; then
umount /dev/loop3;
losetup -d /dev/loop3;
fi;
mknod -m0660 /dev/loop3 b 7 3
chown root.disk /dev/loop3;
mkdir -pm 755 /tmp/apps;
mount -o loop /boot/images/apps /tmp/apps;
cp /tmp/apps/usr/local/cfg/sohoProcs.xml /tmp/apps/usr/local/cfg/sohoProcs.xml.$(date +%Y%m%d%H%M);
vi /tmp/apps/usr/local/cfg/sohoProcs.xml;
umount /tmp/apps;
losetup -d /dev/loop3;
rm /dev/loop3;
Ora la prima cosa da fare è capire come avviare eventuali demoni e/o servizi da sohoProcs.xml... osservando il file, possiamo notare che vi sono 3 sezioni ben definite:
Group Level="0"
Group Level="1"
Group Level="2"
Non avendo trovato documentazione, posso solamente ipotizzare che il level 0 sia per inizializzare il dispositivo, il level 1 contenga i servizi per l'autoconfigurazione e per i demoni "ufficiali" e che il level 2 contenga servizi e/o comandi necessari a livello applicativo evoluto... quindi decido di inserire i riferimenti ai servizi, demoni e/o comandi che voglio eseguire in questa sezione.
Ora rimane solamente più da individuare individuare come utilizzare le opzioni possibili per eseguire demoni, servizi e/o comandi... ma cercando un po' in rete si riesce a trovare la seguente spiegazione:
<Program Name="PROGNAME" Path="PERCORSO">
<Args>OPZIONE_1</Args>
<Args>OPZIONE_2</Args>
<SysOption MaxMem="MAXMEM" Restart="-1"/>
</Program>
Dove i parametri hanno i seguenti significati:
- Nice - imposta il livello di priorità del processo
- Restart - quante volte rieseguirlo quando termina; "-1" significa di eseguirlo infinite volte, ma attenzione ad utilizzarlo con programmi che vengono eseguiti come demoni, essi terminano dopo il fork e se il Restart è abilitato inizia un loop infinito; l'altra possibilità per evitare che succeda è far sì che il demone non esegua il fork rimanendo in foreground
- InitOnly - impostazione specifica per l'utilizzo con i demoni
- NoErrors - dovrebbe ignorare i codici di uscita in caso di fallimento
- DelayStart - ritardo di esecuzione, probabilmente in secondi
- Days, Scheduled, StartTime, RandomDelay - parametri per la schedulazione
Direi che adesso avete abbastanza elementi per divertirvi e fare le prove per configurare il sistema a vostro gusto... attenzione che se sbagliate ad eseguire le modifiche ed il boot non termina rischiate di non riuscire neanche a collegarvi in SSH; in questo caso l'unica possibilità, oltre a rasare tutto e ripartire da zero reinstallando il firmware, è quella di utilizzare linux per accedere fisicamente al disco e modificare nuovamente il file sohoProcs.xml rimuovendo le modifiche fatte, ma questo verrà trattato in un prossimo appuntamento.
Per adesso buon divertimento ed attenzione a cosa modificate!
Cercando all'interno del file system troviamo un file molto interessante che contiene l'elenco di tutti i servizi che vengono avviati al boot: /mnt/apps/usr/local/cfg/sohoProcs.xml, ma se proviamo a modificarlo vediamo che il file è read only... dobbiamo quindi approfondire e capire da dove arriva quel file...
Con l'aiuto dei comandi df e losetup -a cerchiamo di trovarne l'origine e vediamo che proviene dall'interfaccia di loopback collegata al file /sysroot/boot/images/apps:
/dev/loop0: [fd00]:81927 (/sysroot/boot/images/apps) <--- /dev/loop0 <--- /mnt/apps
/dev/loop1: [fd00]:81922 (sysroot/boot/images/config)
/dev/loop2: [fd00]:81924 (/sysroot/boot/images/oem)
A questo punto dobbiamo montare il file interessato configurando un nuovo loopback in modalità read/write per eseguire le modifiche volute... dato che questa procedura probabilmente la utilizzeremo più volte ed io odio riscrivere gli stessi comandi più volte, conviene scrivere uno script che riassuma tutte le operazioni in /opt/bin/service2boot.sh (e ne approfitteremo anche per fare il backup del file prima delle modifiche):
#!/bin/bash
#
# Crea un loopback device per poi montarlo in scrittura
if [ -e /dev/loop3 ]; then
umount /dev/loop3;
losetup -d /dev/loop3;
fi;
mknod -m0660 /dev/loop3 b 7 3
chown root.disk /dev/loop3;
mkdir -pm 755 /tmp/apps;
mount -o loop /boot/images/apps /tmp/apps;
cp /tmp/apps/usr/local/cfg/sohoProcs.xml /tmp/apps/usr/local/cfg/sohoProcs.xml.$(date +%Y%m%d%H%M);
vi /tmp/apps/usr/local/cfg/sohoProcs.xml;
umount /tmp/apps;
losetup -d /dev/loop3;
rm /dev/loop3;
Ora la prima cosa da fare è capire come avviare eventuali demoni e/o servizi da sohoProcs.xml... osservando il file, possiamo notare che vi sono 3 sezioni ben definite:
Group Level="0"
Group Level="1"
Group Level="2"
Non avendo trovato documentazione, posso solamente ipotizzare che il level 0 sia per inizializzare il dispositivo, il level 1 contenga i servizi per l'autoconfigurazione e per i demoni "ufficiali" e che il level 2 contenga servizi e/o comandi necessari a livello applicativo evoluto... quindi decido di inserire i riferimenti ai servizi, demoni e/o comandi che voglio eseguire in questa sezione.
Ora rimane solamente più da individuare individuare come utilizzare le opzioni possibili per eseguire demoni, servizi e/o comandi... ma cercando un po' in rete si riesce a trovare la seguente spiegazione:
<Program Name="PROGNAME" Path="PERCORSO">
<Args>OPZIONE_1</Args>
<Args>OPZIONE_2</Args>
<SysOption MaxMem="MAXMEM" Restart="-1"/>
</Program>
Dove i parametri hanno i seguenti significati:
- Program Name - deve essere univoco.
- Path - il percorso del file eseguibile, può essere sh, /bin/sh o /bin/bash per eseguire gli script.
- Args - ogni argomento da passare allo script; possono essere assenti od essercene uno o più.
- SysOptions - si spiega da sola, è tutto il contenuto è opzionale e può essere:
- Nice - imposta il livello di priorità del processo
- Restart - quante volte rieseguirlo quando termina; "-1" significa di eseguirlo infinite volte, ma attenzione ad utilizzarlo con programmi che vengono eseguiti come demoni, essi terminano dopo il fork e se il Restart è abilitato inizia un loop infinito; l'altra possibilità per evitare che succeda è far sì che il demone non esegua il fork rimanendo in foreground
- InitOnly - impostazione specifica per l'utilizzo con i demoni
- NoErrors - dovrebbe ignorare i codici di uscita in caso di fallimento
- DelayStart - ritardo di esecuzione, probabilmente in secondi
- Days, Scheduled, StartTime, RandomDelay - parametri per la schedulazione
Direi che adesso avete abbastanza elementi per divertirvi e fare le prove per configurare il sistema a vostro gusto... attenzione che se sbagliate ad eseguire le modifiche ed il boot non termina rischiate di non riuscire neanche a collegarvi in SSH; in questo caso l'unica possibilità, oltre a rasare tutto e ripartire da zero reinstallando il firmware, è quella di utilizzare linux per accedere fisicamente al disco e modificare nuovamente il file sohoProcs.xml rimuovendo le modifiche fatte, ma questo verrà trattato in un prossimo appuntamento.
Per adesso buon divertimento ed attenzione a cosa modificate!
martedì 23 ottobre 2012
Iomega StorCenter IX2-200: servizio ddclient per IP dinamici
Adesso che è ovvio che l'utilizzo dello Iomega StorCenter IX2-200 non è più limitato alle funzionalità di NAS, e se state seguendo questi tutorial vuole dire che vorreste avere un sistema con funzionalità da server, dobbiamo far sì di poterlo raggiungere anche da postazioni remote (e non parlo di porte e del loro forwarding sul router che è essenziale, ma di indirizzo IP pubblico), ma quando l'indirizzo non è statico insorgono i problemi... quindi anche in questo caso dovremo studiarci una soluzione e questa si chiama DNS dinamico.
Logicamente mantenerlo a mano è abbastanza scomodo e se non siamo collegati al router dello StorCenter è improbabile conoscerne direttamente l'IP da impostare manualmente, quindi quello che andremo a fare è utilizzare uno dei servizi gratuiti di DNS dinamico e configurarlo per l'update automatico tramite il software ddclient. Questo si occupa di verificare ogni tot tempo che l'host configurato venga risolto con l'indirizzo ip del router e, se così non fosse, provvede ad aggiornare il record di tipo A nel DNS provider.
Ora cominciamo con una lista di siti che offrono servizi di DNS dinamico ed hanno protocolli di aggiornamento standard e compatibili con ddclient (magari ce ne sono anche altri, ma questi li avevo provati):
Qui di seguito riporto un esempio di configurazione per dtdns:
server=www.dtdns.com, protocol=dtdns, client=ddclient, login=username, password='password', use=web, web=myip.dnsdynamic.com
hostname.suroot.com
Dato che non era presente alcuno script per avviare il servizio, mi sono basato su quelli già presenti all'interno di /opt/etc/init.d, creandone uno adhoc... /opt/etc/init.d/S99ddclient, con il seguente contenuto:
#!/bin/bash
#
# Startup script for ddclient
#
# Stop myself if running
DAEMON=/opt/sbin/ddclient
PIDFILE=/opt/var/run/ddclient.pid
[ -f ${PIDFILE} ] && kill `cat ${PIDFILE}`
${DAEMON} -daemon 100 -web checkip.dyndns.com -web-skip 'Current IP Address:' -file "/opt/etc/ddclient/ddclient.conf" -pid ${PIDFILE};
Logicamente questo script dovrà essere reso avviabile (chmod 755 /opt/etc/init.d/S99ddclient.sh) e dovremo assicurarci che venga eseguito ad ogni avvio, come per openVPN, ma lo vedremo nella prossima puntata.
A presto!
Logicamente mantenerlo a mano è abbastanza scomodo e se non siamo collegati al router dello StorCenter è improbabile conoscerne direttamente l'IP da impostare manualmente, quindi quello che andremo a fare è utilizzare uno dei servizi gratuiti di DNS dinamico e configurarlo per l'update automatico tramite il software ddclient. Questo si occupa di verificare ogni tot tempo che l'host configurato venga risolto con l'indirizzo ip del router e, se così non fosse, provvede ad aggiornare il record di tipo A nel DNS provider.
Ora cominciamo con una lista di siti che offrono servizi di DNS dinamico ed hanno protocolli di aggiornamento standard e compatibili con ddclient (magari ce ne sono anche altri, ma questi li avevo provati):
- www.no-ip.com
- www.dnsdynamic.org
- freedns.afraid.org
- www.dtdns.com
- www.sitelutions.com
- www.zoneedit.com
Qui di seguito riporto un esempio di configurazione per dtdns:
server=www.dtdns.com, protocol=dtdns, client=ddclient, login=username, password='password', use=web, web=myip.dnsdynamic.com
hostname.suroot.com
Dato che non era presente alcuno script per avviare il servizio, mi sono basato su quelli già presenti all'interno di /opt/etc/init.d, creandone uno adhoc... /opt/etc/init.d/S99ddclient, con il seguente contenuto:
#!/bin/bash
#
# Startup script for ddclient
#
# Stop myself if running
DAEMON=/opt/sbin/ddclient
PIDFILE=/opt/var/run/ddclient.pid
[ -f ${PIDFILE} ] && kill `cat ${PIDFILE}`
${DAEMON} -daemon 100 -web checkip.dyndns.com -web-skip 'Current IP Address:' -file "/opt/etc/ddclient/ddclient.conf" -pid ${PIDFILE};
Logicamente questo script dovrà essere reso avviabile (chmod 755 /opt/etc/init.d/S99ddclient.sh) e dovremo assicurarci che venga eseguito ad ogni avvio, come per openVPN, ma lo vedremo nella prossima puntata.
A presto!
mercoledì 17 ottobre 2012
Iomega StorCenter IX2-200: openvpn
L'installazione di openvpn su sistemi tradizionali l'ho già trattata in precedenza ed anche la gestione dei certificati, quindi queste informazioni le considero acquisite... tratterò solamente l'installazione di openvpn ed il funzionamento del demone con l'ausilio di xinetd... riporterò inoltre le modifiche apportate agli script dato che per come sono concepiti non hanno funzionato sul mio sistema.
Per prima cosa dobbiamo installare il software desiderato, quindi:
ipkg-opt openvpn openssl xinetd
Cominciamo con i problemi dello script per l'avvio del demone... la versione originale non funziona perchè ricerca il modulo tun.o per inizializzare le interfacce di tipo tun che in realtà sono già compilate all'interno del kernel (è presente /dev/net/tun), quindi lo script di avvio /opt/etc/init.d/S20openvpn dovrà risultare come il seguente:
#!/bin/sh
#
# Startup script for openvpn server
#
# Make sure IP forwarding is enabled
echo 1 > /proc/sys/net/ipv4/ip_forward
# Make device if not present (not devfs)
if [ ! -c /dev/net/tun ]; then
# Make sure the tunnel driver is loaded
if ( !(lsmod | grep -q "^tun") ); then
# Make /dev/net directory if needed
if [ ! -d /dev/net ]; then
mkdir -m 755 /dev/net;
fi;
insmod /opt/lib/modules/tun.o;
else
exit -1;
fi;
mknod /dev/net/tun c 10 200;
fi;
# If you want a standalone server (not xinetd), then comment out the return statement below
return 0
## This is for standalone servers only!!!!
# Kill old server if still there
if [ -n "`/opt/bin/pidof openvpn`" ]; then
/opt/bin/killall openvpn 2>/dev/null;
fi
# Start the openvpn daemon - add as many daemons as you want
/opt/sbin/openvpn --daemon --cd /opt/etc/openvpn --config openvpn.conf
# [EOF]
A questo punto dobbiamo solamente più configurarte xinetd affinchè accetti le connessioni per openvpn e quindi editiamo il file /opt/etc/xinetd.d/openvpn ed abilitiamo la linea "only_from += 0.0.0.0" controllando che il servizio non sia disabilitato.
Ora rimane solamente più da avviare il servizio con /opt/etc/init.d/S10xinetd... ma per avviarlo ad ogni boot ci sarà da fare ancora qualche modifica fuori programma dato che la configurazione in /etc non è persistente e viene eliminata ad ogni riavvio, ma questo argomento sarà la discussione del nostro prossimo appuntamento.
Alla prossima!
Per prima cosa dobbiamo installare il software desiderato, quindi:
ipkg-opt openvpn openssl xinetd
Cominciamo con i problemi dello script per l'avvio del demone... la versione originale non funziona perchè ricerca il modulo tun.o per inizializzare le interfacce di tipo tun che in realtà sono già compilate all'interno del kernel (è presente /dev/net/tun), quindi lo script di avvio /opt/etc/init.d/S20openvpn dovrà risultare come il seguente:
#!/bin/sh
#
# Startup script for openvpn server
#
# Make sure IP forwarding is enabled
echo 1 > /proc/sys/net/ipv4/ip_forward
# Make device if not present (not devfs)
if [ ! -c /dev/net/tun ]; then
# Make sure the tunnel driver is loaded
if ( !(lsmod | grep -q "^tun") ); then
# Make /dev/net directory if needed
if [ ! -d /dev/net ]; then
mkdir -m 755 /dev/net;
fi;
insmod /opt/lib/modules/tun.o;
else
exit -1;
fi;
mknod /dev/net/tun c 10 200;
fi;
# If you want a standalone server (not xinetd), then comment out the return statement below
return 0
## This is for standalone servers only!!!!
# Kill old server if still there
if [ -n "`/opt/bin/pidof openvpn`" ]; then
/opt/bin/killall openvpn 2>/dev/null;
fi
# Start the openvpn daemon - add as many daemons as you want
/opt/sbin/openvpn --daemon --cd /opt/etc/openvpn --config openvpn.conf
# [EOF]
A questo punto dobbiamo solamente più configurarte xinetd affinchè accetti le connessioni per openvpn e quindi editiamo il file /opt/etc/xinetd.d/openvpn ed abilitiamo la linea "only_from += 0.0.0.0" controllando che il servizio non sia disabilitato.
Ora rimane solamente più da avviare il servizio con /opt/etc/init.d/S10xinetd... ma per avviarlo ad ogni boot ci sarà da fare ancora qualche modifica fuori programma dato che la configurazione in /etc non è persistente e viene eliminata ad ogni riavvio, ma questo argomento sarà la discussione del nostro prossimo appuntamento.
Alla prossima!
martedì 16 ottobre 2012
Iomega StorCenter IX2-200: source code del dispositivo
Nella precedente guida mi sono arenato alla compilazione del kernel e dei sui moduli, ma non mi sono ostinato dato che la versione del kernel che era presente in optware e quella dello Iomega StorCenter IX2-200 erano diverse... ho quindi deciso di trovare lo stesso kernel sorgente del dispositivo (che non è quello ufficiale di kernel.org). So che questa ricerca è possibile e che il produttore deve renderlo disponibile perchè questo è uno dei "vantaggi" per gli utenti e sviluppatori che applicano le licenze di tipo GPL.
Come prima cosa andiamo a cercarlo sul sito di supporto della Iomega (https://iomega-na-en.custhelp.com/), cerchiamo il nostro dispositivo Iomega StorCenter IX2-200 e vediamo cosa riusciamo a trovare... wow, dove si parla di software c'è anche "Any / Not Applicable", lo selezioniamo e leggendo vediamo che c'è l'ultimo firmware disponibile (ed eseguite l'aggiornamento se non lo avete)... bingo! C'è una parte in cui dice "open source code associated"... da qui potrete scaricare il codice sorgente.
Ora che siete in possesso di tutti i sorgenti e/o patch del software, sappiate che potete ricompilare tutto quello che volete, provando ad ottimizzarlo o ad adattarlo alle vostre esigenze... importantissime, e fonte di "ispirazione" per sapere cosa è in grado di fare il kernel, le patch del kernel, da applicare al kernel ufficiale che si scarica da kernel.org, ed il file config del nostro dispositivo, da cui potrete capire che moduli e funzionalità sono incluse nel kernel e quali no.
A questo punto il mio "interesse" nel proseguire la compilazione del kernel è terminata, ero giunto fino qui cercando informazioni sulla compilazione del kernel con lo scopo di far funzionare openvpn dato che mi segnalava l'impossibilità di trovare il modulo tun.o, ma verificando il file di configurazione del kernel ho visto che l'interfaccia tun è compilata all'interno dello stesso e quindi non vi è bisogno di alcun modulo (ed anche ipkg comunque avvisava di questa "finta" mancanza, quindi mi ero fidato)... adesso sappiamo che i messaggi ricevuti sono solamente un bug da eliminare a livello di script di avvio.
In un prossimo post mi occuperò delle modifiche necessarie a far funzionare openvpn tramite xinetd.
A presto!
Come prima cosa andiamo a cercarlo sul sito di supporto della Iomega (https://iomega-na-en.custhelp.com/), cerchiamo il nostro dispositivo Iomega StorCenter IX2-200 e vediamo cosa riusciamo a trovare... wow, dove si parla di software c'è anche "Any / Not Applicable", lo selezioniamo e leggendo vediamo che c'è l'ultimo firmware disponibile (ed eseguite l'aggiornamento se non lo avete)... bingo! C'è una parte in cui dice "open source code associated"... da qui potrete scaricare il codice sorgente.
Ora che siete in possesso di tutti i sorgenti e/o patch del software, sappiate che potete ricompilare tutto quello che volete, provando ad ottimizzarlo o ad adattarlo alle vostre esigenze... importantissime, e fonte di "ispirazione" per sapere cosa è in grado di fare il kernel, le patch del kernel, da applicare al kernel ufficiale che si scarica da kernel.org, ed il file config del nostro dispositivo, da cui potrete capire che moduli e funzionalità sono incluse nel kernel e quali no.
A questo punto il mio "interesse" nel proseguire la compilazione del kernel è terminata, ero giunto fino qui cercando informazioni sulla compilazione del kernel con lo scopo di far funzionare openvpn dato che mi segnalava l'impossibilità di trovare il modulo tun.o, ma verificando il file di configurazione del kernel ho visto che l'interfaccia tun è compilata all'interno dello stesso e quindi non vi è bisogno di alcun modulo (ed anche ipkg comunque avvisava di questa "finta" mancanza, quindi mi ero fidato)... adesso sappiamo che i messaggi ricevuti sono solamente un bug da eliminare a livello di script di avvio.
In un prossimo post mi occuperò delle modifiche necessarie a far funzionare openvpn tramite xinetd.
A presto!
Iomega StorCenter IX2-200: compilazione del software
Fin'ora ci siamo appoggiati a software precompilato da altre persone e reso disponibile attraverso i repository ipkg, ma non sempre è tutto cosi facile e semplice, soprattutto se dovete partire dai sorgenti per compilarvi il software non presente.
Prima di tutto sappiate che ci sono due possibili strade da seguire per compilare il software:
La compilazione di tipo cross esula dai limiti di spazio e potenza computazionale del dispositivo, ma potrebbe richiedere operazioni molto complesse per la sua preparazione.
Ora vedremo a grandi linee come fare, ma se non sapete nulla di compilazione, o non avete molto interesse (e dovrete usare bene i motori di ricerca in caso di problemi), lasciate stare e leggete qualcos'altro.
Partiamo con la preparazione dell'ambiente di cross compiling supponendo di avere a che fare con una distribuzione di tipo Debian-based installando i seguenti pacchetti:
apt-get update
apt-get install gcc cvs flex bison make pkg-config rsync gettext libglib2.0-dev autoconf libtool automake automake1.9 sudo patch bzip2 gzip wget sed texinfo subversion
Ora procuriamoci l'ambiente di compilazione optware dal repository SVN:
svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware
Sapendo che l'architettura che ci interessa è cs08q1armel, definiamo il target del nostro ambiente con i seguenti comandi:
cd optware; make cs08q1armel-target
Da qui in poi tutto quello che compileremo verrà compilato per questa tipologia di processore, ma dobbiamo ancora creare i tool di base del sistema e con i seguenti comandi verrà scaricato ed impostato molto software (compreso un kernel in versione "vecchia"):
cd cs08q1armel; make directories ipkg-utils toolchain
Come ultima prova per testare il funzionamento possiamo provare a compilare con i seguenti comandi:
make hello-dirclean hello-check
Per capire come fare a compilare altro software esaminate e cercate di interpretare la struttura dei seguenti file:
make pre-targetcd pre; make directories ipkg-utils toolchain
Da qui in poi sappiate che non sono stato in grado di verificare la documentazione letta dato che avevo degli errori che non ho ancora risolto...
A questo punto dovreste essere in grado di compilare e riconfigurare i moduli del kernel:
make kernel-modules-ipk
Per la riconfigurazione dei kmods:
rm -f builds/kernel/.configured
make kernel-modules-config KERNEL_CONFIG_METHOD=menuconfig
cp builds/kernel/.config sources/kernel-modules/pre/defconfig
Ora, parlando dell'ambiente di tipo "native" sappiate che la procedura è la stessa, tranne che partirete direttamente dall'SVN fatto all'interno della /opt del dispositivo targhet... buon divertimento!
Direi che per oggi è tutto... a presto ed alla prossima puntata!
Prima di tutto sappiate che ci sono due possibili strade da seguire per compilare il software:
- native (compilazione nativa a bordo del dispositivo)
- cross (compilazione del codice su di un'altra piattaforma)
La compilazione di tipo cross esula dai limiti di spazio e potenza computazionale del dispositivo, ma potrebbe richiedere operazioni molto complesse per la sua preparazione.
Ora vedremo a grandi linee come fare, ma se non sapete nulla di compilazione, o non avete molto interesse (e dovrete usare bene i motori di ricerca in caso di problemi), lasciate stare e leggete qualcos'altro.
Partiamo con la preparazione dell'ambiente di cross compiling supponendo di avere a che fare con una distribuzione di tipo Debian-based installando i seguenti pacchetti:
apt-get update
apt-get install gcc cvs flex bison make pkg-config rsync gettext libglib2.0-dev autoconf libtool automake automake1.9 sudo patch bzip2 gzip wget sed texinfo subversion
Ora procuriamoci l'ambiente di compilazione optware dal repository SVN:
svn co http://svn.nslu2-linux.org/svnroot/optware/trunk optware
Sapendo che l'architettura che ci interessa è cs08q1armel, definiamo il target del nostro ambiente con i seguenti comandi:
cd optware; make cs08q1armel-target
Da qui in poi tutto quello che compileremo verrà compilato per questa tipologia di processore, ma dobbiamo ancora creare i tool di base del sistema e con i seguenti comandi verrà scaricato ed impostato molto software (compreso un kernel in versione "vecchia"):
cd cs08q1armel; make directories ipkg-utils toolchain
Come ultima prova per testare il funzionamento possiamo provare a compilare con i seguenti comandi:
make hello-dirclean hello-check
Per capire come fare a compilare altro software esaminate e cercate di interpretare la struttura dei seguenti file:
- make/hello.mk
- make/template.mk
make pre-targetcd pre; make directories ipkg-utils toolchain
Da qui in poi sappiate che non sono stato in grado di verificare la documentazione letta dato che avevo degli errori che non ho ancora risolto...
A questo punto dovreste essere in grado di compilare e riconfigurare i moduli del kernel:
make kernel-modules-ipk
Per la riconfigurazione dei kmods:
rm -f builds/kernel/.configured
make kernel-modules-config KERNEL_CONFIG_METHOD=menuconfig
cp builds/kernel/.config sources/kernel-modules/pre/defconfig
Ora, parlando dell'ambiente di tipo "native" sappiate che la procedura è la stessa, tranne che partirete direttamente dall'SVN fatto all'interno della /opt del dispositivo targhet... buon divertimento!
Direi che per oggi è tutto... a presto ed alla prossima puntata!
domenica 14 ottobre 2012
Iomega StorCenter IX2-200: installazione del software
Lo Iomega StorCenter IX2-200 che ho in mano (firmware 3.2.6.21659), funziona grazie ad una distribuzione Linux Debian 5.0 per ARMv5, repository armel e come gestore dei pacchetti utilizza ipkg (questo sistema di distribuzione dei pacchetti si chiama optware e principalmente viene utilizzato da router/nas per ambienti soho).
Potete trovare ulteriori informazioni tecniche al seguente link:
http://iomega.nas-central.org/wiki/Category:Ix2-200
D'ora in poi considereremo di operare solamente tramite l'accesso SSH abilitato in precedenza ed è IMPORTANTE considerare che qualunque modifica fatta sulla root, e non contenuta in /opt, è altamente probabile che venga persa allo spegnimento od al riavvio del dispositivo; inoltre eseguendo un df possiamo notare che il root filesystem è molto piccolo, mentre c'è molto spazio libero in /mnt/system, e /opt è un link simbolico alla directory /mnt/system/opt.
Per mantenere eventuali configurazioni software, normalmente in salvate in /etc, vedremo più avanti come fare... e se avete notato non è neanche presente la home dell'utente root.
Per poter installare il software è necessario configurare i repository IPKG da utilizzare... nel nostro caso sono mantenuti da www.nslu2-linux.org; è quindi necessario creare il file di configurazione relativo (unstable è il più aggiornato, ma vi è anche il repository stable, cross o native dipende dalla piattaforma sulla quale è stato compilato):
cat <<EOF > /etc/ipkg.conf
src cross http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/cross/unstable
src native http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/native/unstable
EOF
A questo punto possiamo tranquillamente operare con i comandi ipkg (o meglio, ipkg-opt come vedremo più avanti):
ipkg update # Aggiornamento della lista del software disponibile
ipkg list | more # Visualizzare il software disponibile
ipkg install <nome_pacchetto> # Installazione del software
ipkg list_installed # Per verificare i pacchetti installati
ipkg upgrade # Per aggiornare i pacchetti installati
ipkg remove <nome_pacchetto> # Rimozione del software
Come detto in precedenza, tutto il software sarà da installare in /opt ed affinchè questo non crei problemi è necessario installare il pacchetto ipkg-opt che si occuperà espressamente di questa operazione, quindi il primo software da installare sarà ipkg-opt:
ipkg install ipkg-opt
A questo punto però dobbiamo aggiungere al path ed alle librerie il contenuto della cartella /opt con i nuovi pacchetti installati nel sistema:
export PATH=/opt/bin:/opt/sbin:$PATH
echo "/opt/lib/" >> /etc/ld.so.conf
ldconfig -v
mv /opt/etc/ipkg.conf /opt/etc/ipkg.conf.old
ln -s /etc/ipkg.conf /opt/etc/ipkg.conf
Per semplificarsi la vita è possibile creare uno script che esegue in automatico le operazioni...
vi /opt/bin/ipkg-opt.sh
#!/bin/bash
(grep "/opt/lib" /etc/ld.so.conf > /dev/null) || (echo "/opt/lib/" >> /etc/ld.so.conf; ldconfig -v);
#(echo $PATH | grep '/opt/bin:/opt/sbin' > /dev/null) || (PATH=${PATH}:/opt/bin:/opt/sbin;);
if [[ ! ":$PATH:" == *":/opt/bin:/opt/sbin:"* ]]; then export PATH=${PATH}:/opt/bin:/opt/sbin; fi;
[ -L /etc/ipkg.conf ] && mv -f /etc/ipkg.conf /etc/ipkg.conf.old || rm -f /etc/ipkg.conf
[ -L /opt/etc/ipkg.conf ] && mv -f /opt/etc/ipkg.conf /opt/etc/ipkg.conf.old || rm -f /opt/etc/ipkg.conf
echo -e "src cross http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/cross/unstable\nsrc native http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/native/unstable" > /opt/etc/ipkg.conf
ln -s /opt/etc/ipkg.conf /etc/ipkg.conf;
ipkg-opt update;
A questo punto si è pronti per cominciare l'installazione dei software di proprio interesse... riporto un esempio relativo a del software che utilizzo normalmente o che considero indispensabile:
ipkg-opt install unzip bzip2 gzip
ipkg-opt install openvpn xinetd
ipkg-opt install ddclient perl-digest-sha1 perl-io-socket-ssl
Se necessario, il software di gestione dei pacchetti IPKG, si occuperà anche dell'installazione delle dipendenze software.
A presto e continuate a fare esperimenti e divertirvi!
Potete trovare ulteriori informazioni tecniche al seguente link:
http://iomega.nas-central.org/wiki/Category:Ix2-200
D'ora in poi considereremo di operare solamente tramite l'accesso SSH abilitato in precedenza ed è IMPORTANTE considerare che qualunque modifica fatta sulla root, e non contenuta in /opt, è altamente probabile che venga persa allo spegnimento od al riavvio del dispositivo; inoltre eseguendo un df possiamo notare che il root filesystem è molto piccolo, mentre c'è molto spazio libero in /mnt/system, e /opt è un link simbolico alla directory /mnt/system/opt.
Per mantenere eventuali configurazioni software, normalmente in salvate in /etc, vedremo più avanti come fare... e se avete notato non è neanche presente la home dell'utente root.
Per poter installare il software è necessario configurare i repository IPKG da utilizzare... nel nostro caso sono mantenuti da www.nslu2-linux.org; è quindi necessario creare il file di configurazione relativo (unstable è il più aggiornato, ma vi è anche il repository stable, cross o native dipende dalla piattaforma sulla quale è stato compilato):
cat <<EOF > /etc/ipkg.conf
src cross http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/cross/unstable
src native http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/native/unstable
EOF
A questo punto possiamo tranquillamente operare con i comandi ipkg (o meglio, ipkg-opt come vedremo più avanti):
ipkg update # Aggiornamento della lista del software disponibile
ipkg list | more # Visualizzare il software disponibile
ipkg install <nome_pacchetto> # Installazione del software
ipkg list_installed # Per verificare i pacchetti installati
ipkg upgrade # Per aggiornare i pacchetti installati
ipkg remove <nome_pacchetto> # Rimozione del software
Come detto in precedenza, tutto il software sarà da installare in /opt ed affinchè questo non crei problemi è necessario installare il pacchetto ipkg-opt che si occuperà espressamente di questa operazione, quindi il primo software da installare sarà ipkg-opt:
ipkg install ipkg-opt
A questo punto però dobbiamo aggiungere al path ed alle librerie il contenuto della cartella /opt con i nuovi pacchetti installati nel sistema:
export PATH=/opt/bin:/opt/sbin:$PATH
echo "/opt/lib/" >> /etc/ld.so.conf
ldconfig -v
mv /opt/etc/ipkg.conf /opt/etc/ipkg.conf.old
ln -s /etc/ipkg.conf /opt/etc/ipkg.conf
Per semplificarsi la vita è possibile creare uno script che esegue in automatico le operazioni...
vi /opt/bin/ipkg-opt.sh
#!/bin/bash
(grep "/opt/lib" /etc/ld.so.conf > /dev/null) || (echo "/opt/lib/" >> /etc/ld.so.conf; ldconfig -v);
#(echo $PATH | grep '/opt/bin:/opt/sbin' > /dev/null) || (PATH=${PATH}:/opt/bin:/opt/sbin;);
if [[ ! ":$PATH:" == *":/opt/bin:/opt/sbin:"* ]]; then export PATH=${PATH}:/opt/bin:/opt/sbin; fi;
[ -L /etc/ipkg.conf ] && mv -f /etc/ipkg.conf /etc/ipkg.conf.old || rm -f /etc/ipkg.conf
[ -L /opt/etc/ipkg.conf ] && mv -f /opt/etc/ipkg.conf /opt/etc/ipkg.conf.old || rm -f /opt/etc/ipkg.conf
echo -e "src cross http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/cross/unstable\nsrc native http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/native/unstable" > /opt/etc/ipkg.conf
ln -s /opt/etc/ipkg.conf /etc/ipkg.conf;
ipkg-opt update;
A questo punto si è pronti per cominciare l'installazione dei software di proprio interesse... riporto un esempio relativo a del software che utilizzo normalmente o che considero indispensabile:
ipkg-opt install unzip bzip2 gzip
ipkg-opt install openvpn xinetd
ipkg-opt install ddclient perl-digest-sha1 perl-io-socket-ssl
Se necessario, il software di gestione dei pacchetti IPKG, si occuperà anche dell'installazione delle dipendenze software.
A presto e continuate a fare esperimenti e divertirvi!
sabato 13 ottobre 2012
Iomega StorCenter IX2-200: abilitazione SSH
Dato che sono entrato in possesso di uno Iomega StorCenter IX2-200 che ha avuto dei problemi ai dischi e quindi non era più affidabile, ho deciso di cominciare a farci sopra degli esperimenti per sfruttare le potenzialità del processore arm contenuto al suo interno e quindi comincerò una nuova serie di post riguardandi questo argomento... ed ora partiamo con le basi per potersi collegare... l'abilitazione del servizio SSH!
Per abilitare l'SSH è necessario collegarsi all'indirizzo IP dello StorCenter IX2-200, dopo aver eseguito il login, e caricare la pagina:
A questo punto si può abilitare il protocollo SSH e la porta da utilizzare nella schermata apparsa; vi sono anche molte altre funzioni utili, tipo quella di dump della configurazione del NAS... che esulano da questo post, ma vi fanno capire che è sempre importante guardarsi intorno.
A questo punto è possibile collegarsi al NAS tramite l'utente root ed utilizzando come password una stringa "combinata": soho[password dell'utente admin]
Alla prossima puntata e buon divertimento!
Per abilitare l'SSH è necessario collegarsi all'indirizzo IP dello StorCenter IX2-200, dopo aver eseguito il login, e caricare la pagina:
- http://[IP Address of your NAS]/support.html (per la versione "normale");
- https://[IP Address of your NAS]/diagnostics.html (per la versione "cloud edition").
A questo punto si può abilitare il protocollo SSH e la porta da utilizzare nella schermata apparsa; vi sono anche molte altre funzioni utili, tipo quella di dump della configurazione del NAS... che esulano da questo post, ma vi fanno capire che è sempre importante guardarsi intorno.
A questo punto è possibile collegarsi al NAS tramite l'utente root ed utilizzando come password una stringa "combinata": soho[password dell'utente admin]
Alla prossima puntata e buon divertimento!
Iscriviti a:
Post (Atom)