Menu

Pomiędzy bitami

Techno, porno i duszno. Blog niezupełnie technologiczny.

Linux

Nginx z automatycznym odnawianiem certyfikatu SSL, HTTP/2 i A+

rozieblox

Artykuł na z3s o automatycznym odnawianiu darmowego certyfikatu SSL od Let's Encrypt przypomniał mi, że nie skończyłem sprawy z nginx i certyfikatami SSL. Po pierwsze, brakowało mi wpisu w cronie. Trzy miesiące to jednak kawał czasu, a na serwer i tak się logowałem, więc certyfikaty były odświeżane ręcznie. No ale jak robić to porządnie, czyli w pełni automatycznie.

Wpis do crontab, którego używam to:

43 3 * * 2 /usr/bin/certbot renew --post-hook "service nginx reload" >> /var/log/certbot.log

Nie jest idealny - przede wszystkim restart nginx będzie wykonywany przy każdej próbie przeładowania, czyli raz na tydzień. Wydaje mi się, że przedładowanie konfiguracji nie będzie stanowiło problemu, ale jeśli komuś przeszkadza, to polecam zainteresowanie się opcją --renew-hook, zamiast --post-hook, która wykonuje się tylko przy odświeżeniu certyfikatu (czyli raz na kwartał). Z tym, że mam kilka certyfikatów i nie jestem przekonany, że restart nginx podczas odświeżania certyfikatu to jest to, co chcę robić, a testować mi się nie chce, tym bardziej, że na sucho średnio jest jak.

Rozwiązałem sprawę nie do końca działającego HTTP/2 (problemy z Firefox) opisaną w poprzednim wpisie. Przyczyna wskazana w komentarzach była trafna, żeby było ciekawiej, korzystałem dokładnie z

ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:!aNULL';

tyle, że zapewne podczas zabaw ze zwiększaniem kompatybilności z przeglądarkami zmieniłem to na wersję z gotowca, a potem odkręciłem ale... nie wszędzie. Poza tym, dopisanie http2 w każdej linii listen zawierajacej ssl i jest HTTP/2. Trochę sztuka dla sztuki, jak pokazały testy szybkości, ale wynika to głównie z tego, że same strony są małe i lekkie. Albo, jak Planeta Joggera, korzystają głównie z zasobów zewnętrznych, więc zmiany na moim serwerze nic nie dają.

W każdym razie powyższe szyfry i włącznie HSTS wystarczają do uzyskania oceny A+ na teście SSL, czego w nadchodzącym 2017 wszystkim życzę, korzystając z tego, że wpis przeleżał w szkicach nieco dłużej, niż planowałem.

Goodbye lighttpd

rozieblox

Do niedawna korzystałem na prywatnych gratach z lighttpd jako serwera WWW. Lekki, fajny, składnia pliku konfiguracyjnego powiedzmy perlowa, działał. Niby wszystko OK, ale... raczej nie jest wykorzystywany w różnych nowych projektach, jeśli ktoś daje narzędzia czy instrukcje, to raczej można się nie spodziewać znalezienia wersji dla lighttpd.

W międzyczasie troche bliżej miałem okazję zetknąć się z nginx i zrobił na mnie bardzo dobre wrażenie - dla kilku vhostów bardziej przejrzysty konfig, nieźle wspierany w dokumentacji różnych projektów (apache to to nie jest, ale jest dobrze). Gwoździem do trumny dla lighttpd okazał się brak wsparcia dla HTTP/2, a nawet brak planów w tym zakresie. I łatwość włączenia obsługi HTTP/2 na nginx - wystarczy jedna dyrektywa w pliku konfiguracyjnym (przy odpowiednio nowej wersji nginx - jest w backportach debianowych). Trochę na zasadzie "wykorzystać, nie wykorzystać, możliwość mieć można".

Nic dziwnego, że pojawił się pomysł przesiadki na prywatnych gratach z lighttpd na nginx. Brakowało motywacji, bo po pierwsze istniejąca wersja działała, po drugie konfiguracja była lekko zakręcona, po trzecie brak czasu. Ostatecznie któregoś razu zebrałem się, wymyśliłem, że uruchomię oba serwery WWW równolegle, na różnych portach i zrobię szybki benchmark lighttpd vs nginx. Który to benchmark oczywiście wykaże, że nginx jest szybszy i potwierdzi słuszność przesiadki[1]. ;-)

Jak już się zebrałem, to okazało się, że w sumie nie ma aż tak wielu rzeczy skonfigurowanych, a z wielu można/wypadałoby zrezygnować. Głównym wyzwaniem okazało się skonfigurowanie nginx tak, żeby HTTP słuchało na niestandardowym porcie i jednocześnie przekierowywało na HTTPS, również na niestandardowym porcie. Znalazłem rozwiązanie, ale machnąłem ręką - dziwne, nieprzystające do normalnego konfiga, a przydatne tylko na moment, przy benchmarku. Za to przydać się może ładny gotowiec do przekierowań z wersji z www na bez www i odwrotnie.

Przy okazji instalacji SSL dowiedziałem się, że w końcu istnieje oficjalna paczka z klientem Certbot dla certyfikatów SSL od Let's Encrypt w Jessie (trzeba skorzystać z backportów). Plus, strona daje gotowe instrukcje instalacji dla popularnego oprogramowania (znowu: nginx jest, lighttpd nie ma). Czyli w certyfikatach też został zrobiony porządek. Dla pamięci: znalazłem stronkę z gotowcem, jak uzyskać A+ na popularnym teście SSL. Nieco przestarzała, ale nadal przydatna.

