Męcząca administracja blogiem na Wordpress

[jakubd]

Właśnie zakończyłem walkę z drugą rzeczą związaną z Wordpress. W sumie dwie takie "dziury" łatałem:
1. Około roku temu serwer gwałtownie zwolnił. Zobaczyłem, że jest mnóstwo odwołań do adresu jdtech/wp-admin, gdzie normalnie użytkownik/administrator loguje się do interfejsu. Problem w tym, że każda próba powoduje odpalenie całego silnika Wordpressa, odpowiednich modułów php i bazy danych mysql. 20-30 wywołań na sekundę (prób zalogowania) po prostu przeciążyło maszynę.
Rozwiązanie - dodanie autoryzacji niskopoziomej (http auth) na ten folder. Dzięki temu serwer WWW zwraca kod braku dostępu 401 zanim zacznie uruchamiań zasobożerny podsystem php. Problem zniknął natychmiast.
2. Teraz znowu coś takiego znalazłem w logach:

Kod:

185.62.189.47 jdtech.pl - [31/May/2015:21:02:04 +0200] "POST /xmlrpc.php HTTP/1.0" 200 389 "-" "Mozilla/5.0 (compatible; Googlebot/2.1;  http://www.google.com/bot.html)"

Oczywiście nie jest to googlebot, tylko próba ataku na podsystem xmlrpc w Wordpressie. Nieudany, bo podsystem wyłączony, poza tym Wordpress za stary. Problem w tym, że znowu kilka razy na sekundę atakuje i serwer staje dęba. Zastosowałem tę samą metodę - http auth. Problem zniknął.

Czekam na kolejny taki atak
Prze to jednak migracji serwera nie zrobiłem.

[spag]

Mnie sie dzis zdarzyło

Wysłane z mojego GT-N7105 za pomocą Tapatalk 2

[jakubd]

To dokładnie objaw tego problemu, który rozwiązałem wieczorem dopiero.

[Brunatny]

Witam Wszystkich

(31-05-2015 21:13)jakubd napisał(a):  Rozwiązanie - dodanie autoryzacji niskopoziomej (http auth) na ten folder. Dzięki temu serwer WWW zwraca kod braku dostępu 401 zanim zacznie uruchamiań zasobożerny podsystem php. Problem zniknął natychmiast.

Mam pytanie czy możesz napisać jak wykonać tą autoryzację niskopoziomową bo mam ten sam problem. Serwer www stoi na OpenSuse 11.4

Z góry dziękuję za odpowiedź

[jakubd]

