LAMP++

Biztos volt már aki nem örült annak, hogy ha például egy SELECT a végtelenségig futot. Erre eddig nem volt megoldás, de most úgytűnik, hogy mégis meglehet oldani:

• MySQL native driver for PHP - mysqlnd
• MySQL Native Driver

Ez a lényeg:

One important part of the MySQL Native Driver, which is overlooked, is that when connecting to MySQL via a socket, the connection is subject to the "default_socket_timeout" value.

This means that if you have the default_socket_timeout set to 60 (default value), and you have a query that takes longer than 60 seconds to respond, the connection will be severed and getting the query results will fail.

Ugyan PHP -ban nekem még sohasem hiányzott, de azért jó tudni, hogy ilyen is van: Standard PHP Library (SPL). Persze aki C++ irányból jött annak gondolom ez természetes :)

Legutóbb írtam egy postot a PHP fordításról. A cucc látszólag működött, de azért előjött néhány olyan probléma amire álmomban se gondoltam volna. A legfájobb az volt, hogy a phpMyAdmin elég vacakul nézet ki a fordított PHP -val.

Elég rejtélyesnek tűnt a dolog, de némi debuggolás után kiderült, hogy a reguláris kifejezésekkel van a probléma, úgyhogy itt van a végleges configure amivel már tényleg minden megy :)

./configure \
--with-apxs2=/usr/bin/apxs2 \
--disable-cli \
--disable-cgi \
--with-config-file-path=/etc/php5/apache2 \
--with-config-file-scan-dir=/etc/php5/apache2/conf.d \
--disable-ipv6 \
--enable-bcmath \
--with-bz2 \
--enable-calendar \
--enable-dba \
--enable-exif \
--enable-ftp \
--with-gd \
--with-freetype \
--with-t1lib \
--with-zlib \
--with-jpeg \
--with-jpeg-dir=/usr/include \
--with-gettext \
--enable-mbstring \
--with-libmbfl \
--with-mcrypt \
--enable-memory-limit \
--with-mime-magic \
--with-mysql \
--with-mysqli \
--with-pdo-mysql \
--with-pcre-regex=/usr/include \
--enable-shmop \
--enable-soap \
--enable-sockets \
--enable-sysvmsg \
--enable-sysvsem \
--enable-sysvshm \
--enable-wddx

Régebben szerettem fordítani a PHP -t. Kedvencem a statikusan apache -ba fordított verzió volt - tiszta, egyszerű, szép. Egy baja van, ha már több gépen is kéne csinálni, akkor egy idő után macerás az állandó fordítgatás. Igy ma már a csomagos megoldást preferálom.

Viszont, vannak rendkívüli esetek. Nemrég például egy régebbi verziójó PHP -t kellett használni, először csak próbának, aztán ha jó, akkor ez marad. Itt úgy gondoltam, hogy újra elő lehet szedni a fordítgatást.

Fordítás mente:

./configure \
--with-apxs2=/usr/bin/apxs2 \
--disable-cli \
--disable-cgi \
--with-config-file-path=/etc/php5/apache2 \
--with-config-file-scan-dir=/etc/php5/apache2/conf.d \
--disable-ipv6 \
--enable-bcmath \
--enable-calendar \
--enable-dba \
--enable-exif \
--enable-ftp \
--with-gd \
--with-freetype \
--with-t1lib \
--with-zlib \
--with-jpeg \
--with-gettext \
--enable-mbstring \
--with-mcrypt \
--enable-memory-limit \
--with-mime-magic \
--with-mysql \
--with-mysqli \
--with-pdo-mysql \
--enable-shmop \
--enable-soap \
--enable-sockets \
--enable-sysvmsg \
--enable-sysvsem \
--enable-sysvshm \
--enable-wddx

make

Kell néhány csomag is a fordításhoz: flex, bison, libxml2-dev, apache2-prefork-dev, libmysqlclient15-dev, libpng12-dev, libjpeg62-dev, libmcrypt-dev, libt1-dev

