Postaw kawę

Przy pewnej okazji dostałem pytanie, czy korzystam z jakiegoś rozwiązania, gdzie można postawić mi wirtualną kawę. Pytający w przykładzie użył serwisu buycoffee.to. Nie miałem nic takiego. Kiedyś myślałem o Patronite, ale jakoś nie czułem, bym zasługiwał. Zerknąłem na buycoffee.to i stwierdziłem, że założę konto. Po pierwsze, kojarzyłem logo, po drugie, jest to ładnie umocowane legalnie i ma proste zasady, do tego jakoś tak przejrzyście opisane. Last but not least – firma jest z okolic Poznania.

Nadal uważam, że blog pewnie nie zaowocuje wpłatami, ale… robię jeszcze parę rzeczy (kapela, jakieś prezentacje, jakiś open source), więc niech sobie będzie, może komuś się działalność spodoba, uzna za ją za wartościową i zechce postawić kawę. Tym bardziej, że konto w serwisie nie kosztuje, a darowizny korzystnie się rozlicza. Może nie prosto, od strony obdarowywanego, bo trzeba pilnować ostatnich sześciu lat per darczyńca, ale w praktyce nie płaci się podatku. Zresztą, eksport do arkusza, tabela przestawna i gotowe. Gdyby kogoś temat interesował, to dają dobry artykuł nt. rozliczania darowizn.

Nie jest tak, że serwis od darowizn jest za darmo. Pobierają dwie opłaty – 2,5% kosztu transakcyjnego oraz 7,5% opłaty serwisowej. Patronite byłby nieco tańszy, ale różnica jest pomijalna. Ta opłata serwisowa wydaje mi się dość spora, jeśli ktoś ma większe obroty. Mogła by być górna kwota opłat, powyżej której opłata serwisowa nie jest pobierana. W sumie ciekawe czy nie właśnie dlatego Radio 357 zaczęło przyjmować wpłaty na własną rękę?

Zatem, po krótkiej walce z WordPressem[1], w paru miejscach (strona główna, sidebar na blogu) pojawiło się logo serwisu buycoffee.to, prowadzące do miejsca, gdzie można postawić wirtualną kawę. I zapewne zostanie tam na dłużej w ramach eksperymentu. Tym bardziej, że zamierzam wkrótce definitywnie i całkowicie rozstać się z reklamami Google AdSense. Ale o tym będzie już w innym wpisie…

[1] Dodanie jest w skrajnie nieintuicyjnym miejscu. I w skrajnie nieintuicyjny sposób. W ogóle dziwna organizacja tego wszystkiego, a jeszcze mam WordPressa po polsku… W każdym razie skończyło się dodaniem kodu HTML w sidebar. Znaczy wygląd -> widżety.

Aktualizacyjne wpadki

Aktualizować, czy nie aktualizować, oto jest (odwieczne) pytanie. Na systemie, gdzie działa blog wychodzę z założenia, że aktualizować. Nie jest to żaden krytyczny system, problemy z unattended-upgrades są rzadkie. Za to aktualizacje bezpieczeństwa są całkiem częste, więc po co pilnować tego i co chwila klepać apt update && apt upgrade, skoro może się zrobić samo?

Jednak wczoraj sprawdziłem maile i okazało się, że jest wiadomość, że blog leży. Od godziny szóstej z małymi groszami. Przemknęło mi przez myśl, że może jakiś błąd monitoringu, albo zablokowałem im IP (tzn. ktoś ich dopisał jako złośliwe IP, a korzystam z blokad). Jednak otwarcie bloga w przeglądarce potwierdziło. Backendu nie ma, błąd 502, zła brama.

„Równa” godzina podpowiadała, że to jednak coś automatycznego. No i faktycznie, spojrzałem w konfig nginx, powinien korzystać z php-fpm 8.3. A tymczasem takiej wersji w systemie nie ma. Choć była, bo konfiguracje zostały[1]. Za to jest php-fpm 8.4. Cóż, szybka poprawa konfiguracji nginx, by korzystał z nowej wersji, dostosowanie konfiguracji PHP, doinstalowanie brakujących pakietów (np. obsługa mysql) i… działa.

Trochę nie dawało mi spokoju co się dokładnie stało, więc jak tylko miałem chwilę, sprawdziłem logi unattended-upgrades. A tam:

2025-04-03 06:08:19,883 INFO Packages that will be upgraded: php-common php-fpm
2025-04-03 06:08:19,883 INFO Writing dpkg log to /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
2025-04-03 06:08:54,101 INFO All upgrades installed
2025-04-03 06:09:11,494 INFO Packages that were successfully auto-removed: php8.3-cli php8.3-fpm php8.3-opcache php8.3-readline

Zagadki nie ma, żadnej, wszystko jest w zależnościach pakietu php-fpm:

Package: php-fpm
Depends: php8.4-fpm

Dodam jedynie, że problem wynika w tym przypadku z wykorzystania nieoficjalnego repozytorium, z nowszymi wersjami PHP packages.sury.org. W waniliowym Debianie wszystko by działało. Ale PHP byłoby w wersji 8.2. W sumie nie jest to jakaś wielka różnica – kiedyś była większa. Możliwe, że wrócę do waniliowego Debiana… Tym bardziej, że wkrótce wydanie kolejnej wersji stabilnej.

