Bullseye

Zakończyłem aktualizację ostatniej[1] maszyny do Debiana 11 czyli Bullseye, pora na tradycyjne podsumowanie.

Najpierw zaktualizowałem kontenery. Operacja totalnie bezproblemowa przy pomocy apt. Czyli wariant zalecany. Z większych zmian warto jedynie odnotować zmianę wpisu dla repozytorium security w sources.list.

Główny host jedynie odrobinę gorzej. Coś mu nie poszło przy zależnościach i odinstalował mariadb. Konfiguracje i dane zostały, więc przywrócenie trwało moment. Niemniej miał prawo się pogubić, korzystam z dodatkowych repozytoriów w tym systemie.

Desktopy również niemal bezproblemowo, w tym przejście z unstable na stable przy okazji upgrade. Jedyne z czym był problem to WiFi i wicd. Z uwagi na zależność od Pythona 2.x pakiet jest usuwany i… skończyłem bez sieci na pierwszym systemie. Rozwiązanie jest proste: wystarczy przeprosić się z network managerem i zainstalować go zamiast wicd przed aktualizacją. Po takim zabiegu aktualizacja bezproblemowa.

Ostatnie było Raspberry Pi robiące za router GSM. Tam co prawda jest Raspbian, nie Debian, ale można powiedzieć, że także była to aktualizacja do Bustera z uwagi na zmiany wpisów w sources.list. Nieco się pospieszyłem i instalowałem jako wersję niestabilną. Niemniej – bez problemu. Choć przygotowałem się na reinstalację systemu i operację przeprowadzałem nie zdalnie, a z fizycznym dostępem do sprzętu.

Ogólnie wygląda na brak większych zmian i chyba najbardziej bezproblemową aktualizację w historii. Jedyne co zauważyłem, to nieco większe zużycie miejsca na dysku. Generalnie tak to już bywa, że nowszy soft jest większy niż stary, ale w przypadku maszyny z kontenerami lxc zabolało to nieco bardziej. Dobiłem do granicy wolnego miejsca na dysku przy wykonywaniu się backupów. IIRC nie skończyło się zupełnie, ale było dosłownie na styk.

Zrobiłem porządki zarówno w logach, zbędnych rzeczach, jak i pakietach. Okazało się bowiem, że w kontenerach mam trochę nadmiarowych rzeczy. Przy tej ostatniej operacji okazało się, że na jednym z kontenerów apt działa wolno. Pobieranie działało normalnie, przeliczanie zależności także. Natomiast każde dodanie lub usunięcie pakietu zaczynało się od przestoju, podczas którego nic się na oko nie działo. Szybki strace ujawnił, że chodzi o okolice dbus. Usunięcie pakietu – kolejnego zbędnego, zresztą – rozwiązało problem.

[1] Tak naprawdę jeden kontener został na Buster i póki co zostanie – soft do generowania Planety Joggera zniknął z Bullseye. I raczej nie wróci, więc trzeba pomyśleć nad przesiadką na inny soft. Niemniej, nic związanego z samym systemem.

Zmiany we free tier w Google Cloud Platform

Tytułem wstępu: Google ma swoją chmurę, czyli Google Cloud Platform, a w ramach niej coś takiego jak free tier, czyli zasoby dostępne bez opłat[1]. Zasoby są niewielkie, dodatkowo podlegające pewnym ograniczeniom, raczej do zabawy. Ale do testów, nauki czy właśnie zabawy – idealne. Między innymi można mieć uruchomioną w ramach compute engine najsłabszą VMkę, czyli f1-micro.

Mail

Jeśli ktoś korzysta z GCP, to zapewne dostał już maila. Dla tych, co maila przeoczyli, krótkie podsumowanie. Od pierwszego sierpnia 2021 instancje e2-micro są bezpłatne (w określonej ilości czasu), natomiast od pierwszego września instancje f1-micro będą płatne. Regiony pozostają bez zmian. Instrukcja zmiany linkowana w mailu dostępna jest tu.

To różne platformy, więc ciężko porównać dokładnie, ale:
f1-micro to 0.2 VCPU i 0.6 GB RAM w cenie $0.0076 (us-central1)
e2-micro to 0.25 VCPU i 1 GB RAM w cenie $0.008376 (us-central1)
Dodatkowo w przypadku e2-micro możliwy jest burst do 2 VCPU.

Google pisze[2]:

As we improve the experience of the Free Tier, we will be introducing the E2-micro VM, which is a part of a second generation VM family.

Wydajność

W przypadku RAM zysk jest oczywisty, natomiast w przypadku CPU – niekoniecznie. Wiele zależy od tego, na jakiej platformie CPU znajduje się obecnie VMka, i na jakiej wyląduje po przeniesieniu. Tabela platform CPU dla serii N1 i E2 jest dość skomplikowana. Jednak patrząc na base frequency, przeciętnie powinno być szybciej.

I jeszcze wynik cat /proc/cpuinfo z mojej instancji f1-micro:

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 63
model name : Intel(R) Xeon(R) CPU @ 2.30GHz
stepping : 0
microcode : 0x1
cpu MHz : 2299.998
cache size : 46080 KB
physical id : 0
siblings : 1
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology n$
bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs
bogomips : 4599.99
clflush size : 64

Jak się zmigruję to uzupełnię wpis, co dostałem po migracji i jak wrażenia.

Migracja

Wczoraj zmigrowałem maszynę na e2-micro. Migracja błyskawiczna i bezproblemowa. Zgodnie z instrukcją zatrzymać instancję, wyedytować typ, zapisać zmianę, uruchomić maszynę.

Po migracji dostałem dokładnie ten sam procesor. Tyle, że teraz cat /proc/cpuinfo pokazuje dwa. Jeśli chodzi o osiągi i wydajność w praktyce, to najlepiej widać to na obrazku.