Egy trükk van, a make után nem kell make install, inkább kézzel kell a libphp5.so -t a /usr/local/lib/apache2/modules/ alá másolni.

Az új modult engedélyezni a /etc/apache2/mods-enabled/php5.load -ban kell:

#LoadModule php5_module /usr/lib/apache2/modules/libphp5.so
LoadModule php5_module /usr/local/lib/apache2/modules/libphp5.so

Fordítás után jöhet a tesztelés, amit a régi és az új phpinfo() összehaonlításával lehet elvégezni.

Egy olyan kérés ami súlyos másodpercekig fut a webszerveren elég gáz tud lenni, viszont nem mindig könnyű kideríteni, hogy melyek is ezek. Ebben fog segíteni az alábbi kis összeállítás.

Előszőr a proxy -n lehet vizsgálódni. Az nginx log moduljából kideról, hogy a $request_time -ot érdemes lelogolni és akkor kiderül, hogy melyik kérést mennyi ideig tartott kiszolgálni. Ezt igazából csak a teljesség kedvéért írtam, mert a proxy eléggé ártatlan szokott lenni esetekben.

A fő bűnös általában a PHP, vagyis az őt futtató Apache. Az apache doksijából látszik, hogy a %P The process ID of the child that serviced the request. és a %T The time taken to serve the request, in seconds. -t hasznos lehet lelogolni. Előbbi hibakeresésénél (beragadt child), míg utóbbi a lassú kérések megkeresésénél lehet hasznos. Annak ,akinek nagyon jó rendszere van és mindne kérés egy másodperc alatt lefut van egy másik lehetőség: %D The time taken to serve the request, in microseconds..

Szerencsére erre is van már célszerszám: a modlogslow. Ez egy apache modul, amivel le lehet logolni a lassú kéréseket. Mivel csomagban nincs, ezért le kell fordítani, amihez a apache2-prefork-dev -kell. Konfigurálása ennyi:

LogSlowEnabled On
LogSlowLongRequestTime 4000
LogSlowFileName /var/log/apache2/slow.log

A modlogslow kimenetét is lehet még tovább finomítani:

cut -d ' ' -f 13,15,5 /var/log/apache2/slow.log| \
sed -r "s/^([0-9.]+) (.+) (.+)/\2 \3 \1/" |sed -r "s/^www\.(.+)/\1/" |sort

ha ezt még egy egyszerű PHP programmal rendezgetjük, akkor a userek számára is emészthető eredményt kapunk..

Az apache persze igen gyakran a nem jól megírt SQL parancsok miatt lassú. Ezt úgy lehet kideríteni ha bekapcsoljuk a slow logot:

log_slow_queries = /var/log/mysql/mysql-slow.log
long_query_time = 4

Ennek a kimente elég nagy tud lenni, ugyhogy nemárt ha kiemeljük a lényeget a mysql-log-filter -el. Ennek futtatásához kell a php5-sqlite (már amennyiben PHP -ban futtatjuk). Használata pedig ilyen:

php /usr/local/mysql-log-filter/mysql_filter_slow_log.php -T=3 --no-duplicates \
--sort-execution-count --top=10 --incremental /var/log/mysql/mysql-slow.log

Én úgy vettem észre, hogy a log váltásokat nem kezeli jól,úgyhogy havonta nem árt letörölni az sqlite adatbázisát (pl.: cron.monthly -ban).

A DoS gáz dolog. Ha jól csinálják akkor sok mindent úgyse tehet az ember, de azért normál site -oknál ritka, hogy igazán "komoly ellenséget" szerezzen az ember, úgyhogy valószinűleg az esetleges támadás se kivédhetetlen.

Webszervereknél legelső védvonal a tűzfal. Léteznek olyan megoldások amik dinamikusan a forgalom elemzése alapján generálnak új tűzfal szabályokat és ezzel zárják ki az esetleges támadókat. Én ezekkel most nem foglalkozom. Nem mintha nem lennének jók, de valahogy ódzkodom attól, hogy életre keljen a szerverem ;)