W zasadzie poszło zaskakująco dobrze, najwięcej niespodzianek wyszło na rzeczach najprostszych - a to serwer nie kompresował treści (tu jest o włączaniu kompresji), a to był problem z przetwarzaniem skryptów PHP. W końcu jest sensowna obsługa haseł na dostęp do stron (ew. miałem to wcześniej zrobione słabo).

Z rzeczy, które powinny działać, a nie działają - HTTP/2. Nie wiem, czy bardziej kwestia konfiguracji, wersji nginx, czy Firefoksa, ale wg testu HTTP/2 działało, a w Firefoksie (i na niektórych testach, zapewne korzystają z Firefoksa) strona się nie otwierała. Na innych przeglądarkach działało OK, ale do czasu rozwiązania problemu wyłączam HTTP/2.

Ponieważ wygląda, że publiczne motywatory działają: następna w kolejce jest przesiadka z chronicle na pelican na Wattmeter. Robi dobre wrażenie i jest w Pythonie. ;-)


[1] Na przykładzie strony nextbike.tk i prostego testu przy pomocy ab -n 2000 -c 20 okazało się jednak, że różnicy większej niż błąd pomiaru nie ma. Być może kwestia wielkości małej wielkości pliku i narzutu na transmisję, być może kwestia obciążenia serwera, konfigi serwerów też nie były ani identyczne, ani optymalizowane. W każdym razie dla mnie szybciej nie będzie.

Aero2 - powiadamianie o konieczności wpisania CAPTCHA

rozieblox

Kolejny wyjazd na urlop i znowu dostęp do internetu sponsoruje Aero2. Oczywiście w wariancie z kompresowanym tunelem i proxy cache'ującym. Pewnie gdyby nie to rozwiązanie, to po prostu kupiłbym pakiet w Aero2, bo są naprawdę tanie, a jak testowałem przy okazji awarii netu u mojego ISP - śmiga to bardzo dobrze. Tak czy inaczej, gołe Aero2 jest nieprzyzwoicie wolne do WWW, po włączeniu ww. proxy śmiga na tyle dobrze, że stwierdziłem, że nie ma sensu kupować, tym bardziej, że nie pamiętam, czy aktywują od razu itp., a po włączeniu rozwiązania z tunelem wszystko działało. Przy czym najwięcej czasu przy włączaniu zajęło odszukanie wpisu z opisem.

W związku z użyciem ww. proxy WWW pojawia się jeden problem: nie działa przekierowanie i podstawowa przeglądarka nie wyświetla w takiej konfiguracji pytania o captchę. Zresztą, nawet gdyby przekierowanie działało, to mało ono pomaga przy czynnym korzystaniu z internetu, tj. nie przy biernym przeglądaniu, ale np. podczas pisania komentarza na jakiegoś bloga. Co prawda dzięki dodatkowi Lazarus do przeglądarki (polecam!) treść komentarza nie zginie nawet jeśli funkcja cofnij w przeglądarce nie działa i nastąpi przekierowanie, ale postanowiłem sobie sprawę ułatwić, przez napisanie prostego skryptu w Perlu, który sprawdzi dostępność zdefiniowanych hostów, a przy braku dostępności zadanej ilości wyświetli wyskakujące powiadomienie (xmessage). Przy czym sprawdza dość często (co 15 sekund), a jak brak łączności, to przerwa jest dłuższa.

Wyszło trochę ciekawiej, niż się spodziewałem. Wiadomo, że mocną stroną Perla są moduły, więc postanowiłem oprzeć się na dedykowanym module. Po pierwsze, okazało się, że Net::Ping domyślnie korzysta z TCP, nie ICMP, którego planowałem użyć, ale wydało się nawet lepsze. Niestety tylko do czasu, gdy okazało się, że przy podaniu hostów w formie domen i sprawdzaniu portu 80, za sprawą mechanizmu przekierowania Aero2 strona nadal jest dostępna. Tyle, że jest to strona mówiąca o konieczności wpisania captcha.

Rozwiązania są trzy. Pierwsze, to sprawdzanie zawartości strony, tj. czy nie pojawił się tekst mówiący o konieczności wpisania kodu captcha. Po pierwsze komplikuje to budowę skryptu, po drugie, zmniejsza jego uniwersalność (będzie działał tylko dla Aero2), po trzecie, możliwe, że przestanie działać przy jakiejś zmianie komunikatu. Drugie rozwiązanie, to podanie IP zamiast nazw domenowych. Przy takim rozwiązaniu przekierowanie dokonywane przez Aero2 nie będzie miało wpływu. Mniej czytelne i... zwyczajnie nie wpadłem w pierwszej chwili.

Zamiast tego postanowiłem skorzystać z wersji najoczywistszej i pierwotnie zamierzonej: wykorzystać jednak ICMP do sprawdzania osiągalności hostów. I tu największa niespodzianka: Net::Ping (ogólnie Perl) do wykorzystania ICMP wymaga uprawnień roota. Zdziwiłem się, ale po prostu tak jest i nie jest to feature Perla, a systemu - zwykli użytkownicy nie mają dostępu do tworzenia socketów. Z tego co znalazłem w sieci, polecane/najprostsze rozwiązanie na obejście tego to... wykorzystanie systemowego polecenia ping, do którego zwykle użytkownicy mają dostęp (SUID). Tak też uczyniłem.