Wykorzystanie CPU na f1-micro i po migracji na e2-micro w GCP free tier
Wykorzystanie CPU na f1-micro vs e2-micro

Migracja chwilę przed 12:00, później wzrost obciążenia spowodowany porządkami, chwilę po 18:00 koniec ostatnich ręcznych prac. Jak widać, główny zysk wynika ze wzrostu mnożnika z 0.2 do 0.25 VCPU. Ponieważ przydział jest dynamiczny, procesy jednowątkowe także skorzystają na zmianie parametrów.

Podsumowując, warto migrować, bo e2-micro w stosunku do f1-micro oferuje 66% więcej RAM i 25% więcej CPU.

[1] Wymagane jest podpięcie karty debetowej, a po przekroczeniu puli darmowych zasobów jest automatycznie naliczana opłata za przekroczoną część.
[2] Nawiasem, wysłaniem tego maila Google Cloud Platform zdobyło u mnie sporo punktów sympatii. Mogli przecież np. zamieścić info o zmianie cenników free tier na blogu i billować nieuważnych, albo wysłać suchego maila o zmianach w cenniku. Wiele firm tak właśnie by postąpiło. A tu osobne, czytelne powiadomienie, z instrukcją migracji. Miło.

Instalacja podatnych wersji oprogramowania HOWTO

Niekiedy zachodzi potrzeba uruchomienia starej, podatnej wersji systemu lub usługi w celu przetestowania czegoś, np. exploita. W przypadku Debiana i podobnych dystrybucji opartych na pakietach deb, instalacja starej wersji systemu bywa nieco problematyczna. Po pierwsze, system pakietów nie wspiera downgrade’u, po drugie, domyślnie instalator instaluje najnowsze wersje pakietów, jeśli tylko ma taką możliwość.

Sposoby instalacji podatnych wersji oprogramowania

Sposobów na instalację starszych, podatnych wersji pakietów jest wiele. Można kompilować określoną wersję, ale nie jest to wygodne, jest czasochłonne i niekoniecznie uzyskamy wersję dokładnie taką, jaka była w systemie, np. z powodu patchy nakładanych przez Debiana czy nieco innego środowiska w którym pakiet był budowany[1].

Skoro jednak korzystamy z dystrybucji opartej o pakiety binarne, można także próbować robić downgrade pakietów, albo usuwać pakiety i instalować przy pomocy dpkg zamiast apt[2]. Jeśli nie mamy pecha, wszystko zadziała czy to od razu, czy po małym force przy instalacji. Można też instalować ze starych obrazów instalacyjnych, bez dostępu do sieci. Czasem jednak nie mamy szczęścia. A wszystko można zrobić szybciej i prościej.

Repozytorium starych wersji pakietów Debiana

Przede wszystkim, i tak trzeba jakoś zdobyć podatne wersje pakietów. W przypadku Debiana istnieje snapshot.debian.org, czyli serwis z oficjalnymi, snapshotami mirrorami repozytoriów Debiana. Doskonałe miejsce pozwalające i na pobranie pakietów w takich wersjach, w jakich były w danym momencie w repo, i na postawienie całego systemu w stanie na dany dzień. Snapshoty wykonywane są częściej, niż raz dziennie. Poza głównym repozytorium pakietów dostępne inne, w tym security i backports, więc trudno sobie wyobrazić coś lepszego. Pozostaje instalacja systemu z wykorzystaniem powyższych repozytoriów.

Naprościej można to zrobić z użyciem debootstrap, poprzez podanie mirrora., z którego mają być pobierane pakiety. Przykładowo, aby zainstalować Debiana Buster w wersji, w jakiej był on dostępny dzień po wydaniu:

debootstrap buster /chrooted/ https://snapshot.debian.org/archive/debian/20190707T150059Z/

Po instalacji należałoby jeszcze wejść do chroota i uzupełnić sources.list o wpisy dla repozytorium security, zaktulizować pakiety i… gotowe. W katalogu /chrooted będzie dostępny podatny system. Jeśli był tam podmontowany dysk zdalny, to można uruchomić podatną maszynę według podlinkowanej wyżej instrukcji.

Wykorzystanie LXC do uruchamiania podatnych wersji

Istnieje jeszcze szybszy i IMO wygodniejszy sposób uruchomienia podatnej wersji systemu. Można wykorzystać kontenery LXC do instalacji, a następnie uruchomienia podatnego systemu. O tyle wygodne i bezpieczne, że kontener LXC może być dostępny – i jest to domyślna konfiguracja – wyłącznie z poziomu hypervisora, bez udostępniania go na świat. Kontener z Debianem Buster w wersji na dzień po wydaniu z użyciem LXC tworzymy:

lxc-create -n test -t debian -- -r buster -a amd64 --mirror=https://snapshot.debian.org/archive/debian/20190707T150059Z/ --security-mirror=https://snapshot.debian.org/archive/debian-security/20190707T153344Z/

I gotowe. Po zakończeniu powinniśmy mieć dostępny kontener LXC z podatną wersją systemu. W tym przypadku o nazwie test, którym możemy zarządzać w standardowy sposób, czyli sources.list będziemy mieli:

cat /etc/apt/sources.list
deb https://snapshot.debian.org/archive/debian/20190707T150059Z/          buster         main
deb https://snapshot.debian.org/archive/debian-security/20190707T153344Z/ buster/updates main

[1] Przy weryfikacji zgodności pakietów pomóc mogą reproducible builds.
[2] W tym miejscu nadal odsyłam do wpisu o wajig i zachęcam do zapoznania się z narzędziem. To stary wpis, nie wszystkie opisane okoliczności muszą być prawdziwe, ale wajig ma się dobrze. Warto więc zatem go poznać.