Aktualizacja Ubuntu: jest ryzyko, jest zabawa

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.

9
Dodaj komentarz

avatar
4 Comment threads
5 Thread replies
6 Followers
 
Most reacted comment
Hottest comment thread
6 Comment authors
StefekxpilPatrykFutrak40i6 Recent comment authors
  Subscribe  
najnowszy najstarszy oceniany
Powiadom o
Hoko
Gość

ktoś mniej techniczny wziąłby sobie wirtuala 🙂 swoją drogą, masz na tym serwerze coś poza blogiem?

40i6
Gość

a jutro obsługa klienta odpisze, że właśnie zrobili i naprawili, chociaż łatwo nie było…

Futrak
Gość

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.

Patryk
Gość
Patryk

Sam się wkopaleś. Ja bym nie robił upgrade. Jak działa to działa.

%d bloggers like this: