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.

Jakiś już czas temu Mozilla ogłosiła, że Thunderbird od wersji 78 będzie posiadał natywne wsparcie dla szyfrowania wiadomości z wykorzystaniem kluczy GPG/PGP, przez co dodatek Enigmail będzie już zwyczajnie zbędny. Dziś z kolei czytam sobie o zakończeniu wsparcia dla wersji 68 tego klienta pocztowego, które będzie miało miejsce z końcem września 2020, czyli został już niespełna miesiąc i ta starsza wersja Thunderbird'a nie będzie już dostawać łat bezpieczeństwa. Pewne jest zatem, że dystrybucje linux'a w niedługim czasie pchną wersję 78 do głównych repozytoriów. W Debianie, wersja 78 Thunderbird'a od dłuższego czasu jest dostępna w gałęzi eksperymentalnej i można było ją już wcześniej sobie zainstalować, jeśli ktoś wyrażał taką chęć. Gdy ja ostatni raz testowałem wersję 78, to nie była ona zbytnio do użytku ale wygląda na to, że większość niedogodności, których mi się udało doświadczyć, została już wyeliminowana. Pozostał w zasadzie jeden problem, tj. Thunderbird domyślnie używa własnego keyring'a kluczy GPG/PGP, w efekcie czego systemowy GPG/GnuPG nie jest w ogóle wykorzystywany. Taki san rzeczy sprawia, że będziemy mieć dwie różne bazy danych kluczy (jedna dla Thunderbird'a, a druga dla reszty linux'a), co może trochę irytować. Na szczęście jest opcja wymuszenia na TB, by korzystał on z systemowego keyring'a kluczy GPG/PGP i celem tego artykułu jest pokazanie właśnie jak tego typu zabieg przeprowadzić.

Parę dni temu na forum dug.net.pl pojawiło się zapytanie dotyczące skonfigurowania linux'a w taki sposób, by ten umożliwił pojedynczemu procesowi w systemie (i tylko jemu) korzystanie z VPN, podczas gdy wszystkie pozostałe aplikacje korzystają ze standardowego łącza internetowego naszego ISP. Oczywiście to niekoniecznie musi być tylko jeden proces, bo to zagadnienie można rozciągnąć też na większą grupę procesów jednego lub więcej użytkowników. By to zadanie zrealizować, trzeba zdać sobie sprawę z faktu, że każdy proces w linux ma swojego właściciela, a ten właściciel przynależy do co najmniej jednej grupy. Dzięki takiemu rozwiązaniu, każdy proces w systemie ma przypisany m.in. identyfikator użytkownika (UID) oraz identyfikatory grup (GID), z którymi działa i na podstawie których to linux przyznaje uprawienia dostępu do różnych części systemu, np. urządzeń czy plików na dysku. W ten sposób możemy bardzo prosto ograniczyć dostęp do określonych zasobów konkretnym użytkownikom (bardziej ich procesom). Problem się zaczyna w przypadku sieci, gdzie w zasadzie dostęp do internetu ma domyślnie przyznany każdy proces. Naturalnie możemy skonfigurować filtr pakietów i zezwolić tylko części aplikacji na dostęp do sieci ale w dalszym ciągu, gdy tylko odpalimy VPN (w tym przypadku OpenVPN), to każdy proces mający prawo wysyłać pakiety sieciowe będzie je przesyłał z automatu przez VPN, jak tylko to połączenie zostanie zestawione. Istnieje jednak sposób, by nauczyć linux'a aby tylko procesy określonych użytkowników czy grup miały dostęp do VPN i gdy to połączenie zostanie zerwane, to te procesy nie będą mogły korzystać ze standardowego łącza internetowego. Trzeba jednak zaprzęgnąć do pracy iptables / nftables , tablice routingu oraz nieco inaczej skonfigurować klienta OpenVPN.

Do konfiguracji systemu LibreELEC, który jest zainstalowany na moim Raspberry Pi 4B nie potrzebuję żadnego monitora czy wyświetlacza, a wszystkie prace administracyjne związane z tym małym komputerem ogarniam po SSH. Niemniej jednak, są pewne rzeczy, których się po SSH nie da skonfigurować. Chodzi generalnie o konfigurację Kodi i sprawy związane z domowa wideoteką. Ten Raspberry Pi 4B jest podłączony do TV, zatem bez problemu można przez graficzny interfejs Kodi skonfigurować to, co potrzeba. Niemniej jednak konfigurowanie Kodi przez aplikację na Androida (Kore) nie należy do najłatwiejszych zadań. Nie uśmiecha mi się też ciągle latać z myszą i klawiaturą w celu podłączania ich do portów USB maliny. Nie mam też w zasadzie zewnętrznego monitora HDMI, bo od lat używam jedynie laptopów. Pomyślałem zatem, by zrobić użytek z protokołu VNC/SPICE i przesłać obraz z Raspberry Pi 4B przez sieć do mojego laptopa. W ten sposób odpadłoby mi ciągłe przemieszczanie się między pokojami i byłbym w stanie podejrzeć obraz TV na ekranie monitora w moim laptopie przy jednoczesnym zachowaniu możliwości używania myszy i klawiatury, co by mi bardzo zaoszczędziło czas przy konfiguracji Kodi.

Parę lat temu, gdy pojawił się u mnie w domu bezprzewodowy router WiFi, postanowiłem wgrać na niego linux'a w postaci OpenWRT. Pierwszym kluczowym elementem konfiguracyjnym tego urządzenia było przesłanie jego logów systemowych przez sieć do mojego laptopa, tak by wszystkie zarejestrowane komunikaty zostały wyświetlone na konsoli mojego komputera z zainstalowanym Debianem. W ten sposób nie musiałem się co chwila logować na router po SSH (czy też przez panel webowy), by sprawdzić czy aby na pewno z tym urządzeniem jest wszystko w porządku. Teraz, po nabyciu Raspberry Pi 4B i wgraniu na niego LibreELEC z preinstalowanym Kodi, mam dokładnie to samo zadanie do zrealizowania. Trzeba zatem znaleźć sposób na przesłanie wszystkich logów generowanych przez system LibreELEC do demona rsyslogd , który jest uruchomiony na zdalnej maszynie.

Po paru dniach zabawy z LibreELEC na Raspberry Pi 4B mogę powiedzieć, że ten system ma w zasadzie wszystko to, co jest potrzebne przy zabawie z Kodi/XBMC i przerabianiu maliny na domowe centrum multimediów. Niestety jednak, w moim przypadku pojawił się jeden problem, który dotyczył montowania zasobów (konkretnie dysku HDD). Chodzi generalnie o to, że LibreELEC nie umożliwia zdefiniowania własnych punktów montowania i opcji dla tych punktów. W ten sposób wszystkie dyski USB podłączone do Raspberry Pi 4B będą działać w trybie do zapisu. Teoretycznie LibreELEC (czy Kodi) nie powinien nic na tych dyskach zapisywać sam z siebie. Niemniej jednak, system plików NTFS działający w trybie do zapisu na maszynie z linux, która nie ma podłączonego żadnego UPS'a, budzi u mnie lekki dyskomfort psychiczny. Chciałem zatem swój dysk zamontować w trybie tylko do odczytu ale polityka LibreELEC na to domyślnie nie pozwala, co nie znaczy oczywiście, że tego zadania się nie da zrealizować.