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!