Zapuszczając się w coraz to i głębsze warstwy systemu podczas dążenia do zbadania jak on tak naprawdę działa, zacząłem się stykać z regułami udev'a (tymi umieszczanymi w katalogu /etc/udev/rules.d/ ). Jako, że nazbierało mi się już ich kilka, zaistniała potrzeba przebadania tego co ten katalog tak naprawdę zawiera. Na dobrą sprawę nigdy się nad tym nie zastanawiałem, jedynie kopiowałem rozwiązania z internetu i wklejałem je do odpowiedniego pliku i jeśli ono działało, to odznaczałem problem jako rozwiązany. Zwykle takich reguł się nie potrzebuje, temu praktycznie niewielu ludzi w ogóle się orientuje jak ogarnąć tego całego udeva. Są przypadki kiedy przepisanie nazw urządzeń czy wykonanie określonych akcji po podłączeniu jakiegoś sprzętu do komputera jest wielce niezbędne i nie ma innej opcji jak tylko zrozumieć co udev tak naprawdę robi.

Wszelkie obrazy .iso płyt cd/dvd czy nawet pliki .img zawierające strukturę obrazów live możemy zamontować lokalnie na komputerze uzyskując tym samym dostęp do ich systemu plików. W większości przypadków, każdy taki obraz zawiera tylko jedną partycję, czasem lekko przesuniętą względem początku ale generalnie nie ma większych problemów z zamontowaniem tego typu plików. Najwyżej trzeba podać jeden dodatkowy parametr, tj. offset . A co w przypadku obrazów dysków, które zwykle mają więcej niż jedną partycję? Gdybyśmy spróbowali zamontować taki plik w systemie, to zostanie nam zwrócony błąd, no bo przecież kernel nie wie za bardzo jak taki plik ma odczytać. Możemy za to skorzystać z urządzeń loop , które po odpowiedniej konfiguracji, są w stanie nam takie obrazy z powodzeniem zamontować na naszym linux'ie.

Struktura pliku .img czy .iso niczym nie odbiega od struktury przeciętnego dysku twardego. W obu przypadkach mamy dokładnie taki sam schemat budowy, tj. mamy obecny MBR i partycje, z których pierwsza zwykle jest wyrównana do 1MiB, zostawiając tym samym 2047 sektorów wolnego miejsca z początku pliku, tuż za MBR, tzw. MBR-GAP. Obraz .img można poddać edycji, np. utworzyć wewnątrz niego inne partycje, zmienić rozmiar ich systemu plików, a nawet można manipulować rozmiarem samego obrazu .img . Taki plik możemy również zamontować w systemie przy pomocy narzędzia mount ale też trzeba odpowiednio podejść do tego zadania, bo przez fakt, że mamy z początku MBR i trochę wolnego miejsca, to linux zwyczajnie nie potrafi rozpoznać systemu plików, który znajduje się w obrazie .img.

W poprzednim wpisie przygotowywaliśmy sobie plik gpg.conf. Opcje w nim ustawione są niezbędne do wygenerowania dobrego pod względem bezpieczeństwa klucza GPG. Taki klucz GPG nie powinien być krótszy niż 4096 bitów. Dodatkowo, nie powinno się ustawiać daty ważności dłuższej niż 2 lata, a to z tego powodu, że zawszę tę datę można zmienić i to nawet w przypadku gdy klucz straci ważność. Chodzi generalnie o ustawienie jakiegoś mechanizmu zabezpieczającego na wypadek gdyby nasz klucz GPG wpadł w niepowołane ręce i stracilibyśmy nad nim panowanie. Wtedy po jakimś czasie automatycznie się on unieważni i nie będziemy musieli się martwić czy ktoś może przez przypadek go używać. Jest również szereg innych rzecz, o które powinniśmy się zatroszczyć i tej tematyce będzie poświęcony ten wpis, który w dużej mierze powstał w oparciu o te dwa linki.

Parę dni temu jednemu z użytkowników forum DUG przytrafiła się niezbyt miła sytuacja. Rozchodzi się o to iż zakupił on kartę SD i, jak sprzedawca zapewniał, miała mieć pojemność 128 GiB. Wszyscy wiemy, że sprzedawcy nieco zawyżają te numerki na opakowaniach, bo operują na potęgach o podstawie 10, a nie 2, i tak ze 100 GB robi się zaraz 93 GiB. Do tego oczywiście jeszcze dochodzi rezerwacja miejsca na potrzebę obsługi systemu plików. Niemniej jednak, w tym przypadku, różnica była trochę większa i tutaj mamy do czynienia z czymś co się nazywa fake flash.

