Menu

Pomiędzy bitami

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

DSP2017 - co ciekawsze projekty

rozieblox

Ostatni dzwonek na wpis, a w związku z aurą i nawałem innych zajęć niewiele się u mnie wydarzyło[1], więc pozwolę sobie zacząć małą metatematykę, czyli pisać o projektach, które przykuły moją uwagę i które planuję śledzić. Ocena zupełnie subiektywna. Raczej ograniczam się do "żywych", czyli mających szanse w konkursie, projektów. Trochę nawiązując do Blog Day, ograniczę się jednorazowo do pięciu sztuk. Docelowo pewnie zmienię linki na bezpośrednie do blogów lub repo na GitHubie.

http://uczestnicy.dajsiepoznac.pl/profil/adrian-dzik - Instant Dinner czyli podpowiadanie co tu ugotować z dostępnych w lodówce składników. Pomysł mi się bardzo podoba i może się przyjąć, choć korzystać raczej nie będę - nie mam cierpliwości do wklepywania wszystkiego i nie lubię gotować z przepisów. Parę ciekawych wyzwań - interfejs, baza przepisów.

http://uczestnicy.dajsiepoznac.pl/profil/pawel-filipek http://uczestnicy.dajsiepoznac.pl/profil/pawel-panek - dwa projekty związane z modnym temat badania czystości powietrza. Tu: informowania o zanieczyszczeniu w danym miejscu. Po cichu liczę, że będzie kolaboracja z projektem Smolgy o którym niedawno pisałem.

http://uczestnicy.dajsiepoznac.pl/profil/kamil-kubacki - projekt Citizen, czyli zgłaszanie do władz miasta/służb uszkodzeń itp. Po prostu zgłaszasz dziurę w jezdni (geolokalizacja, fota, opis) i jest to odpowiednio przeroutowane dalej, nie trzeba się edukować/odbijać od kolejnych instytucji. Przyznaję, że myślałem o czymś podobnym niedawno. Widzę fajne możliwości - ranking najsprawniej działających miast/organizacji w danym mieście (np. czas od zgłoszenia do usterki). Widzę też jeden problem: żeby to działało, instytucje muszą się zaangażować...
Podobna tematyka http://uczestnicy.dajsiepoznac.pl/profil/andrzej-chmielewski - niestety wygląda na martwe.

http://uczestnicy.dajsiepoznac.pl/profil/maciej-sykala - działko na gołębie oparte o Raspberry Pi. Temat niezbyt mi się podoba, ale przyznaję, że zakres robi wrażenie i... ciekaw jestem efektu. BTW dawno temu czytałem, że w Korei Południowej studenci projektowali automatyczne wieżyczki strzelnicze do pilnowania granic. Nie pamiętam, czy była analiza obrazu, czy po prostu wykrywanie ruchu...

http://uczestnicy.dajsiepoznac.pl/profil/sebastian-czarnecki - arduino sterowane po wifi. To mi się najprawdopodobniej zwyczajnie przyda w niedalekiej przyszłości.

Na wypadek gdyby powyższe nie wyczerpywało wymagań wpisu o IT, to przyszła mi do głowy nieco inna formuła konkursu programistycznego, która mogłaby trochę pomóc w rozwoju projektów. Pierwszy etap to prezentacja pomysłów, pisanie kodu i blogowanie (czyli dokładnie jak DSP), drugi etap to połączenie się ludzi w zespoły i wspólne rozwijanie projektów. Można by to zakończyć jakimś hackatonem, żeby ludzie się poznali na żywo. A może istnieje już coś takiego?

Co prawda nie widzę za bardzo kryteriów oceny w powyższym układzie, ale mogłoby to dać coś trwalszego i większego, niż małe projekciki, nauczyć pracy w zespołach, umożliwić poznanie ludzi i wymianę wiedzy np. o narzędziach. No ale ja cały ten konkurs traktuję bardziej jako pretekst, czyli droga jest ważniejsza od celu. ;-)

[1] Przynajmniej niewiele zostało commitnięte, za to wkrótce pierwsze pomiary na dwóch łączach i pewne uwagi nt. internetu w Virgin Mobile.

Logowanie

rozieblox

Pora dorobić logowanie w skrypcie. Nie będę tu przepisywał tutoriali, więc jedynie odeślę do opisu logowania w Hitchhiker's guide to Python oraz chyba nawet lepszego wpisu na temat dobrych praktyk logowania w Pythonie Docelowo konfiguracja logowania w pliku konfiguracyjnym. Waham się czy jednak syslog, czy może osobny plik, ale to jest detal.

Wczoraj w pociągu rozpisałem wstępnie, co chciałbym logować na poszczególnych poziomach i wyszło mi coś takiego:

