Czy używanie systemu plików root tylko do odczytu to dobry pomysł na osadzoną konfigurację?

Zadanie polegało na uruchomieniu Linuksa jako systemu operacyjnego na urządzeniu wbudowanym.

Cel ma procesor x86 i urządzenie CompactFlash o pojemności 8 GB do przechowywania.

Udało mi się użyć buildroot do stworzenia obrazu jądra i narzędzi do kompilacji krzyżowej. Podzieliłem urządzenie CF na małą partycję FAT, na której znajduje się obraz jądra, a także syslinuxkonfigurację rozruchową i system ext3plików, w którym rozpakowałem główny system plików wygenerowany przez buildroot.

System uruchamia się pomyślnie syslinux, ustawiając katalog główny na partycję CF ext3, na której znajduje się mój system plików buildroot.

Moje pytanie koncentruje się na potrzebie niezawodności w obliczu natychmiastowej (i częstej) utraty zasilania, ponieważ jest to kluczowe dla pomyślnego rozruchu urządzenia po przerwach w zasilaniu. Przeczytałem, że zamontowanie głównego systemu plików jako tylko do odczytu jest sposobem na zapewnienie integralności danych. Czy to dla mnie rozsądny sposób?

Przeczytałem również o możliwości załadowania głównego systemu plików do pamięci RAM, aby osiągnąć to samo, ale jak dotąd nie wiem, jak to zrobić.

Czy istnieje preferowany sposób osiągnięcia tego celu, a jeśli tak, jaki jest najlepszy sposób, aby kontynuować?

Nowa odpowiedź (2015-03-22)

( Uwaga: ta odpowiedź jest prostsza niż poprzednia, ale nie jest bezpieczniejsza. Moja pierwsza odpowiedź jest silniejsza, ponieważ można zachować pliki tylko do odczytu za pomocą opcji montowania fs przed flagami uprawnień. Więc zmuszanie do pisania plików bez uprawnień do zapisu nie będzie działać) w ogóle.)

Tak, pod Debianem znajduje się pakiet: fsprotect ( strona główna ).

Używa aufs(domyślnie, ale może użyć innego unionfsnarzędzia), aby zezwolić na zmiany sesji na żywo, ale domyślnie w pamięci RAM, więc wszystko zostaje zapomniane przy ponownym uruchomieniu.

Możesz je zainstalować, uruchamiając po prostu:

apt-get install fsprotect

Po zakończeniu z dokumentu online:

Po tym:

• Edytuj /boot/grub/menu.lstlub /etc/default/grub2lub /etc/lilo.confdodaj „ fsprotect=1G” do parametrów jądra.
• Zmodyfikuj 1G zgodnie z potrzebami.
• Zastosuj zmiany (tj. Uruchom update-grub)
• Edytuj, /etc/default/fsprotectjeśli chcesz chronić systemy plików inne niż /.
• restart

Możesz także zabezpieczyć hasłem program ładujący gruba lub zabronić jakichkolwiek zmian w nim.

Stamtąd, jeśli jakiś plik jest chroniony przed zmianami, na przykład przez

chmod ugo-w myfile

jeśli użyjesz próbki vi myfilei spróbujesz napisać na niej za pomocą komendy :w!, to zadziała i twoja myfilezmieniona. Możesz uruchomić ponownie, aby odzyskać niezmodyfikowane myfile.

Nie jest to nawet możliwe w przypadku mojego pierwszego pierwszego rozwiązania:

Stara (pierwsza) odpowiedź:

Tak, to silne rozwiązanie, ale potężne!

Uczynienie r / o użytecznym

Trzeba zamontować kilka katalogów w RW , jak /var, /etca może /home. Można to zrobić za pomocą aufs lub unionfs . Podoba mi się to w inny sposób , używając /dev/shmi mount --bind:

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

Możesz wcześniej przenieść wszystkie katalogi, które nie muszą zmieniać się podczas normalnego działania static-var, niż tworzyć dowiązania symboliczne w / 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

Więc kiedy zamontowaniem w ro, kopiując /varna /dev/shmnie zajmie zbyt wiele miejsca, ponieważ większość pliki są przenoszone do /static-vari tylko dowiązania mają być kopiowane do pamięci RAM.

Lepszym sposobem na zrobienie tego drobiazgowo jest wykonanie pełnego cyklu zasilania, jeden dzień pełnej pracy i dokładne wykonanie polecenia takiego jak:

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

Zobaczysz więc, które pliki muszą znajdować się na partycji do odczytu i zapisu.

Logowanie

Ponieważ na tym hoście nie ma zapisywalnej pamięci statycznej, w celu przechowywania historii i innych dzienników należy skonfigurować zdalny syslogserwer.

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

W ten sposób, jeśli system z jakiegoś powodu ulegnie awarii, wszystko przedtem jest rejestrowane.

Aktualizacja

Podczas uruchamiania z niektórymi mount --bindw użyciu, w celu przeprowadzenia takiej aktualizacji, gdy system jest w użyciu (bez potrzeby uruchamiania init 1, w celu skrócenia przestojów), najprostszym sposobem jest przebudowanie czystego katalogu głównego , który może wykonać aktualizację:

Po ponownym zamontowaniu „/” w trybie do odczytu i zapisu :

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 /

I teraz:

shutdown -r now

Mam tylko doświadczenie w korzystaniu z nowszej wersji (2014-02). W tej wersji możesz wyłączyć opcję „ponownie podłącz główny system plików do odczytu i zapisu duing boot” w pliku konfiguracyjnym za pomocą:

BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW nie jest ustawiony

Udało mi się stworzyć obraz, który po prostu używa swojej partycji ext4 / tylko do odczytu, więc odłączenie zasilania systemu w ogóle nie szkodzi. Działa świetnie, więc jeśli nie musisz pisać do systemu plików, być może jest to znacznie prostsze rozwiązanie niż wspomniane powyżej (które wydaje się mniej lub bardziej odpowiednie dla systemu Debian w odniesieniu do apt-get).