Efekty można zobaczyć na mojej ulubionej sieci społecznościowej (hrhrhr), czyli w repo aero2-watch na GitHubie. Grupa potencjalnych użytkowników bardzo wąska (Linux + Aero2), ale może się komuś przyda...

Gdyby ktoś się zastanawiał, czemu klepię skrypty/siedzę na necie na urlopie to: lubię i zawsze to robię, poza tym, do porannej kawy jak znalazł; robię też inne, typowo urlopowe rzeczy; napisanie ~50 linii w Perlu trwa znacznie krócej, niż napisanie tego wpisu.

Uruchomienie karty Wi-Fi Mediatek MT7601U na Banana Pi

rozieblox

Jakiś czas temu kupiłem małe, tanie karty USB Wi-Fi w Chinach. Stwierdziłem, że przydadzą się do niewyposażonych we wbudowane karty płytek z ARM, czy nawet żeby któryś komputer podpiąć na szybko do sieci Wi-Fi w standardzie N. Karty przetestowałem na szybko na laptopie i wszystko było fajnie, ale... uruchomienie ich wymagało rzeźby i dokompilowania modułu. Dla jasności: chodzi o karty, które sprzedawane są jako Mediatek MT7601U USB bgn WiFi dongle.

Po podłączeniu w wyniku lsusb widać:

Bus 002 Device 002: ID 148f:7601 Ralink Technology, Corp.

 

a wymagany driver dla tej karty to mt7601u. W momencie podłączania karty USB w dmesg pojawia się:

[ 1075.027898] usb 2-1: new high-speed USB device number 2 using ehci-platform
[ 1075.189356] usb 2-1: New USB device found, idVendor=148f, idProduct=7601
[ 1075.196330] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1075.203764] usb 2-1: Product: 802.11 n WLAN
[ 1075.208160] usb 2-1: Manufacturer: MediaTek

 

Dziś potrzebowałem uruchomić Banana Pi pod kontrolą dystrybucji Bananian z tą kartą, wetknąłem ją w lapka, żeby odświeżyć sobie budowanie modułu i... miło mnie zaskoczył - działało od kopa. Stwierdziłem, że może zasługa nowszego kernela (4.5), ale prawdopodobnie nie - brakujący firmware jest dostarczany w Debianie w pakiecie firmware-misc-nonfree. Niedostępnym w Jessie, ale nie jest to wielki problem. Poniżej krótka instrukcja, co zrobić, żeby zadziałało (dla Bananiana 16.04 (released 2016-04-23)). Być może zadziała także na starszym kernelu, ale nie testowałem. Zgodnie z tym, co piszą na GitHubie projektu, driver jest dołączony do mainline kernela, i opisany poniżej sposób powinen działać dla kerneli od 4.2 w górę.

Instalacja kernela z linii 4.x na Banana Pi (niezalecana w FAQ Bananiana, ale...):

wajig install linux-image-4.4-bananian

 

Następnie reboot, by Banana Pi działało z nowym kernelem. Kolejnym krokiem jest pobranie pakietu z firmware dla karty:

wget http://ftp.de.debian.org/debian/pool/non-free/f/firmware-nonfree/firmware-misc-nonfree_20160110-1_all.deb

 

Usunięcie pakietów, które konfliktują z ww. pakietem (oczywiście wajig; wykonać dla wszystkich pakietów, które zgłoszą konflikt):

wajig remove firmware-ralink

 

Ostatnim krokiem jest instalacja pobranej paczki:

wajig install firmware-misc-nonfree_20160110-1_all.deb

 

Od tej pory karta USB Mediatek powinna po prostu działać po włożeniu do USB. Oczywiście należy połączyć się jeszcze z siecią bezprzewodową, ja polecam do tego wicd i wygodny konsolowy wicd-curses. Zadziała także dla Debiana w wersji stable (Jessie) - w zasadzie Bananian różni się tylko kernelem.

UPDATE Dobrzy ludzie słusznie donoszą, że firmware-misc-nonfree jest w repozytorium backports, więc instalacja jest prostsza - wystarczy dodać stosowne repozytorium do źródeł. Przyznaję, że nie sprawdzałem, bo jakoś mi się błędnie zakodowało, że ani armel, ani armhf nie są dostępne w backports.

KVM i task blocked for more than 120 seconds - solved

rozieblox

Sprawę miałem opisać już jakiś czas temu i zapomniałem, a jest szansa, że komuś się przyda. Był sobie serwer, na którym działało trochę VPSów. Wszystkie KVM, wszystkie z systemem plików ext4 i obrazem dysku qcow2. Czyli standard. Sprzęt nie pierwszej młodości, ale działały względnie stabilnie. Poza jedną, w sumie najbardziej obciążoną, bo działał w niej jeden z serwerów Zabbixa, niespecjalnie obciążony w porównaniu z innymi, w których jednak żaden nie działał w KVM.

Tej jednej zdarzał się zaliczyć zwis, z komunikatami:

kernel: INFO: task XXX blocked for more than 120 seconds.
kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

Wymagany był reboot wirtualki. Dotyczyło to różnych tasków, a całość działa się losowo - potrafiło działać przez kilka tygodni, a potrafiło wywalić się co parę dni, co nie ułatwiało diagnostyki. Początkowo działo się to na tyle rzadko, że sprawa została zignorowana, ale w miarę wzrostu obciążenia maszyny fizycznej, problem się nasilał. Objaw był taki, że operacje wymagające zapisu na dysk nie wykonywały się (czyli monitoring zdychał). Zacząłem szukać przyczyn - pierwotnie podejrzenie padło na coś, co wykonuje się z crona, bo sporo procesów crona wisiało, ale przejrzenie skryptów pokazało, że niespecjalnie mogą one być przyczyną