Amit viszont használok az a shorewall blacklist funkciója. Itt kézzel kell hozzáadni a nem kivánatos IP -ket a blacklist filehoz. Hogy mik a kitiltandó IP -k azt a logokból vagy így lehet meghatározni.

Következő lépés a proxy. Ezzel sok baj nincs az nginx elég gyors, de azért picit ezen is lehet finomítani. A client_body_timeout és a client_header_timeout értékek megfelelően kicsi megválasztásával lehet segíteni a dolgon. Hogy mennyi a megfelelően kicsi az jó kérdés. A default az 60 sec én átállítottam 10 sec -re, erre még senki se panaszkodott.

Következik az Apache. Ez már problémás dolog, mivel a kiszolgálás ideje itt veszik el. Itt van az a pont ahol előjön, hogy az adott alkalmazás mennyire van jól megírva. Ha egy kérés kiszolgálása több másodpercig fut akkor DoS se kell ahoz, hogy vészessen belassuljon a szerver. Mivel a DoS elleni védekezés jórészt teljesítmény kérdés ezért érdemes azzal is foglalkozni. Következő postomban néhány módszert fogok mutatni a lassú alkalmazások felderítésére, de addig is mit lehet tenni a szerverrel?

Az Apache -nak vannak ilyenirányú útmutatásai, ezeken érdemes végigmenni. Én még ide sorolnám a MaxRequestsPerChild -et is. Ezt célszerű egy nem túl magas értékre állítani (5000), ami lehet, jót tesz a vészes memória fogyás ellen. Érdekes kérdés még a KeepAlive, hogy kell e egyáltalán? Normál esetben nyilván jó ha van, de ha proxy mögött vagyunk (ahol be van állítva) és az Apache -hoz csak a PHP -s cuccok jutnak el már nem kéne. Köztes esetekben, fogalmam sincs, - ki kéne próbálni, melyik a gyorsabb. Én nálam van, csak levettem a KeepAliveTimeout -ot.

Végezetül, egy célszerszám a mod_evasive, ami egy DoS elleni védekezést támogató Apache modul. Ez tud aktívan is védekezni, de én csak passzív módon használom. Mikor egy adott IP -ről a megadottnál gyakrabban jön kérés akkor oda 403 -al válaszol. Bővebben ittlehet róla olvasni.

Biztos sokan ismerik a regchecket. Ez az az eszköz, amivel le lehet tesztelni, hogy egy (.hu -s) domain DNS rekordjai helyesek -e? A beregisztrálás pillanatában ez biztos, hogy jó (mivel ez a feltétele), de később elromolhat attól még a rendszer működik.

Annak akinek sok domainje van néha jól jöhet egy shell -ből futtatható regcheck, amivel gyorsan lehet sok domaint ellenőrizni. Az említett script 1 domaint ellenőriz, de ebből már könnyen megoldható, hogy többre is menjen. Eredményként a hibákat és az esetleges sikeres futást írja ki. A hibáknak itt lehet utánanézni.

Végezetül még anyit, hogy "óvatosan" érdemes használni a programot célszerű az egyes lekérdezések közé egy kis szünetet iktatni, ne szivassuk szegény NIC -es webszervert ;)

Csípem a LAMP szervereket. Szépen be van állítva és gyönyörűen működik is már jó ideje mind. Nemrég viszont az a szörnyűség történt, hogy valaki JBoss -t is szeretett volna a szerverre. Na most ez nekem kemeny, ugyanis a Java az valamiért nem a szivem csücske. Ráadásul az is felmerült, hogy az illető szeretné telepiteni...

Rövid tanakodás után bevillant, hogy erre (is) való a virtualizáció. Az Ubuntuban ez már elég jól támogatott, és a doksik alapján a KVM lett a nyerő. Könnyű telepíteni és igen jó a sebessége.

A telepítésről röviden itt írtam, de igazából mindent megold a ubuntu-vm-builder. Érdemes már telepítésnél felrakni az SSH -t mert egy szerveren lehet, hogy könnyebb azzal belépni mint tunelt csinálni a VNC -hez (a default user aszthiszem, hogy ubuntu/ubuntu).

