Kategoria: Linux

Opublikowane w

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.

Opublikowane w

Ubuntu – płatne bezpieczeństwo

Ubuntu LTS kojarzy się nam z dystrybucją stabilną i bezpieczną, prawda? Otóż niezupełnie tak jest. Bowiem nie wszystkie pakiety w Ubuntu LTS (np. 20.04 LTS czy 22.04 LTS) otrzymują aktualizacje bezpieczeństwa. Przynajmniej nie za darmo. Od strony technicznej, które pakiety otrzymują aktualizacje (main), a które niekoniecznie (universe) przeczytacie w artykule na nfsec.pl, podobnie jak o genezie szumu wokół Ubuntu i repozytorium ESM (Expanded Security Maintenance).

Zarys sytuacji

Zamiast na stronie technicznej, skupię się na stronie etycznej i prawnej. Sytuacja wygląda bowiem na dość skomplikowaną. Tytułem wprowadzenia niezbędny skrót. Ubuntu w ramach Ubuntu Pro daje między innymi dostęp do repozytorium ESM, które zawiera łatki bezpieczeństwa do tych pakietów z repozytorium universe, do których zostały one przygotowane przez opłaconych przez Ubuntu maintainterów, zamiast przez maintainerów ze społeczności. Osoby fizyczne (personal) mogą bezpłatnie korzystać z Ubuntu Pro na maksymalnie 5 systemach. Natomiast firmy (enterprise) powinny zapłacić za dostęp, albo… nie korzystać z załatanych pakietów. Jest jeszcze trzecia kategoria – edukacja (education, research, and academia). Też powinni kupić, ale dostaną zniżkę w niejawnej wysokości.

Abonament na bezpieczeństwo

Mam mocno mieszane uczucia w stosunku do tego podejścia. Z jednej strony nie ulega wątpliwości, że maintainerzy, którzy wykonali na zlecenie pracę, której nikt nie chciał podjąć się za darmo, powinni otrzymać wynagrodzenie. Z drugiej strony, jest to podcinanie gałęzi, na której się siedzi i z której Ubuntu wyrasta. Bowiem maintainterzy społeczności mogą dojść do wniosku, że nie ma sensu robić za darmo tego, za co inni otrzymują wynagrodzenie. To z czasem może przełożyć się na gorsze wsparcie wolnego oprogramowania, w szczególności dystrybucji opartych o pakiety deb.

Kolejny aspekt to pewnego rodzaju szantaż w stosunku do użytkowników. Niby system i oprogramowanie są za darmo, ale jak chcesz mieć bezpiecznie, to zapłać… Płatne bezpieczeństwo to skomplikowane zagadnienie. Co powiecie na abonament na ABS, poduszki powietrzne czy pasy bezpieczeństwa w aucie? Albo jeszcze lepiej: hamulce w wersji zwykłej i pro, te drugie zapewniające krótszą drogę hamowania? I wszystko to rzecz jasna w formie abonamentu, czyli wszędzie jest zamontowane, ale trzeba zapłacić, by było aktywne.

Opłata za udostępnianie

No i ostatnia sprawa – czy Ubuntu może w ogóle brać pieniądze za udostępnianie oprogramowania na wolnych licencjach? Ograniczę się do licencji GPL. Zarówno wersja druga, jak i trzecia GPL wprost mówi, że akt udostępnienia oprogramowania może być zarówno darmowy, jak i płatny. Czyli Ubuntu może żądać wynagrodzenia za udostępnienie oprogramowania.

Jednak jednocześnie GPL zabrania zmiany licencji[1], a licencjonobiorca nabywa wszystkie prawa. W szczególności prawo do dalszej dystrybucji. Czyli czy dowolna osoba może skorzystać z Ubuntu Pro w wersji personal, pobrać z repozytorium ESM pakiety lub kod źródłowy i udostępnić je na swoim serwerze każdemu chętnemu? IANAL, ale wygląda na to, że tak. Przynajmniej te pakiety/patche wydane na licencji GPL.

O sprawie zaczęło się robić głośno dopiero teraz i sam jestem ciekaw, czy jakoś bardziej się to rozwinie i jak się ostatecznie skończy. Trzeba pamiętać, że Ubuntu Pro to znacznie więcej, niż tylko dostęp do załatanych pakietów z repozytorium universe w ramach ESM. To także możliwość aktualizacji kernela bez konieczności restartu systemu, support 24/7. Być może lepszą strategią dla Canonical byłoby udostępnienie patchy społeczności za darmo? Tym bardziej, że z prawnego punktu widzenia raczej są na przegranej pozycji, przynajmniej w kontekście licencji GPL.

[1] Pomijam tu przypadki oprogramowania wydawanego równolegle na kilku licencjach. Wówczas można wybrać, którą licencję się wybrało i modyfikować tylko kod na tej wybranej, dystrybuując go zgodnie z jej – i tylko jej – postanowieniami.

Opublikowane w

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