Jakiś już dłuższy czas temu opisywałem mechanizm przekierowania ruchu sieciowego jednego lub wybranych procesów do VPN na przykładzie OpenVPN pod moim Debianem. Zawarta w tamtym artykule konfiguracja jak najbardziej działa do tej pory, choć minęło już prawie 6 lat od jej wdrożenia w życie. Od tamtego momentu jednak, sporo się zmieniło w świecie linux'a, a konkretnie pojawił się wireguard, który jest nieco bardziej dostosowany do otaczającej nas rzeczywistości i kładzie na łopatki wysłużonego już OpenVPN. Nie mam nic do OpenVPN ale przydałoby się zrobić podobne rozwiązanie opisane w powyżej podlinkowanym artykule ale na przykładzie właśnie wireguard. Samo skonfigurowanie do pracy VPN na bazie wireguard jest w zasadzie dość proste i nie trzeba pisać kolejnego artykułu na ten temat. Niemniej jednak, stawiając VPN w opisany na stronie wireguard sposób będziemy przesyłać przez to połączenie cały ruch sieciowy, czego raczej nie chcemy. To tutaj właśnie zaczynają się problemy z wireguard, których w OpenVPN nie szło zaobserwować, a które uniemożliwiają poprawne działanie (zapętlanie się) połączenia VPN. Postaramy się zatem przyjrzeć nieco bliżej samej konfiguracji wireguard i spróbować sprawić, by ruch sieciowy tylko wybranych przez nas procesów był kierowany w tunel VPN.

Jakiś już czas temu naskrobałem kawałek artykułu na temat mechanizmu Trim/discard w kontekście LUKS/LVM na dysku SSD pod Debian linux, przy okazji poruszając tam kwestie nieco daleko idącej optymalizacji systemu pod kątem przedłużenia żywotności tego typu dyskom opartym o technologię flash. Opisane w tym powyższym artykule zabiegi sprawiły, że zapis danych na tym dysku systemowym waha się w okolicy 3 GiB na dzień (średnia za rok 2024 i 2025). Gdyby ten stan rzeczy utrzymać, to ten dysk SSD posłużyłby jeszcze przez około 160 lat i taka żywotność nośnika SSD mnie jak najbardziej zadowala... Przez te dwa ostatnie lata tylko kilka aplikacji chciało zapisywać ogromne ilości danych na dysku systemowym bez wyraźnej przyczyny, np QuiteRSS, a tak poza tym, to ten dysk SSD nie wykazywał większych odchyłów od normy w kwestii zapisu danych. Niestety ten stan rzeczy uległ zmianie kilka dni temu. Szukając przyczyny udało się zawęzić krąg podejrzanych do przeglądarki Firefox (ewentualnie też Google Chrome i Chromium). Okazało się, że jeden z jej dodatków, a konkretnie Video DownloadHelper (VDH), z jakiegoś powodu zapisuje ogromne ilości danych w katalogu profilu tej przeglądarki (tj. w ~/.mozilla/firefox/ ). Pobierając dużo materiałów audio/video, np. z YouTube czy CDA, bardzo szybko nam taki dysk SSD padnie i to bez znaczenia czy docelowy katalog zapisu pobranych danych z internetu mamy ustawiony, np. na osobnym dysku HDD. Czy istnieje zatem jakiś sposób, który by powstrzymał dodatek Video DownloadHelper od zniszczenia nam dysku SSD?

