W poprzednim wpisie poruszyłem temat konwersji tablicy partycji MS-DOS (MBR) na GPT. Jak można było zauważyć, ten proces nie był skomplikowany i niemalże automatyczny. Nie towarzyszyło mu także zjawisko utraty jakichkolwiek danych, jedynie w przypadku posiadania systemu operacyjnego, trzeba było przeinstalować bootloader. Nasuwa się zatem pytanie, czy również w tak prosty sposób można przerobić tablicę partycji GPT na MS-DOS? Jest to wykonalne z tym, że trzeba odpowiednio przygotować sobie do tego celu dysk.

Od jakiegoś czasu nosiłem się z zamiarem utworzenia na swoim dysku tablicy partycji GPT. Problem w tym, że tam jest wgranych sporo cennych danych i nie mam gdzie ich przenieść. Jedyne co mi wpadło do głowy to konwersja tablicy MS-DOS (zwanej też MBR) na GPT. Nie żebym jakoś tego potrzebował ale tak z ciekawości chciałem zobaczyć czy da się to zrobić w sposób łatwy i bezproblemowy. Z tego co wyczytałem na necie, to taka konwersja nie powinna sprawić problemów, zarówno przy przechodzeniu z MS-DOS na GPT jak i odwrotnie, choć w tym drugim przypadku trzeba się trochę bardziej wysilić.

Parę dni temu opisywałem jak udało mi się realokować uszkodzony sektor z dysku, który już przepracował dość długi okres czasu. Nie było to znowu jakoś specjalnie trudne, z tym, że cały problem dotyczył jakiegoś losowego sektora gdzieś w środku partycji. Jako, że domyślnym systemem plików na linuxie są te z rodziny ext (ext2, ext3, ext4) , oraz, że trzecia wersja tego systemu plików została wyposażona w dziennik (journal), to trzeba by się zastanowić, co w przypadku gdy taki uszkodzony sektor trafi się właśnie w dzienniku tego systemu plików?

Pisząc ostatni artykuł na temat udeva i montowania przy jego pomocy zaszyfrowanego kontenera, wpadł mi do głowy ciekawy pomysł na trzymanie pliku klucza (keyfile) w czymś co się potocznie nazywa "głębokim ukryciem". Z reguły ludzie nie chcą używać haseł do odblokowywania swoich systemów czy partycji i zamiast nich wolą stosować keyfile, czyli małe pliki, zwykle o rozmiarze paru KiB, które, jakby nie patrzeć, są dość unikatowe i odporne na ataki słownikowe czy inne formy przemocy. Jedyny problem z jakim człowiek musi się zmierzyć, to z zabezpieczeniem takiego keyfile i tutaj sprawa nie wygląda wcale dobrze. Takie pliki klucze są trzymane zwykle na tym samym urządzeniu, do których mają zapewniać bezpieczny dostęp, a nawet jeśli nie na tym samym, to w pobliżu takich urządzeń, dając nam tym samym jedynie fałszywe poczucie bezpieczeństwa.

Uszkodzone sektory w przypadku dysków HDD, to jak sama nazwa wskazuje, sektory, które z jakichś przyczyn nie działają tak jak powinny. Doprowadza to z reguły do niestabilności systemu operacyjnego objawiającej się jego zawieszaniem w momencie próby odczytu danych z takiego padniętego sektora. Przyczyny mogą być różne. Zwykle jest to jednak fizyczne uszkodzenie powierzchni nośnika, np w wyniku wstrząsu, czy też zwyczajne zmęczenie materiału. Jest wielce prawdopodobne, że nie jesteśmy w stanie nic poradzić w tego typu sytuacji, a ci bardziej zaawansowani użytkownicy zalecają jak najszybszą wymianę dysku, bo pierwszy bad sektor oznacza, że niedługo będzie ich więcej. Czasem jednak błędy odczytu mogą być programowe, tj. fizycznie każdy sektor jest w porządku ale z jakiegoś powodu system nie potrafi odczytać z nich danych. Przy odrobinie szczęścia jesteśmy w stanie odblokować taki sektor.

Udało mi się znaleźć trochę informacji ma temat parametru S.M.A.R.T 198 , tj. Offline Uncorrectable . Wychodzi na to, że część dysków nie resetuje go, nawet po pomyślnym przejściu testu offline. Za to demon smartd domyślnie ma ustawione informowanie o niezerowej wartości tego atrybutu w logu systemowym i prawdopodobnie chyba nie da się nic zrobić w tej sprawie ale można poinstruować smartd by wyrzucał komunikat tylko w przypadku gdy wartość tego atrybutu zostanie zwiększona w stosunku do wartości zapisanej przy poprzednim skanowaniu, czyli jeśli teraz mamy wartość, np. 2, to ostrzeżenie pojawi się gdy będzie tam widniało 3 i więcej.

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.