Zapewne każdy użytkownik linux'a tworzył na dysku HDD/SSD partycje sformatowane systemem plików EXT4. Prawdopodobnie też zastanawiało nas pytanie odnośnie ilości zajmowanego miejsca przez strukturę samego systemu plików, zwłaszcza w przypadku dysków o sporych rozmiarach (setki GiB, czy nawet kilka TiB). Jako, że musiałem ostatnio zmigrować kolekcję filmów ze strych dysków na jeden większy, który miał zostać podłączony pod Raspberry Pi z działającym Kodi na bazie LibreELEC, to przy okazji postanowiłem ten dysk sformatować w taki sposób, w jaki powinno się do tego zadania podchodzić wiedząc, że ma się do czynienia z dużym dyskiem, na którym będą przechowywane głównie duże pliki. Celem tego artykułu jest pokazanie jakie błędy przy tworzeniu systemu plików EXT4 można popełnić przez posiadanie niezbyt wystarczającej wiedzy z jego zakresu, oraz jak te błędy wyeliminować przed rozpoczęciem korzystania z tak nie do końca poprawnie przygotowanego do pracy dysku twardego

Przeglądając ostatnio log systemowy, zauważyłem, że pojawia się w nim komunikat kernel: ENERGY_PERF_BIAS: Set to 'normal', was 'performance' . Co prawda korzystam z laptopa i cokolwiek związane z energią ustawione w trybie wydajności nie zawsze zdaje się być optymalnym rozwiązaniem ale też moja maszyna zwykle jest podpięta do źródła zasilania i przydałoby się, by była ona skonfigurowana właśnie bardziej w stronę profilu wydajności niż oszczędności energii. Ten powyższy komunikat informuje nas zaś, że system zmienił ustawienia z performance (tryb wydajności) na normal (jakiś bliżej nieokreślony tryb normalny). Chodzi naturalnie o ustawienia trybu pracy procesora Intel. Postanowiłem zatem poszukać informacji na temat tego czym jest ten cały Energy Performance Bias (EPB) i jak go skonfigurować w odpowiedni sposób pod linux.

Sporo użytkowników przeglądających tego bloga zdążyło już zauważyć, że sekcja komentarzy została usunięta. W efekcie czego nie można już komentować żadnych wpisów. Taki zabieg miał miejsce ze względu na fakt, że sporo osób zaczęło mi zgłaszać, że na Morfitroniku pojawiły się reklamy. Wszyscy znają raczej moje zdanie w kwestii serwowania ludziom reklam i mocno się zdziwiłem, że pojawiły się one właśnie tutaj. Ja nikomu żadnego pozwolenia na wykorzystywanie mojego bloga jako platformy reklamowej nie udzieliłem. Okazuje się jednak, że Disqus (bo to jego system komentarzy był tutaj wykorzystywany) nawet nie pofatygował się, by zapytać mnie o zgodę na serwowanie reklam i bezczelnie zaczął je w komentarzach umieszczać. Jak tylko się dowiedziałem, że te reklamy faktycznie w tych komentarzach są oraz, że nie mam żadnego wpływu na to, by je usunąć, to postanowiłem natychmiast wywalić Disqus'a.

Bawiąc się ostatnio drukarką laserową Hewlett Packard (HP) LaserJet P2055dn, zauważyłem, że ma ona wgrany dość stary firmware. Naturalnie sama drukarka do najmłodszych nie należy, bo została wyprodukowana w 2011 roku ale skoro na stronie producenta jest dostępna nowsza wersja oprogramowania dla tego urządzenia, to przydałoby się je do tej drukarki wgrać. Problem jednak pojawia się w przypadku takich osób jak ja, tj. tych, które korzystają w swoim środowisku pracy z maszyn mających na pokładzie system operacyjny z rodziny jakieś dystrybucji linux'a, np. Debian czy Ubuntu. Producent drukarki udostępnia stosowne narzędzia do aktualizacji firmware ale tylko i wyłącznie dla OS z gatunku Windows. Co mają zrobić osoby, które z Windows'a nie korzystają, a chciałyby przy tym mieć aktualny firmware w drukarkach HP? Możemy spróbować postawić maszynę wirtualną na bazie QEMU/KVM, tam zainstalować Windows'a i udostępnić w obrębie tej maszyny wirtualnej drukarkę, której firmware mamy zamiar aktualizować.