WARNING/ERROR:

  • błąd otwarcia lub parsowania pliku konfiguracyjnego
  • nieistnienie interfejsu zdefiniowanego w pliku konfiguracyjnym
  • błąd zwrócony przez skrypty pomocnicze
  • brak skryptu pomocniczego, jeśli był zdefiniowany w pliku konfiguracyjnym[1]
  • nieosiągalne IP[2]

INFO:

  • znalezienie lepszej trasy i zmiana routingu, czyli podstawa
  • ostateczna punktacja dla danego interfejsu (docelowo może w DEBUG?)
  • znalezienie lepszej trasy, niż istniejąca, z pominięciem kosztu przełączenia[3]

DEBUG:

  • chwilowe zmiany routingu per badane IP
  • dane wczytane z konfiguracji
  • parametry wywołania funkcji
  • punktacja dla interfejsu z rozbiciem na składowe
  • parametry wywołania skryptów pomocniczych

Domyślny loglevel to oczywiście INFO. Jeśli wszystko pójdzie OK,to zmiany pojawią się w repo dziś wieczorem - niestety czas goni, a dwa wpisy w tygodniu muszą być...

[1] Wybiegam w sekcję ogólną konfiguracji, która dopiero powstanie, o skryptach pomocniczych planuję napisać w kolejnym wpisie.
[2] Jeśli będzie często występowało, to warto je usunąć, żeby nie zaburzało wyników.
[3] W celu poinformowania użytkownika, że być może warto zmienić przy okazji konfigurację sieci.



Początek

rozieblox

No to wysłałem na GitHuba to co mam w tej chwili. Nie ma tego wiele - w zasadzie jeśli chodzi o kod to jest to dokładnie wersja testowa o której pisałem wcześniej. Zupełnie nie miałem czasu i weny na siedzenie z kodem.

Ale nie jest tak, że nic nie przybyło w kwestii projektu. Po pierwsze, dotarł modem i udało mi się go uruchomić, więc będzie na czym testować. Po drugie, zrobiłem lekkie porządki w plikach i zaktualizowałem opis. Po trzecie i najważniejsze: chyba rozwiązałem problem wag. Proste rozwiązania są najlepsze, na papierze i szybkim teście wygląda wstępnie OK. Oczywiście jest to średnia ważona - musiałem mieć jakieś zaćmienie, że od razu o niej nie pomyślałem, ale powiedzmy, że bardziej myślałem o pliku konfiguracyjnym.

Co poza tym w temacie DSP2017? U mnie nic, poczytałem za to trochę wpisów. innych uczestników Co prawda w repozytoria nie zaglądałem, ale z wpisów mogę wywnioskować, że wszyscy mają mało czasu, generują niewiele kodu za to piszą, bo... muszą. Czyli za dużo blogowania, za mało programowania, ale chyba autor konkursu świadomie tak wybrał. Wnioskuję po dopuszczeniu wpisu niezwiązanego tematycznie z projektem jako drugiego. IMVHO trochę szkoda, bo czas zabiera, a wnosi niewiele.

Huawei E353/E3131 w Debianie

rozieblox

Kiedyś opisywałem uruchomienie Aero2 z modemem Huawei E3131. Kupiłem "taki sam" model i dziś przyszedł. Po podłączeniu do komputera spodziewałem się, że będzie tak samo, jak w poprzednim, ale nie, więc może komuś oszczędzę walki, na którą straciłem dziś dobry kwadrans, jak nie lepiej.

Otóż nowy modem przedstawia się w lsusb:

Bus 002 Device 016: ID 12d1:14db Huawei Technologies Co., Ltd. E353/E3131

Natomiast po wpięciu do portu USB w dmesg widać:

[11264.677637] usb 2-1.2: new high-speed USB device number 15 using ehci-pci
[11264.787001] usb 2-1.2: New USB device found, idVendor=12d1, idProduct=1f01
[11264.787005] usb 2-1.2: New USB device strings: Mfr=2, Product=1, SerialNumber=0
[11264.787007] usb 2-1.2: Product: HUAWEI HiLink
[11264.787009] usb 2-1.2: Manufacturer: HUAWEI
[11264.788426] usb-storage 2-1.2:1.0: USB Mass Storage device detected
[11264.788583] scsi host6: usb-storage 2-1.2:1.0
[11265.736276] usb 2-1.2: USB disconnect, device number 15
[11268.517690] usb 2-1.2: new high-speed USB device number 16 using ehci-pci
[11268.627263] usb 2-1.2: New USB device found, idVendor=12d1, idProduct=14db
[11268.627267] usb 2-1.2: New USB device strings: Mfr=2, Product=1, SerialNumber=0
[11268.627269] usb 2-1.2: Product: HUAWEI HiLink
[11268.627271] usb 2-1.2: Manufacturer: HUAWEI
[11268.630336] cdc_ether 2-1.2:1.0 eth0: register 'cdc_ether' at usb-0000:00:1d.0-1.2, CDC Ethernet Device, 58:2c:80:XX:XX:XX
[11268.707401] cdc_ether 2-1.2:1.0 enx582c80xxxxxx: renamed from eth0

