L'uso di un file system di root di sola lettura è una buona idea per l'installazione integrata?


15

Mi è stato assegnato il compito di eseguire Linux come sistema operativo su un dispositivo incorporato.

L'obiettivo ha un processore x86 e un dispositivo CompactFlash da 8 GB per l'archiviazione.

Sono riuscito a usare buildroot per creare l'immagine del kernel e strumenti di compilazione incrociata. Ho partizionato il dispositivo CF in una piccola partizione FAT in cui risiede l'immagine del kernel, nonché la syslinuxconfigurazione di avvio e un ext3file system in cui ho decompresso il file system radice generato da buildroot.

Il sistema si avvia correttamente utilizzando syslinuximpostando la directory principale sulla partizione CF ext3 in cui si trova il mio file system buildroot.

La mia domanda è centrata sulla necessità di robustezza di fronte a una perdita di potenza immediata (e frequente) in quanto è fondamentale che il dispositivo si avvii correttamente dopo un'interruzione di corrente. Ho letto che montare il file system di root in sola lettura è un modo per garantire l'integrità dei dati. È un modo ragionevole per procedere?

Ho anche letto della possibilità di caricare il file system di root nella RAM per ottenere la stessa cosa, ma non so ancora come farlo.

Esiste un modo preferito per raggiungere questo obiettivo e, in caso affermativo, qual è il modo migliore per procedere?

Risposte:


11

Nuova risposta (22-03-2015)

( Nota: questa risposta è più semplice della precedente, ma non più sicura. La mia prima risposta è più forte perché potresti mantenere i file di sola lettura con le opzioni di mount fs prima dei flag di autorizzazione. Quindi forzare la scrittura di un file senza il permesso di scrivere non funzionerà affatto.)

Sì, sotto Debian , c'è un pacchetto: fsprotect ( homepage ).

Utilizza aufs(per impostazione predefinita, ma potrebbe utilizzare un altro unionfsstrumento) per consentire le modifiche alla sessione live ma nella RAM per impostazione predefinita, quindi tutto viene dimenticato al riavvio.

Puoi installarli semplicemente eseguendo:

apt-get install fsprotect

Una volta fatto, dal documento online:

Dopo di che:

  • Modifica /boot/grub/menu.lsto /etc/default/grub2o /etc/lilo.confe aggiungi " fsprotect=1G" ai parametri del kernel.
  • Modifica 1G secondo necessità.
  • Applica modifiche (es. Corsa update-grub)
  • Modifica /etc/default/fsprotectse desideri proteggere file system diversi da /.
  • riavvio

Potresti anche voler proteggere con password il bootloader grub o vietare qualsiasi modifica ad esso.

Da lì, se alcuni file sono protetti dalle modifiche, ad esempio

chmod ugo-w myfile

se usi per esempio vi myfilee provi a scrivere su di esso con il comando :w!, questo funzionerà e il tuo sarà myfilecambiato. È possibile riavviare per recuperare non modificati myfile.

Questo non è nemmeno possibile con la mia prima soluzione seguente:

Vecchia (prima) risposta:

Sì, è una soluzione forte, ma potente!

R / o utilizzabile

È necessario montare alcune directory nel rw , come /var, /etce forse /home. Questo potrebbe essere fatto usando aufs o unionfs . Mi piace in un altro modo , usando /dev/shme mount --bind:

cp -a /var /dev/shm/
mount --bind /dev/shm/var /var

In precedenza, è possibile spostare tutte le directory che non devono cambiare durante il normale funzionamento in a static-var, piuttosto che creare collegamenti simbolici in / var:

mkdir /static-var
mkdir /static-var/cache
mkdir /static-var/lib
mv /var/lib/dpkg /static-var/lib/dpkg
ln -s /static-var/lib/dpkg /var/lib/dpkg
mv /var/cache/apt /static-var/cache/apt
ln -s /static-var/cache/apt /var/cache/apt
... # an so on

Quindi quando si rimonta in ro, la copia /varin /dev/shmnon occuperà troppo spazio in quanto la maggior parte dei file viene spostata /static-vare solo i collegamenti simbolici devono essere copiati in ram.