Od wielu lat próbowałem rozstać się z moją leciwą już klawiaturą Logitech Media Keyboard Elite, która działała u mnie od początków przesiadki na linux'a, czyli ponad 15 lat. Nic tej klawiaturze nie dolega i dalej sprawnie działa ale ma jedną cechę, której nie da się wyeliminować. Mianowicie jest ona przewodowa. Przez te wszystkie lata próbowałem znaleźć klawiaturę bezprzewodową ale nie dało się. Takie klawiatury kosztowały blisko 500-1000zł, a te tańsze były pod względem jakości typowo chińskie. Do tego doszła nowa technologia komplikująca niesamowicie budowę klawiszy, przez co te klawiatury praktycznie są nierozbieralne, np. na potrzeby czyszczenia. Nie wiem ile razy przez te prawie 20 lat czyściłem mojego Logitech'a (kompletne rozkręcenie i powyciąganie klawiszy) ale obstawiam, że co najmniej kilkanaście razy (średnio raz do roku). Z przycisków nawet jedno oznaczenie się nie starło. Dlatego też miałem ogromne problemy znaleźć coś bezprzewodowego, w miarę taniego, co by mi posłużyło kolejne dwie dekady. Gdy straciłem już wiarę w producentów klawiatur, udało mi się za 50zł dorwać klawiaturę (używaną) od Logitech. Jest to model Logitech K350, który jest bardzo podobny do tej mojej starej klawiatury, z tą różnicą że jest on bezprzewodowy. Do tej klawiatury jest dostarczony odbiornik Logitech Unifying i całość w zasadzie działa bezproblemowo na moim Debianie, choć trzeba było parę rzeczy skonfigurować. Nie obyło się także bez aktualizacji firmware w tym odbiorniku, bo czynił on to urządzenie podatne na atak typu MouseJack.

Każdy z nas korzysta z całej masy aplikacji na swoich linux'ach. Na ogół te appki działają w sposób oczekiwany i nie ma z nimi większych problemów. Czasem jednak zdarza się tak, że z jakiegoś powodu taki program niespodziewanie kończy swoje działanie i w konsoli (czy logu systemowym) zostaje wydrukowany komunikat zawierający frazę segfault (segmentation fault, naruszenie ochrony pamięci). Ostatnio taki problem dotknął jedną z moich ulubionych aplikacji, z których korzystam na co dzień, tj. strawberry . Gdyby ta sytuacja wystąpiła raz, to pewnie nawet bym się nią bardziej nie zainteresował ale w tym przypadku ten cały segfault potrafił wyskoczyć kilka-kilkanaście razy w ciągu godziny, co trochę zaczęło mnie irytować. Postanowiłem poszukać przyczyny i nawet znalazłem stosowny bug na git projektu strawberry, no ale sytuacja niby nowa, a mi ta appka crash'owała od dobrych kilku tygodni, jeśli nie miesięcy. Dlatego też zacząłem udzielać się w tamtym wątku i przy okazji nauczyłem się jak przy pomocy gdb (GNU Debugger) pozyskać nieco bardziej użyteczne informacje i podesłać je deweloperowi aplikacji, tak by był on w stanie namierzyć przyczynę i wyeliminować zaistniały problem. W tym artykule została zebrana garść użytecznych informacji, które mogą przydać się użytkownikowi Debiana, na wypadek gdyby i jego aplikacje cierpiały na podobne problemy.

Jakiś czas temu opisywałem jak na Debianie włączyć obsługę mechanizmu TRIM (realizowanego przez polecenie fstrim ) na podpiętych do komputera dyskach SSD. Problem w tym, że dyski SSD, z którymi będziemy wchodzić w interakcję, nie zawsze będą podłączane do dedykowanych portów SATA/mSATA. Jak zachowa się zatem nasz linux, gdy będziemy chcieli podłączyć po portu USB zewnętrzny dysk SSD? Przez zewnętrzny dysk USB nie mam na myśli dedykowanych zewnętrznych dysków USB, bo te raczej nie powinny sprawiać kłopotów. Chodzi mi bardziej o wewnętrzne dyski SSD (np. ze starego laptopa), które zamkniemy w dedykowanej obudowie USB, lub też będziemy taki dysk podłączać na krótko za pomocą adaptera USB-SATA. W takich przypadkach zwykle kernel linux'a nie odważy się włączyć wsparcia dla TRIM dla nośników SSD i tak właśnie się stało w przypadku mojego nowo zakupionego dysku od Goodram, a konkretnie jest to model SSDPR-CX400-02T-G2 , który to został podłączony do portu USB3 mojego Raspberry PI (i Debiana) przy pomocy kabelka USB-SATA (Unitek USB3.1 USB-A to 2.5" SATA6G). Przez kilka miesięcy dysk sprawował się bez zarzutu ale ostatnio przy próbie wgrania na niego danych (przez sieć), transfer spadł do dosłownie pojedynczych MiB/s. Poszukałem trochę informacji i okazało się, że dla tego typu nośników trzeba ręcznie włączyć TRIM, o ile będzie to w ogóle możliwe.

