Strona główna » wordpress

Tag: wordpress

Gdy wtyczki się aktualizują ale WordPress już nie

Zagadkowy taki przypadek mi się trafił ostatnio: serwis oparty o WP z jednej strony pozwalał bez przeszkód aktualizować wtyczki, ale niemożliwe było zaktualizowanie samego WordPressa. Nieustannie pojawiał się monit o podanie danych do FTP, aby móc wgrać pliki. Rozwiązałem tę sprawę, przyczyną było niewłaściwe działanie mechanizmu zabezpieczającego nazywającego się SELinux. Poniżej opisuję jak do tego doszedłem, aby innym dopomóc diagnozować podobne problemy.

Po pierwsze, jeżeli pojawia się monit o dostęp FTP, to znaczy to, że WP ma problem z zapisem i próbuje zaproponować jedną z kilku możliwości jego dokonania. Dopóki ta nie jest określona, to nic mądrzejszego się nie dowiemy. Stąd warto w wp-config.php dopisać taką linijkę:

define('FS_METHOD', 'direct' );

Co to daje? Narzuca metodę zapisu: bezpośrednio do plików. Teraz w widoku „Stan witryny” (w menu Narzędzia) pojawi się w podpowiedziach problemów lista plików, do których dostępu brakuje. Te pliki trzeba będzie sprawdzić. Należy się upewnić, że:

  • Należą do właściwego użytkownika systemowego lub właściwej grupy – te zapewne będzie można wyczytać z konfiguracji serwera WWW (np. /etc/httpd/conf/httpd.conf) lub konfiguracji PHP-FPM (np. /etc/php-fpm.d/www.conf);
  • Mają nadane odpowiednie uprawnienia do zapisu;
  • Sprawdzić kontekst SELinux (ls –context) czy nie jest ustawiony na tylko-do-odczytu.

W moim przypadku problemem było to ostatnie. Aby to naprawić, musiałem użyć polecenia chcon no narzucenia nowego kontekstu, bo odzyskanie za pomocą restorecon nic nie pomagało.

Użycie certyfikatów Let’s Encrypt do wielu serwisów na zwykłym hostingu

Wprowadzenie

Kiedyś pisałem o tym jak można dla serwisów umieszczonych na zwykłych hostingach WWW używać darmowych certyfikatów Let’s Encrypt. Procedura jest jednak żmudna, nudna i trzeba ją powtarzać co kilka miesięcy, co dla kogoś, kto utrzymuje wiele serwisów a nie tylko jeden, jest dosyć nużące. Jeżeli jednak wciąż nie chcemy iść w kierunku zakupu płatnych certyfikatów, to rozwiązaniem jest uruchomienie tzw. reverse proxy na tanim serwerze wirtualnym. Wyjaśnijmy sobie to po kolei.

Najtańsze płatne certyfikaty są obecnie na rynku za około 10 zł. Jeżeli ktoś opiekuje się 10 serwisami internetowymi, które są umiejscowione ma zwykłym hostingu na którym nie można w sposób zautomatyzowany korzystać z darmowych certyfikatów, to musi wydać 100 zł rocznie na certyfikaty. Nie jest to duża kwota a kłopotu jest troszeczkę mniej.

Innym rozwiązaniem jest wykupienie na rok taniego serwera wirtualnego. Ich oferta w Internecie jest spora a mówimy tutaj o wersji naprawdę bardzo ubogiej, bo wymagającej 1 procesora wirtualnego, około 5 GB miejsca dyskowego, od 512 do 1024 MB RAM. Można takie kupić płacąc za rok około 110 zł, czyli wiele więcej niż za certyfikaty – a stajemy się bogatsi o serwer VPS!

Przygotowanie VPSa

W moim przypadku zamówiłem serwer z systemem operacyjnym CentOS 8, aby móc na nim uruchomić skrypt konfiguracyjny, który rozwijam i którego kod jest w repozytorium na GitHub:

curl -s -L http://grzegorzkowalski.pl/install/ | bash

Skrypt będzie wykonywał wiele działań i zada kilka pytań. Odpowiedź „Y” należy udzielić na te:

  • Enable Apache [default port 80 and 443] ? [y/N]
  • Change timezone to Europe/Warsaw? [y/N]
  • Enable FirewallD ? [y/N]

