Przeprowadzka blogu na nowy serwer. Wersja 2024

https://xpil.eu/nbgo

Ponieważ w kwietniu upływa mi termin rocznej płatności za mojego VPS-a, a kwota jest niebagatelna (prawie dwie stówki w lokalnej walucie), stwierdziłem, że poszukam czegoś tańszego. No bo po co wydawać dwie stówki rocznie na takiego prawie-że-wyłącznie-tekstowego bloga, skoro być może można wydać mniej, nieprawdaż.

Poklikałem, pozagadywałem do różnych krewnych i znajomych, w końcu znalazłem firmę, która była w stanie zaoferować mi podobny serwer za mniej niż połowę tego, co płacę w OVH. Firma jest na rynku od dość dawna, więc ryzyko, że się znienacka zwinie - niewielkie. Serwer jest nieco bardziej wypasiony od poprzednika: procesor trzyrdzeniowy zamiast jedno-, pamięci operacyjnej ponad dwa razy więcej, pojemność dysku identyczna, łącze symetryczne tu i tam 100 Mbps, czyli całkiem nieźle.

Myślę sobie, raz kozie śmierdźć, zaryzykujemy.

Zaczęło się trochę pod górkę, bo w formularzu zakładania konta użytkownika uporczywie nie mogłem przeskoczyć pola z adresem. Durna puszka twierdziła z uporem godnym lepszej sprawy, że łączę się spoza Irlandii, więc nie powinienem podawać irlandzkiego adresu. Ale wymieniłem kilka wiadomości z obsługą klienta (nie obyło się bez przesłania paru screenshotów) i okazało się, że to znany problem i że mam użyć innej przeglądarki. Z Edge zadziałało od razu. Co ciekawsze, po założeniu konta już mogłem się zalogować z Firefoxa, więc gitara majonez.

Potem wybór OS-a (padło na najnowsze Ubuntu) - tu poszło bezboleśnie i dwie minutki później dostałem automatycznego e-maila ze szczegółami logowania.

Tutaj stanąłem na rozdrożu. Z jednej strony mam sprawdzone kopie zapasowe na Vaultpressie, i jeszcze drugie, niezależnie wydziergane, na domowym NAS-ie (tych jeszcze nie testowałem), z drugiej strony lubię dłubać i chętnie bym sobie postawił WordPress-a od zera.

No dobra. Jak od zera, to od zera.

Najpierw nieśmiertelne sudo apt update; sudo apt upgrade -y żeby mieć pewność, że jest świeżo. Oczywiście okazało się, że nowy kernel, więc reboot. Przy okazji zmierzyłem czas restartu - stary serwer restartuje się w siedem sekund, nowy - w dziesięć. Ale to może dlatego, że było dobrze ponad 200 MB aktualizacji. Tak czy siak - szybciutko.

Jak testuję czas potrzebny na restart? Prosto: tuż przed restartem w osobnym okienku odpalam na lokalnej maszynie ping -t adres-serwera i liczę nieudane próby. Ping domyślnie wysyła jedną próbę na sekundę, więc nawet nie trzeba przez nic mnożyć 😉

Po restarcie próbuję się zalogować przez ssh, ale mnie wywala.

Ki czort?

Spróbowałem z innej maszyny, nic. Potem jeszcze ze strony dostawcy VPS-a (mają webowego klienta SSH, całkiem wygodna sprawa) - też nic. Zrywa sesję od razu po podaniu nazwy użytkownika, jeszcze przed wpisaniem hasła.

No-ż...

Na szczęście dostawca VPS oferuje też wejście bokiem, przez KVM. Oczywiście trzeba mieć dane logowania, ale omija się protokół SSH. Tamtędy się w końcu udało i po szybkim /etc/init.d/ssh restart sytuacja wróciła do normy.

W następnej kolejności należało skonfigurować firewalla, żeby mi się jakieś złodupce nie zaczęły dobijać. A więc najpierw ufw:

sudo apt install ufw
sudo ufw allow ssh
sudo ufw allow https
sudo ufw enable
sudo ufw status

Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere
80/tcp                     ALLOW       Anywhere
443                        ALLOW       Anywhere
22/tcp (v6)                ALLOW       Anywhere (v6)
80/tcp (v6)                ALLOW       Anywhere (v6)

Potem dodanie lokalnego nieuprzywilejowanego użytkownika, razem z sudo, a następnie wyłączenie konta root z ssh (prosta modyfikacja w /etc/ssh/sshd_config). No i obowiązkowo fail2ban, żeby zniechęcić script-kiddies.

Na tym etapie uznałem już, że serwer jest wystarczająco zabezpieczony. Powymieniałem jeszcze (za pomocą ssh-copy-id) klucze sesji SSH między starym i nowym serwerem (w obie strony), a także między maszyną lokalną a nowym serwerem, żeby móc swobodnie używać ssh i scp - i zabrałem się za robotę właściwą.

Najpierw Apacz, czyli:

sudo apt install apache2
sudo systemctl start apache2
sudo systemctl enable apache2

Coś mi się tam przypomniało, że na starym serwerze mam do Apacza pododawane jakieś niestandardowe moduły. A więc szybciutko ssh na stary serwer, i:

sudo apache2ctl -M

potem to samo na nowym serwerze, porównałem jedno z drugim i wyszło, że mi brakuje następujących modułów:

php_module
proxy_module
proxy_http_module
rewrite_module
socache_shmcb_module
ssl_module

Niektóre trzeba było doinstalować APT-em, niektóre po prostu powłączać za pomocą a2enmod:

sudo apt install php libapache2-mod-php
sudo a2enmod proxy
sudo a2enmod proxy_http
sudo a2enmod rewrite
sudo a2enmod ssl
sudo a2enmod socache_shmcb

Potem oczywiście restart apacza...

sudo systemctl restart apache2

... i można było uznać, że serwer www mam postawiony. Kolejny krok: przeniesienie konfiguracji serwera www dla blogu. To są dwa pliki: jeden główny, i jeden dodający obsługę https (za pośrednictwem Certbota). Oba siedzą w /etc/apache2/sites-available i są podlinkowane symbolicznie do /etc/apache2/sites-enabled.

Po skopiowaniu obydwu plików do sites-available trzeba je było włączyć:

sudo a2ensite xpil.eu.conf
sudo a2ensite xpil.eu-le-ssl.conf

... i tu okazało się, że apacz nie chce wystartować. Oczywiście, bo na nowym serwerze nie ma przecież jeszcze zainstalowanego Certbota.

No to instalujemy:

sudo apt-get install certbot python3-certbot-apache

Normalnie wykonałbym teraz:

sudo certbot --apache -d xpil.eu

... ale to było z góry skazane na niepowodzenie, bo Certbot wymaga odpowiednich wpisów w strefie DNS, a ja jeszcze nie chciałem zmieniać DNS-a na nowy serwer, bo przecież nic tutaj nie ma, tylko się jakieś kłaki turlają z lewa na prawo i apiać z prawa na lewo. Na szczęście nie ja pierwszy miałem ten problem i okazało się, że odpowiednia inkantacja pozwala uzyskać certyfikat bez przekierowania DNS:

sudo certbot -d xpil.eu --manual --preferred-challenges dns certonly

Niby fajnie, ale jeżeli tak można, to każdy by sobie mógł wygenerować dowolny certyfikat dla dowolnej domeny.

Czy aby na pewno?

Jednak nie:

Please deploy a DNS TXT record under the name:

_acme-challenge.xpil.eu.

with the following value:

(tutaj długi ciąg przypadkowo wyglądających znaczków)

Aha. Czyli jednak trzeba się wylegitymować aktem własności domeny. Dobrze. Loguję się do swojego registrara, dodaję nowy rekord jak przykazał Certbot, pukam Enter, gotowe. Restartuję apacza...

Failed to start The Apache HTTP Server.
░░ Subject: A start job for unit apache2.service has failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A start job for unit apache2.service has finished with a failure.
░░
░░ The job identifier is 2324 and the job result is failed.

Noż kurza melodia, myślę sobie, taki ty owaki... ale problem okazał się tym razem trywialny: brakowało pliku z konfiguracją SSL, który jest na szczęście uniwersalny i daje się wygenerować prostym kopiuj-wklej:

# /etc/letsencrypt/options-ssl-apache.conf

SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite          HIGH:!aNULL:!MD5:!3DES:!CAMELLIA:!AES128
SSLHonorCipherOrder     off
SSLSessionTickets       off

Po uruchomieniu sudo apache2ctl configtest dostałem tylko ostrzeżenie, że folder wskazany w konfiguracji apacza jest pusty (logiczne), ale tak poza tym to syćko gro i bucy.

Następnym krokiem było skopiowanie wszystkich plików z folderu www blogu z jednego serwera na drugi. Chciałem to zapuścić bezpośrednio, ale się odbiłem od uprawnień (folder blogu może czytać tylko apacz, a ja byłem zalogowany jako zwykły lokalny użyszkodnik). Dlatego też, jako root, zapisałem sobie cały ten folder www na źródłowym serwerze jako plik .tar.gz, który następnie grzecznie przekopiowałem (za pomocą scp) na nowy serwer, a tam rozzipowałem, pozmieniałem uprawnienia... i już?

Nie, za prosto by było. Jeszcze baza SQL wordpressa przecież.

Najpierw więc trzeba było zainstalować MariaDB na nowym serwerze i go zabezpieczyć:

sudo apt install mariadb-server
sudo mysql_secure_installation

