Serwer na OrangePi cz.3 – apache, php, mysql, wordpress, domena

Witam serdelecznie w trzeciej części wywodów na temat Orange Pi. Mamy już podłączoną i uruchomioną płytkę, możemy teraz zamknąć ją w szafce z routerem, i zasiąść wygodnie przed laptopem celem poinstalowania tego całego tatałajstwa (apache, php, mysql i wordpress). Jak się okazało nie jest to ani trochę trudne, najwięcej trudu z tego wszystkiego sprawiło mi przeniesienie swojego wordpressa tak, aby działał poprawnie. I postaram się to wszystko jako tako opisać.

Apache, PHP, i MySQL

Sprawa prosta – apt-get install apache2 php5 php5-gd libapache2-mod-php5 mysql-server php5-mysql. To powinno zainstalować wszystko co będzie potrzebne do zbudowania serwera i zajmie to około 100MB miejsca na dysku. Podczas instalacji pojawi się prośba o ustawienie nowego hasła dla użytkownika root dla MySQL, najlepiej od razu robić to z głową i wszystko sobie zapisywać. Po zakończeniu można sprawdzić działanie Apache pod adresem swojej strony, powinna się wyświetlić strona domyślna z pliku /var/www/html/index.html
apache

Domyślny katalog dla html można zmienić na praktycznie dowolny inny, i trzeba to zrobić w dwóch miejscach – w /etc/apache2/sites-available/000-default.conf oraz /etc/apache2/apache2.conf. Po prostu podmieniamy /var/www/html na inny i dajemy service apache2 restart aby zmiany przyniosły efekt. Pamiętaj że cała późniejsza konfiguracja będzie wymagała podawania nowego katalogu.

Zanim przejdziemy dalej warto zrobić jedną rzecz. Edytuj plik nano /etc/php5/apache2/php.ini (a najlepiej zrób to w WinSCP bo plik jest duży), znajdź następujące linie, i zmień je na:
post_max_size = 32M
upload_max_filesize = 32M

Dzięki temu będzie można wysłać plik o wielkości do 32MB zamiast domyślnego zdaje się 2MB. Będzie to zaraz potrzebne do zaimportowania bazy danych. Możemy sobie ustawić to wg indywidualnych potrzeb, po przesłaniu bazy danych możemy sobie to zmniejszyć np do 2MB jeśli nie zamierzamy przesyłać większych plików (np. tylko zdjęcia). Pozostawienie dużego limitu bardzo ułatwi atak typu Denial of Service, choć przy tak słabej maszynie nie ma to większego znaczenia.

Dla Apache należy jeszcze włączyć kilka modułów, bez nich wordpress (zależnie od ustawień i wtyczek) nie będzie działał poprawnie. Są to mod_headers, mod_expires, oraz mod_rewrite. Zrobimy to jednym poleceniem w konsoli: a2enmod headers expires rewrite a następnie service apache2 restart aby zmiany przyniosły efekt.

Ostatnia zmiana w konfiguracji Apache to zezwolenie na nadpisywanie globalnych ustawień poprzez pliki .htaccess – bez tego nasz serwer będzie kompletnie olewał nasze reguły. Otwórz do edycji plik /etc/apache2/apache2/conf, znajdź:

Options Indexes FollowSymLinks
AllowOverride None
Require all granted

I zamień AllowOverride None na AllowOverride All.

Przenoszenie plików

Jeśli zakładasz nowego WP, to będzie łatwiej. Jeśli przenosisz, trzeba trochę powalczyć, ale wygląda to prawie identycznie jak przenoszenie z jednego serwera na drugi. Zaloguj się do swojego obecnego FTP i pobierz całą zawartość katalogu /html/ lub /www/, zależy od serwera. Najlepiej zrobić to zawczasu, bo jeśli masz sporo plików, to ściąganie ich przez FTP będzie trwało wieczność, tym bardziej jeśli masz kilka GB danych. (kliknij aby powiększyć).

Możesz oczywiście teraz całość przekopiować do katalogu /html/ na nowym serwerze poprzez WinSCP, po prostu przeciągnij pliki z folderu do okna WinSCP i… czekaj. No nie jest tak źle, u mnie 1350MB kopiowało się 20 minut. To jest nadal o 1 dzień szybciej niż przez FTP ;)

