Noworoczne porządki

Postanowień noworocznych brak, ale zmiana roku na 2022 to dobry moment na porządki informatyczne z jednej strony, a na ich zapowiedź – w roli motywatora – z drugiej.

PUM

Zaczęło się od informacji na IRCu, że PUM przestał działać[1]. Przyczyną okazała się cicha zmiana API przez Uptime Robot. API v2 to większe zmiany, niż sądziłem – część danych przekazywana jest teraz w payload w POST, pojawił się limit zapytań w czasie, lekkie zmiany formatu danych. Nie wiem, czy pierwsza wersja umiała zwracać dane w JSON, v2 potrafi. Rzut oka na Perla i wiedziałem, że raczej do przepisania na Pythona[2], przy okazji parę zmian i… trochę utknąłem. Mam „większą połowę” zrobioną, obecnie jestem rozdarty między chęcią zachowania dokładnej starej funkcjonalności, a napisaniem tego bardziej elegancko. W ogóle trochę uderza mnie oglądana z perspektywy zwięzłość Perla.

Zrobiłem. Nie jestem w 100% zadowolony, ale pum.pl is dead, long live pum.py!

Nextbike

Monitoring ilości rowerów Nextbike na stacjach zacząłem w roku 2013. W roku 2017 skrypt został przepisany na zgrabniejszego Pythona. O ile na początku zaglądałem regularnie, to obecnie praktycznie nie korzystam. Powód jest prosty: rzadko kiedy korzystam z rowerów na stacjach. Odkąd pojawiły się rowery z odbiornikiem GPS, niemal zawsze w praktyce biorę rower „z ulicy”, nie ze stacji. I tak go zostawiam. Po prostu niemal zawsze bliżej mam jakiś rower luzem. No i rzadko moja trasa kończy się na stacji Nextbike.

Co się udało w tym projekciku? Całkiem sporo: działał i był użyteczny, przynajmniej dla mnie, przynajmniej przez pewien czas. Pozwoliły poćwiczyć Pythona i zapoznałem się w praktyce z jinja2. Nauczyłem się, ile (nie)warte są „darmowe” domeny (tu: .tk).

Co się nie udało? Liczyłem, że stanie się popularniejszy. Nie udał się eksperyment z automatycznym SEO. Liczyłem, że dobrze otagowane strony z konkretnymi informacjami trafią wysoko w pozycje w wyszukiwarce Google. Nie było całkiem źle, ale gorzej, niż liczyłem, biorąc pod uwagę otagowanie metadanymi. Chęć zachowania maksymalnej prostoty i automatyzacji spowodowały, że nie dodawałem dodatkowej treści, mogącej pozytywnie wpłynąć na pozycjonowanie.

Wkrótce projekt przestanie istnieć – skrypt zostanie wyłączony i zapewne trafi na GH.

Hosting

Szykuje się zmiana platformy, na której utrzymuję hosting. VPS w Aruba Cloud podrożał jakiś czas temu i od tamtego czasu rozglądałem się niespiesznie za czymś innym. W zasadzie decyzja już zapadła i była pierwsza próba, niestety, weryfikacja kart w nowym miejscu jest lekko przesadzona. Ma szansę być szybciej, bo znacznie większe zasoby, ma szansę być wesoło, bo szykuje się przesiadka na architekturę ARM. Nie rozwijam tematu, bo zapewne zasłuży na osobny wpis.

Tyle z większych planowanych zmian. Od dawna wisi temat lekko przestarzałego softu do tworzenia Planety Joggera, ale na razie się nie pali – póki co system posiada jeszcze wsparcie.

[1] Tak, jest pomysł na drobną modyfikację we wszystkich skryptach tak, by przy błędzie wykonana powiadamiały np. mailem. Bo nie jest to pierwszy raz, kiedy o padzie czegoś z powodu zmian po stronie źródła dowiaduję się po długim czasie. Inna sprawa, że to nic krytycznego.
[2] Nazwa zostanie bo Perl Uptime Monitor -> Python Uptime Monitor.

Certstream HOWTO

Do czego można wykorzystać dane pochodzące z certstream można zobaczyć choćby na prezentacji z konferencji z BSides Warsaw z 2019 roku. Ponieważ każdy ma certstream, mam i ja. Nie jest to zbyt zasobożerne, a można popatrzeć pod kątem security i phishingu, co w sieci piszczy.

Problem

Niestety, zauważyłem korzystanie z certstream jak w przykładach, z użyciem biblioteki Pythona nie jest idealne. Problem objawia się tym, że co jakiś czas następuje zerwanie połączenia z serwerem widoczne jako:

[ERROR:certstream] 2021-11-22 17:18:01,171 - Error connecting to CertStream - Connection to remote host was lost. - Sleeping for a few seconds and trying again…
[INFO:certstream] 2021-11-22 17:18:06,564 - Connection established to CertStream! Listening for events…
[ERROR:certstream] 2021-11-22 17:18:51,893 - Error connecting to CertStream - Connection to remote host was lost. - Sleeping for a few seconds and trying again…
[INFO:certstream] 2021-11-22 17:18:57,213 - Connection established to CertStream! Listening for events…

Początkowo nie wydawało się to dramatem. Kilka sekund przerwy, co parę minut nie powinno mocno wpływać na wyniki. Niestety, pominięte certyfikaty okazały się zauważalne, więc zacząłem szukać przyczyny i rozwiązania tego problemu.

Debug

Na pierwszy ogień poszła wyszukiwarka. Okazało się, że ludzie mają ten problem w różnych warunkach. Jedni sugerowali, że zależne jest to od wersji Pythona. Inni nie potwierdzali i sugerowali problem z serwerem certstream.calidog.io. Podejrzewałem także zbyt niską wydajność serwera VPS na którym działa skrypt, ale ten pomysł szybko odrzuciłem – na mocniejszym VPS nie było wielkiej różnicy. Problem nie był palący i przeleżał trochę czasu. Dopiero na którejś konferencji zaczepiłem Adama L., który również korzysta z certstream i zdarza mu się wspominać w prezentacjach o tym. Zasugerował problem z biblioteką, jej debug i zrobienie po swojemu, na wzór.

Zainspirowało mnie to do bliższych oględzin. Nie jest to trudne – biblioteka jest niewielka i prosta. Na pierwszy ogień poszła złożoność operacji wykonywanych w skrypcie podczas sprawdzania domen. Szybko jednak okazało się, że nawet nie wykonując jakichkolwiek operacji, nawet nie wyświetlając domen, nadal obserwuję rozłączenia. Postanowiłem spróbować skorzystać z innego serwera certstream, tym bardziej, że biblioteka wprost przewiduje zmianę URLa. Tyle, że miałem problem ze znalezieniem takowego.

Na szczęście CaliDog udostępnia także kod źródłowy serwera napisany w… Eliksirze. Nie ukrywam, że była to dla mnie nowość. Instalacja na Debianie była pewnym wyzwaniem. Dla leniwych jest dostępny obraz dockera, ale z pewnych względów stwierdziłem, że wolę zainstalować w systemie.

Instalacja serwera certstream na Debianie

Instalacja na Debianie Bullseye jest w zasadzie zgodna z tym, co napisano w instrukcji repo i na stronie Elixir. Czyli nie jest zgodna. Pierwsza sprawa, to brak pakietów dla Bullseye[1]. Bez problemu można jednak skorzystać z pakietów przygotowanych dla starszej wersji, czyli Buster. W pliku /etc/apt/sources.list.d/erlang-solutions.list powinno pojawić się zatem:

deb http://binaries.erlang-solutions.com/debian buster contrib

Kolejna rzecz powodująca problemy z uruchomieniem serwera certstream to konieczność doinstalowania pakietu erlang-dev:

apt-get install erlang-dev

