Iomega StorCenter IX2-200: accesso fisico al disco

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!

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!

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:

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

            - MaxMem - massima occupazione di RAM consentita
            - 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!