Wyglądało, jakby momentami coś nie wyrabiało się dostępem do dysków w momentach większego obciążenia. Z tym, że znowu - widać było, że nie jest to deterministyczne. Ponieważ maszyny jak wspomniałem starawe, to podejrzenie padło na sprzęt - problemy z dostępem do dysków potrafią robić cuda. SMART pokazywał, że wszystko OK, ale sprawdzić nie zawadzi... Przeniesienie wirtualki na inną, mniej obciążoną maszynę fizyczną nie przyniosło rezultatów - wieszało się nadal, chociaż rzadziej.

Oczywiście wyłączenie komunikatu, które jest w nim wspomniane, nie rozwiązuje problemu. W międzyczasie trafiłem na opis rozwiązania problemu, czyli zmniejszenie vm.dirty_ratio oraz vm.dirty_backgroud_ratio. Tylko że... to nie pomogło. Nie pomogło także zwiększenie kernel.hung_task_timeout_secs początkowo do 180, potem do 300 sekund. Było trochę lepiej, ale problem nadal występował. Pół żartem, pół serio zacząłem się zastanawiać nad automatycznym rebootem po wystąpieniu problemu (zawsze to krótsza przerwa), ale to brzydkie obejście, nie rozwiązanie. Tym bardziej, że w miarę wzrostu obciążenia i VPSa, i maszyny fizycznej na której on działał, problem zaczął występować częściej - góra co parę dni. Paradoksalnie, dobrze się stało, bo i motywacja większa, i sprawdzanie efektu wprowadzonych zmian łatwiejsze.

Z braku opisów w sieci, pomocy znajomych adminów i innych pomysłów zacząłem sprawdzać po kolei wszystko. Od fsck systemu plików, przez nowsze wersje kernela, zarówno na maszynie fizycznej, jak i na wirtualce - a nuż coś poprawili. Bez rezultatu. Ostatecznie postanowiłem zmienić format dysku wirtualki z qcow2 na raw i... trafiony, zatopiony - wirtualka zaczęła działać stabilnie.

Dla pewności wróciłem jeszcze z raw z powrotem na qcow2, na wypadek, gdyby chodziło o jakieś błędy, których nie wykrywało narzędzie do sprawdzania qcow2, ale... problem natychmiast wrócił. Gwoli ścisłości: ww. tuning dotyczący parametrów kernela z serii vm.dirty został zachowany.

LXDE -> LXQt - podejście pierwsze

rozieblox

Od dłuższego czasu (notka wskazuje, że już sześć lat, jak ten czas leci...) moim domyślnym - i w zasadzie jedynym używanym - środowiskiem na desktopie (ang.: desktop environment) jest LXDE. Nie udało mi się oczywiście całkiem zrezygnować z zależności od KDE. Z aplikacji przychodzących z KDE ostały się: edytor kate (jednak z GUI - najwygodniejszy, obecnie myślę o Atom, ale kobyła...); konsole (w szczególnych przypadkach typu konieczność wyboru charsetu, bo lxterminal ogólnie działa bardzo fajnie) oraz... kdiff3, który jest wygodny. Ale nie o tym ma być notka.

Środowisko LXDE

Środowisko LXDE Źródło: http://lxde.org/lxde_desktop/

Swego czasu w sieci było sporo zachwytów nad LXQt i trochę bolało mnie, że nie ma paczek w Debianie, żeby się pobawić. Potem zauważyłem, że paczki pojawiły się w unstable, ale nie było już jakoś ani czasu, ani ochoty. Ostatnio sobie przypomniałem o ich istnieniu, zainstalowałem pakiety, przelogowałem się i... trochę rozczarowanie. Może za dużo czytałem zachwalania i miałem za wysokie oczekiwania, ale przyznam, że LXQt nie powaliło mnie.

Pierwsze co mi się rzuciło w oczy, to brzydkie dekoracje okien i brak większego wyboru w tym zakresie. OK, może kwestia przyzwyczajenia. Do tego doszły braki widgetów (np. wyloguj) oraz zmiany działania tych, które były wcześniej używane. Przykładowo wykres użycia CPU czy RAM zawiera teraz więcej informacji, na jednym wykresie. W przypadku CPU pokazuje nie po prostu zużycie, ale z rozbiciem na nice, system, user. RAM podobnie - used, buffers... Po co to komu na desktopie, tak naprawdę? Na pierwszy rzut oka jest mniej czytelnie, choć informacji więcej. I jest to ogólny trend. Widget do pokazywania temperatury korzysta domyślnie ze wszystkich możliwych źródeł, zarówno tych działających, jak i nie działających. I żeby było "normalnie", to trzeba wyłączyć niechciane (i niedziałające).

Podgląd pulpitów jakiś taki brzydszy. Znaczy wybór pulpitów, bo podglądu po prostu nie ma. QTerminal nadal nie ma możliwości wyboru kodowania. Wbudowane blokowanie terminala (czyli screensaver) odwołuje się do nieistniejącej binarki, chociaż to akurat obchodzę przy pomocy xscreensavera, tak samo miałem zrobione w LXDE.