Z racji, że w mojej sieci domowej pojawia się coraz więcej maszyn, które mają na pokładzie różne systemy operacyjne (począwszy od linux'ów, przez androidy, a na windows'ach skończywszy), to postanowiłem w końcu wypracować jakiś w miarę uniwersalny sposób na dzielenie się plikami w tej sieci LAN. Rozwiązania pokroju SSH/SSHFS są w porządku ale jedynie w przypadku linux'ów. Serwery HTTP/FTP są trochę mało poręczne i słabo się nadają do tego celu. Z kolei NFS miał u mnie jakieś większe/mniejsze problemy z wydajnością, a i też nie wiem jak wygląda wsparcie dla NFS na windows. W zasadzie to pozostała mi ostatnia opcja w postaci protokołu CIFS/SMB/SAMBA, który przynajmniej na windows powinien działać bez zarzutu. Trzeba jednak będzie przystosować mojego Debiana do pracy z tym protokołem. Chodzi generalnie o to, by bez większego problemu być w stanie udostępnić z jednej maszyny kilka katalogów innym użytkownikom sieci domowej i to bez znaczenia czy robimy to z windows'a i docelowo siedzimy na linux'ie, czy też w drugą stronę, tj. udostępniamy katalogi z linux'a, by być w stanie przeglądać ich zawartość na windows. Wdrożenie obsługi protokołu CIFS/SMB/SAMBA na linux jest stosunkowo proste, bo wystarczy zainstalować pakiet samba , wydać w terminalu kilka poleceń i po sprawie. Problem jednak zaczyna się, gdy chcemy sobie nieco ułatwić życie, tak by w menadżerze plików (np. nemo , caja , pcmanfm ) te wszystkie zasoby były z automatu widoczne po przejściu do zakładki sieć/network. Pozostają też do rozważenia kwestie związane z bezpieczeństwem tego całego mechanizmu wymiany plików.

W obecnych czasach, rola przestrzeni wymiany w zasadzie ograniczyła się z grubsza do umożliwienia nam przeprowadzenia procesu hibernacji. Inne aspekty pracy systemu, w których SWAP brał udział zostały albo zepchnięte na margines (bardzo stare maszyny z niewielką ilością RAM), albo zupełnie wyeliminowane za sprawą nowszych technologi lub/i posiadania większej ilości pamięci operacyjnej w takich systemach. Obecnie domowy komputer z 32 GiB pamięci RAM to nic niezwykłego i przestrzeń wymiany na takich maszynach nie jest już nam w zasadzie do niczego potrzebna, bo raczej jest mało prawdopodobne, że nam tej pamięci zabraknie przy codziennym użytkowaniu naszego linux'a. Niemniej jednak, hibernacja systemu jest czymś pozytywnym z perspektywy użytkownika, bo umożliwia mu zapisanie stanu pracy przed wyłączeniem komputera i odtworzenie tego stanu po ponownym uruchomieniu systemu. Jeśli chcielibyśmy się cieszyć urokami hibernacji, to bez konfiguracji SWAP'a się nie obejdzie. Problem jednak zaczyna się, gdy mamy dysk SSD i taka przestrzeń wymiany zostanie na nim skonfigurowana. Chodzi generalnie o pewne aplikacje, które są w stanie generować bardzo dużo cache w pamięci operacyjnej, czego efektem będzie przenoszenie danych z RAM do SWAP, a to może bardzo szybko wykończyć taki nośnik flash. Dlatego też przydałoby się nieco zabezpieczyć przestrzeń wymiany przed tego typu sytuacjami, tak by można było jej używać jedynie w przypadku hibernacji.

