Zmiana katalogu baz danych MySQL
Na dzierżawionych serwerach często nie mamy wpływu na podział dysku na partycje i w przypadku gdy mamy nie nazbyt szczęśliwe wielkości partycji, nasza baza MySQL, szczególnie kiedy się rozrośnie, może zapchać nam dysk. Przeprowadzenie zmiany katalogu jest… proste, na szczęście
Zaczynamy od wyłączenie serwera.
-
/etc/init.d/mysql stop
Następną czynnością będzie przekopiowanie baz z aktualnego katalog do nowego (domyślnie w ubuntu bazy danych są w /var/lib/mysql)
-
cp -R -p -v /var/lib/mysql /nowy/katalog/mysql
I teraz mamy dwie możliwe drogi, zmiana katalogu w pliku konfiguracyjnym mysql, bądź podmontować nową lokalizację do starej. Więc opcja 1, edytujemy plik konfiguracyjny:
-
nano /etc/mysql/my.cnf
-
- datadir = /var/lib/mysql
-
+ datadir = /nowy/katalog/mysql
No i uruchamiamy MySQL
-
/etc/init.d/mysql start
Drugą możliwością jest podmontowanie nowego katalogu, do starego.
-
nano /etc/fstab
-
+ /nowy/katalog/mysql /var/lib/mysql bind 0 0
-
mount -a
No i uruchamiamy MySQL
-
/etc/init.d/mysql start
Jak wszystko gra, MySQL uruchomi się nam bez błędów
MySQL – pamiętaj o aktualizacji
Robiąc porządki na pulpicie, znalazłem ten wykresik z munina. Spójrzcie na niego. Widać prawie 10 krotny spadek zasobożerności MySQL! Jedyną poczynioną przeze mnie rzeczą, było proste wykonanie aktualizacji systemu: apt-get update && apt-get upgrade. Jak widać, trochę popracowali nad wydajność
.
Luka w nginx+fastcgi pozwalające na zdalne wykonanie dowolnego kodu
Oryginalny post: klik
po „ingliszu”: klik
a po naszemu, jest możliwość wykonania dowolnego kodu php.
możliwy model ataku:
1) prowadzimy hosting obrazków/plików, jest możliwość uploadu plików ogólnie;
2) ktoś wgrywa plik, plik to obrazek.jpg (nazwa czy rozszerzenie nie istotne) z kodem php;
3) dowolne wywołanie bezpośrednie pliku http://domain.tld/pliki/obrazek.jpg/cosdowlnego.php spowoduje wykonanie spreparowanego pliku;
przykład podatnej konfiguracji:
-
location ~ \.php$ {
-
root html;
-
fastcgi_pass 127.0.0.1:9000;
-
fastcgi_index index.php;
-
fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
-
include fastcgi_params;
-
}
która jest.. wszędzie, w każdym how to itp.
Możliwe formy zabezpieczenia się? Polecam lekturę: http://forum.nginx.org/read.php?2,88845. Można np dodać:
-
location ~ \..*/.*\.php$ {
-
return 403;
-
}
Nginx – kompilacja ze źrodeł
Nadrobię trochę zaległości w pisaniu na blogu
.
Chciałbym dziś przedstawić sytuację, gdzie samodzielnie skompilujemy sobie nginx-a. Ten fakt będzie miał wiele zalet. Po pierwsze – spokojnie można używać linii deweloperskiej. Używam już jej od ponad rok i nie było żadnych problemów. Po drugie – uzyskujemy możliwość dokompilowania dodatkowych modułów, które mogą nam ułatwić życie
. Rozważymy dwie sytuacje.
- Kompilacja na systemie bez nginx-a
- Kompilacja na systemie w którym jest już obecny nginx
Opis poczęty na Debian/Ubuntu. Więc zaczynamy
Nginx – jak zacząć
Ze swej praktyki mogę polecić każdemu, kto ma własnego VPSa bądź dedyka porzucenie Apacha na rzecz Nginxa bądź też użycie Nginxa jako revers proxy dla Apacha. Kilkukrotnie pozwala to podnieść wydajność naszej maszyny. Chciałem trochę popisać, jak się z nim obchodzić, ale ponieważ niektórzy już mnie ubiegli, nie będę odkrywał ameryki na nowo, tylko podam linki do miejsc, gdzie opisane jak zacząć przygodę z tym serwerem www
[1] Postawy konfiguracji nginxa
- Testowanie konfiguracji;
- Virtualhosty;
- Opcja include;
- Dyrektywa location;
- Rewrite
- Debug log
[2] Średnio zaawansowana konfiguracja nginxa
- Reverse proxy
- Fast CGI
- PHP
[3] Zaawansowana konfiguracja nginxa
- Ilość procesów roboczych
- Ograniczenie ilości otwartych plików
- SSL
- Kontrola dostępu
- Reguły Proxy
- Logi
- Optymalizacja
- Status
[1-3] Blog – http://notatnik.mekk.waw.pl polecam poczytać!
[4] Opis instalacji i konfiguracji
Błąd MySQL podczas kompilacji PHP
Mówię tutaj o takowym błędzie:
-
configure: error: Cannot find MySQL header files under yes.
-
Note that the MySQL client library is not bundled anymore!
Rozwiązanie?
-
apt-get install libmysqlclient-dev
Brak odpowiednich pakietów podczas kompilacji.
Tym razem poruszę kwestie kompilacji, a mianowicie sytuacji, kiedy podczas kompilacji pojawia nam się błąd, że akurat czegoś nie mamy. Np podczas kompilacji php możemy zobaczyć coś takiego:
libpng.(a|so) not found.
i zamiast wstukiwać bład w google, wpiszmy to w konsoli:
root@tessa:~# apt-cache search libpng fp-units-gfx - Free Pascal -- graphics libraries units libpng-sixlegs-java - Java package to read and display PNG images libpngwriter0-dev - easy to use graphics library (development) libpngwriter0c2 - easy to use graphics library (runtime) pngcheck - PNG file format checker pngquant - PNG (Portable Network Graphics) image optimising utility libpng12-0 - PNG library - runtime libpng12-dev - PNG library - development libpng3 - PNG library - runtime
Dzięki temu wyszukaliśmy pakiety, które mają w nazwie libpng. Z listy wybieramy interesujący nas pakiet, konkretnie to biblioteke do obsługi PNG -> libpng12-dev (a|so to kwestia brakujących bibliotek). Instalujemy ją i ponawiamy kompilację
Logrotate – brak rotacji logów.
Czasem się zdarza, że coś nagle przestaje działać mimo że, nie ma ku temu żadnego powodu. I mnie to również spotkało. Problem pojawił się z Logrotate. Oczywiście należy sprawdzić czy logrotate jest dodany do crona. Jak jest, a dalej nie ma rotacji logów możemy zrobić jedną rzecz, wydaje się dość błahą. Wykonajmy rotację ręcznie.
logrotate /etc/logrotate.d/*
W moim przypadku okazało się, że jeden wpis został podwojony (podczas aktualizacji którejś z aplikacji?) na czym logrotate się wykładał. Po usunięciu problemów z podwójnym wpisem, wszystko działa jak należy
Slowloris a Apache
Na howtoforge.com pojawił się tutorial, co do poradzenia sobie z atakiem przy pomocy Slowloris na serwer Apache przy pomocy mod_qos. Bęz zbędnego pisania, link do tutoriala. Mogę umieścić na blogu przetłumaczony tutek na nasz ojczysty język, w razie potrzeby skorzystajcie z opcji kontaktu
.
Slowloris a Nginx (atak typu DOS)
Ostatnio zrobiło się głośno o Slowloris, napisały o tym programiku większość portali informacyjnych. Jako że, ten programik jest łatwy w użyciu i łatwo dostępny to… spowoduje to, że zacznie się częste ataki przy użyciu tego skryptu w perlu, to na pewno
. Najbardziej narażony na atak jest Apache, ze względu na to jak działa samo Apache i na sama metodę przeprowadzenia ataku. Apache dla każdego połączenia tworzy osobny proces. Atak wygląda zaś w sposób, iż skrypt wysyła niedokończone nagłówki HTTP w ilości spoooorej, zależy z jakimi parametrami wywoła się skrypt, jednocześnie nie kończąc połączenia. Z tego powodu Apache czeka na dokończenie nagłówka przez klienta, ale on tego nie zrobi. Więc nagle Apache tworzy baaaardzo dużo procesów co zabiera baaardzo dużo zasobów. Powoduje to zadyszkę serwera, a w najgorszym wypadku, serwer przestanie odpowiadać w ogóle. Niestety… nie zmieni się sposobu działania apache. Ale to problemem przy dobrej konfiguracji nie jest. Należy zmniejszyć keepalive na kilka sekund np. Inną metodą może byś zastosowanie skryptu, który będzie sprawdzał ilość połączeń per IP. Jak ich będzie za duże, wyląduję gość w IPTables
. I na przykład serwerownia Leasweb udostępniła tego typu skrypt.
Ale o czym to ja chciałem… a, już wiem
. Ale nie używam Apache, tylko Nginxa.. i ja o tym chciałem
. Nginx działa w sposób odmienny. Tworzy 2-4 procesy, ewentualnie więcej w zależności od konfiguracji i każdy z tych procesów, może obsłużyć kilkadziesiąt/set tysięcy połączeń. Jedyny ograniczeniem jest ustawienie kernela co do ilości dostępnych socketów, otwartych plików przez proces itp. Zaś na przykład buffory związane z cachowanie połączeń sieciowych, połączeń itp. należy zmniejszyć. Po prostu ustawienia systemu ograniczą Nginxa. Ale, jednak należy pamiętać, że trzeba ustawić odpowiednio wysokie limity ilości połączeń dla pojedynczego procesu w konfiguracji Nginxa. Np proponowane przez autora Nginxa Igora Sysoeva.
worker_processes 4;
events {
worker_connections 200000;
use epoll;
}
Jak policzyć ilośc możliwych klientów podłaczonych do serwera?
worker_process * worker_connections = 4 * 200'000 = 800'000 połączeń
I Nginx spokojnie obsłuży taką ilość połączeń, pytanie tylko, czy system mu na to pozwoli, o czym wspominałem wcześniej
. Jeszcze jeden taki mały szkopuł. Należy zwrócić uwagę, czy Nginx działa jako pojedynczy serwer, czy też z tandemem np Apache, gdzie to Apache odpowiada za PHP. W takiej konfiguracji ilość maksymalnych połączeń należy podzielić na połowę. Z racji tego, że dla nginx 1 połączneie to kient <-> Nginx. Zaś kolejnym jest Nginx <-> Apache.