Żeby nie było, że tylko wady: widać, że poświęcono trochę pracy na łatwiejsze (drag & drop) dodawanie programów do pasków. Pojawiło się jakby więcej opcji w wielu miejscach. Trochę mam skojarzenia z KDE 3.5 (tak jak je pamiętam), jeśli chodzi o możliwości konfiguracji. Wiele rzeczy daje się obejść, np. zamiast brakującego widgetu do wylogowania można użyć drugiego paska ze skrótami do aplikacji i tam przeciągnąć z menu odpowiednie programy. Zdecydowanie fajny jest menadżer nośników wymiennych - w LXDE nie korzystałem, nie wiem czy w ogóle był.

Drobiazgów typu zużycie RAM nie mierzyłem - w porównaniu z dowolną przeglądarką WWW to są orzeszki teraz... Ogólnie środowisko działa szybko i sprawnie. Mam je na domowym desktopie od jakichś dwóch tygodni i zdecydowanie daje się używać.

Środowisko LXQt

Środowisko LXQt. Źródło: http://lxqt.org/screenshots/dark/

Podsumowując: wygląd jest sprawą dyskusyjną. Moim zdanie LXQt nie wnosi nic specjalnego w stosunku do LXDE, poza wyglądem, więc jeśli ktoś korzysta z LXDE, to raczej nie będzie zachwycony zmianą. Faktem jest, że LXQt działa i daje się używać, więc gdyby LXDE zniknęło, to mam wybranego następcę. Zmiana filozofii z "jest prosto i działa" na "można więcej skonfigurować" - co kto lubi. Mi LXDE pasowało, bo korzystałem z praktycznie niemodyfikowanej konfiguracji domyślnej i wielką zaletą przesiadki na LXDE był właśnie fakt, że praktycznie wszystko od kopa działa i nie trzeba rzeźbić. Przy przejściu z LXDE na LXQt trochę trzeba się pobawić z konfiguracjami.

Póki co zostawiam LXQt, żeby pozbyć się przyzwyczajeń, ale nie wykluczam, że za parę tygodni wrócę do LXDE. Tym bardziej, że właśnie z LXDE korzystam na innych desktopach. - paczki LXQt w Debianie są dopiero w testing i wyżej.

Muzyka z YouTube w konsoli

rozieblox

Na YouTube można w prosty sposób znaleźć sporo różnej muzyki i obecnie jest to mój wybór numer jeden, jeśli chodzi o muzykę z sieci[1]. Odtwarzanie YouTube w przeglądarce jest oczywistym wyborem w przypadku filmów, ale jeśli zależy nam tylko na audio, czyli np. słuchamy w pracy, to odtwarzanie w przeglądarce tylko przeszkadza - niepotrzebnie obciążamy i sieć, i CPU, i RAM.

Niedawno znalazłem program mps-youtube, który jest napisany w Pythonie i który stawia sobie za cel obsługę YouTube w konsoli. Można m.in. wyszukiwać utwory, dodawać URLe, tworzyć lokalne playlisty, a także pobierać muzykę w określonym formacie na dysk. Opis mówi, że można też importować istniejące playlisty z YouTube, ale tej funkcjonalności jeszcze nie testowałem. Całość pomyślana w taki sposób, aby można było dowiedzieć się wszystkiego z samej aplikacji, bez konieczności czytania manuali, a sam program przychodzi z sensownymi ustawieniami domyślnymi.

Pomoc programu mps-youtube
Pomoc programu mps-youtube - screenshot

Wersja z Jessie 0.01.46-3 jest o wiele starsza, niż dostępna w unstable 0.2.5-5, ale... obie wersje mają błędy, niestety i bywa, że jedna wersja potrafi otworzyć dany URL, a druga nie. Na GitHubie dostępna jest wersja 2.6, ale jeszcze nie testowałem - w pracy, gdzie słucham najwięcej (niby leci jakieś radio ogólnie, ale słaba muza, w kółko te same utwory, dużo reklam, poza tym, "uroki" openspace...), wystarcza mi wersja z Jessie. Niemniej nadal polecam przymiarkę do programu.

Wyniki wyszukiwania w mps-youtube
Wyniki wyszukiwania w mps-youtube. Źródło: strona projektu.

Lokalna playlista mps-youtube
Lokalna playlista w mps-youtube. Źródło: strona projektu.

Niby działa na dowolnym systemie operacyjnym, ale z racji trybu obsługi (konsola) wróżę popularność raczej na Linuksie i wśród geeków. Dla porządku: wymaga mplayera lub mpv, z których korzysta do odtwarzania muzyki.

[1] Jak widać, opisywane kiedyś słuchanie radia w konsoli się nie sprawdziło, podobnie jak wykorzystanie mpd. Łatwe tworzenie playlist z dostępnych od ręki zasobów jednak wygrywa.

3 powody dla których nie kupię Raspberry Pi 3

rozieblox

Blisko trzy lata temu (ależ ten czas leci) pisałem, dlaczego nie kupię Raspberry Pi. Parę dni temu opublikowana została specyfikacja Raspberry Pi 3. I też widzę, że nie kupię, choć cieszę się na płytkę z 64 bit ARM. Powody są trzy:

  1. Brak portu SATA. Najmniej istotny, bo można podłączyć dysk po USB (i raczej tak zrobię), ale nadal trochę boli.
  2. Tylko 1 GB RAM. Mało. Na desktop - przeraźliwie mało. IMO minimum dla desktopa na dzień dzisiejszy to 2 GB RAM. Zresztą skoro mocniejszy procesor, to i serwer można by bardziej obciążyć, a tu RAM też się przydaje.
  3. 100 Mbps ethernet. Dla rozwiązań typu NAS 100 Mbps to zdecydowanie za mało.