Z okazji zbliżającego się końca roku, postanowiłem nieco ogarnąć swojego Debiana, tj. postawić go na nowo. Jakby nie patrzeć 4 lata korzystania z tego linux'a z włączonymi gałęziami unstable i experimental sprawiło, że trochę syfu się nazbierało. Nie chciałem też czyścić całego kontenera LUKS czy samej struktury LVM z systemowymi voluminami logicznymi na starym dysku HDD, bo zainstalowany tam system zawsze może się do czegoś przydać, np. do odratowania tego nowego linux'a. Dlatego też postanowiłem zakupić niedrogi dysk SSD (MLC, używany) i to na nim postawić świeżego Debiana z wykorzystaniem narzędzia debootstrap. Sama instalacja linux'a na dysku SSD nie różni się zbytnio od instalacji na dysku HDD, za wyjątkiem skonfigurowania w takim systemie mechanizmu trim/discard. Standardowi użytkownicy linux'a nie muszą zbytnio nic robić, aby ten mechanizm został poprawnie skonfigurowany. Sprawa się nieco komplikuje, gdy wykorzystywany jest device-mapper, który mapuje fizyczne bloki urządzenia na te wirtualne, np. przy szyfrowaniu dysku z wykorzystaniem LUKS/dm-crypt, czy korzystaniu z voluminów logicznych LVM. Dlatego też postanowiłem przyjrzeć się nieco bliżej zagadnieniu konfiguracji mechanizmu trim/discard na dysku SSD w przypadku zaszyfrowanego systemu na bazie LUKS+LVM.

Przeglądając ostatnio stronę xiaomifirmwareupdater.com zauważyłem, że jest tam dostępna nowsza wersja firmware dla mojego telefonu Xiaomi Redmi 9 (lancelot/galahad). Patrząc po numerkach V13.0.1.0.SJCEUXM (nowy dla Android 12) oraz V12.5.4.0.RJCEUXM (stary dla Android 11), miałem pewne wątpliwości czy wgrać sobie ten nowszy firmware. Niby na tym smartfonie mam wgrany ROM crDrdoid v8.9, który dostarcza Androida 12.1, więc aktualizacja firmware sposobem opisanym tutaj powinna przebiec bez żadnych problemów. No i przebiegła, tylko po zrestartowaniu telefonu, ten już się nie uruchomił. Działał mi jedynie tryb fastboot (normalny boot i tryb recovery były martwe). Postanowiłem przywrócić poprzedni firmware wydobywając obrazy ze starej paczki firmware i ręcznie przy pomocy narzędzia fastboot wgrać te obrazy na odpowiadające im partycje w telefonie z poziomu mojego Debiana. Tutaj jednak zostało poczynionych parę błędów (o tym później), które doprowadziły do całkowitego uwalenia telefonu (hard brick), gdzie nawet tryb fastboot zdechł. W efekcie telefon już nie reagował na żadne kombinacje przycisków, a ekran pozostawał czarny -- jednym słowem nie działał żaden tryb pracy telefonu i wyglądało na to, że mam w łapkach już tylko sam złom elektroniczny i tak by w istocie było, gdyby z pomocą nie przyszedł mi SP Flash Tool.

Kernele oferowane przez różne dystrybucje linux'a, np. Debian czy Ubuntu, są tak budowane by możliwie jak największa ilość sprzętu na takim jądrze operacyjnym nam zadziałała bez zbędnego przerabiania systemu. Takie podejście sprawia, że nowo nabyty przez nas sprzęt możemy od razu podłączyć do komputera, a stosowne moduły po rozpoznaniu urządzenia zostaną załadowane do pamięci operacyjnej, przez co my będziemy mogli wejść w interakcję z takim kawałkiem elektroniki. Problem w tym, że kernel ma bardzo dużo tych modłów. Dużo modułów, to więcej kodu, a więcej kodu to więcej błędów, które na poziomie jądra mogą być bardzo opłakane w skutkach. Z zagrożeniem, jakie niosą moduły zewnętrzne (te spoza drzewa kernela linux), można sobie poradzić podpisując kernel kluczami od firmware EFI/UEFI. W takim przypadku załadowanie niepodpisanego modułu już się nie powiedzie. Niemniej jednak, dystrybucyjne kernele mają całą masę modułów do różnorakiego sprzętu, które na etapie budowania kernela są podpisywane, co otwiera im drogę do bycia załadowanymi w naszym systemie nawet jeśli nie posiadamy urządzeń, które by użytek z tych modułów robiły. Przydałoby się zatem zabezpieczyć możliwość ładowania modułów kernela w taki sposób, by jedynie administrator systemu miał możliwość określenia jakie moduły i na którym etapie pracy systemu mogą one zostać załadowane.