Potem - ponieważ jestem osobnikiem leniwym - utworzyłem sobie na nowym serwerze, w katalogu domowym, plik .my.cnf z następującą zawartością:

[client]
user=nazwa użytkownika
password=hasło
database=baza wordpressa

Dzięki temu jeżeli wpiszę teraz polecenie mysql, to mi się ono automagicznie połączy właściwym użytkownikiem do właściwej bazy - i nie muszę pamiętać hasła. Oczywiście na koniec trzeba jeszcze:

chmod 600 ~/.my.cnf

... żeby się nikt za bardzo nie interesował, i można już kopiować bazę.

A nie, jeszcze nie. Trzeba sobie jeszcze utworzyć użytkownika przecież. A więc logujemy się do mysql-a jako root i uruchamiamy:

CREATE DATABASE wordpress;
CREATE USER 'nazwa użytkownika'@'localhost' IDENTIFIED BY 'hasło';
GRANT ALL PRIVILEGES ON wordpress.* TO 'nazwa użytkownika'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Teraz na serwerze źródłowym trzeba sobie zrobić kopię zapasową bazy (w MySQL nazywa się to dump), za pomocą polecenia mysqldump:

mysqldump wordpress > [kopia_zapasowa.sql]

Potem się - przynajmniej w teorii - ten plik sql kopiuje na nowy serwer. Ja jednak chciałem sobie poeksperymentować z ssh, więc zamiast się zalogować do starego serwera i uruchomić mysqldump lokalnie, wpisałem (na nowym serwerze):

ssh xpil.eu mysqldump wordpress > kopia_zapasowa.sql

będąc przekonanym, że wynikowy plik kopia_zapasowa.sql zostanie utworzony na maszynie zdalnej. Okazało się jednak, że operator przekierowania (>) zadziałał lokalnie i po dłuższej (naprawdę dłuższej) chwili, kiedy już się zacząłem martwić, że coś się gdzieś zesrało, proces zakończył się bez błędów, a plik kopia_zapasowa.sql wylądował od razu na serwerze docelowym. Dwa wróble jednym kamieniem, jak mawiają lokalni.

Potem już tylko:

mysql wordpress < kopia_zapasowa.sql

... i można zabierać się za testowanie bloga na nowym serwerze.

Przypominam jednak, że "żywy" blog ciągle jeszcze siedzi na oryginalnym serwerze OVH, więc żeby przetestować nowy serwer potrzebuję przekierować lokalnego DNS-a na nową maszynę. Na szczęście jest to proces całkiem łatwy: trzeba otworzyć (jako Administrator) plik hosts, który w Windows siedzi w folderze C:\Windows\System32\Drivers\etc i dopisać na końcu linijkę:

adres.ip.nowego.serwera xpil.eu www.xpil.eu

Od tej pory wpisując w adres przeglądarki xpil.eu (albo www.xpil.eu) system będzie używał nowego serwera - przynajmniej tak długo, dopóki nie cofniemy modyfikacji w pliku hosts.

No to szybki paciorek do wszystkich bóstw, odpalam bloga...

Your PHP installation appears to be missing the MySQL extension which is required by WordPress.

Please check that the mysqli PHP extension is installed and enabled.

If you are unsure what these terms mean you should probably contact your host. If you still need help you can always visit the WordPress support forums.

No tak. Murphy nie śpi. Zawsze jest jeszcze jeden krok do zrobienia...

Niezbyt trudny, na szczęście:

sudo apt-get install php8.1-mysql
sudo phpenmod mysqli
sudo systemctl restart apache2

I oto stał się cud: blog zabanglał i to już bez żadnych dodatkowych hopsztosów.

Dla pewności zagadałem jeszcze do kolegi, żeby sprawdził od siebie (a więc szybka modyfikacja pliku hosts a potem wejście na blog i losowe poklikanie tu i tam). Kolega po pięciu minutach wrócił z informacją, że bardzo próbował coś zepsuć, ale bezskutecznie, i że chyba wszystko działa jak trzeba.

A skoro tak, to jedyne, co mi pozostało, to przekładka DNS na nowy serwer - et voila!

Aha, no i rzecz jasna jak się już DNS rozpropaguje (co będzie można poznać po tym, że na blogu pojawi się ten wpis, bo napisałem go w całości już na nowym serwerze), to stary VPS będzie sobie leżał bezużytecznie, więc jeżeli ktoś z Czytelników miałby ochotę sobie poużywać, niech da znać. Stary serwer jest opłacony do 11 kwietnia, więc można się nim bawić jeszcze przez pięć tygodni.

Jeżeli więc masz pomysł jak wykorzystać taki serwer, podeślij znak dymny na cokolwiek małpa adres blogu i będziemy działać. Po co się ma, bidulek, zmarnować.

https://xpil.eu/nbgo