Po tym wszystkim dostaniemy serwer z Apache’m i mnogością różnych użytecznych narzędzi (m.in. PHP 7.4, Python 2/3, NPM, Node.js, Composer, Certbot, wget, GIT). Nas interesuje głównie Apache, którego możemy skonfigurować w tryb reverse proxy.

Tworzymy sobie nowy plik konfiguracyjny do tego celu i jeżeli nasz hosting ma adres 123.123.123.123 to piszemy tak.:

vi /etc/httpd/conf.d/moje_proxy.conf

Wypełniamy go treścią:

<VirtualHost *:80>
ServerName grzegorzkowalski.pl
ServerAlias www.grzegorzkowalski.pl
ServerAlias kolejnyserwis.pl
ServerAlias innyserwis.pl
ServerAlias jeszczeinny.pl
ServerAlias itakdalej.pl
# ...
ServerAlias az_do_ostateniego.pl

DocumentRoot "/var/www/html/proxy"
ServerAdmin grzegorz.adam.kowalski@outlook.com

<Directory "/var/www/html/proxy">
DirectoryIndex index.php
AllowOverride All
Require all granted
</Directory>

ProxyPreserveHost On
ProxyPass / http://123.123.123.123:80/
ProxyPassReverse / http://123.123.123.123:80/
RequestHeader set X-Forwarded-Proto expr=%{REQUEST_SCHEME}
RequestHeader set X-Forwarded-SSL expr=%{HTTPS}
</VirtualHost>

W pliku konfiguracyjnym odwołujemy się do folderu, którego jeszcze nie ma, więc warto go stworzyć:

mkdir /var/www/html/proxy

Teraz w panelu konfiguracyjnym hostingu znajdźmy edycję stref DNS i zmieńmy we wszystkich domenach wskazanych w powyższym pliku konfiguracyjnym numer IP przypisany do tzw. rekordu „A” na adres IP naszego serwera VPS.

Gdy to wszystko jest gotowe, zresetujmy Apache na serwerze wirtualnym, aby nowa konfiguracja weszła w życie. W zależności od systemu może to wymagać trochę innego polecenia, na moim CentOS wygląda to tak:

service httpd restart

No i teraz przed nami zagadnienie wygenerowania certyfikatów. W systemie powinien już być zainstalowany i gotowy do użycia skrypt:

certbot-auto

Należy postępować zgodnie z pytaniami, które będą pojawiać się na ekranie a wynikiem będą wygenerowane certyfikaty, lekko rozszerzony plik konfiguracyjny Apache, który wcześniej stworzyliśmy oraz dodatkowo zostanie stworzony drugi plik konfiguracyjny przeznaczony tylko dla ruchu szyfrowanego na porcie 443.

Gdy WordPress odmawia współpracy

Teraz proxy jest już sprawne, certyfikaty również są zrobione. To,co jeszcze może nas spotkać to zaskoczenie, gdy np. nasz serwis oparty o WordPress odmówi posłuszeństwa a przeglądarka internetowa zwróci komunikat „Too many redirects” czyli „zbyt wiele przekierowań”.

Jak się okazuje, twórcy WordPressa zaszyli jedną ważną informację w instrukcji do tego systemu. W pliku wp-config.php należy ręcznie dopisać w dowolnym miejscu dwie linie kodu:

if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false)
$_SERVER['HTTPS']='on';

Debugowanie zbyt wielu przekierowań

Jeżeli problem „Too many redirects” pojawia się pomimo odpowiedniej konfiguracji takiego czy innego systemu, warto zbadać zjawisko pomocniczym skryptem (jest to zmodyfikowana wersja tego skryptu):

#!/bin/bash
echo
for domain in $@; do
  echo --------------------
  echo $domain
  echo --------------------
  curl -sILk $domain | egrep 'HTTP|Loc|X-Redirect-By: ' | sed 's/Loc/ -> Loc/g'
  echo
done

Skrypt używamy np. tak:

skrypt-do-przekierowan.sh grzegorzkowalski.pl

W wyniku skryptu zobaczymy serię nagłówków HTTP wskazujących na typ przekierowania, docelowe miejsce przekierowania oraz kto zlecił przekierowanie. W przypadku np. WordPressa wyświetli się np. „WordPress 7.4.3”. Jest to informacja, że przyczyna problemu leży nie w konfiguracji Apache, nie w jakimś zabłąkanym pliku .htaccess na hostingu, ale np. w pluginie WordPressowym do obsługi HTTPS albo właśnie w braku wpisu w wp-config.php.