Aktualizacja Ubuntu: jest ryzyko, jest zabawa

https://xpil.eu/xpb

W życiu każdego blogera nadchodzi taka chwila, że musi zaktualizować system operacyjny na serwerze.

Wroć, kłamię.

W życiu wielu blogerów nadchodzi taki moment, że muszą zaktualizować system operacyjny na serwerze.

Nie, też przesada.

W życiu niektorych blogerów nadchodzi taki moment, że muszą zaktualizować system operacyjny na serwerze.

No, powiedzmy.

W życiu…

W życiu bym nie przypuszczał, że niewinna komenda "do-release-upgrade" uruchomiona na moim wiernym VPS-ie sprawi mi tyle radości nerwów, a także położy blog na kilkanaście ładnych godzin.

No bo tak: loguję się, jak co tydzień, na swojego VPS-a, żeby sprawdzić czy wszystko w porządku, czy się miejsce na dysku nie kończy, czy mi jakieś tanie dranie nie hakują maszyny, czy procesor nie płonie. Takie tam.

Loguję się i widzę radosną wieść, że pojawiła się nowa wersja Ubuntu i żebym uruchomił komendę do-release-upgrade jeżeli chcę tę nową wersję tenteges.

Chciałem. Uruchomiłem więc…

I mi mówi, żebym tego z sesji SSH lepiej nie uruchamiał, bo jak się coś - odpukać - zesra, to będzie trudniej. I że najlepiej to robić bezpośrednio na serwerze.

Myślę sobie, specjalnie do Francji jechać żeby zainstalować aktualizację, trochę przesada. Zresztą pewnie i tak by mnie nie wpuścili do serwerowni.

Ale od czego jest KVM?

Wbiłem się więc przez interfejs WWW na KVM swojego serwera, uruchomiłem ww. komendę i czekam.

Przez ekran przewinęło się od groma i ciut literek, z Sieci pobrało się od groma i ciut nowych pakietów, a ja się wślipiałem w to jak jakiś głupi przez ładnych parę minut. Wreszcie serwer zakomunikował: gotowe, weź mnie teraz zrebutuj i będziemy kwita.

No to wpisuję: reboot. Wciskam enter. Serwer grzecznie się kładzie, żeby po chwili wstać…

A nie, jednak nie.

Kernel panic przy próbie wystartowania systemu! Coś z partycją, z VFS, jakieś heksadecymalne zaklęcia wojenne, ogólnie rzecz biorąc magia do kwadratu.

Kilka kolejnych prób zakończyło się identycznie, więc pierwsze co zrobiłem to wrzuciłem zapytanie do obsługi klienta, czy mogliby coś z tym zrobić.

Parę godzin później zapytanie nadal wisiało w kolejce, więc stwierdziłem, że nie ma co na nich liczyć, trzeba zakasać rękawy i samemu coś tenteges.

Najpierw uruchomiłem serwer w trybie "rescue" (OVH oferuje taką opcję), dzięki czemu owszem, wstał, ale całkiem "surowy". Po chwili myszkowania odkryłem, że oryginalne dane z serwera są podmontowane w osobnym folderze (uff, nie zginęły), a to, co wystartowało, to takie głupiątko, żeby tylko wstać i nic więcej.

Ponieważ na konfiguracji GRUB-a się nie znam (i znać nie chcę) stwierdziłem, że zamiast czekać na obsługę klienta, po prostu postawię nowy serwer od zera, przeniosę nań dane z tego padniętego i będziemy wszyscy żyć długo i szczęśliwie.

Odpalenie nowego serwera w OVH to kwestia trzech minut. Dosłownie.

Kolejne trzy minuty czeka się na dane dostępowe (czyli adres IP i hasło root-a), które przychodzą pocztą e-mail na podany przy rejestracji konta adres.