Jest taka żelazna zasada, by po zakupie jakiegoś sprzętu, sprawdzić go czy aby działa jak należy i czy jest z nim wszystko w porządku. Jest to wręcz obowiązek przy zakupie pamięci opartych o technologię flash, bez znaczenia z jakiego to źródła by one nie pochodziły.

MBR to pierwszy sektor dysku twardego, który może ma jedynie 512 bajtów ale jest to bardzo krytyczny obszar nośnika, po którego uszkodzeniu czy nadpisaniu tracimy dostęp do wszystkich partycji znajdujących się na dysku. Ci bardziej przezorni użytkownicy robią sobie backup tego kluczowego punktu, tak by w przypadku problemów mogli go sobie przywrócić. Nie zawsze jednak potrzebujemy przywracać cały sektor MBR, w większości przypadków będziemy potrzebować jedynie kodu bootloadera lub samej tablicy partycji.

Jeśli mamy nieco odbiegające od standardowych oczekiwania dotyczące systemów live, np. wynikają one z braku obecności pewnych pakietów w obrazie wygenerowanym przez developerów jakiejś konkretnej dystrybucji, to możemy sobie stworzyć własny obraz live, gdzie mamy możliwość dostosowania całej konfiguracji takiego systemu wliczając w to również i instalację brakujących pakietów. Obrazy, które są dostępne na stronie debiana, zawierają wydanie stabilne i jak wiadomo, nie jest ono zbyt aktualne pod względem oprogramowania. Natomiast jeśli chodzi o tworzenie własnych obrazów live, to możemy zdefiniować sobie gałąź, z której mają być pobierane pakiety użyte w procesie budowania, jak i również dograć te pakiety, które nie są w żaden sposób powiązane z daną dystrybucją.

Linuxy mają tę właściwość, że bardzo ciężko jest stracić do któregoś z nich dostęp, nawet w przypadku kompletnego zawału systemu. Jeżeli dysponujemy jakimś alternatywnym środowiskiem w postaci płytki live cd/dvd czy pendrive albo też posiadamy gdzieś zainstalowanego innego linuxa, to istnieje spore prawdopodobieństwo, że uda się nam reanimować nasz główny system. Wszystko za sprawą narzędzia jakim jest chroot , przy którego to pomocy możemy zmienić główny katalog systemu plików ( / ) dla wykonywanych procesów bez potrzeby przechodzenia całej skomplikowanej procedury uruchamiania systemu operacyjnego. Jeśli tylko uda nam się uzyskać dostęp do shella, to nie ma takiej możliwości by system nie stanął na nogi.

Systemy live mają jedną ale za to dość dającą się odczuć wadę, mianowicie chodzi o to, że po wypaleniu takiego obrazu, nie mamy możliwości zachowania zmian. Nawet jeśli doinstalujemy nowy pakiet czy wyedytujemy jakiś plik, to zmiany wprowadzone przez nas są jedynie tymczasowe, bo dokonywane w pamięci operacyjnej RAM. W efekcie jeśli uruchomimy taki system ponownie, będziemy zmuszeni przeprowadzać raz jeszcze wszystkie poprzednie czynności pod kątem jego dostosowania. W przypadku cd/dvd nie mamy praktycznie żadnego pola manewru. Inaczej jednak ma się sprawa jeśli chodzi o pendrive, bo tutaj możemy utworzyć osobną partycję, gdzie będą przechowywane wszystkie zmiany jakich dokonamy.

System live to nic innego jak spakowany system plików jakieś zainstalowanej dystrybucji, który podczas startu maszyny jest montowany w trybie tylko do odczytu, a potrzebne pliki są wypakowywane w czasie rzeczywistym w pamięci operacyjnej RAM. Do implementacji takiego rozwiązania stosuje się squashfs i jako że jest to system plików tylko do odczytu, nie można go jako tako edytować. Nie jesteśmy też zupełnie na straconej pozycji, bo możemy skorzystać z dwóch rozwiązań: persistence lub możemy pokusić się o przepakowanie systemu plików.