Po tych zabiegach serwer powinien się bez problemu uruchomić. Domyślnie działa bez szyfrowania na porcie 4000, więc jeśli nie postawimy frontu z certyfikatem SSL, to URL serwera certstream zmieni się z domyślnego wss://certstream.calidog.io na ws://NASZ.ADRES:4000 – trzeba podać port i usunąć jedno s.

Po uruchomieniu własnego serwera i podłączeniu tego samego skryptu, z tego samego VPSa, okazało się, że rozłączenia prawie nie występują. Zaś porównując ilość zgubionych domen okazało się, że jest ich znacznie więcej, niż przypuszczałem. Nawet średnie kilkadziesiąt procent.

Serwis

Do pełni szczęścia brakuje tylko, aby wszystko działało automatycznie. Można to uzyskać tworząc serwis. Można np. utworzyć plik:

/etc/systemd/system/certstream-server.service

o zawartości

[Unit]
Description=Certstream server service
After=network.target
StartLimitIntervalSec=3


[Service]
Type=simple
Restart=always
RestartSec=1
User=certstream
WorkingDirectory=/opt/certstream-server
ExecStart=/usr/bin/mix run --no-halt

[Install]
WantedBy=multi-user.target

Następnie należy zarejestrować serwis i można cieszyć się serwisem uruchamiającym się automatycznie podczas startu systemu. A także po ew. awarii. Ścieżki i user do dokonfigurowania we własnym zakresie.

[1] UPDATE: Część o braku pakietów dla Bullseye jest nieaktualna. Ze sporym opóźnieniem, ale się pojawiły. Warto zatem korzystać z wersji dedykowanej dla używanej dystrybucji.

Książki, Biblionetka, BookWyrm

Od zawsze korzystam z Biblionetki, dziś przeczytałem wpis o BookWyrm. Przypomniał mi o moich skomplikowanych relacjach z Biblionetką. Serwisu używam od zawsze, ale nie raz myślałem o migracji. Dawno temu serwis co prawda żył, ale wyrosła mu międzynarodowa konkurencja w postaci Goodreads. Wyglądał na nierozwijany programistycznie, a międzynarodowa konkurencja w social media raczej nie służy serwisom lokalnym. Patrz Nasza Klasa.

Potem Biblionetka została odświeżona, ponadto nie jest to serwis krytyczny z mojego punktu widzenia, dodatkowo okazało się, że na Goodreads brakuje wielu pozycji, które były na Biblionetce. Nie zmigrowałem więc. Stwierdziłem, że poczekam.

Poczekałem nieco dłużej, niż planowałem i… okazało się, że Goodreads likwiduje API. I w tym momencie gdybym korzystał z Goodreads, to rozważałbym ucieczkę. Albo raczej szukał miejsca, do którego się przenieść. Nie żeby Biblionetka miała API. Ale da się skorzystać z jej danych, co pokazuje choćby serwis do korelacji, o którym pisałem w jaką książkę warto przeczytać. Nie ma API, ale rozwiązanie 3rd party działa po niemal dekadzie. Szacun.

Tymczasem wpis o BookWyrm wspomina o możliwości importu danych z innych serwisów. Na przykład z Goodreads. O Biblionetce nic nie ma, ale nie dziwi mnie to. Stwierdziłem, że w sumie może warto robić backup ocen. Albo mieć skrypt, który zescrapuje dane ze strony i zwróci formę łatwą do parsowania.

Nie mam złudzeń, ze względu na różnice językowe to rozwiązanie nie wystarczy do eksportu do BookWyrm. Ale na pewno taką migrację ułatwi. Autor albo nie będzie wymagał interwencji, albo co najwyżej wystarczy zmapować raz. Przypuszczam, że autor plus automatyczne tłumaczenie tytułu pozwoli w wielu przypadkach na określenie tytułu.

Tak czy inaczej powstał taki oto scrapper Biblionetki. I jeśli ktoś przypuszcza, że można w ten sposób pobrać oceny wszystkich użytkowników, to prawdopodobnie ma rację. Publikuję, bo podstawowe, założone użycie to backup własnych ocen.