Potem tylko kilka chwil z tar-em, gzip-em i scp i już miałem całą zawartość /etc oraz /var/www skopiowaną na nowy serwer, zzipowaną grzecznie w katalogu domowym.

Co dalej?

Dalej trochę dupa, ponieważ okazało się, że jako osobnik z gruntu leniwy postawiłem (błąd!) na dystrybucję zwaną "Wordpress", która pod maską okazała się zwykłym, starym Debianem obciętym do niezbędnego minimum, z LAMP-em na pokładzie oraz - niestety - MySQL-em w wersji 5.5.x. Kopia zapasowa bazy danych, którą znalazłem na DropBox-ie (dzięki UpdraftPlus mam tam mnóstwo dziennych kopii na takie właśnie sytuacje) była niekompatybilna z wersją 5.5.x i wymagała wersji co najmniej 5.6.x.

Upgrade do tej wersji pociagnął za sobą absolutną rozpierduchę w zależnościach APT, przez co po dwóch godzinach rwałem sobie włosy z głowy garściami, a moj prywatny słownik wzbogacił się o wyrażenia, od których zarumieniłby się Hugh Heffner (gdyby żył).

Problem rozwiązałem metodą gordyjską i już po trzech minutach zamiast stareńkiego Debiana miałem na tym nowym serwerze postawione świeże, jeszcze chrupiące Ubuntu 18.04 (Bionic Beaver, czyli po naszemu Bioniczny Bóbr). Po dalszych parunastu minutach był tam też LAMP oraz kopie danych ściągnięte ze starego serwera, a nazajutrz rano - po przekładce na serwerze DNS - blog wstał i znów zaczął działać. Jeszcze tylko małe tete-a-tete z Let's Encrypt! (https, panie) i można było odetchnąć.

Ostatnie, co mi się przydarzyło, to to, że wprawdzie działała strona główna blogu, ale otwarcie któregokolwiek z wpisów kończyło się błędem 404. Na szczęście zabrzęczało mi w głowie, że kiedyś już ten problem miałem (https://xpil.eu/c6p) i już chwilę później wszystko działało jak trzeba.

Stary serwer zwinąłem, nadpłatę kazałem przenieść na nowy (pod tym względem OVH są bardzo sprawni) i tyle.

Rachu ciachu i po strachu.

Gdyby jednak do sprawy zabrał się ktoś nieco mniej techniczny…

(…tu chciałem napisać, że byłby teraz w czarnej głębokiej…)

… to by się w ogóle nie zalogował do serwera na samym początku, nie zauważyłby komunikatu o nowej wersji systemu i nie miałby w ogóle żadnego problemu.

Tak że tego, ten.

https://xpil.eu/xpb

9 komentarzy

    1. Nie. Planuję w niedalekiej przyszłości przenieść na niego Siupy.com (które póki co siedzą na innym hostingu, a po cholerę płacić za dwa, skoro obydwie strony mają łącznie może ze 150-200 wejść dziennie), ale to jeszcze nie dziś, nie jutro. Muszę najpierw opanować konfigurację Apache dla wielu domen. Ponoć do ogarnięcia.

      1. e, przy takim ruchu tani wirtualny by starczył, tylko w WP cache trzeba włączyć. Apache becik, kilka wpisów w kilku plikach i po ptokach 😉

  1. Właśnie między innymi dlatego wolę nie stawiać własnych serwerów. Ja zamiast rwać włosy z głowy od razu pewnie bym sobie w nią palnął z dużego kalibru.

    1. Wiem, wiem, “don’t fix if it ain’t broken”, ale ja czasem po prostu lubię sobie pogrzebać tu i ówdzie 😉

Leave a Comment

Komentarze mile widziane.

Jeżeli chcesz do komentarza wstawić kod, użyj składni:
[code]
tutaj wstaw swój kod
[/code]

Jeżeli zrobisz literówkę lub zmienisz zdanie, możesz edytować komentarz po jego zatwierdzeniu.