Ale po co się w ten sposób męczyć skoro nasz serwer jest w tym samym pomieszczeniu? Przecież można jego kartę SD włożyć do komputera i zwyczajnie przekopiować pliki (o ile system jeszcze nie jest przeniesiony na wewnętrzną pamięć). Wystarczy włożyć kartę do komputera żeby przekonać się że… nie jest rozpoznawalna i windows proponuje jej format. Nasz system Armbian Jessie ma już domyślnie zainstalowaną paczkę do obsługi formatów NTFS więc widzi wszelkie pendrive’y bez potrzeby ich formatowania, ale Windows nie umie EXT4 w którym sformatowana jest karta, i nigdy umieć nie będzie. Na szczęście ktoś się pofatygował i napisał sterownik Ext2Fsd który wystarczy zainstalować na naszą wingrozę, po czym „bez problemu” będą obsługiwane te „dziwne” formaty. Niestety nie działa to tak świetnie, przed wyjęciem pamięci skorzystaj z opcji „usuń” aby bezpiecznie odmontować sprzęt. Podczas moich zabaw raz dostałem BSODa, raz przekopiowane pliki w ogóle nie pojawiły się w docelowym systemie, a raz uszkodziłem system plików i system wywalał że cała pamięć jest ustawiona na tylko do odczytu i musiałem zaczynać od zera. Potem przeprosiłem się z WinSCP :)

Przenoszenie bazy danych

Masz wszystkie pliki, teraz baza danych. Zrzut bazy danych można wykonać w panelu phpMyAdmin swojego obecnego serwera. Wybierz bazę danych, kliknij w zakładkę export, i opcjonalnie wybierz tabele które chcesz wyeksportować. Ja zaznaczyłem tylko tabele dotyczące wordpressa, bo na serwerze miałem jeszcze jakiś inny szajs który korzystał z bazy danych, a jako że mój tani hosting przewidywał tylko jedną bazę danych, to wrzuciłem w nią wszystko co musiałem. Format SQL powinien być zaznaczony domyślnie. Opcjonalnie zaznacz kompresję .gz, wtedy baza zostanie skompresowana co znacznie zmniejszy jej rozmiar. Wykonaj spowoduje wyeksportowanie zaznaczonych tabel, skompresowanie, i pobranie na dysk. (kliknij aby powiększyć)

Zanim zamkniesz okno, przejdź jeszcze do zakładki Operacje i zanotuj sobie jaką masz metodę porównywania napisów. W zasadzie to samo musimy zrobić po drugiej stronie, tyle, że odwrotnie. Dobrze by było mieć łatwy wgląd w całą strukturę baz danych, zamiast bawić się w niezrozumiałe polecenia w konsoli. Właśnie dla tego zainstalujemy teraz apt-get install phpmyadmin. Podczas instalacji wybierz serwer który masz zainstalowany czyli w tym przypadku apache2, a następnie zgódź się na utworzenie nowej bazy danych – tutaj podaj hasło do MySQL dla użytkownika root, które ustawialiśmy wcześniej. Panel powinien być dostępny pod adresem /phpmyadmin. Jeśli dostajesz 404, to spróbuj w konsoli dodać dowiązanie ln -s /usr/share/phpmyadmin /var/www/html/phpmyadmin – u mnie to rozwiązało ten problem. Zaloguj się do panelu danymi które podwałeś wcześniej, i utwórz nową bazę danych w zakładce Bazy danych, najlepiej podaj tę samą metodę porównywania napisów jaką miałeś na poprzednim serwerze.

Teraz przejdź do zakładki Import (cały czas mając wybraną nowo utworzoną bazę), wskaż plik z bazą danych którą pobrałeś wcześniej, i kliknij na Wykonaj . Dzięki temu że zmieniliśmy wcześniej limit wysyłanych plików, możemy przesłać większą bazę danych. (kliknij aby powiększyć)

Import może potrwać minutkę lub dwie.

No to już prawie. Teraz trzeba ustawić plik wp-config.php tak, aby wordpress mógł korzystać z bazy danych – i właśnie w tym celu go teraz otwieramy:
define(‚DB_NAME’, ‚nazwa bazy’);
define(‚DB_USER’, ‚nazwa uzytkownika’);
define(‚DB_PASSWORD’, ‚haslo’);
define(‚DB_HOST’, ‚localhost’);

Nazwa to nazwa bazy danych którą tworzyliśmy w phpMyAdmin, nazwa użytkownika to root jeśli nie dodawaliśmy innego użytkownika, a hasło to jego hasło, czyli te które tworzyliśmy podczas instalacji MySQL/phpMyAdmin. Nazwą hostu będzie localhost bo system zarządzania bazami danych jest umieszczony na tej samej maszynie co serwer www.

W panelu phpMyAdmin możesz stworzyć nowego użytkownika, przypisać do niego bazę wordpressa, nadać mu tylko niezbędne uprawnienia, i użyć tego użytkownika w pliku wp-config.php zamiast roota. Nazwa „wordpress” dla bazy wordpressa jest zbyt przewidywalna więc można wpisać coś innego. Również prefix wszystkich tabeli wordpressa dobrze jest zmienić z domyślnego „wp_” na cokolwiek innego. Takie zmiany pozwolą skuteczniej bronić się przed atakami SQL injection lub chociaż zmniejszyć ich straty.

Usuń teraz plik index.html (domyślny plik apache) z głównego katalogu serwera, i przejdź pod jego adres żeby sprawdzić czy wordpress próbuje się wyświetlić. Prawdopodobnie będzie działała tylko główna strona, i możliwe że strasznie koślawo.

Domena tymczasowa

Działa tylko pierwsza strona, bo wszystkie linki w każdym jednym miejscu Twojej strony będą wskazywały na poprzednią domenę, a teraz przecież wywołujemy ją z gołego adresu w sieci lokalnej. Aby to zmienić, trzeba wykonać operację podmiany tego fragmentu adresu na nowy, choć będzie to tylko tymczasowy adres, bo końcowo chcemy (ja chcę) wrócić na pierwotną domenę, czyli mdiy.pl – wtedy wykonam taką podmianę po razu drugi, ale najpierw chcę się upewnić że wszystko działa zanim zaserwuję przeniesioną stronę swoim odbiorcom.

Zamiast adresu lokalnego, dobrze będzie już teraz podpiąć jakąś domenę tymczasową i wystawić serwer na świat, a no na przykład żeby dać komuś z zewnątrz do potestowania. Osobiście korzystałem z adresu mdiy.duckdns.org, który założyłem na stronie duckdns.org. Może ta kaczka nie napawa na pierwszy rzut oka profesjonalizmem, ale usługa (w pełni darmowa z resztą) działa bezbłędnie. Wystarczy się zalogować i dodać domenę. Już, to wszystko. Działa. Opcjonalnie, jeśli mamy zmienne IP, instalujemy ich program który będzie uaktualniał nasz IP w ich bazie, dzięki czemu odwiedzający naszą tymczasową kaczą domenę zawsze trafią pod nasz IP. Ja zainstalowałem to na laptopie z windowsem, ale na stronie jest instrukcja jak taki „uaktualniacz” dodać do naszej płytki PI.

Jeśli masz wykupioną domenę, i jeśli Twój dostawca usługi udostępnia opcję DynHost, to możesz przekierować swoją domenę pod swój zmienny IP – będzie o tym niżej.

Trzeba będzie jeszcze raz dostać się do routera i przekierować ruch przychodzący z portu 80 na naszą płytkę. Służy do tego opcja port forwarding lub po prostu forwarding. Jak widzisz przekierowałem również port 8888 aby mieć dostęp do armbianmonitora. Możesz tutaj też dodać port 22 dla SSH, ale zastanów się dwa razy zanim wystawisz takie coś na zewnątrz.

Naprawa

Ok, to teraz naprawa wordpressa. Aby się w ogóle dostać do panelu administracyjnego, musimy ustawić nowy adres strony w… panelu administracyjnym. Bez tego, próba przejścia do /wp-admin skończy się przekierowaniem do panelu na starej domenie. Zaloguj się do phpMyAdmin, wybierz bazę danych z wordpressem, przejdź do zakładki Przeglądaj, wybierz tabelę wp_options i wyedytuj pola siteurl oraz home wpisując w nie poprawny adres.