Il modo migliore per farlo con precisione è fare un ciclo completo, un giorno di pieno lavoro ed eseguire finemente un comando come:

find / -type f -o -type f -mtime -1

Quindi vedrai quali file devono trovarsi sulla partizione di lettura / scrittura.

Registrazione

Come in questo host non esiste memoria statica scrivibile, al fine di memorizzare la cronologia e altri registri, è necessario configurare un syslogserver remoto .

echo >/etc/syslog.conf '*.* @mySyslogServer.localdomain'

In questo modo, se il sistema si interrompe per qualsiasi motivo, viene registrato tutto prima.

Aggiornamento

Quando si esegue con alcuni mount --bindin uso, per fare un tale aggiornamento mentre il sistema è in uso (senza la necessità di funzionare init 1, per ridurre i tempi di fermo), il modo più semplice è ricostruire una radice pulita , in grado di eseguire l'aggiornamento:

Dopo aver rimontato '/' in modalità lettura-scrittura :

mount -o remount,rw /

for mpnt in /{,proc,sys,dev{,/pts}};do
    mount --bind $mnpt /$mnt$mpnt;
    done

chroot /mnt

apt-get update && apt-get dist-upgrade

exit

umount /mnt/{dev{/pts,},proc,sys,}

sync
mount -o remount,ro /

E adesso:

shutdown -r now

Grazie per la tua risposta. Non lo capisco completamente dato che le mie abilità su Linux non sono grandi al momento. È comunque molto utile e mi dà alcune aree in più per la ricerca.
matematico,

Risposta modificata! Nuova soluzione e differenze spiegate!
F. Hauri,

Questo non risponde alla domanda, è un'ottima risposta per un sistema basato su debian, ma Buildroot non è basato su debian.
Ama

@LovesTha Dai un'occhiata alla vecchia (prima) risposta ! Questo è meno basato su Debian e U potrebbe comprendere il principio e implementare lo stesso meccanismo per qualsiasi tipo di distribuzione / installazione. (anche se la sezione Upgrade mostra i comandi Debian, U potrebbe fare lo stesso per l'aggiornamento manuale o qualsiasi altro aggiornamento basato su distrib.)
F. Hauri,

La tua vecchia risposta sarebbe un'ottima risposta a una domanda generica sulla configurazione di sistemi Linux di sola lettura. Una volta terminata la mia esplorazione per rendere il nostro buildroot di sola lettura, spero di tornare e dare una risposta molto dettagliata sulla domanda specifica qui. Buildroot ha già i bit temporanei di / var collegati a / tmp che è un tempfs. / etc non dovrebbe essere usato come spazio per i programmi, quindi non dovrebbe essere gestito in modo speciale.
Ama

3

Ho solo esperienza con un buildroot più recente (2014-02). In quella versione è possibile disabilitare 'remaunt root filesystem read-write duing boot' nel file di configurazione con:

BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW non è impostato

Sono riuscito a creare un'immagine che utilizza solo la sua ext4 / partizione in sola lettura, quindi scollegare la potenza del sistema non danneggia affatto. Funziona benissimo, quindi se non hai bisogno di scrivere sul tuo filesystem, forse questa è una soluzione molto più semplice di quella sopra menzionata (che sembra più o meno applicabile a un sistema Debian come si riferisce a apt-get).


Grazie per la risposta, tuttavia alla fine ho optato per una configurazione di initramfs con il montaggio di un paio di directory con l'opzione di sincronizzazione sull'unità CF per la persistenza dei dati. Questo mi è servito abbastanza bene per il momento.
matematico,

Per aggiungere a questo: usando le versioni buildroot precedenti, controlla /etc/inittabse il rimontaggio /avviene lì. In tal caso, modificalo in base alle tue esigenze.
evnu,

Questa risposta è un pezzo importante del "modo buildroot" per farlo. Gran parte del consiglio nella risposta accettata sarà necessario per far funzionare i sistemi più complessi. È probabile però che tutto ciò che dovrà essere fatto sia impostare alcuni symlink aggiuntivi su / tmp (tempfs) e tutto funzioni.
Ama
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.