Co prawda świtało mi coś o hilink i zauważyłem kartę sieciową w systemie, ale stwierdziłem, że to tylko jeden z trybów i można używać "po staremu" z /dev/ttyUSB0 i wvdial, który to sposób mam obcykany. Zmyliło mnie też to, że nie mogłem wejść na wskazywany przy opisach wersji hilink adres 192.168.1.1.

Robiłem różne cuda, o których pisać nie będę, na szczęście zapytałem na IRCu i dobrzy ludzie naprowadzili me zawiłe rozumowania na proste tory.

No więc ostatecznie "po staremu" mi się nie udało, natomiast żeby uzyskać adres IP wystarczy wydać polecenie:

dhclient enx582c80xxxxxx

 

I wtedy po wpisaniu w przeglądarkę 192.168.1.1 mamy dostęp do klikalnego interfejsu zarządzania modemem i wszystko działa od kopa.

Niestety, opisy są chyba obliczone albo na ludzi, którzy robią wszystko z ręki, albo na tych, którzy mają wszystko automatycznie. Pobieranie IP z DHCP też.

Wskaźniki jakości łącza

rozieblox

Dumałem trochę nad parametrami łącza internetowego, które abcc mógłby mierzyć, poza tym, komentarze pod wpisem o założeniach abcc trochę pomieszały mi szyki, jeśli chodzi o chronologię, więc najwyższy czas przejść do rzeczy.

Techniczne wskaźniki jakości łącza internetowego to:

  • Opóźnienie - czyli potocznie lag albo ping, zrozumiała chyba dla każdego miara i dość powszechnie używana do określenia, czy łącze jest sprawne. Im jest mniejsze, tym lepiej. Ma znaczenie przy korzystaniu interaktywnym, czyli SSH/remote desktop albo graniu w gry online (zwł. FPP). Niezbyt istotne przy pobieraniu danych czy strumieniowaniu.
  • Straty pakietów - na sprawnym łączu strat nie ma. W przypadku łącz bezprzewodowych lub awarii, straty mogą się pojawiać. Wiążą się z koniecznością retransmisji pakietów lub utratą danych. Mają znaczenie praktycznie wszędzie. Im niższa wartość, tym lepiej.
  • Jitter - zmienność opóźnienia pakietów, czyli dokładniej statystycznie, wariancja opóźnienia pakietów. Ma znaczenie przy korzystaniu interaktywnym, szczególnie przy transmisji głosowej/video. Im niższa wartość, tym lepiej.
  • Prędkość pobierania - określa, jak szybko można pobierać dane. Ważne przy pobieraniu danych.
  • Prędkość wysyłania - określa, jak szybko można wysyłać dane. Ważne tylko przy wysyłaniu większych maili itp.

W wariancie minimum planuję mierzyć tylko dwie pierwsze miary. Waham się nad jitterem - prawdopodobnie kiedyś zaimplementuję, ale wymagałoby zmiany bibliotek i/lub liczenia wszystkiego samodzielnie. Wykonalne, ale na początek mało istotne. Z uwagi na pierwotne zastosowania (GSM) i możliwość opłat za transfer, rezygnuję z badania prędkości pobierania i wysyłania. Zresztą, jest szansa, że same pomiary mogłyby tu wpłynąć na funkcjonowanie łącza, szczególnie słabszego. Dodatkowo wymagany jest host zdalny, udostępniający określoną zawartość (w przypadku downloadu) lub pozwalający na wysyłanie treści (w przypadku uploadu). Nie skreślam zupełnie, ale zdecydowanie nie pojawi się w pierwszej wersji, a jeśli się pojawi, to domyślnie będzie wyłączony.

Na koniec pozostała część zasadnicza, czyli formuła określająca jakość łącza. Ponieważ dla większości parametrów im niższa wartość, tym lepiej, stwierdziłem, że najprościej jest liczyć tylko koszt, czyli sumować "punkty karne", łącze o najniższej wartości "wygrywa". W przypadku dwóch ostatnich parametrów łatwo zamienić je na analogiczne miary - im niższy czas przesyłania znanej ilości danych, tym lepiej.

Ostatecznie na razie wyszło coś takiego:

f(route)= suma(mnożnik_IP * (mnożnik_strat_route * straty_IP + mnożnik_opóźnień_route * opóźnienie_IP))

