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.

Każdy z nas spotkał się już chyba w swoim życiu z systemami live. To taki wynalazek zawierający domyślne oprogramowanie, tak skonfigurowane, by system zdołał się odpalić na większość maszyn w ich pamięci operacyjnej, oczywiście zakładając, że wymagania sprzętowe zostaną zaspokojone, głównie chodzi o pamięć RAM. Takie systemy live są dostarczane w postaci kilku rodzajów obrazów: iso, hdd oraz hybryda. Pierwszy z nich zwykle wypala się na płytkach, drugi na pendrive, z kolei hybrydowy obraz można wgrać na każdy rodzaj urządzenia i nawet wykorzystać w przypadku maszyn wirtualnych i zwykle spotkamy się z tym ostatnim typem, nawet jeśli plik ma rozszerzenie .iso .

Każdy z nas dla wygody, albo raczej przez lenistwo, stara się nie używać zbyt skomplikowanych haseł. Zwykle też korzystamy z tego samego hasła do większości kont online w internecie. Jeśli zdarzyło nam się tworzyć proste, krótkie i do tego łatwe do przewidzenia hasła, np. w oparciu o datę urodzenia lub inne tego typu informacji, to przydałoby się nieco popracować nad zabezpieczeniami tych poufnych danych, tak by nie były proste do odgadnięcia czy też i złamania.

Jakiś czas temu opisywałem jak podejść do pisania reguł dla udev'a . W tamtym przypadku wykorzystywana reguła składała się tak naprawdę z dwóch mniejszych, z których jedna miała ustawioną zmienną ACTION na add , z kolei zaś druga na remove i w ten oto sposób pierwsza z nich była aplikowana podczas podłączania określonego urządzenia do komputera, a druga przy jego odłączaniu. Okazuje się jednak, że dwie reguły nie są konieczne w przypadku gdy mają one dotyczyć tego samego sprzętu i możemy zamiast nich stworzyć jedną regułę, która będzie stosowana zarówno przy podłączaniu jak i odłączeniu danego urządzenia.