3 rzeczy w Debianie, których nie aktualizujesz.

Jeśli korzystasz z systemu Debian, to zapewne przywykłeś do wygodnej sytuacji, że aktualizacje zwykle przychodzą w repozytorium security. Jest to wygodne, bo proste apt-get update; apt-get upgrade teoretycznie zapewnia aktualne wersje wszystkich pakietów w systemie, z aktualizacjami bezpieczeństwa. Prawda?

Niestety, nie do końca. Po pierwsze, sama instalacja aktualnych wersji pakietów nie zawsze oznacza, że automatycznie zaczynają być one używane. Pomijając kernel, którego faktyczna aktualizacja wiąże się z rebootem, także inne programy niekoniecznie zaczynają być używane automatycznie w aktualnej wersji po ich instalacji. W określeniu programów do restartu przydatne bywa polecenie checkrestart z pakietu debian-goodies, o którym pisałem w ściągawce z przydatnymi poleceniami dla Linuksa. Ogólnie: próbuje ono podać procesy, których restart jest wymagany ze względu np. na aktualizację bibliotek.

Ale i to nie wszystko. Jest kilka innych rzeczy, które nie aktualizują się, mimo zainstalowanych paczek, które spowodowały ich obecność w systemie:

  1. Flash od Adobe. Popularny na desktopach, spaczkowany – w specyficzny sposób – w Debianie w pakiecie flashplugin-nonfree, przy okazji podobno popularny wektor ataku. Aktualność swojej wersji Flasha można sprawdzić na stronie Flash Player check. Jakoś wolę ten sposób od strony Adobe. Aby zaktualizować wersję w systemie należy wydać polecenie:
    update-flashplugin-nonfree --install --verbose

    Oczywiście po powyższym trzeba zrestartować przeglądarki, żeby zmiana była efektywna.

  2. Java od Sun. Ze względu na zmianę polityki, niedawno Java od Sun przestała być aktualizowana, również w zakresie aktualizacji bezpieczeństwa w Debianie i Ubuntu. Jeśli nadal korzystasz z niej w systemie, jest spora szansa, że masz starą wersję, o której aktualizację musisz zadbać samodzielnie. Można też zmienić wersję na którąś z wolnych alternatyw.
  3. Mikrokod procesora. Jeśli posiadasz procesor Intela, to dostępne są aktualizacje mikrokodu od producenta. Co prawda bez tego też będzie działać, ale może udało się poprawić coś, co zwiększy wydajność? Sama instalacja pakietu microcode.ctlnie wystarczy, by zawsze mieć aktualną wersję zainstalowaną i wykorzystywaną w systemie. Aktualizację obecnego w systemie mikrokodu można wywołać ręcznie poprzez polecenie:
    update-intel-microcode

    Potem można przeładować mikrokod przy pomocy:

    /etc/init.d/microcode.ctl restart

    Począwszy od wersji Wheezy niestety jest to nieco bardziej skomplikowane i aktualizację mikrokodu w Debianie opisałem w osobnym wpisie.

Powyższe aktualne dla Debiana (głównie na desktopie, stąd nic o bazach wirusów, filtrach antyspamowych itp.), zapewne także dla pochodnych typu Ubuntu. Chyba, że tam jest to lepiej rozwiązane?

UPDATE: Przeładować owszem, można, ale jeśli dokonywana jest aktualizacja, to przeładowanie jest automatyczne.

UPDATE: Wzmianka o nowym sposobie aktualizacji mikrokodu we Wheezy.

WPS prawie tak słaby jak WEP.

Wygląda, że WPS (włączony domyślnie w wielu routerach) jest w tej chwili porównywalnie słaby, jak WEP. Niezależnie od użytego WPA/WPA2 możliwe jest – przy włączonym WPS – stosunkowo szybkie poznanie hasła do sieci WiFi ofiary, dodatkowo są gotowe narzędzia do tego celu (np. reaver-wps spaczkowany niedawno dla Debiana). Spodziewać się można niebawem aktualizacji firmware’ów dla routerów z dodaniem/wydłużeniem czasu dla funkcji lock down, ale to nie jest rozwiązanie, tylko drobne utrudnienie. Do szczegółów, w tym czasu brute force na WPS odsyłam do krótkiego, ale treściwego pdf ze strony.

Jak sprawdzić, czy sieć obsługuje WPS (czyli czy dana sieć jest podatna)? Najprościej (na Linuksie) przy pomocy wpa_supplicantPrzemek w komentarzach na tej stronie opisał jak, a wygląda, że da się prościej i wystarczy (Debian Squeeze z wicd jako helperem do WiFi):

wpa_cli scan
wpa_cli scan_results | grep WPS