Dodatkowo całość należałoby przemnożyć przez mnożnik dla danego łącza[1] i wprowadzić, czy to do wzoru, czy przy podejmowaniu decyzji o przełączeniu, koszt przełączenia. Docelowo przydała by się pewnie jeszcze jakaś normalizacja względem ilości IP, żeby dodanie dodatkowych IP do sprawdzania nie powodowało zmiany wartości, bo to zmienia rolę kosztu przełączania. Najprostsza byłaby średnia, ale gryzie się z mnożnikami dla poszczególnych IP. Te z kolei chciałem mieć, bo wyobrażam sobie sytuację, że ktoś chce sprawdzać jakość łącza do różnych IP docelowych, ale niektóre (np. IP firmy) są bardziej istotne przy podejmowaniu decyzji.

Mnożniki dla route wprowadziłem z uwagi na możliwość ustawiania nie tylko routingu domyślnego, ale dla poszczególnych tras. Może się zdarzyć, że do sieci, do której łączymy się przez SSH ruch będzie wysyłany innym łączem, niż podstawowe, ze względu np. na mniejsze opóźnienia. Raczej na wyrost w tej chwili, ale kiedyś pewnie się przyda.

Przechodząc do spraw praktycznych: pobawiłem się chwilę w weekend, jest PoC - czytanie konfiga, część przykładowego konfiga, przepingowanie IP, liczenie kosztu (niedoskonałe). Czekam na zamówiony modem GSM. 56 linii kodu, commit do repo pewnie w tym tygodniu, ale o tym następnym razem. ;-)

[1] Koszt łącza miałby być dodatkowym parametrem, dzięki któremu użytkownik może w jakiś sposób odwzorować parametry pozatechniczne, choćby koszt transmisji za pośrednictwem danego łącza.

Guetzli - lepsza kompresja JPEG

rozieblox

Przedwczoraj Google ogłosiło na blogu nowe narzędzie do kompresji JPEG o nazwie Guetzli, wydawane na wolnej licencji (Apache License). Ma dawać lepsze optycznie rezultaty przy mniejszym rozmiarze wynikowym (mowa nawet o 35% mniejszych plikach). Cena? Oczywiście czas kompresji.

Postanowiłem przetestować na szybko, co mogło by się zmienić, gdybym wykorzystał grafiki skompresowane przy pomocy Guetzli na blogu. W tym celu sięgnąłem po obrazki z backupu bloga i uruchomiłem program (domyślne opcje kompilacji, domyślne ustawienia jakości, czyli 90%) na moim laptopie (CPU: Intel(R) Core(TM) i3 CPU M 380 @ 2.53GHz). Zdziwiło mnie to, że aż przy 12 plikach nie udało się ukończyć działania - program zgłosił błąd:

Invalid input JPEG file
Guetzli processing failed

Udało się przetworzyć 66 plików, całość trwała prawie 17 minut (sic!). Czyli jest bardzo wolno. Kompresor wykorzystywał tylko jeden rdzeń CPU. Efekty są obiecujące, zarówno wizualne, jaki i objętościowe. Mimo, że algorytm jest zaprojektowany z myślą o działaniu na możliwie nieprzetworzonych obrazach wejściowych, a te na blogu raczej są już zoptymalizowane, to łączny rozmiar udało się zmniejszyć o 14% (z ok. 3,3 MB do ok. 2,8 MB).

Jeśli wezmą się za wykorzystanie i optymalizację duże firmy, a jest na to szansa po uwolnieniu programu, może to oznaczać mniej przesyłanych danych po sieci, czyli szybsze ładowanie się stron, widoczne zwłaszcza na komórkach. Chwilowo główną barierą jest czas działania, który wygląda na zależny bezpośrednio od wielkości pliku wejściowego.

Zrobiłem jeszcze jeden test - plik JPG bezpośrednio z aparatu, rozmiar 2560x1440, rozmiar wejściowy 1,2 MB. Po kompresji (trwającej kilka minut) brak zauważalnych zmian jakości, natomiast rozmiar zmniejszony aż o 50% (614 kB).

Międzyczas

rozieblox

Zacząłem od opisu założeń i tym podobnych rzeczy nie związanych bezpośrednio z programowaniem, ale ciągnie wilka do lasu i chciałem się w międzyczasie na boku pobawić fragmentami kodu i modułami. Ponieważ już w komentarzach w poprzednim wpisie pojawiły się wzmianki o tym co będzie, nie będzie wielkiej szkody czy niespodzianki, jeśli nieco wybiegnę naprzód.

Na pierwszy ogień poszło pingowanie, bo właśnie w ten sposób chcę mierzyć jakość łącza. Jak można się spodziewać, do korzystania z ICMP wymagane są uprawnienia użytkownika root. Nie jest to dla mnie niespodzianką, bo spotkałem się z tym przy perlowym skrypcie do powiadamiania o konieczności wpisania CAPTCHA dla Aero2. Tym razem postanowiłem nie odpuścić, tym bardziej że w sumie dopuszczam - przynajmniej w pierwszej wersji - uruchamianie skryptu z użytkownika root. W końcu i tak będzie trzeba dotykać routingu, a do tego potrzebne są wyższe uprawnienia niż posiadają zwykli użytkownicy.