Co zamiast Raspberry Pi 3? Czaję się na najwyższy model Pine 64 czyli PINE64+ 2GB. Co prawda też nie ma SATA, ale ma 1Gbps kartę sieciową oraz 2 GB pamięci RAM. I ma kosztować przy tym 29 dolarów + 12 dolarów za wysyłkę do Polski.

Wady Pine64? Wspomniany brak SATA, jeśli ktoś potrzebuje USB i bluetooth, to musi dołożyć kolejnych 10 dolarów, albo kupić wersje na USB (2,5 w Chinach) i zająć oba porty. No i trzeba poczekać do maja.

UPDATE To wszystko oczywiście z mojego punktu widzenia, który można streścić "małe, tanie, mocne i Linux działa". Z punktu widzenia kogoś, kogo bardziej interesuje zabawa elektroniką będzie to wyglądało zupełnie inaczej, bo w grę wchodzi choćby łatwość supportu czy dostępność rozszerzeń.

Warto też przeczytać komentarz Piotra (pierwszy) - Odroid wygląda nieźle (jak zwykle zresztą), choć jest nieco droższy (jak zwykle zresztą). Patrz porównanie. Czyli ciekawych alternatyw dla Raspberry Pi 3 jest więcej.

Dowiedziałem się też o istnieniu dystrybucji Armbian. Autorzy nie piszą niestety zbyt wiele, ale wygląda interesująco i wspiera wiele płytek. Oferuje świeży kernel i wspiera Debiana (Wheezy, Jessie) oraz Ubuntu Trusty.

Letsencrypt i lighttpd - HOWTO

rozieblox

Czym jest Let's Encrypt wie już chyba każdy, kogo interesują certyfikaty SSL, ale wypada jakieś wprowadzenie napisać, więc: to prosty sposób na odnawialne automatycznie, rozpoznawane przez przeglądarki, bezpłatne certyfikaty SSL dla każdego. Projekt jest w fazie public beta, więc przystąpić może każdy, stoją za nim duzi (przykładowi, bardziej znani sponsorzy: Mozilla, EFF, Cisco, OVH, Google Chrome, Facebook), więc raczej coś z tego będzie i jest krokiem w kierunku zwiększania bezpieczeństwa w sieci pod hasłem wszystko po HTTPS (które to rozwiązanie ma wady, ale o tym już było).

Let's Encrypt logo

Źródło: https://letsencrypt.org/trademarks/

Ponieważ właśnie dostałem maila od Let's Encrypt, że wygenerowany przez nich, darmowy certyfikat SSL dla mojej domeny wygasa, postanowiłem skorzystać z największego dobrodziejstwa, czyli zautomatyzować całość. Prosty skrypt, który zadziała dla lighttpd i jednej domeny:

#!/bin/bash 

LECMD="/opt/bin/letsencrypt/letsencrypt-auto"
DOMAIN="mojadomena.com"
WEBROOT="/var/www/mojadomena.com/html/"
EMAIL="adres@email"

$LECMD --renew-by-default -a webroot --webroot-path $WEBROOT --server https://acme-v01.api.letsencrypt.org/directory --email $EMAIL --text --agree-tos -d $DOMAIN auth
cat /etc/letsencrypt/live/$DOMAIN/privkey.pem /etc/letsencrypt/live/$DOMAIN/cert.pem > /etc/letsencrypt/live/$DOMAIN/ssl.pem
service lighttpd restart

Zakładam oczywiście, że skrypt letsencrypt jest pobrany z gita, masz dostęp do roota, lighttpd jest skonfigurowane i ma podpięty certyfikat SSL. Plus, że w konfiguracji lighttpd jest linia w stylu:

ssl.pemfile = "/etc/letsencrypt/live/mojadomena.com/ssl.pem"

To co wyżej to sama esencja, brakuje choćby kontroli błędów/statusu wykonania poleceń, ale wywołane z ręki działa i pewnie dodam do crona wykonywanie raz w miesiącu (wzmocnione przez && w ramach "kontroli błędów"). Opisuję, by mi nie zginęło, poza tym, widziałem albo skrypty automatyzujące, albo opisy uruchomienia letsencrypt z lighttpd, więc liczę, że zebrane do kupy się komuś przyda.

UPDATE Wpis się lekko zdezaktualizował o czym więcej w tym wpisie. A krótko: jest gotowiec od EFF o nazwie Certbot do automatycznego zarządzania darmowymi certyfikatami SSL Let's Encrypt, z opisami dla różnych serwerów.

Jak zrobić router GSM na Linuksie?

rozieblox

Niedawno miałem awarię netu. Stwierdziłem, że warto przy tej okazji poćwiczyć awaryjne udostępnianie sieci na Linuksie. Oczywiście zrobienie routera z komputera z Linuksem to kwestia paru poleceń, ale stwierdziłem, przećwiczyć udostępnianie sieci po wifi.

Istnieje pakiet hostapd, który ułatwia zamianę komputera z Linuksem w access point. Instalacja pakietu hostapd:

apt-get install hostapd

Jakość pakietu nie zachwyca, ale jest niezły tutorial do hostapd. Skrypt init nie zadziała (należy go uzupełnić o ścieżkę do pliku - zmienna DAEMON_CONF), podobnie sam pakiet nie dostarcza - jak to zwykle ma miejsce w przypadku pakietów Debiana - pliku konfiguracyjnego umieszczonego w katalogu /etc. Przykładowy plik konfiguracyjny dla hostapd znajdziemy jednak w /usr/share/doc/hostapd/examples.

