Suma kontrolna daje możliwość sprawdzenia czy dane zawarte w pliku nie zostały zmienione podczas transferu z jednego medium informacyjnego na inne. Jeśli weźmiemy przykład pakietów sieciowych, to pliki przesyłane między dwoma punktami są dzielone na mniejsze kawałki. W każdym z nich są zawarte sumy kontrole danych, które zawierają. Komputer odbierający taki pakiet generuje własną sumę kontrolą i porównuje ją z tą otrzymaną w pakiecie. W przypadku gdy suma kontrolna się nie zgadza, mamy do czynienia z błędami przesyłu, tj. pakiet został uszkodzony gdzieś po drodze. W tej sytuacji maszyna odbierająca dane prosi o ponowne przesłanie uszkodzonego segmentu. Ta sytuacja może się zdarzyć ale błędy są automatycznie naprawiane. Problem jest taki, że przy pobieraniu plików z internetu nie zawsze korzystamy z bezpiecznych połączeń, poza tym, zawsze ktoś może uzyskać dostęp do serwera i podmienić pliki. Czy możemy zatem mieć pewność, że dany plik trafił do nas w formie takiej jak powinien?

Wiele czasu zajęło mi opanowanie w końcu tych bestii zwanych dirty pages, które to są trzymane w cache pamięci RAM i potrafią dać się nieźle we znaki, zwłaszcza gdy ma się mało pamięci operacyjnej i maszynę 64 bitową. Chodzi o to, że podczas kopiowania plików z/na pendrive, system zaczyna się strasznie przycinać, bo następuje zrzucanie danych innych procesów z RAM do SWAP by zrobić miejsce pod te dane, które są aktualnie kopiowane.

Narzędzie gpg posiada swój własny plik konfiguracyjnych, który zwykle jest zlokalizowany w ~/.gnupg/gpg.conf . Można w nim sprecyzować większość z opcji, które zwykle są podawane w terminalu przy wywoływaniu polecenia gpg . Po zdefiniowaniu odpowiednich wpisów w pliku konfiguracyjnym, nie będziemy musieli już wyraźnie podawać tych parametrów ilekroć będziemy chcieli skorzystać z gpg . Przy okazji szukania info o kluczach GPG, natknąłem się na dość ciekawy artykuł na temat GnuPG. Jest tam sporo informacji, które są wielce użyteczne w procesie konfiguracji tego narzędzia poprawiając tym samym dość znacznie bezpieczeństwo komunikacji.

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