Żeby poznać najlepszy i zalecany sposób pingowania, wrzuciłem zapytanie do wyszukiwarki i... włos mi się zjeżył na głowie. Rozwiązań jest wiele, modułów jest wiele, a prostego i działającego jakoś nie widać. Zacząłem od prostego modułu ping, który ma funkcję quiet_ping robiącą to, co potrzebuję, ale o ile dał się bez problemu zainstalować z Python 2, o tyle z Python 3 ma problem:

virtualenv --python=python3 test
Already using interpreter /usr/bin/python3
Using base prefix '/usr'
New python executable in /tmp/abcc3/test/bin/python3
Also creating executable in /tmp/abcc3/test/bin/python
Installing setuptools, pkg_resources, pip, wheel...done.
source test/bin/activate
pip3 install ping
Collecting ping
  Using cached ping-0.2.tar.gz
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "", line 1, in
      File "/tmp/pip-build-qqotvnqc/ping/setup.py", line 23, in
        from ping import __version__
      File "/tmp/pip-build-qqotvnqc/ping/ping.py", line 196
        except socket.error, (errno, msg):
                           ^
    SyntaxError: invalid syntax
   
    ----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-qqotvnqc/ping/

Z kolei próba użycia modułu python3-ping wygląda tak:

pip3 install python3-ping
Collecting python3-ping
  Could not find a version that satisfies the requirement python3-ping (from versions: 2014.05.01.022aa83, 2014.05.02.805ee25, 2014.05.02.16245f0)
No matching distribution found for python3-ping

Wgląda więc, że prawdopodobnie w pierwszym etapie, by nie tracić czasu, pozostanę przy Python 2, zachowując zgodność z Python 3, a najwyżej później dostosuję całość. Nie powinno być to trudne - wystarczy wymienić moduł i jego wywołanie, funkcje u mnie i argumenty raczej się nie zmienią. Będę wdzięczny za sugestię działającego modułu do pingowania. Oczywiście zawsze zostaje użycie systemowego polecenia ping i parsowanie wyjścia, ale tego wolałbym uniknąć...

Z innych newsów okołoprojektowych: zakupiłem modem GSM, żeby mieć na czym testować. Jest wbudowana karta w lapka, mam jakieś wifi na USB, dorzucę modem i wygląda, że nawet do pięciu łącz jestem w stanie w środowisku testowym mieć. Pewnie zostanę przy dwóch-trzech, ale dobrze jest mieć perspektywy. ;-)

Założenia i opis projektu abcc

rozieblox

Projekt abcc składa się z demona, napisanego w Pythonie, który czyta plik konfiguracyjny, a następnie na podstawie jego zawartości dokonuje cyklicznej kontroli jakości dostępnych łącz względem określonych w konfiguracji IP docelowych. Przeprowadzane operacje zapisywane są do logu (syslog?), podobnie jak oceny poszczególnych łącz.

Zakładam wykorzystanie Pythona w wersji 3, przestrzeganie PEP8 i programowanie funkcyjne. Całość ma być możliwie prosta koncepcyjnie i możliwie konfigurowalna przy pomocy pliku konfiguracyjnego za pomocą wag poszczególnych wskaźników, wag IP. Rozwiązanie ma też zapewniać użytkownikowi pełną przejrzystość działania, wybór poziomu logowania i możliwość uruchomienia w wersji "na sucho", w celu przetestowania, jak uruchomienie z daną konfiguracją wpłynęłoby na zmiany routingu.

Aby to osiągnąć, zmienia na czas pomiaru routing do docelowych IP na dane łącze, dokonuje pomiaru jakości łącza, a następnie, po zebraniu danych dla wszystkich łącz, określa, które z nich jest najlepsze i - jeśli zachodzi taka potrzeba, dokonuje zmiany routingu.

Do zmiany routingu wykorzystywane są zewnętrzne skrypty bashowe - pozwala to na dostosowanie działania demona do różnych platform i potrzeb - np. dodanie zmiany NATowanaia, wywołanie zmian na zdalnym systemie (router sprzętowy) - bez zmian w samym silniku.

Teoretycznie można by to napisać w czystym Bashu i wywoływać z crona, ale po pierwsze, chcę potrenować Pythona, po drugie tak będzie łatwiej, bardziej elegancko i będzie otwarta droga np. do zwiększenia częstotliwości próbkowania przez zrównoleglenie pomiarów.

