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


15

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ć?

Odpowiedzi:


11

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

Dziękuję za odpowiedź. Nie do końca to rozumiem, ponieważ moje umiejętności w zakresie Linuksa nie są obecnie świetne. Jest jednak nadal bardzo pomocny i daje mi więcej obszarów do badań.
matematyk

Odpowiedź edytowana! Nowe rozwiązanie i wyjaśnione różnice!
F. Hauri

To nie odpowiada na pytanie, to świetna odpowiedź dla systemu opartego na Debianie, ale Buildroot nie jest oparty na Debianie.
LovesTha

@LovesTha Spójrz na starą (pierwszą) odpowiedź ! Jest to w mniejszym stopniu oparte na Debianie i U może zrozumieć zasadę i wprowadzić ten sam mechanizm dla każdego rodzaju dystrybucji / instalacji. (nawet jeśli sekcja Uaktualnienia pokazuje polecenia Debiana, U może zrobić to samo dla ręcznej aktualizacji lub innej aktualizacji opartej na dystrybucji).
F. Hauri

Twoja stara odpowiedź byłaby świetną odpowiedzią na ogólne pytanie dotyczące konfigurowania systemów Linux tylko do odczytu. Po zakończeniu moich badań nad tym, aby nasz buildroot był tylko do odczytu, mam nadzieję wrócić i udzielić bardzo szczegółowej odpowiedzi na konkretne pytanie tutaj. Buildroot ma już tymczasowe bity / var dowiązane symbolicznie do / tmp, który jest tempfs. / etc nie powinien być używany jako miejsce na zarysowania dla programów, więc nie trzeba go traktować specjalnie.
LovesTha

3

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).


Dzięki za odpowiedź - jednak ostatecznie zdecydowałem się na konfigurację initramfs z zamontowaniem tylko kilku katalogów z opcją synchronizacji na dysku CF dla zachowania danych. Na razie służyło mi to całkiem dobrze.
matematyk

Aby dodać do tego: używając starszych wersji buildroot, sprawdź, /etc/inittabczy ma miejsce ponowny montaż /. Jeśli tak, zmień to na swoje potrzeby.
evnu,

Ta odpowiedź jest ważnym elementem „wbudowanego sposobu”, aby to zrobić. Wiele porad zawartych w przyjętej odpowiedzi będzie potrzebnych, aby bardziej złożone systemy działały. Są jednak szanse, że wszystko, co trzeba będzie zrobić, to skonfigurować kilka dodatkowych dowiązań symbolicznych do / tmp (tempfs) i wszystko działa.
LovesTha
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.