UPDATE: Po krótkim namyśle stwierdziłem, że nie ma na co czekać na nowe wydanie i wróciłem do waniliowego Debiana już teraz. Zresztą przy aktualizacji i tak jest zalecane usunięcie pakietów z 3rd party repozytoriów…

[1] Debian przy usuwaniu pakietu zwykle nie usuwa jego konfiguracji.

Zatrzymanie planety

Niedawno napisałem, że planeta weszła na dach. Jest to nawiązanie do pewnego dowcipu, który w jednej z późniejszych odpowiedzi zacytowałem. Dowcip najbardziej kojarzę z ostatniego odcinka drugiego sezonu serialu Przystanek Alaska pod tytułem Slow dance i jest tam genialnie podany.

Jednak do rzeczy. Planeta Joggera została uruchomiona prawie równo dziewięć lat temu. Już wtedy Planet Venus, czyli oprogramowanie, o które jest oparta, wyglądało na nierozwijane. Ale znałem je i były pakiety w Debianie, więc uznałem, że jest to jakoś utrzymywane i łatwo dostępne. Liczyłem, że w tak zwanym międzyczasie znajdę jakąś rozwijaną alternatywę. Albo sam wprowadzę zmiany.

W międzyczasie zauważyłem, że są problemy z kodowaniem, które zwalałem na obsługę UTF-8 w Pythonie 2. Nawet robiłem jakieś podejście do naprawy, bez sukcesu. A na przepisywanie na Pythona 3 nie miałem czasu.

Fast forward. Zgłoszenie błędu pewnie jest bliższe prawdy. Problem nie jest z UTF-8, a z emoji. Jednak nie w tym rzecz. Silnik działa na Pythonie 2, który jest nierozwijany od lat. Debian, na którym jest to aktualnie uruchomiony, jest prehistoryczny, bez wsparcia bezpieczeństwa. Zaraz wychodzi kolejna wersja i będzie mnie to uwierać jeszcze bardziej. Nie jest to coś, co chcę mieć uruchomione na serwerze, nawet w kontenerze.

Próbowałem napisać własny prosty parser feedów w Pythonie. W końcu robiłem to parę razy. Nie jest to niby trudne, ale… Formatów feedów jest wiele. I czym innym jest pobranie informacji z feedu, co robiłem dotychczas, a czym innym pobranie HTML. W grę wchodzą błędy bezpieczeństwa (XSSy i podobne atrakcje), konieczność poprawy linków na bezwzględne. Format niby jest standardowy i jest do tego feedparser, ale różni się znacznie między feedami blogów z których składa się planeta. Last but not least, jeden feed to nie zbiór feedów, jakiś cache by tu się przydał.

Wspominałem, że popularna i polecana biblioteka do tzw. sanityzacji HTML w Pythonie bleach, nie jest już rozwijana? Nadal działa, ale… No i nie korzysta się z tego tak po prostu. Co z tego, że zrobię sanityzację linków do obrazków, jeśli zamiast zdjęcia wyświetli się kod HTML. Wygląda to fatalnie. Mogę usunąć te tagi i wtedy po prostu nie będzie zdjęć. Też średnio.

Kolejna sprawa: ruch. O ile planeta ma stały ruch – i przyznaję, że sam często korzystam w ten sposób – to jest on niewielki.

Ostatnia sprawa: czas. Po tym, jak znowu spędziłem z godzinę na szukaniu alternatyw i kolejną na próbach napisania własnego parsera stwierdzam, że nie mam czasu. OK, nauczyłem się nieco o parsowaniu feedów i sanityzacji w Pythonie. Znalazłem alternatywny soft w Ruby, nierozwijany od raptem 5 lat, czyli w porównaniu – nówka. No ale nie jestem przekonany do niego. I nie mam teraz czasu na zabawę.

Co wchodzi w grę dalej:

  • Uruchomienie planety na innej domenie, niezależnie od wybranego silnika. Rozwiązuje – w sumie tylko mój – problem z XSS itp. Nawet mam domenę i serwer. Mógłbym luźniej podejść do sanityzacji. Tylko nadal, to będzie słaby, niebezpieczny soft. I trzeba go napisać.
  • Prosta planeta, gdzie będą tylko tytuły i daty wpisów. Może tekstowy fragment opisu, bez formatowania HTML. Przyznaję, że ma to swoje zalety, jeśli chodzi o pisanie kodu i jest mi blisko do tego rozwiązania. Nadal, trzeba napisać, przetestować, uruchomić.
  • Ktoś z większym zapałem przejmuje planetę. W sumie oczywista oczywistość, cała konfiguracja i wszystkie potrzebne pliki są dostępna na GitHub.

Tymczasem w najbliższym czasie Planeta przestanie aktualizować wpisy. Nie wyłączam zupełnie, bo jest tam trochę linków do blogów. Nie podjąłem decyzji o wyłączeniu (w końcu finalnie to statyczny plik HTML, więc co tu wyłączać). Jako ołtarzyk – zostaje.