Żeby nie przedłużać, poniżej cały plik konfiguracyjny, którego ostatecznie użyłem:

interface=wlan0
country_code=PL
ssid=NAZWA_SIECI
hw_mode=g
channel=6
wpa=2
wpa_passphrase=TAJNE_HASLO
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP
auth_algs=1
macaddr_acl=0

Jak widać, są lekkie różnice w stosunku do tutoriala. Brakujące ustawienie zmiennej w skrypcie startowym znalazłem później, więc ostatecznie uruchamiałem hostapd z ręki, bez demonizacji (w ramach debugu, zresztą).

Oczywiście sama konfiguracja hostapd nie wystarczy. Trzeba mieć jeszcze skonfigurowane "przyjście" netu. W moim przypadku internet był dostarczony z modemu GSM (tutaj opis konfiguracji Aero2 na modemie Huawei E3131). Użycie modemu LTE pozwoli oczywiście zrobić router LTE na Linuksie. Przyda się również serwer DHCP i konfiguracja DNS. Obie rzeczy może załatwić dość dokładnie opisany kiedyś dnsmasq, ale tak naprawdę dla przydzielania adresów IP systemom łączącym się z naszym routerem GSM wystarczą dla ww. konfiguracji dwie linie w /etc/dnsmasq.conf:

interface=wlan0
dhcp-range=192.168.1.100,192.168.1.200,255.255.255.0,1h

Należy też dodać adres IP na interfejsie wlan0, włączyć forward pakietów dla IPv4 oraz uruchomić NAT. Wersja "ręczna" ww. czynności (dla mojej konfiguracji, interfejsy mogą się zmieniać) to:

ip a a 192.168.10.1/24 dev wlan0
ip link set wlan0 up
service dnsmasq restart
echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

Po tym wszystkim, inne komputery powinny móc się połączyć z naszym linuksowym routerem GSM, dostać adres IP oraz posiadać dostęp do internetu za jego pośrednictwem. W przypadku problemów warto sprawdzić kolejno: otrzymanie adresu IP, ping do routera (192.168.10.1), ping do świata po IP, ping do świata pod domenie (w zasadzie: resolvowanie DNS).

Na rynku jest sporo sprzętów, które pozwolą na budowę mocnego routera GSM na Linuksie (przykładowo Banana Pi, Orange Pi czy nieśmiertelne Raspberry Pi). Oczywiście jeśli miałby być to sam router, to nie bardzo widzę sens ekonomiczny, bo zestaw modem+płytka+karta wifi+zasilacz pewnie będzie kosztował więcej, niż tani router LTE (no chyba, że ktoś akurat - jak ja - ma ww. graty pod ręką ;-) ), ale w przeciwieństwie do taniego routera GSM można tu uruchomić dodatkowe funkcjonalności typu NAS, VPN czy serwer WWW. Ten ostatni to może niekoniecznie na łączu GSM...

Mam nadzieję, że opis się przyda. Gdybym o czymś zapomniał, albo coś nie działało, proszę o uwagi.

PS. Oczywiście mam świadomość, że udostępnienie internetu z GSM potrafi w trzech kliknięciach zrobić chyba każdy smartfon z Androidem i w przypadkach awaryjnych jest to najszybsza droga. I tak, użyłem Aero2 i pakietu testowego bez captcha. Niskie opóźnienia pozytywnie zaskakują.

Ubuntu 14.04 LTS, apt-dater i restart usług

rozieblox

Jakiś czas temu zachwalałem apt-dater jako narzędzie do aktualizacji większej ilości systemów. Jak pisałem w późniejszych uwagach, apt-dater nieźle integruje się z programem needrestart. Tyle teorii...

Niestety, o ile na Debianie Jessie wyglądało to naprawdę dobrze i sprawdzenie przez checkrestart (inne polecenie realizujące podobne zadanie) dawało spójne wyniki z needrestart, o tyle na Ubuntu 14.04 LTS needrestart pokazywał często, że do restartu nic nie ma, o tyle checkrestart był zupełnie innego zdania... I - co gorsza - miał rację.

Przyczyną okazała się różnica w wersji needrestart. W Jessie jest to 1.2, w Ubuntu 14.04 LTS - 0.5. Ponieważ to skrypt perlowy, to dałem szansę i wrzuciłem wersję z Debiana (stable). Instaluje się czysto, działa bardzo dobrze - w połączeniu z apt-dater wykrywa więcej usług do restartu i także tu wyniki needrestart są teraz spójne z checkrestart.

Nawiasem, checkrestart w Jessie ma problem z mysql i zawsze pokazuje, że należy go zrestartować. Jest na to zgłoszony bug. Ale to tak nawiasem, kto korzysta, ten wie, zresztą można dopisać mysql do wyjątków w konfigu.

Raspberry Pi Zero

rozieblox

Pojawił się na rynku nowy mini komputer z procesorem ARM. Raspberry Pi Zero, bo o nim mowa, posiada:

  • CPU BCM2835 1GHz (1 rdzeń)
  • 512 MB RAM
  • slot micro-SD
  • 1 micro USB
  • 1 mini HDMI
  • GPIO zgodne z poprzednimi modelami (wymagana przejściówka z pinami)

Największe zalety to jednak minimalne wymiary i równie minimalna cena. Ma ona wynosić $5 (zobaczymy ile w praktyce w Polsce).

Raspberry Pi Zero