Z racji wymogów konkursowych dotyczących ilości postów, tworzenie projektu będzie trochę przegadane, i spowolnione, przynajmniej na początku. Zaleta jest taka, że będzie lepiej widać sposób rozumowania, gdyby ktoś chciał coś skomentować lub się przyłączyć. Commity kodu i dokumentacji będą się pojawiały w miarę równolegle z wpisami na blogu, pierwszy właśnie poszedł.

Geneza, nazwa i zastosowania

rozieblox

Projekt, który mam zamiar zrealizować w ramach DSP2017 nazywa się abcc (Automatic Best Connection Chooser). Pierwotnie miał się nazywać abpppcc i działać dla połączeń PPP, ale w sumie nie ma to sensu. Pomysł narodził się, gdy kiedyś znajomy z FB napisał, że jest w drodze, ma 2 czy 3 połączenia GSM i przełącza się między nimi, bo raz lepiej działa to, raz tamto. Oczywiście przełącza się ręcznie.

Stwierdziłem, że gdyby miał Linuksa, to uruchomienie wszystkich naraz, sprawdzanie automatem i przełączanie ruchu na najlepsze nie powinno być trudne. Sprawę wstępnie przemyślałem, zacząłem nawet zabawę z dwoma modemami GSM, ale wkrótce pojawiły się ważniejsze sprawy i projekt trafił do szuflady. Znaczy na dysk. Nawet nie tyle projekt, co krótko spisane wstępne założenia i wymyślona nazwa.

Potem stwierdziłem, że rozwiązanie można zastosować też w innych okolicznościach, nie tylko przy laptopie w podróży. Może służyć do przełączania ruchu na łącze zapasowe w przypadku sieci i routera na Linuksie i pogorszeniu parametrów łącza podstawowego, a nawet... do sterowania ruchem operatorskim.

W tym ostatnim zastosowaniu oczywiste jest podobieństwo do rozwiązania firmy Border6 omówionego na PLNOG13, przy czym to co zamierzam napisać jest o wiele bardziej prymitywne, więc mam nadzieję, że klientów nie odbierze. Choć IMO ma szansę być opensource'ową namiastką.

Blox.pl - feed RSS dla pojedynczej kategorii

rozieblox

Wymaganiem udziału w konkuresie DSP2017 jest podanie feedu RSS zawierającego wyłącznie posty związane z konkursem. Blox.pl spłatał mi niemiłego figla i dał wybór - albo stary, paskudny wygląd, albo brak możliwości pobrania feedu RSS dla pojedynczej kategorii. Sprawę zgłosiłem, ale znając czasy realizacji stwierdziłem, że mam trzy możliwości: zrezygnować z DSP2017, postawić osobnego bloga specjalnie dla DSP2017 albo zrobić coś samemu.

Pierwsze dwie możliwości odrzuciłem. Jakoś nie widział mi się blog z 20 postami, kolejnego prowadzić mi się nie chce, a Blox ma swoje zalety i do porzucenia jeszcze nie dojrzałem. Spojrzałem co też mam do dyspozycji pod ręką, bo w pewne parsowanie feedu RSS bawiłem się już przy pomocy Perla (patrz zawartość mojego konta na blabler.pl). Niestety, stwierdziłem, że niezbyt się to nadaje do użytku.

Poza tym, przeszedłem na Pythona, więc pomyślałem o małej rozgrzewce. Pierwszym pomysłem było przeparsowanie całego feeda i złożenie RSS. Znalazłem przykłady parsowania XML z użyciem beautifulsoup4, z którego zresztą trochę wcześniej korzystałem. Wyciąganie zawartości poszczególnych postów poszło bardzo dobrze.

Stwierdziłem, że zamiast się bawić w tworzenie feedu kolejnym modułem, w ramach eksperymentu dodam przy pomocy chamskich printów nagłówki od XML. O dziwo zadziałało, Firefox widział coś, co wyglądało prawie jak oryginał. Jedynym problemem było kodowanie - zdecydowanie był problem z pl-znakami. Rzecz w tym, że Blox używa iso-8859-2, a Python wypluwa UTF-8. Wystarczyła szybka zmiana deklaracji kodowania w nagłówku XML i już było OK.

Kolejny problem wyszedł przy przepuszczeniu feeda przez validatory feedów RSS. Okazało się, że beautifulsoup4 zamienia wszystkie znaki w tagach na lowercase i - wierząc szybkiemu sprawdzeniu - nie ma prostego sposobu, by go od tego odwieść. Podjąłem próbę zamiany moduł na inny, ale szybko zrezygnowałem na rzecz brzydkich, ale skutecznych sedów na wyniku działania skryptu.

Na koniec zostało dodanie wywołania (z użyciem utworzonego na tę okoliczność virutalenv) do crona:

