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 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.

Od już dłuższego czasu (będzie parę lat) korzystam z internetu LTE zamiast tradycyjnego połączenia przewodowego. Głównie ze względu na fakt, że w mojej okolicy nie ma praktycznie żadnych szanujących się ISP, z którymi warto by wejść w interakcję i podpisać z nimi jakąś sensową umowę. Poza tym, dla osób mojego pokroju, które cenią sobie mobilność, internet stacjonarny i tak jest mało praktyczny. Dlatego w moim domowym routerze mam wgrany firmware OpenWRT umożliwiający zainstalowanie na tym urządzeniu odpowiedniego oprogramowania obsługującego modemy LTE podłączane przez port USB. Połączenie sieciowe ze światem zwykle działa prawidłowo ale z jakiegoś powodu jest ono zrywane. Zwykle taka sytuacja ma miejsce w środku nocy (czasami parokrotnie), zwłaszcza gdy przekroczę limit danych i do końca okresu rozliczeniowego muszę przemęczyć się z lejkiem 1 mbit/s. Gdy ten lejek jest aplikowany, to zwykle odpalam sobie torrent'a, tak by pobrać najnowsze obrazy ISO tej czy innej dystrybucji linux'a. Niemniej jednak, jak mi net rozłączą, to nie załączy się on ponownie sam z siebie. Modem Huawei E3372s-153 w wersji NON-HiLink zdaje się pracować poprawnie, bo świeci się na nim dioda sugerująca, że połączenie z internetem jest nawiązane. Dlatego też postanowiłem w końcu ten problem rozwiązać raz na zawsze i mieć przy tym nieco spokojniejszy sen.

Parę dni temu na jednych z forów, które czasem odwiedzam, pojawił się wątek dotyczący problemu jaki może nieść ze sobą budzenie linux'a ze stanu uśpienia/wstrzymania (Suspend to RAM, STR) za sprawą myszy. O ile w przypadku klawiatury sprawa wybudzania komputera zdaje się być dość oczywista, to w przypadku tego małego gryzonia już niekoniecznie, bo wystarczy lekko mysz przemieścić po blacie stołu czy innego biurka i system się nam wybudzi. Część komputerów ma stosowne opcje w BIOS/UEFI i można za ich sprawą skonfigurować to jakie urządzenia będą mieć możliwość wybudzania systemu. Niekiedy jednak, opcje w BIOS są tak ubogie, że nie mamy możliwości skonfigurowania tego aspektu pracy naszej maszyny. Trzeba zatem w nieco inny sposób podejść do tego zagadnienia. Na necie można się spotkać z radami odnośnie zapisu pliku /proc/acpi/wakeup przez przesłanie do niego czteroznakowych kodów, np. EHC1 czy USB1 . Takie rozwiązanie może nieść ze sobą negatywne konsekwencje i powinno się go unikać. Lepszym rozwiązaniem jest napisanie reguły dla UDEV'a dla konkretnego urządzenia, gdzie będziemy mogli łatwo sterować (przez plik power/wakeup ) tym czy dane urządzenie ma mieć możliwość wybudzania systemu czy też nie.

Jeszcze nie tak dawno temu przeciętnej klasy desktop był wyposażony w pojedynczy i do tego niewielkiej pojemności dysk twardy, który był w stanie pomieścić wszystkie pliki swojego właściciela. Obecnie jednak większość maszyn ma tych nośników już kilka. Mowa tutaj nie tylko o dyskach systemowych, które są fizycznie na stałe zamontowane w komputerze ale również o tych wszystkich urządzeniach, które można podłączyć do portu USB. Polityka linux'a wymusza, by wszystkie nośniki pamięci masowej (HDD, SSD, pendrive czy też karty SD) były montowane w systemie jedynie przez użytkowników posiadających uprawnienia administratora. Domyślnie taki przywilej ma jedynie root. Zatem by uzyskać dostęp do danych na takim zewnętrznym nośniku musimy logować się na root'a. Jakby nie patrzeć ma to swoje plusy patrząc z perspektywy bezpieczeństwa, niemniej jednak czy naprawdę potrzebny nam jest root do wgrania czegoś na nasz ulubiony pendrive? Widać nie tylko ja zadawałem sobie takie pytanie i ktoś postanowił stworzyć narzędzie UDisks (lub jego nowszą wersję UDisks2), które za pomocą mechanizmu PolicyKit (zwanym też PolKit) jest w stanie nadać stosowne uprawnienia konkretnym użytkownikom systemu, przez co można określić zespół akcji, które będą oni w stanie przeprowadzić bez potrzeby podawania hasła, np. montowanie czy odmontowanie zasobu. Postanowiłem zatem zobaczyć jak ten duet sobie radzi na moim Debianie przy tradycyjnym użytkowaniu systemu i ocenić jego stopień przydatności.

