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.

Debian Bookworm

Debian 12 o nazwie Bookworm został wydany niemal dwa miesiące temu. Zapomniałem o wpisie z tej okazji, choć większość systemów (kilka desktopów, kilka serwerów) już zaktualizowałem. Może dlatego, że aktualizacja bezproblemowa, żeby nie powiedzieć nudna. Zatem zgodnie z tradycją, wrażenia z aktualizacji.

Przy aktualizacji do Bookworm warto pamiętać o dwóch istotnych zmianach:

  1. Niewolne firmware zostały przeniesione z non-free do non-free-firmware. Jeśli korzystamy, to warto dodać stosowny wpis w sources.list. I przy okazji można pomyśleć, czy potrzebujemy non-free. Jeśli nie, można usunąć.
  2. W związku ze zmianami w pakietach, pojawił się osobny pakiet systemd-resolved. Teoretycznie nie powinien być potrzebny, bo w domyślnej konfiguracji rozwiązywanie nazw nie korzystało z rozwiązania systemd. W praktyce na paru – ale nie wszystkich – VMkach resolvowanie DNS przestało mi działać, a doinstalowanie systemd-resolved rozwiązało problem. Polecam zatem pobranie go przed rozpoczęciem aktualizacji[1]:

wget http://ftp.de.debian.org/debian/pool/main/s/systemd/systemd-resolved_252.12-1~deb12u1_amd64.deb

Gdyby rozwiązywanie nazw nie działało po aktualizacji, będzie pod ręką i wystarczy wtedy

dpkg -i systemd-resolved_252.12-1~deb12u1_amd64.deb

W przeciwnym razie będziemy zmuszeni do drobnej kombinacji z dostarczeniem pakietu przy nie do końca działającej sieci. Co nie jest trudne, ale nieco bardziej niewygodne.

[1] Wersja dla amd64, pozostałe architektury dostępne na https://packages.debian.org/bookworm/systemd-resolved