*/15 * * * * /home/rozie/dsp2017/bin/python /home/rozie/rss_from_category_blox.py 2>/dev/null | /bin/sed s'/pubdate/pubDate/g' | /bin/sed 's/lastbuilddate/lastBuildDate/g' > /tmp/dsp2017.xml && /bin/mv -f /tmp/dsp2017.xml /var/www/dsp2017.xml
*/15 * * * * /home/rozie/dsp2017/bin/python /home/rozie/rss_from_category_blox.py 2>/dev/null > /tmp/dsp2017.xml && /bin/mv -f /tmp/dsp2017.xml /var/www/dsp2017.xml

Całość wrzucam na GitHub, na wypadek, gdyby miało się komuś przydać.


UPDATE: Zgodnie z sugestią z komentarza, parsuję XML prawidłowo i pozbyłem się sed poprawiającego wyjście.

5 powodów do udziału w DSP2017

rozieblox

Nie jestem programistą i nie jest to blog programistyczny[1]. Czemu więc dołączyłem do konkursu Daj Się Poznać 2017?

  • Po pierwsze, uważam, że to świetna inicjatywa, dobra zabawa i doskonały motywator.
  • Po drugie, zawsze lubiłem konkursy programistyczne typu Potyczki Alogrytmiczne.
  • Po trzecie, uważam, że administrator powinien znać przynajmniej podstawy programowania, nawet jeśli nie udziela się programistycznie w większych projektach. Zresztą, devops (modne słowo) way to konfiguracja jako kod i bez przynajmniej podstaw jest... ciężko. Jeśli w ogóle się da. ;-)
  • Po czwarte, ostatnio spodobał mi się Python i jest okazja, żeby poćwiczyć.
  • Po piąte, mam pomysł na mały projekt, który trafił do szuflady (czytaj: na dysk) i DSP2017 jest świetną okazją, żeby go zmaterializować. Jak to ładnie ktoś ujął "wizja bez implementacji to halucynacja".

Największy problem sprawiła mi... platforma bloga czyli sam Blox. Wymogiem uczestnictwa w DSP2017 jest podanie kanału RSS, na którym będą pojawiały się wpisy konkursowe. I tylko one. Niestety, nic takiego tu nie istnieje, przynajmniej nie w nowym szablonie. Zgłosiłem to na forum, mają sprawdzać, ale złudzeń nie mam - muszę radzić sobie sam. Jest plan, szczegóły jutro.

Konkursem zainteresowałem się bliżej 28. lutego i powyższy problem sprawił, że pierwotnie odpuściłem, na szczęście zapisy do DSP2017 zostały przedłużone do 12. marca, więc podobnie jak ja macie jeszcze szansę zdążyć się zarejestrować.

Do całości podchodzę luźno - ma to być głównie motywator do materializacji projektu i okazja do poćwiczenia Pythona. Biorąc pod uwagę ilość wpisów na blogu, głównym problemem mogą być same dwa wpisy tygodniowo, a szczególnie ten drugi, niekoniecznie związany z projektem. A jeszcze trzeba sam projekt realizować... Niemniej, trzeba próbować. :-)

[1] Mam nadzieję, że to wyznanie nie spowoduje dyskwalifikacji. Postaram się spełnić wymagania konkursowe.

Jak włączyć SSH w Raspbian?

rozieblox

Sytuacja zmusiła mnie do odkopania RPi. Szybko potrzebowałem przetestować jedną rzecz, więc wybrałem Raspbian Jessie Lite. Główna zaleta to niewielki rozmiar i kernel w wersji 4.4. Po włączeniu i pobraniu IP przez RPi okazało się jednak, że nie sposób się zalogować - nic nie słuchało na porcie.

Instrukcje, które znalazłem, są dobre, jeśli ktoś ma monitor i klawiaturę. Ja nic takiego pod ręką nie miałem, więc zacząłem przyglądać się skryptom startowym, ale w międzyczasie zapytałem na IRCu i dostałem linka, który podaje prosty przepis na włączenie SSH - wystarczy utworzyć plik ssh o dowolnej zawartości w katalogu /boot na karcie SD z Rasbianem:

touch /boot/ssh

Oczywiście powyższe zadziałałoby, gdyby było wykonywane bezpośrednio z Raspberry Pi, trzeba wziąć poprawkę na punkt montowania, ale wiadomo o co chodzi. ;-)

Po tym zabiegu SSH jest dostępne po uruchomieniu systemu, zalogować się można tradycyjnie przy pomocy użytkownika pi i hasła raspberry.

Wyłączenie SSH w domyślnej wersji podyktowane było względami bezpieczeństwa (tu link).

Z kronikarskiego obowiązku: w Raspbianie bazujązym na Jessie wiele się nie zmieniło. Swap nadal domyślnie włączony i zarządzany w dziwny sposób (nie /etc/fstab), journal na FS obecny, sterowanie LED i odczyt temperatury bez zmian.