Jeśli okaże się, że mamy włączonego WPS, a go nie potrzebujemy, to wypadałoby zmienić hasło do sieci WiFi oraz poszukać, czy WPS nie da się wyłączyć. Często (zwykle?) się da, przynajmniej na Linksysach.

Recenzja testu ultrabooka.

Test ultrabooka i konkurs to jedno, teraz pora na recenzję testu, czyli co mi się podobało w teście i konkursie, a co nie.

Przede wszystkim, fajnie, że konkurs w ogóle miał miejsce – jest szansa na pomacanie sprzętu przed zakupem, zapoznania się na żywo, sprawdzenia, jak sobie Linux radzi (tylko teoretycznie niestety, patrz niżej) itp. I żadna recenzja czy parę minut klikania w sklepie tego nie zastąpią, niestety. Dowiedziałem się, że nadal nie lubię ekranów glare, że klawiatura przy 13,3″ to pełen wymiar i może być zupełnie wygodna i że touchpad może być nie tylko używalny, ale nawet wygodny. Co prawda mysz jest wygodniejsza i pewnie na biurku podłączę, ale przy dobrym touchpadzie mogę ją sobie darować przy korzystaniu mobilnym.

Sprawa druga to to, co było podkreślane od początku przez wiele osób – jeden dzień to stanowczo za mało na test. Zwyczajnie mało czasu, żeby dokładnie przeklikać wszystko i poużywać, jeśli pojawią się problemy, żeby je rozwiązać itd. Do tego dochodzi kwestia konieczności poświęcenia jednorazowo sporej ilości czasu, wypadających niespodziewanych rzeczy niezwiązanych z testem itp. Jakby do tego dodać czas na synchronizację danych (żeby móc używać komputera w takich samych warunkach, jak dotychczasowy), to robi się dramat.

Kolejna sprawa – zakres grzebania w sprzęcie i odpowiedzialności. Jak pisałem w komentarzu pod wpisem konkursowym, istnieje coś takiego jak ubezpieczenie od zepsucia sprzętu, poczynając od jego zrzucenia, zalania, aż po naprawę po np. nieudanej aktualizacji BIOSu (to ostatnie kumpel niedawno sprawdzał w praktyce). Zdecydowanie warto wydać parę zł i skorzystać, dając testującym więcej komfortu. Tak samo zmiana systemu operacyjnego w urządzeniu – to tylko komputer, komputery pracują pod różnymi OS. W przypadku tak krótkiego testu co prawda zmiana OS średnio ma sens, ale przy dłuższym teście na pewno warto zezwolić na taką zmianę, a grzebanie w partycjach to wręcz konieczność.

Kolejna kwestia, czyli bezpieczeństwo. Czyli główny powód, dla którego zrezygnowałem z testu smartphone’a. Miałem opory przed podaniem haseł do serwisów na „niepewnym” (czytaj: nie moim) systemie, który na dodatek za moment ode mnie wyjeżdża nie wiadomo dokąd (a weź tu wyczyść dokładnie Windowsa…). Ostatecznie jedynym hasłem, które podałem było to do wifi. Zakładanie testowych kont jest pracochłonne i nadal nie korzystamy z systemu identycznie, jak normalnie. A jeszcze jakbym miał swoje dane skopiować na taki system? W żadnym razie. Możliwość postawienia swojego systemu, wyczyszczenia (wyzerowania) partycji to minimum. Jak rozwiązać sprawę przywrócenia oryginalnego systemu? Prosto: pendrive przywracający domyślny system i bootowanie z USB załatwią sprawę, niezależnie co się stanie z oryginalnym systemem na dysku. Proste, wygodne, bezpieczne i działa.

Organizacyjnie: trochę do życzenia pozostawiała komunikacja dotycząca konkursu. Papiery, które miały przyjechać przed przekazaniem sprzętu, a nie przyjechały (z tego co czytam, nie tylko ja nie dostałem umowy wypożyczenia przed otrzymaniem sprzętu), trochę zamieszania z terminami. Fajnie by było, jakby w przypadku przybycia kuriera ze sprzętem, a bez umowy można się dodzwonić do kogoś i wyjaśnić (no ale ostatecznie nie mój problem, że dostaję komputer bez umowy, prawda?). Fajnie też, żeby kurier przywożąc „upominki na otarcie łez” (dziękuję, zgrabny pendrive o słusznym rozmiarze, przyda się pod linuksowe live’y) i papiery do podpisania (umowa wypożyczenia po oddaniu sprzętu? po co?) zapowiedział wcześniej, co wiezie. Albo ktoś, kto wysyła, żeby zapowiedział. Bo osoba zdatna do odbioru przesyłki może być dostępna, ale nie musi być jednocześnie osobą mogącą podpisać umowę.

Pewnie jakby konkursy tego typu się powtarzały, to się warunki dotrą i będzie lepiej. Na co – w nadchodzącym roku – liczę. 😉