Wszystkie odnośniki na całej stronie prowadzą nadal na starą domenę, tzn odnośniki do wszystkich wpisów, zdjęć, itd. Jest tego naprawdę sporo, dla tego skorzystamy z funkcji podmiany ciągów znaków wbudowanej w mysql. Wybierz bazę danych z wordpressem, przejdź do zakładki SQL, wklej, i kliknij na Wykonaj.
UPDATE wp_posts SET guid = replace(guid, ‚http://stary.com’,’http://nowy.com’);
UPDATE wp_posts SET post_content = replace(post_content, ‚http://stary.com’,’http://nowy.com’);
UPDATE wp_postmeta SET meta_value = replace(meta_value, ‚http://stary.com’,’http://nowy.com’);

Oczywiście podmieniając wcześniej adresy na prawidłowe. Operacja ta zajmie minutkę lub dwie, w zależności od tego jak duża jest baza, u mnie było 2824 zmienionych rekordów. Spróbuj teraz wejść do panelu administracyjnego. Jeśli widzisz tylko menu po lewej a reszta jest pusta, to prawdopodobnie któraś wtyczka tutaj miesza (u mnie była to wp-supercache). Spróbuj tymczasowo zmienić nazwę katalogu wp-contents/plugins na jakąś inną aby pozbyć się wtyczek. Wejdź jeszcze raz do panelu a następnie do menu wtyczek – dostaniesz informację że wszystkie wtyczki zostały wyłączone. Możesz teraz przywrócić nazwę dla katalogu wtyczek i spróbować ponownie je powłączać. Takie problemy biorą się z tego że apache nie jest jeszcze dobrze skonfigurowany, a katalogi wordpressa nie mają jeszcze odpowiednich uprawnień. Ale jesteśmy coraz bliżej :)

Przede wszystkim należy zmienić prawa własności całego katalogu serwera (/var/www/html) na www-data, czyli apache, dzięki czemu wszystkie później ustawiane uprawnienia będą miały sens i będą działać jak trzeba. W tym celu wykonaj w konsoli chown -R www-data:www-data /var/www.

Wszystkie katalogi powinny mieć uprawnienia 755, tak aby tylko właściciel i grupa mieli prawa do zapisu. Odczytać i wykonać może każdy:
find /var/www/html -type d -exec chmod 755 {} \;

Wszystkie pliki powinny mieć uprawnienia 644, tak aby tylko właściciel i grupa mieli prawa do zapisu. Odczytać może każdy:
find /var/www/html -type f -exec chmod 644 {} \;

Plik konfiguracyjny wp-config.php może być tylko odczytany przez właściciela i grupę, nie ma sensu ustawiać jakichkolwiek praw do zapisu:
chmod -v 440 /var/www/html/wp-config.php

Jeśli niektóre wtyczki (np. wp-super-cache) będą chciały nanieść zmiany w pliku wp-config.php, to można tymczasowo zmienić jego prawa na 640. Nigdy nie ustawiaj 777 dla żadnego pliku lub katalogu. Jeśli jakaś wtyczka tego wymaga, to spróbuj ustawić 775, a jeśli uparcie chce 777 to zrób to tylko tymczasowo.

Jeśli będziemy próbowali zainstalować lub zaktualizować jakąś wtyczkę, lub w ogóle zaktualizować wordpressa, ten poprosi nas o dane dostępowe do FTP. Ale my FTP nie mamy i nie jest nam do niczego potrzebny (no chyba że chcemy). Aby pozwolić WP na bezpośredni zapis do swoich katalogów, otwórz do edycji plik wp-config.php i dodaj linię define(‚FS_METHOD’,’direct’);.

WP Super Cache

Jeśli jeszcze nie korzystasz z tej wtyczki, to lepiej zacznij. Każda strona naszego wordpressa przed wyświetleniem musi być wygenerowana. Jeśli ktoś odwiedza stronę, to wordpress musi wykonać całą masę kodu PHP i całą masę zapytań do bazy danych, zanim będzie w stanie ją wyświetlić. Za każdym jednym razem, dla każdego jednego odwiedzającego i dla każdej podstrony i dla każdego wpisu włącznie ze wszystkimi komentarzami. Takie generowanie strony zużywa zasoby procesora i trwa pewien czas. Na normalnym serwerze może być to niezauważalne, ale na słabszych maszynach lub na tanich hostingach współdzielonych generowanie da się odczuć. Może ono trwać np 2-3 sekundy lub dłużej, jeśli mamy jakieś dodatkowe wtyczki zmieniające zawartość strony. No i do tego dochodzi czas potrzebny na przesłanie tych informacji do odwiedzającego, wraz z każdym jednym obrazkiem jaki jest na stronie zamieszczony, i to też przecież trwa. Moc obliczeniowa minikomputera na którym instalujemy wordpressa nie powala na kolana, wg google pagespeed insights czas samej odpowiedzi serwera OPi (wczytując stronę główną z 10 ostatnimi wpisami) wynosi aż 4.9 sekundy, a to jest bardzo dużo.

Można całkowicie zrezygnować z generowania strony w php, i zamiast tego serwować statyczne strony html. Dzięki temu czas odpowiedzi serwera będzie zmniejszony do minimum, będzie on tylko musiał wydobyć z dysku odpowiednią wygenerowaną wcześniej kopię strony i zaserwować odwiedzającemu, używając przy tym minimum potrzebnego kodu php. WP Super Cache, bo tak nazywa się wtyczka, wymaga zwykłego zainstalowania i prostej konfiguracji. Pierwsze otwarcie strony wymusi jej wygenerowanie i zapisanie do pliku, a wszystkie kolejne otwarcia będą polegały już tylko na przesłaniu jej kopii. Oczywiście nie możesz wtedy korzystać z takich rzeczy jak np. licznik otwarcia postu, bo nie będzie on aktualizowany. Strona będzie generowana na nowo także wtedy gdy ktoś doda komentarz lub gdy wyedytujemy wpis. Po uruchomieniu super-cache, czas odpowiedzi serwera zmalał praktycznie do zera, strona jest ładowana niemal natychmiastowo. Co na ten temat ma do powiedzenia pagespeed insights?

Wierzcie lub nie – ale wg tego testu strona osiąga taki sam lub minimalnie wyższy wynik w porównaniu do mojego obecnego mocno-współdzielonego hostingu. Pozostałe braki punktów to m.in. „Wyeliminuj blokujący renderowanie kod JavaScript i CSS z części strony widocznej na ekranie” – nie mam zamiaru się w to bawić bo trzeba grzebać w plikach motywu, który jest często aktualizowany.

Opisałem tylko te problemy które miałem sam podczas przenoszenia wordpressa, u Ciebie mogą i zapewne wystąpią inne, w zależności od tego w jakiej wersji i jak ustawione były poszczególne moduły serwera Twojego hostingu. Nie zapomnij też zajrzeć do pliku .htaccess głównego katalogu, zapewne masz tam jakieś własne reguły które być może trzeba uaktualnić.

Domena właściwa, dynamiczne IP

No to przekierowujemy starą domenę pod adres OPi. Jeśli mamy zmienne IP (a pewnie mamy), to mamy do obejścia też pewien mały problem. Nie wiem jak to wygląda u innych rejestratorów domen, ale pokażę na przykładzie OVH, bo właśnie u nich mam swoją domenę i dotychczasowy hosting. OVH udostępnia usługę DynHost (u innych rejestratorów może to się nazywać inaczej) która pozwala na przekierowanie domeny lub subdomeny na zmienne IP i uaktualnienie tego IP na serwerze DNS. Zaloguj się w panelu klienta, rozwiń menu domeny, i wybierz domenę którą chcesz przekierować. Wybierz kartę DynHost i utwórz nowy wpis DynHost, podając nazwę subdomeny oraz swoje aktualne IP. Musisz podać nazwę subdomeny, np. 1234.mdiy.pl, bo inaczej formularz Cię nie przepuści – nie wiem czemu jest to tak zrobione.

Po utworzeniu wpisu edytuj go, i usuń subdomenę (u mnie 1234) i zapisz – teraz przekierowujesz domenę główną.

Aby nasz adres mógł być automatycznie aktualizowany, należy dodać nowy identyfikator dostępu, w tej samej karcie czyli DynHost. Mój panel sam zaproponował mi dodanie takiego identyfikatora. Należy podać nazwę istniejącej subdomeny (wpisz gwiazdkę dla wszystkich subdomen, czyli *.mdiy.pl, bo kreator nie przepuści pustego pola nawet w edycji), nazwę identyfikatora, oraz hasło:

Aby móc z tego dobrodziejstwa skorzystać, należy skorzystać z któregoś z klientów aktualizacji dynamicznego IP, ja opiszę tutaj popularny program ddclient. Miałem z nim kilka problemów, ale to dla tego że błędnie wpisywałem dane.

Instalujemy apt-get install ddclient i przechodzimy przez prosty kreator, podając adres serwera DNS (u mnie www.ovh.com), protokół (u mnie dyndns2), nazwę i hasło które podawaliśmy przy tworzeniu identyfikatora, nazwę interfejsu sieciowego (eth0 jeśli korzystamy z kabelka), oraz adres którego dotyczy aktualizacja (u mnie mdiy.pl). To tak w skrócie, bo i tak trzeba otworzyć plik /etc/ddclient.conf i zmienić m.in. linię use, bo niestety interfejs eth0 będzie znał tylko swój adres lokalny, więc IP trzeba pobrać z internetu:
daemon=3600 – wysyłanie zmian co 3600 sekund (1 godzina)
protocol=dyndns2 – protokół
use=web, web=checkip.dyndns.com, web-skip=’IP Address’ – sposób pozyskiwania naszego adresu
server=www.ovh.com – adres serwera
login=identyfikator – identyfikator który założyliśmy
password=’haslo’ – hasło identyfikatora (w apostrofach)
mdiy.pl – adres którego zmiana dotyczy

Zrestartuj teraz usługę ddclient service ddclient restart aby wczytać zmiany. Działanie usługi można sprawdzić wpisując ddclient -debug -verbose -noquiet i chwilę poczekać na wysłanie i odebranie danych. Ddclient najpierw połączy się do checkip.dynds.com aby pobrać adres, a potem do serwera DNS dla naszej domeny aby uaktualnić IP. Jeśli nie ma błędów a na końcu widać odpowiedź serwera, to jest ok. Przykładowa odpowiedź:
RECEIVE: good 89.228.96.197
SUCCESS: updating mdiy.pl: good: IP address set to 89.228.96.197

Odpowiedź good oznacza poprawną zmianę adresu.

RECEIVE: nochg 89.228.96.197
WARNING: updating mdiy.pl: nochg: No update required; unnecessary attempts to change to the current address are considered abusive

Odpowiedź nochg to brak zmiany, czyli IP jest taki jak wcześniej. Dodatkowo otrzymujemy ostrzeżenie, że niepotrzebne spamowanie tą usługą grozi banem – stąd czas 1 godziny będzie bardzo bezpieczny. Usługa ddclient nie jest jednak głupia, zapisuje IP do pamięci i żądanie wysyła tylko gdy ten się zmieni.

Jeśli masz błędy, upewnij się że podajesz dobre dane. U mnie problemem było www.ovh.com – z początku wpisywałem ovh.com i dostawałem błąd w ogóle nie związany z tym adresem. Takie dane znajdziesz w FAQ swojego rejestratora pod hasłem DynHost lub DynDNS.

Ostatnią rzeczą którą trzeba tutaj zrobić (w panelu klienta), to usunięcie rekordu A w zakładce Strefa DNS który nadal przekierowuje naszą główną domenę na adres dotychczasowego hostingu. Lub inna opcja, jeśli jakimś cudem posiadasz stałe IP, to wtedy już bez kombinacji przekierujesz domenę główną na nasz IP. Po prostu wyedytuj rekord A i zmień IP na własny i nie kombinuj z żadnymi dynamicznymi DNSami.

Propagacja Twojego nowego adresu pomiędzy serwerami DNS może trwać nawet do 24 godzin, ale często jest to dużo mniej. Jako pierwszy o zmianach dowie się DNS który bezpośrednio obsługuje Twoją domenę u Twojego rejestratora, masz to w zakładce Serwery DNS – jeśli są nazwy zamiast adresów, to adres bez problemu znajdziesz w FAQ. Czemu o tym piszę? Bo już teraz możesz podejrzeć czy wszystko jest dobrze ustawione, bez potrzeby czekania kilkunastu godzin, nanoszenia ewentualnych poprawek, i znów czekania. Możesz ręcznie odpytać dowolny DNS o dowolną domenę i sprawdzić jaki adres zwraca. Ba, windows ma nawet wbudowane narzędzie. Otwórz konsolę cmd.exe i uruchom program nslookup. Program wyświetli z którego serwera korzysta komputer i tego będzie domyślnie używał (u mnie OpenDNS bo tak sobie ustawiłem na routerze). Aby zmienić serwer wpisz server xxx.xxx.xxx.xxx gdzie x to adres IP serwera DNS Twojej domeny. Następnie wpisz nazwę swojej domeny z kropką na końcu, czyli mdiy.pl. , i sprawdź jaki adres zwraca. Jeśli jest to Twój publiczny adres, to wszystko powinno być dobrze. Możesz sprawdzić inne DNSy, np. googla, czyli 8.8.8.8.

Teraz wystarczy poczekać aż wszystkie serwery DNS wymienią się nową informacją, i wszyscy przechodząc pod Twoją domenę będą mogli trafić na nowy adres. No właśnie, a co się stanie jeśli moje IP się zmieni, czy znów będę musiał czekać na rozpowszechnienie go po wszystkich DNSach? Tak, niestety. Oczywiście cały czas mówimy o amatorskim domowym hostingu amatorskiej strony www i wtedy można sobie na takie coś (na kilkugodzinne przerwy w działaniu co jakiś czas) pozwolić. Mój ISP potrafi zmienić mi IP raz na kilka miesięcy, więc jest dobrze. Jeśli Twój zmienia je codziennie, to raczej nie tędy droga. Możesz skorzystać wtedy z usługi stałego IP za dodatkowy czteropak miesięcznie, ale taka zabawa raczej nie jest opłacalna.

WordPressa na czas przenoszenia mieliśmy skonfigurowanego z innym adresem, i teraz trzeba to wszystko (wszystkie wewnętrzne odnośniki) zmienić na właściwe. Ponownie wejdź w phpMyAdmin i ponownie wykonaj polecenia podmiany adresów w bazie danych:
UPDATE wp_posts SET guid = replace(guid, ‚http://stary.com’,’http://nowy.com’);
UPDATE wp_posts SET post_content = replace(post_content, ‚http://stary.com’,’http://nowy.com’);
UPDATE wp_postmeta SET meta_value = replace(meta_value, ‚http://stary.com’,’http://nowy.com’);

I możliwe że niektóre wtyczki znów przestaną działać. Jeśli Ci to nie przeszkadza, to najpierw możesz przekierować domenę na nowy serwer, a dopiero później się bawić w naprawianie wordpressa.

Na serwerze nie jest zainstalowany ani FTP, ani MAIL. Bez problemu znajdziesz poradniki jak to zrobić. Jeśli chodzi o wysyłanie wordpressowych powiadomień na email to wystarczy założyć sobie dodatkową skrzynkę np. na gmailu, i skorzystać z SMTP aby przekazywać pocztę z wordpressa do gmaila który to dopiero wyśle ją na właściwy adres.

Podsumowanie

Jak realnie sobie radzi nasz OPi w powierzonym mu zadaniu? Całkiem zacnie, dla odwiedzających nie ma różnicy w ładowaniu strony, no może niektóre większe pliki będą się pobierać dłużej, ale to z powodu marnego uploadu mojego łącza które przy dobrych wiatrach osiąga deklarowane 4Mbit UP. Jedyne opóźnienia jakie mogą być odczuwalne ale nie jakoś uciążliwie, to te przy generowaniu strony w php, czyli np dla użytkownika wysyłającego komentarz, lub dla administratora grzebiącego w panelu. Robiłem też testy obciążenia ruchem sieciowym (na w pełni funkcjonalnym wordpressie), i normalne przeglądanie strony z zapytaniami GET (pobieranie treści, zdjęć, itd) przez wielu użytkowników jednocześnie nie rodzi żadnych problemów. Użycie procesora jest małe, wąskim gardłem jest tylko mój upload. Serwer równie dobrze radzi sobie z umiarkowaną ilością zapytań POST (z punktu widzenia odwiedzającego będzie to wysyłanie komentarza lub formularza kontaktowego).

Tak wygląda obciążenie CPU w przeciągu dwóch dni:

Podczas przyjmowania normalnych odwiedzających i normalnych robotów sieciowych, średnie użycie procesora nie przekracza 10%. Widoczne 30% piki trwające około godziny każdy to zautomatyzowane ataki robotów sieciowych, np ataki brute-force na formularz logowania (wp-login.php). W tej chwili jakiś robot przeprowadza atak na XML-RPC – w logach widać mnóstwo zapytań POST do xmlrpc.php. To taki przykład. Dopóki stronę trzymałem na wykupionym hostingu to kompletnie się tym nie interesowałem, ale teraz jak na dłoni widać wzmożony ruch złych robotów. Po zablokowaniu dostępu do pliku (nie korzystam ze zdalnej publikacji więc nie jest on mi w ogóle potrzebny) atak ustał i użycie CPU spadło.


PS. Jeśli z powodzeniem korzystasz z Armbiana, to rozważ wsparcie projektu dowolną sumą – goście odwalają kawał dobrej roboty, a sam Armbian jest najbardziej sensownym wyborem jeśli chodzi o OrangePI.

Aktualizacja po 113 dniach

System pracował w sposób ciągły aż 113 dni i uważam że to bardzo dużo jak na jego niewielkie możliwości i moją znikomą wiedzę. Dzisiaj rano po prostu przestał odpowiadać, zniknął z listy klientów routera, i tyle. Jeśli restart routera nie naprawia takiego problemu, no to coś musiało pójść źle w samym OPi. A jako że jest to maszyna typu headless, to przy braku połączenia całkowicie tracimy z nią możliwość komunikacji. No, zawsze można przytargać jakiś telewizor i klawiaturę (której nie mam), lub do komputera podpiąć się przez port szeregowy, żeby prawdopodobnie stwierdzić że i tak będzie potrzebny restart :) Miał to być eksperyment, a wygląda na to że na stałe przeniosłem swoją stronę do własnej szafy i działa to wszystko całkiem niezawodnie, uptime 113 dni to całkiem sporo. Aktualizacje były wykonywane na bieżąco, w setnym dniu uptime Armbian dostał aktualizację systemu do wersji 5.30 i od tamtej pory nie aktualizowałem bo chciałem wpierw zrobić jakiś porządny system backupów – na wypadek gdyby nowa wersja mocno coś popsuła. No ale na razie nie mam kiedy się tym zająć. Jeśli już się przez to przegryzę, to wpis otrzyma następną aktualizację :)

5.00 avg. rating (98% score) - 3 votes

12 komentarzy

  1. No to mnie namówiłeś koleżko. Jaką płytkę teraz najlepiej jest kupić? Czy niewiele się zmieniło?

  2. Jeszcze nie wiem do czego, ale jak za 15 baksów to można nawet do zabawy. Przeglądałem te modele i faktycznie stosunek możliwości do ceny w modelu PC wypada chyba najlepiej. Bez wifi się obejdę. Widziałem jak ludzie stawiają serwer minecraft na raspberry pi, myślisz że na orange ma to szansę działać?

    • Też to widziałem, na pierwszych wersjach RPi było to kompletnie niegrywalne. Podobno na RPi2 / RPi3 z serwerem SPIGOT działa to już w miarę, próbuj, wynik na OPi powinien być podobny.

      Dla mnie pisali że wordpress na takim sprzęcie to tylko dla zabawy i że będzie to ledwie działać. Sprawdziłem, mylili się, i to bardzo :)

  3. Ok trochę poczytałem i poszukałem porównań, niestety Orange PI jest kiepska w porównaniu do innych płytek, zostaje w tyle za Raspberry PI 2, zobacz na ten benchmark http://www.phoronix.com/scan.php?page=article&item=raspberry-pi-3&num=1

    • Niestety – to ten „benchmark” jest kiepski. Bardzo. Zobacz tutaj:
      https://forum.armbian.com/index.php/topic/789-breaking-news-choosing-armbian-speeds-up-your-orange-pi-multiple-times/

      W skrócie, użyty system i karta SD mają gigantyczne znaczenie. W tym wątku rozchodzi się o to, że dla płytek OPi autor testów używał nieodpowiedniego systemu który nie potrafił poprawnie zarządzać taktowaniem i napięciami, i nie dość że CPU pracował poniżej nominalnej częstotliwości, to do tego wyłączał rdzenie z powodu przegrzania – przez co OPi PC dostawała tak niski wynik w stosunku do RPi2 i RPi3. I ogólnie cały ten test był przeprowadzony bez odpowiedniej wiedzy i przygotowań.

      W rzeczywistości OPi H3 i RPi2 używają tego samego procesora czyli Cortex ARM A7, z tym że w RPi2 jest 900MHz a w OPi mamy 1300MHz no mamy i lepsze peryferia. Więc jeśli jakiś benchmark pokazuje że RPi2 jest szybsze od OPi H3, to od razu można zamknąć taką stronę.

      RPi3 używa już procesora A8 64 bit (ale nie tylko, kilka OPi również). Niestety te całe 64bit naprawdę niewiele zmienia na tych płytkach, liczy się po prostu nowa architektura procesora. Póki co na RPi3 dostępny jest system Raspbian 32bit z zestawem instrukcji ARMv7 (procesor A8 jest kompatybilny wstecz) więc ta płytka nie może się wykazać jakąś super wydajnością. Niestety jeszcze przyjdzie nam trochę zaczekać na odpowiednie systemy 64bit ARMv8.

      Spójrz na te testy – tutaj płytki dostały odpowiedni system:
      http://openbenchmarking.org/result/1604016-GA-MERGE757555&obr_sor=y&obr_hgv=Orange+Pi+PC+on+Armbian

      Wg nich OPi H3 wydajnościowo depcze po piętach RPi3, zostawiając RPi2 daleko w tyle. Zerknij też na wydajność vs cena. Przypominam że OPi PC to 15$, a RPi3 to jakieś 38$ zależnie od źródła. W Polsce za RPI3 trzeba zapłacić 180zł

  4. Muszę przyznać że im więcej czytam tym mniej wiem.

  5. Super poradnik! Ja teraz kombinuję jak zrobić to samo na moim Raspberry Pi 3 (jak były wyprzedaże 11.11 to kupiłem z kuponami od sprzedawcy i tymi, które miałem od Ali po 29$ za sztukę). Orange Pi chyba też kupię, bo widzę, że po taniości teraz można kupić, zwłaszcza że są urodziny Ali.

  6. Hej.
    Zastanawiam się jakie masz parametry łącza. Stronka świetnie się wczytuje aż dziw że działa to na miniaturowym serwerku

Odpowiedz na „KtośAnuluj pisanie odpowiedzi

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Proszę pozostawić te dwa pola tak jak są: