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:
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ąć.
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]:
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.
W poprzednim wpisie pisałem o planowanej migracji na Oracle Cloud. Jak widać blog stoi już w nowej lokalizacji, więc operacja jest zakończona i mogę napisać kilka słów z perspektywy.
Migracja
Poszło niemal bezproblemowo. Backup w zasadzie zadziałał. Był problem z detalami typu lista zainstalowanych pakietów i crony. W sumie nieistotne i/lub poprawione. Xpil opisał swoją migrację VPSa i po tej lekturze miałem silne postanowienie zamknięcia wszystkiego w kontenerach LXC. To nieco wydłużyło proces migracji i dodało trochę zadań. Co prawda nadal nie jest to taka separacja jak w dockerach czyli per usługa, ale mariadb + nginx + całe WWW w osobnym VPSie też jest OK.
Konieczne było lekkie przemeblowanie. Musiałem rozdzielić skrypty cron do właściwych kontenerów. Okazało się też, że wynik działania jednego kontenera (Planeta Joggera) musi trafić nie do hypervisora, tylko do innego kontenera, a ten nie ma dostępu. Skrypt w cronie na hypervisorze załatwił sprawę. Podobnie niezbyt elegancko rozwiązany jest backup bazy danych. Dump robię teraz w LXC, a następnie cały kontener jest backupowany. W ten sposób zawartość bazy jest zdublowana. Mam pomysł jak to rozwiązać, nie wiem, czy potrzebuję. Tyle o samej migracji, a efekty i hosting?
Efekty
Przede wszystkim jest szybciej, przynajmniej wg GTmetrix. Niestety nie zrobiłem testu tuż przed migracją i od razu po niej. Mam tylko ten link z twardymi danymi, ale w międzyczasie się poprawiło, więc polegam głównie na pamięci. Ale tak dobrze to nigdy nie było:
GTmetrix w Oracle Cloud
Hosting
Pewnie w sporej części to kwestia przejścia z jednego VPSa na dwa, w dodatku z widocznymi dwoma rdzeniami w systemie. W Arubacloud było:
Blog zawsze dominował, jeśli chodzi o obciążenie, ale teraz ma całe zasoby dla siebie. Z drugiej strony bieżący VPS ma sporo wolniejszy dysk (3000 IOPS, 24 MB/s). Można tym jakoś sterować, ale zakładałem na domyślnych wartościach. No i nie widzę potrzeby zmiany.
Wady
Żeby nie było, że wszystko jest fajnie – port 25 TCP w Oracle Cloud jest zablokowany na twardo, w obie strony. Czyli ani maila nie przyjmę, ani nie wyślę. Znalazłem, że trzeba pisać do supportu o odblokowanie. Napisałem i zobaczymy. O ile do monitoringu poczta nie jest mi potrzebna, bo powiadomienia mogę wysyłać Telegramem, to przy blogu jest to jakby kluczowe. Potwierdzanie subskrybcji komentarzy itp. Z drugiej strony widzę, że nie było to jakoś mocno wykorzystywane… Zobaczę co odpowiedzą i wtedy pomyślę, co dalej.
Ogólnie sporo rzeczy w Oracle Cloud jest załatwianych przez support. Ustawienie PTR – support (działa!). Inny obraz dysku dla arm64 – support (tak powiedzieli na czacie, odpuściłem).
UPDATE: Port 25 nie został odblokowany, bo free tier. Nie jest to duży problem – wystarczy skonfigurować SMTP relay u któregoś z dostawców.
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.