Nie ma znaczenia serwer (w znaczeniu dystrybucja) tylko jakiegoś używasz demona (serwera) WWW - ja mam lighttpd, większość używa apacha, z rzadka nginx innych.
Ogólnie musisz skonfigurować http auth (autoryzacja http) i tego szukasz dla swojego serwera WWW - w apache robi się to za pomocą pliku ./htaccess (zawiera zasady autoryzacji i dostępu do treści) i umieszczonego gdzieś obok .htpasswd lub podobnego, w którym trzymasz zaszyfrowane hasła. Ja w lighttpd takie rzeczy muszę trzymać w samym konfigu /etc/lighttpd/* - to jest męczące, ale z powodu wydajności imho się opłaca męczyć.

Uwaga techniczna - są pluginy wordpressa, które źle znoszą brak dostępu klientów do wp-admin - a to powoduje właśnie zahasłowanie wp-admin. Jednak ja na szczęście żadnego z nich nie używam.

[whiteindian]

W jaki sposób robisz backupy WP, czy używasz wtyczek czy kopiujesz wszystko via FTP, co jaki czas?

[jakubd]

Wtyczka robiąca zrzut plików i bazy MySQL + zewnętrzny skrypt pobierający kopię na inny serwer, a dodatkowo na NAS zainstalowany w lokalizacji, gdzie zarządzam siecią lokalną i mam szybkie łącze.
Zaleta - bardzo szybko się to przywraca.
Wady - wydajność backupu jest ograniczona (w większych systemach potrafi się robić kilka godzin).

[whiteindian]

A jakie to konkretnie narzędzia jeżeli jesteśmy przy tym?

[jakubd]

To zależy od konkretnego serwera i usługi, którą zarządzam.
Najczęściej w przypadku Wordpressów używam BackUpWordPress
Natomiast do kopiowania między serwerami - własnych skryptów korzystających z rsync po ssh z raportowaniem w logach i powiadomieniami email.

Backup jednego z obsługiwanych przeze mnie serwerów trwa 14 godzin, więc jest wykonywany nie codziennie, tylko co kilka dni przy mniejszym ruchu i bez skryptów wbudowanych - tylko na żywych plikach z kompresją podczas kopiowania między serwerami - głównie z powodu wielkości i liczby plików nie da się tego zrobić inaczej przy przydzielonym budżecie. 14 godzin nawet pomimo tego, że to jest tylko przyrostowe.

[whiteindian]

Czyli sam BackUpWordpress Tobie wystarcza? Bo ja oprócz niego kopiuję wszystko przez FTP, i czy do tego osobno jeszcze bazy MySQL poprzez panel cPanel zrobić backup? Czy to wystarcza żeby zabezpieczyć Wordpressa.

Raz wgrałem nowszą wersję tematu i wszystko mi się posypalo, bo nie wiedziałem które pliki .php na nowo zmieniać. U mnie jedynie uciążliwe byłoby podnoszenie tego na nowo, no ale 14 godzin tutaj jak piszesz - to szmat czasu.

[jakubd]

Wtyczka backupowa robi tylko zrzut - ale komplet: plików i bazy danych. To wystarcza do odtworzenia bloga w innej lokalizacji. Są takie, które potrafią taki pakiet potem wysłać dalej, np. na dropboxa. Ja to wolę rsync'iem zaciągnąć na inny serwer.
cPanelem to raczej zrzucasz, żeby mieć kopię z danej chwili, niezależnie od regularnych kopii.

Co do tego 14 godzin - to własny system, i to tylko aktualizacja zmian tyle trwa. Pełen backup to już idzie w dni.

[whiteindian]

Postanowiłęm osobno przez FTP. Natomiast bazy mySQL nie dało się. phpmyadmin pokazał że nia ma tabeli, a wtyczka WP pokazałą:

MYSQL dump path does NOT exist
MYSQL path does NOT exist
passthru() disabled.
system() disabled.
exec() disabled.

Mimo że ustawiłęm w niej,
/usr/bin/mysqldump
/usr/bin/mysql


A support podał mi trzy linki, jakby nie rozwiązali tego z któego mogę sobie pobrać:
http://yyy.org/xx_16222222_13042016.sql.gz
http://yyy.org/xx_16222222_wordpress.sql.gz
http://yyy.org/xx_16222222.tar.gz

Ostatni to cała baza, to które to SQL i jak to potem odzyskiwać? Wzasadzie miewałęś jakieś bardzo poważne problemy w takich przypadkach?

[jakubd]

Zaraz, zaraz, phpmyadmin nie może powiedzieć, że wskazanej konkretnej tabeli nie ma - po prostu coś źle robisz. Dalsze komunikaty oznaczać można, że usługa jest straszliwie ograniczona i takich podstawowych operacji robić z jakiegoś powodu nie można.

Ręczne wskazywanie ścieżek systemowych nie jest dobrym pomysłem, jak to nie jest twój cały fizyczny serwer i nie wiesz co dokładnie robisz.

A te zrzuty to skąd się wzięły i dlaczego ich aż tyle? Powinny być dwa - foldera z wordpressem i osobno dump bazy danych. Ale nie ma to sensu, jak nie jest regularnie robione z automatu.

Odzyskiwanie:
1. Skopiować odpowiednio pliki tak, aby były we właściwych miejscach i były dostępne pod tymi samymymi URLami
2. Wrzucić obraz bazy danych dokładnie tak samo jak to było w bazie źródłowej - uwaga na nazwę użytkownika mysql i jego uprawnienia.
W razie potrzeby należy poprawić konfigurację wordpressa tak, aby miał nadal dostęp do tych samych danych.

Po tym powinien ruszyć.

Jeżeli używasz gotowych pluginów, to czasem można odpowiedni plik podać pluginowi i on zrobi resztę. - wystarczy postawić wordpressa i plugin od backupu. Ale tego nie testowałem.

[whiteindian]

No ten pierwszy ma 4KB ten drugi 1MB a ostatni to cały wp zrzucony do archiwum z plikami.

Po rpostu wszedłem do phpmyadmin, usunąłem domyślną bazę któa tam była, stworzyłęm nową z datą w nazwie, i próbowałem się połączyć, nic tam nie ma. Więc napisałem do supportu oni przysłąli mi linki do tych trzech plików, czyli jakby przysłali mi tą któą usunąłem? Skoro stworzyłęm nową bazę należało po połączeniu do niej dodać elementy i dopiero exportować? Lecz nie do końca wiem jak, i nie rozumiem czemu support tego mi nie wytłumaczył tylko przesłał to co wystarczyło.

[jakubd]

Jak grzebiesz w phpmyadmin to wszyscy zakładają, że wiesz co robisz Machanie po bazie za pomocą SQLa w ciemno to słaby pomysł.

Wytłumacz mi co dokładnie zrobiłeś, bo nie rozumiem, widzę to tak:
1. Masz działającego bloga na wordpressie i bazie danych
2. Wszedłeś do phpmyadmin i wywaliłeś blogowi jego bazę danych i dziwisz się, że nie ma nic do eksportu.

No to coś mi tu nie gra.

Prawidłowo podłączony pod odpowiedni DBMS (serwer baz danych) i z odpowiednimi danymi logowania (user/pass) widzi bazy danych, z których korzysta blog. Wybierasz w nim DB (bazę danych - z żywymi danymi bloga) i możesz dokonać eksportu (dumpa) do pliku w formacie SQL, zwykle od razu skompresowanego ZIPem lub czymś podobnym (jak pracuję w konsoli zwykle uniksowej, to wolę tar.gz).
Import - w drugą stronę: logujesz się i od razu robisz wciągnięcie pliku SQL.

Szczegóły zależą od takich rzeczy, jak ew. dostęp do bazy danych jaki masz - czy sam tworzysz użytkowników, czy masz przypisanego (w tym drugim wypadku na kolejnej maszynie musisz grzebać w plikach konfiguracyjnych wordpressa, żeby ew. zmienić dostęp do bazy).

[whiteindian]

No już sam nie wiem, bo oni niby przysłąli mi te linki, a teraz tłumaczą:

"If you deleted the wordpress DB the data for your blog will have been irrecoverably removed, you should consider using Softaculious script installer to install a new blog again."

???
Dostałęm od nich jakąś bazę sql jak to teraz załądować, choć mam obawy czy mi nie rozwali WP.(Jak widać słąbo to kojarzę). I o jakim skrypcie mówią, instalacja na nowo oznacza wgranie tych kilkuset megabajtów na nowo? Bo chciałem już teraz zrobić nową nazwę subdomeny, i może wtedy ten cały skrypt jednocześnie przywróćiłby mi bazę.

[jakubd]

Jeszcze raz napisz w dwóch osobnych listach:

A. Co chcesz zrobić/uzyskać.
B. Co tak naprawdę zrobiłeś.

Bo jak na razie to oni napisali to co ja - jak skasowałeś bazę, to jej nie masz. Proste. Wordpress ze skasowaną bazą nie działa - jest martwy, nie ma artykułów, nie ma nic poza materiałami zapisywanymi na dysku (media), ale i tak nie wiadomo do czego służą, bo to jest zapisane w... bazie.

[whiteindian]

A. Chcę eskportować bazę danych SQL + plki z FTP
B.

Celem było zrobienie bazy danych WP + SQL jako kompletny backup mojej strony Wordpressa.
Jak mi powiedziano to wystarczy zrobić żeby zrobić kopię poprawną wszystkiego z WP.

1. Skopiowałem całe htdocs poprzez FTP programem Cyberduck
2. Wszedłęm do cPanel -> phpMyadmin i usunałęm istniejącą tam podstawową bazę SQL - to był błąd....
3. Stworzyłęm nową bazę SQL
4. Poprzez phpMyadmin połączyłęm się z nową bazą danych lecz nic tam w środku nie było

Napisałem do supportu webhostingu, jest to bezpłątny amerykański dostawca.
O oni mi przysłąli "A full backup can be downloaded from" bez nawiązywania do kwestii bazy SQL.
Tam były trzy pliki: jeden to wszystko co miałem z FTP tutaj zapakowane do archiwum ok. 300MB, drugi plik to nazwa bazy danych nowostworzona (pusta) o wadze 4KB, a trzecia
to rzekomo baza danych któą ja usunąłem (nie jest pewien) o wadze 1MB.

Czy ta przesłąna od nich baza _wordpress.sql.gz to gdzies jakiś backup u nich zanim ja usunąłem to poprzez phpmyadmin? Nie wiem teraz czy to jakoś przywróćić, czy jest tak jak oni pisza w supporcie, że musze jakimś skryptem instalować na nowo bloga.

[jakubd]

No to dobrze zrozumiałem, że sam sobie skasowałeś wszystkie dane.

Masz ten drugi plik SQL (większy z przed usunięcia) i za pomocą phpmyadmin możesz go "wciągnąć" do bazy i wszystko wróci do normy.

Backup rób raczej wtyczkami, a nie bezpośrednio, bo to się jak widać źle kończy

[whiteindian]

Nie zrobię restore przez cPanel on jest w okrojonej wersji....