Alapból a hálózat NAT -olt, ami szerintem jó is (a másik lehetőség a bridge). Nem kell hozzá semmit módosítani a szerver hálózati beállításainál ami éles szerver esetén nem rossz. Általában kell FTP és SSH a usereknek ezt be lehet forwardolni, míg a webes elérésre pedig fel lehet használni a már amugy is működö web proxyt.

A virtuális gépet a virsh -val lehet kezelni.

A történet vége az lett, hogy végül én telepítettem a JBoss -t a gépre és azóta is fut szépen.

Egyszer már írtam a DNS cache -ről, úgyhogy most itt az ideje továbblépni, jöhet a DNS szerver. Ez is egy olyan dolog ami nélkül jól meg lehet lenni egy webszerveren, de azért néha mégis hasznos tud lenni. Ha például gyorsan kell egy aldomain (pl.: teszteléshez), akkor azt így a leggyorsabb megcsinálni.

A Tinydns installálása nem vészes dolog, ugyhogy itt most inkább a miértekkel és a hogyanokkal foglalkozom. Tehát miért pont Tinydns?
Hát mert még mindig jó :) De tényleg megírása óta se bug fix, se semmi probléma, csak teszi a dolgát. A legutóbbi (?) DNS sebezhetőségben majdnem az összes DNS szerver érintett volt, de a Tinydns persze nem.
Mi az ami ellene szól? Általában azok akik BIND -et használtak valamiért nem csípik. Ezt pontosan nem tudom miért, de valószinüleg más a logikája a programnak. Annak aki ezen kezdi el tanulni a DNS szerver mesterséget, annak garantáltan nem lesz vele baja.

Hogyan működik a DNS szerver?
A tinydns szolgálja ki a DNS kéréseket UDP -n, így ö figyel a publikus interface -en (DNS cache a lokálison). Szükség van még egy másodlagos DNS szerverre, aki időnként tőlünk fogja leszedni a zónákat. Ezt a zóna transzfert az axfrdns program végzi aki TCP -n figyel szintén a publikus interface -en. Ebböl látszik, hogy be kell szerezni egy másodlagos DNS szervert. Ezt vagy valami (fizikailag) távoli ismerős vagy pedig a szolgáltató biztosíthatja.

Ha már futnak a szerverek akkor jön a zónák létrehozása. Példa zóna fájl van itt is. Ami lényeg az az, hogy .hu végű domain neveknél nem szabad megfeletkezni a postmaster@domain.hu email cím létrehozásáról. Ha elkészült a zóna és megcsináltuk belőle a data.cdb file akkor lehet tesztelni a regcheck -el. Itt jegyzem meg, hogy a tűzfalon a www.nic.hu és a hureg.nic.hu gépeket célszerű beengedni. Ezeket a gépeket és persze a másodlagos name szervereket fel kell venni az axfrdns konfigjába is (tcp.cdb).

Hát röviden ennyi. Amit érdemes jól megfontolni az a domanek elsődleges és másodlagos name szervereinek neve. Idővel ugyanis előfordulhat, hogy más gépre akarjuk költöztetni a zónákat, így olyan nevek kellenek amik jól "mozgathatók" lehetőleg anélkül, hogy a domain tulajdonosának kérni kéne bármit is a regisztrátorától.

Nem tudom, hogy ki, hogy szabályozza az SSH port elérését, de én azt szeretem ha minél kevesebb helyről elérhető. Csak hát vannak a felhasználok akik viszont azt szeretik, ha könnyen be tudnak SSH -zni a szerverre.

Ennek a két dolognak az összehozásában sokat segít ez az oldal. Itt megtalálhatóak a fontosabb magyar ISP -k IP tartományai. Ezzel a listával már el lehet dönteni, hogy a kliens dinamikus IP -je alapján milyen osztályú hálózatot kell kinyitni a tűzfalon ahoz, hogy bármikor be tudjon jönni.

Nincs kizárva, hogy ez az info hozzáférhető máshonnan is, de nekem eddig nem sikerült beszerezni.