Parę tygodni temu moja leciwa już (20 letnia) drukarka atramentowa Epson Stylus Color 760 postanowiła odmówić współpracy i zaprzestała dalszego drukowania stron. Po rozkręceniu jej, okazało się, że ma ona w sobie tyle syfu (m.in. w okolicach dysz), że mechanizmy tej drukarki nie były już w stanie najwyraźniej tego doczyścić. Pomyślałem, że najwyższy już czas pozbyć się tej drukarki i poszukać jej następcy. W wytycznych kupna nowej drukarki były przede wszystkim cena (do 500 zł), bezproblemowa praca pod linux (Debian/Ubuntu) oraz możliwość pracy w sieci (preferowane WiFi) bez zaprzęgania do tego celu innych sprzętów, np. routera czy komputera stacjonarnego/laptopa. Wybór padł na poleasingową drukarkę laserową Hewlett Packard (HP) LaserJet P2055dn, ze względu na fakt, że posiada ona wszystkie te wyżej wymienione właściwości (no może poza WiFi) i można nią zarządzać bez większego problemu czy to przy pomocy dedykowanych narzędzi z pakietu hplip / hplip-gui , czy też bezpośrednio za sprawą CUPS.

Użytkownicy Androida do przeglądania serwisu YouTube używają z reguły tej dedykowanej aplikacji od Google. Problem z tą appką jest taki, że serwuje ona całą masę reklam, których to nie można wykroić stosując popularne rozwiązania na bazie Blokada czy AdAway. Niektórzy starają się korzystać z innych aplikacji pokroju NewPipe czy SkyTube ale one mają swoje ograniczenia, np. nie można pisać komentarzy czy też nie działają powiadomienia push. Kiedyś by rozwiązać ten problem reklam w appce YouTube korzystałem z Magisk'a i jego modułu YouTube Vanced ale to rozwiązanie od jakiegoś czasu nie jest już wspierane, choć w dalszym ciągu można z niego korzystać. Jako, że od paru miechów nie zaglądałem na stronę YouTube Vanced, to postanowiłem sprawdzić czy coś w tej kwestii się zmieniło. Wygląda na to, że jednak coś drgnęło, bo teraz dostępny jest Vanced Manager, który to jest w stanie tak skonfigurować nasz telefon, by aplikacja YT Vanced działała bez problemu nawet na nieukorzenionym Androidzie (nie trzeba mieć root'a). Możemy zatem zachować całą funkcjonalność serwisu YouTube pozbywając się przy tym reklam oraz segmentów sponsorowanych, no i też nie musimy nic kombinować z telefonem, tj. odblokowywać bootloader'a czy wgrywać TWRP. Problematyczne może być jednak zainstalowanie YouTube Vanced, bo czasami powiadomienia (notyfikacje push) mogą nam nie działać poprawnie. Właśnie dlatego postanowiłem napisać parę słów na temat instalacji tej aplikacji z wykorzystaniem Vanced Manager w Androidach bez root, by uniknąć tego jak i innych problemów.

Użytkownicy linux'a, którzy korzystają z mechanizmu wirtualizacji QEMU/KVM, wiedzą, że takie maszyny wirtualne potrafią zjadać dość sporo pamięci operacyjnej. Im więcej takich maszyn zostanie uruchomionych w obrębie danego hosta, tym większe ryzyko, że nam tego RAM'u zwyczajnie zabraknie. Można oczywiście ratować się dokupieniem dodatkowych modułów pamięci ale też nie zawsze taki zabieg będzie możliwy, zwłaszcza w przypadku domowych stacji roboczych pokroju desktop/laptop. Szukając rozwiązania tego problemu natrafiłem na coś, co nazywa się Kernel Samepage Merging. W skrócie, KSM to mechanizm, który ma na celu współdzielenie takich samych stron pamięci operacyjnej przez kilka procesów. W ten sposób można (przynajmniej teoretycznie) dość znacznie obniżyć zużycie RAM, zwłaszcza w przypadku korzystania na maszynach wirtualnych z tych samych systemów operacyjnych. Przydałoby się zatem ocenić jak bardzo KSM wpłynie na wykorzystanie pamięci i czy będzie z niego jakiś większy użytek zarówno przy korzystaniu z maszyn wirtualnych, czy też w codziennym użytkowaniu komputera.

Gdy chodzi o bezpieczeństwo danych przechowywanych na nośnikach pamięci masowych, takich jak dyski twarde, to użytkownicy linux'a często piszą sobie skrypty shell'owe mające na celu przeprowadzić backup całego nośnika lub też jego konkretnych plików/katalogów. Zwykle zaprzęgany jest do pracy rsync , który bez problemu jest w stanie zsynchronizować zawartość dwóch folderów (źródłowego i docelowego) i po tym procesie wołany jest także tar mający na celu skompresować pliki backup'u, tak by zajmowały mniej miejsca. Nie mam nic do tego rozwiązania, bo sam też przez lata z niego korzystałem ale ma ono całą masę wad. Przede wszystkim, ten mechanizm nie bierze pod uwagę zmian w samych plikach, czyli tworzy kopię tego co mu się poda i w taki sposób mamy wiele paczek .tar.gz , które zajmują sporo miejsca. Kolejną sprawą jest brak zabezpieczenia przed nieuprawnionym dostępem do plików kopii zapasowej, np. przy pomocy szyfrowania. W ten sposób trzeba posiłkować się zewnętrznymi rozwiązaniami, np. pełne szyfrowanie dysku za sprawą LUKS/dm-crypt, co nie zawsze jest możliwe i też bardzo komplikuje cały proces tworzenia kopii zapasowej, zwłaszcza na zewnętrznych nośnikach czy zdalnych hostach w sieci. Ostatnio jednak trafiłem na narzędzie BorgBackup, które to dość znacznie upraszcza cały proces tworzenia backup'u plików na linux, a takie cechy jak szyfrowanie, kompresja i deduplikacja danych są w borg zaimplementowane standardowo. Postanowiłem zatem zmigrować z mojego skryptowego systemu tworzenia kopii zapasowych na rzecz borg'a i spisać przy okazji te użyteczniejsze informacje dotyczące posługiwania się tym narzędziem

Przepisując ostatnio stare artykuły dotyczące zabezpieczenia zapytań DNS za sprawą wdrożenia na linux dnsmasq i dnscrypt-proxy, natknąłem się na informację, że nie tylko komunikacja DNS w obecnych czasach w sporej mierze nie jest zaszyfrowana. W zasadzie każda maszyna podłączona do internetu potrzebuje dysponować w miarę dokładnym czasem. By ten czas był dokładny, wymyślono mechanizm synchronizacji czasu przez wysyłanie zapytań do serwerów NTP (Network Time Protocol). Niemniej jednak, odpowiedzi z tych serwerów czasu nie są w żaden sposób zabezpieczone i praktycznie każdy na drodze tych pakietów może nam zmienić ustawienia czasu w systemie (MITM). W taki sposób możemy zostać cofnięci w czasie, co z kolei może oznaczać, że system zaakceptuje certyfikaty SSL/TLS czy też klucze/bilety sesji (używane do wznawiania sesji TLS), które już dawno temu wygasły lub/i zostały w jakiś sposób skompromitowane. Pchnięcie nas do przodu w czasie również oznacza problemy, bo możemy zaakceptować certyfikat, który jeszcze nie zaczął być ważny. To z kolei otwiera drogę do odszyfrowania połączeń z serwisami WWW, a przecie nie po to szyfrujemy ruch, by go ktoś bez większego problemu odszyfrował. Dlatego też powinniśmy zadbać o to, by informacje o aktualnym czasie otrzymywane z sieci docierały do nas z wiarygodnego źródła i były w jakiś sposób uwierzytelnione. Na Debianie standardowo do synchronizacji czasu wykorzystywany jest systemd-timesyncd ale nie wspiera on póki co protokołu NTS. Trzeba będzie zatem się go pozbyć i zastąpić go demonem ntpd z pakietu ntpsec .

Ostatnio na forum dug.net.pl jeden z użytkowników miał dość spory problem z ogarnięciem zadania polegającego na zaszyfrowaniu zapytań DNS z wykorzystaniem dnscrypt-proxy i dnsmasq. Ładnych parę lat temu opisywałem jak skonfigurować te dwa narzędzia na Debianie (i też na OpenWRT), choć od tamtego czasu w świecie linux'owym trochę rzeczy się pozmieniało. Dla przykładu, dnscrypt-proxy przeszedł gruntowną przebudowę, no i też systemd jest w powszechniejszym użyciu niż to miało miejsce w tamtych czasach, przez co w sporej części przypadków usługi takie jak systemd-networkd.service czy systemd-resolved.service są już włączone domyślnie. Zatem sporo informacji zawartych w tych napisanych przeze mnie artykułach już niekoniecznie może znaleźć obecnie zastosowanie. Dlatego też pomyślałem, że nadszedł już czas, by ździebko zaktualizować tamte wpisy. Ostatecznie stanęło jednak na tym, by w oparciu o te artykuły napisać kompletnie nowy tekst na temat szyfrowania zapytań DNS na linux przy wykorzystaniu oprogramowania dnscrypt-proxy oraz dnsmasq i zawrzeć w nim te wszystkie ciekawsze informacje, które udało mi się pozyskać przez te ostatnie lata w kwestii poprawy bezpieczeństwa i prywatności przy przeglądaniu stron WWW.