Ostatnio na Niebezpieczniku pojawił się artykuł na temat niezbyt przyjaznych urządzeń podłączanych do komputera za sprawą portów USB (opisanych na przykładzie niepozornego przewodu) i tego jaką szkodę tego typu hardware może nam wyrządzić w systemie. Ataki z wykorzystaniem podstawionych urządzeń zadziałają nawet na linux, choć pewnie cała masa użytkowników wyznaje jeszcze mit, że ich komputer jest bezpieczny, bo przecie używają alternatywnego systemu operacyjnego, który jest OpenSource i za priorytet obrał sobie szeroko rozumiane bezpieczeństwo. Niestety nie jest tak różowo jakby mogło się co niektórym wydawać ale można ten stan rzeczy naturalnie zmienić i nie trzeba przy tym rekompilować kernela z zamiarem wyłączenia obsługi modułu USB, co ten opisany w podlinkowanym artykule atak oczywiście by również powstrzymało. Zamiast tego możemy zainstalować sobie narzędzie usbguard i przy jego pomocy skonfigurować politykę podłączanych do portów USB urządzeń.

System Android w większej lub mniejszej części zmienia się z wydania na wydanie. Te nowsze wersje zwykle zawierają całą masę nowych mechanizmów i rozbudowują te już istniejące, tak by ten OS w lepszym stopniu zaspokajał zachcianki użytkowników smartfonów. Problem w tym, że niektóre kroki deweloperów Androida potrafią wprawić w zastanowienie niejednego logicznie myślącego osobnika. Przykładem może być przestawienie domyślnego trybu USB w Marshmallow z MTP na Charge-Only (tylko ładowanie). Jedni mówią, że takie posunięcie jest podyktowane względami bezpieczeństwa, a inni, że chodzi o performance przy ładowaniu baterii, gdzie moduł USB nie działa w tym drugim trybie i nie konsumuje energii, przez co ładowanie ma przebiegać szybciej. Ile w tym prawdy, tego nie wiem ale ja za bardzo nie widzę żadnych wymiernych korzyści z przestawienia tego trybu na Charge-Only. Natomiast widzę bardzo wyraźnie utrudnienia przy interakcji telefonu z komputerem za sprawą tej zmiany. Poszukałem trochę informacji na ten temat i znalazłem rozwiązanie w postaci aplikacji MTP enabler.

Jakiś czas temu opisywałem kartę sieciową na USB UE200 od TP-LINK. Taki adapter jest bardzo przydatny w momencie, gdy nie posiadamy z jakiegoś powodu standardowej karty sieciowej, tak by za jej sprawą przewodowo połączyć komputer do domowej sieci. Jeden z moich komputerów cierpi właśnie na tego typu przypadłość z powodu jakiegoś bliżej nieznanego mi uszkodzenia jego wbudowanej karty sieciowej. Generalnie rzecz biorąc w ofercie TP-LINK poza tym wspomnianym UE200 jest także dostępny adapter UE300, który różni się głównie tym, że ma gigabitowy port Ethernet oraz karta jest na USB 3.0. Jako, że jestem w posiadaniu adaptera UE300, to postanowiłem sprawdzić jak (i czy w ogóle) jest rozpoznawany przez system z rodziny linux, a konkretnie na dystrybucji Debian, której używam na co dzień.

Każdy z nas słyszał o alternatywnym firmware na bezprzewodowe routery WiFi. Mam tutaj na myśli oczywiście OpenWRT/LEDE oraz jego GUI Gargoyle i LUCI. Przy zabawach z takim oprogramowaniem bardzo łatwo jest uszkodzić router w sytuacji, gdy tak na dobrą sprawę nie wiemy co robimy. Mi się jeszcze nie zdarzyło ubić żadnej z moich maszyn, a mam ich kilka. Problem w tym, że tak naprawdę nie wiem jak wygląda proces odzyskiwania routera w przypadku zaistnienia takiego złego scenariusza. Dlatego też postanowiłem zainicjować zdarzenie, które doprowadziło do ubicia systemu w moim TL-WR1043ND V2 od TP-LINK. Co zrobić w takim przypadku, gdy system routera nie chce wystartować, a na obudowie diody sygnalizują nieprawidłową pracę urządzenia? W takiej sytuacji będziemy musieli rozebrać sprzęt i podłączyć się do portu szeregowego na PCB za pomocą adaptera USB-UART, najlepiej na układzie CP2102, który bez problemu działa pod linux. Ten artykuł nie powstałby (tak szybko), gdyby nie pomoc ze strony @Heinz.

Czasami bardzo dziwne rzeczy mogą się przytrafić naszym komputerom. Kilka tygodni temu, z niewiadomych przyczyn port ethernet w moim laptopie zwyczajnie zamarł. Linux go nie rozpoznaje i nie da rady za jego pośrednictwem podłączyć się do sieci. Można oczywiście skorzystać z WiFi ale w pewnych sytuacjach ta opcja odpada i zostaje nam jedynie łącze przewodowe. Tak się składa, że mam na wyposażeniu adapter UE200 od TP-LINK. Jest to karta sieciowa mająca z jednej strony gniazdko ethernet, z drugiej zaś złącze USB, dzięki któremu łatwo tę kartę można podłączyć do komputera. Pytanie tylko jak taka sieciówka na USB zachowa się pod linux'em. W tym wpisie obadamy sobie właśnie tę kwestię.