Źródło: https://www.raspberrypi.org/

Choć uważam, że od Raspberry Pi ogólnie ciekawsze są Banana Pi czy Orange Pi, to ten produkt mi się nawet podoba. Świetna cena, możliwości porównywalne z pierwszymi Raspberry (OK, trzeba dołożyć kartę sieciową na USB, ale sensowne zasilanie to i tak aktywny hub USB, a rpi z tego co pamiętam i tak miało ethernet over USB).

Sprzęt trochę słaby, patrząc z punktu widzenia bardziej linuksowego/serwerowego, (słaby procesor, mało RAM), ale Cena Czyni Cuda. Poza tym, z tego co widzę, celowany bardziej w mniejsze projekty, wręcz wearables, więc niezupełnie fair byłoby oceniać go z perspektywy linuksowo/serwerowej. Co ciekawe, nowy produkt będzie dołączony do grudniowego wydania MagPi.

Największa wada to oczywiście nadal architektura procesora. Jest to dokładnie ten sam model, co w pierwszych modelach rpi, tylko wyżej taktowany, co oznacza, że albo korzystamy z wynalazków typu Raspbian, albo z architektury armel w np. Debianie (i wydajność cierpi), bo niestety armhf nie zadziała.

Chef i cookbooki bez metadata.rb

rozieblox

W firmie korzystamy z Chefa, niby robi swoją robotę, ale nie przepadam za nim z różnych względów. Jedna z rzeczy, która mnie drażni, to wersjonowanie i niekompatybilność (bardziej: pozorna kompatybilność) pomiędzy wersjami. W Debianie Jessie, którego mam na desktopie jest chef w wersji 11, który generalnie działał. Na serwerach mamy Chefa 12.

Ostatnio instaluję cookbook nodejs:

knife cookbook site install nodejs
Installing nodejs to /home/rozie/chef-repo/cookbooks
Checking out the master branch.
Pristine copy branch (chef-vendor-nodejs) exists, switching to it.
Downloading nodejs from the cookbooks site at version 2.4.2 to /home/rozie/chef-repo/cookbooks/nodejs.tar.gz
Cookbook saved: /home/rozie/chef-repo/cookbooks/nodejs.tar.gz
Removing pre-existing version.
Uncompressing nodejs version 2.4.2.
removing downloaded tarball
No changes made to nodejs
Checking out the master branch.
ERROR: IOError: Cannot open or read /home/rozie/chef-repo/cookbooks/nodejs/metadata.rb!

Zacząłem szukać i widywać różne dziwne rozwiązania na nieistniejące metadata.rb, przez chwilę przyszło mi dogenerowanie "brakującego" pliku na podstawie obecnego metadata.json, ale... coś mnie tknęło i postanowiłem najpierw spróbować z nowszym Chefem u siebie na lapku.

Ależ oczywiście, że instalacja Chefa w wersji 12 rozwiązała problem.

Orange, wvdial i modem Huawei E1752C

rozieblox

Ponieważ w ramach jednego projektu (hm, na razie nic nie nadaje się do publikacji) klikałem na dwa modemy GSM, to obok mojego Huawei E3131 w laptopie pojawił się pożyczony modem GSM Huawei E1752C z kartą sieci Orange. Dla pamięci i gdyby komuś miało się przydać - konfiguracja dostępu do internetu dla sieci Orange pod Linuksem.

W lsusb Huawei E1752C jest widoczny jako:

new high-speed USB device number 11 using ehci-pci
New USB device found, idVendor=12d1, idProduct=141b
New USB device strings: Mfr=3, Product=2, SerialNumber=4
Product: HUAWEI Mobile
Manufacturer: HUAWEI Technology

w dmesg jako:

Bus 002 Device 011: ID 12d1:141b Huawei Technologies Co., Ltd.

Sam modem działał od kopa (kernel 4.1.0-1-amd64, Debian unstable) i nie wymagał żadnych ingerencji, ale zaznaczam, że trafił do mnie jako używka, więc nie wiem, czy było grzebane.

Szybka przeróbka mojej konfiguracji dla Aero2, w oparciu o oficjalne instrukcje ze strony Orange nie zakończyła się sukcesem. Poszukiwania w sieci naprowadziły mnie na ten artykuł nt. konfiguracji modemu GPRS dla sieci Orange w Debianie. Potwierdzam, działa. Ale IMO trochę przydługie, więc postanowiłem skrócić do wersji mniej więcej minimalnej. Skończyłem z takim konfigiem do wvdial:

[Dialer orange-pin]
Modem = /dev/ttyUSB0
Init1 = ATZ
Init2 = AT+CPIN=1234

[Dialer orange]
Modem = /dev/ttyUSB0
Init3 = AT+CGDCONT=1,"IP","internet"
Username = "internet"
Password = "internet"
Phone = "*99#"
Dial Command = ATDTW
Stupid Mode = yes
Dial Attempts = 0

Najpierw trzeba wywołać wvidal orange-pin, a gdy się zakończy, można połączyć się z siecią przy pomocy wvidal orange. Jak widać, kluczową różnicą było ustawienie parametru Dial Command.

Samo połączenie z Orange można uruchomić na Linuksie prościej, bo na desktopie da się wyklikać konfigurację w network manager. Sprawdzone na Debianie Jessie z kernelem w okolicach 4.0. Ale czasem może przydać się wersja bardziej ręczna, szczególnie jeśli ktoś nie ma GUI w maszynce.

© Pomiędzy bitami
Blox.pl najciekawsze blogi w sieci