Autossh

rozieblox

Jak zapowiedziałem w notce o porządkach, przepiąłem się z łącza ADSL na komórkę. Decyzję przyspieszyła wydatnie awaria ADSL, polegająca na tym, że transfery liczone są w pojedynczych kB, a mimo obiecującego początkowego kontaktu, awaria nadal trwa... Przy czym po tym jak odesłałem parametry łącza, które chcieli, to przestali się odzywać, mimo dwóch kontaktów mailowych z mojej strony.

Nie obyło się bez zawirowań i ledwo działający dostęp ADSL ratował mi tyłek, ale może o tym w innej notce. W tej chwili sytuacja wygląda tak, że cały ruch leci przez modem GSM wpięty do routera na Banana Pi. Jeśli chodzi o dostawcę łącza, to poszedłem na łatwiznę i jest to Aero2. W zeszłym miesiącu zużyłem (tj. bardziej rodzice) niecałe 2GB z 3GB pakietu. Czyli przewidywany koszt łącza to 5-10 zł/m-c. Wyższe pingi nie są problemem, zresztą różnica w stosunku do BSA jest niewielka. Prędkość to jakieś 3/1 Mbps[1], więc też lepiej, niż było.

Problemem okazał się dostęp do routera, który chciałbym zachować. Znalazłem autossh, o którym wspominałem w komentarzach do notki o porządkach, ale uruchomienie zajęło znacznie więcej czasu, mimo prostych instrukcji. Oczywiście wszystko przez moje niezrozumienie tematu, albo raczej wcześniejsze wyobrażenia. Liczyłem, że po zestawieniu tunelu, łącząc się do zdalnego hosta na określonym porcie, zostanę automagicznie przekierowany do hosta za NAT, z którego jest zestawiony tunel.

Tak jednak nie jest. Autossh słucha na zdalnym hoście wyłącznie na adresie lokalnym (127.0.0.1) i zdebugowanie tego zajęło mi dłuższą chwilę, więc może oszczędzę tym wpisem komuś szukania. Korzystając z instrukcji dostępnych w sieci faktycznie połączymy się do hosta za NAT, ale tylko z maszyny do której jest zestawiony tunel. Można wystawić ten dostęp na świat, ale wymaga to dodatkowego przekierowania portu, czy to przy pomocy iptables, czy programu redir.

Ostatecznie wypracowałem następujący schemat. Połączenie zestawione z hosta za NAT przy pomocy autossh (uruchamiane przy starcie systemu, logowanie po kluczach bez hasła):

autossh -f -M 5122 -N -R 8888:127.0.0.1:22 user@host

Jeśli chcę się dostać do routera (hosta za NAT) to na hoście docelowym uruchamiam przekierowanie portów:

redir --lport=8888 --laddr=IP_PUBLICZNE --cport=8888 --caddr=127.0.0.1

W tym momencie łącząc się na port 8888 maszyny z publicznym IP, de facto łączę się do routera za NAT:

ssh -p 8888 user_za_nat@host

Oczywiście analogicznie mogę także zestawiać tunele SSH itp., które umożliwią mi wyjście w świat przez modem GSM.

Czemu redir, a nie iptables? Nie potrzebuję dostępu do tej maszyny cały czas, więc wolę uruchomić na chwilę przekierowanie, niż wystawiać router na świat, chociaż po docelowym zabezpieczeniu pewnie się to zmieni.

[1] Tzn. 3/1Mbps wykazał speedtest, ale może być lepiej, zwł. download - później zauważyłem, że konfigurując router ustawiłem limitowanie pasma na 3 Mbps dla pojedynczej końcówki za NAT.

Planeta Joggera - About

rozieblox

Powstała strona about dla planety Joggera. Normalnie bym nie pisał o tym, ale prośba do linkujących do planety o... zmianę linkowania i kierowanie bezpośrednio na stronę O planecie.

Powód jest prosty - indeksowanie w wyszukiwarkach. Było poruszone w komentarzach, że ludzie szukający zamkniętego Joggera w wyszukiwarce nie mają szansy trafić na planetę i... faktycznie nie mają, bo indeksowanie treści na planecie jest wyłączone, żeby nie podbierać treści właściwym blogom. A na stronie Jogger.pl nie ma żadnej wzmianki o planecie (i nie mam na to żadnego wpływu).

Żeby wilk był syty i owca cała, strona about deklaruje, że chce być indeksowana, archiwizowana i w ogóle. Jeśli wszystko pójdzie dobrze, będzie ona - i tylko ona - widoczna w wyszukiwarkach. Zatem linkujemy bezpośrednio do niej.

Oczywiście aktualna wersja to raczej zalążek. Jeśli ktoś czuje się na siłach, pomoc w skleceniu sensowniejszego about mile widziana.

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