LAMP++

Tegnap este frissítettem egyik szerveremen a csomagokat. Lényegi változás az új PHP volt. Production gép, de hát mi baj lehet? ;)

Az eredmény egy kicsit felűlmúlta a várakozásaimat. Konkrétan se kép, se hang. Még konkrétabban: "exit signal Segmentation fault" lett az összes apache child -nél.

Ekkor jutott eszembe egy pár nappal ezelőtti vita egyik haverommal, ahol a Debian vs. Ubuntu volt a téma. Régebben mindketten Debian -t használtunk, de én egy ideje "áruló" lettem és átpártoltam az Ubuntu server -re. A vitának persze nem lett eredménye, de abban azért egyetértettünk, hogy a frissítések megbízhatóságában a Debian a király. Nyugodt szívvel ki lehet adni egy apt-get upgrade -et.

A segmentation fault -ok között hazudnék ha nem jutott volna eszembe, hogy bizony lehet, hohgy én választottam rosszul...

Azért rövid pánik, és aktív Google használat után, kezdett körvonalazódni, hogy mégse lehet olyan nagy gáz ebben az új csomagaban, így nálam van a probléma. Még egy nyom volt, a php logban: "PHP Fatal error: mktime(): Timezone database is corrupt - this should *never* happen!", de ez a segfaultok számához képest elenyésző volt, és különben is elég hülyén hangzott. Így utolsó megoldásként nem volt más, csak a strace.

Így már viszonylag gyorsan előjött a hiba, az apache chroot -jábol hiányzott az /usr/share/zoneinfo/Europe/Budapest és a /usr/share/zoneinfo/Europe/Berlin! Ennek oka az, hogy eddig nem kellett, vidáman ment a szerver ezek nélkül (időzónaval se volt gond) és ha már chroot akkor tényleg csak a legszükségesebbek legyenek benne. Szerintem.

Ebből az egészből több tanulságot is le lehet vonni, de ami ennél érdekesebb az inkább a második hiányzó file: /usr/share/zoneinfo/Europe/Berlin (nyilván sokan nem aprozzák el a dolgot, és bemásolják az egész zoneinfo -t a chroot -ba, így ott ez fel se tűnik). Az tuti, hogy az én timezone -omnak semmi köze Berlin -hez, ugyhogy a tippem az, hogy a programozó igy ellenőrizte, hogy a "Timezone database" rendben van e? Ez azért kicsit szomorú szerintem. Ez a tök értelmetlen ellenőrzés minden kérésnél (ez persze nem igaz) megtörténik ami nemigazán szép megoldás. Másrészt pedig ha nincs ott a Berlin, akkor valóban szükséges a "Fatal error"? Aligha...

Ami még érdekes volt, az a strace kimenete. Amikor az ember PHP -ban programozik, nem is gondol bele abba, hogy alacsonyabb szinten mik is történnek - megdöbbentően sok minden, de ez már 1 külön történet...

Miután elkészült a weboldal, biztosan felmerül 1-2 plusz igény:

• Jó lenne valami statisztika a látógatókról.
• Ha már van saját domainünk, akkor jó lenne néhány hozzá kapcsolódó email cím, ami a weboldalon is megjelenik.
• SEO

Ami a statisztikát illeti, legegyszerűbb választás a Google Analytics. Könnyű használni, és egyre többet tud. WordPress alá nagyon egyszerűen be lehet integrálni a Google Analyticator -al.

Emailek kezelésére szintén létezik ingyenes megoldás, ez pedig a Google Apps Standard Edition. Használatához át kell irányítani a domain MX rekordját a megadott módon, és nem árt egy CNAME rekordot beállítani a felület könnyebb eléréséhez. Ezután akár 200 email címet is létrehozhatunk a domain alá, és a tárhely is több mint elegendő.

A SEO annyira már nem egyszerű dolog. Néhány SEO tippet már írtam régebben, így aki megelékszik a title és a description helyes kitöltésével, annak elég az Another Wordpress Meta Plugin. Aki pedig többre vágyik, az használja az All in One SEO Pack -et.

Időnként felmerül az emberben, hogy jó lenne csinálni egy weboldalt. Csak egy egyszerűt, az ismerősnek vagy csak azért, hogy legyen. Régebben ilyenkor nekiestem PHP -ban és pár nap, 1-2 hét és kész van amit akartam. Most már ovatosabban közelítem meg a dolgot, keresek valami eszközt amivel a munka nagy részét megspórolhatom.

Az ismertebb CMS rendszerek, valahogy nem voltak szimpatikusak. Nyilván jók, de nekem valami egyszerű kellett.

A WordPress -t már használtam régebben, és akkor is felmerült bennem, hogy ebből lehetne CMS -t csinálni. A neten keresgélve kiderült, hogy ez valóban működik, mások is használják erre a cuccot.

Pluginok közül ami nekem bejött:

• WP-CMS
• Email Spam Protection
• Thumbnail Viewer
• RSS Includes Pages

Ami még kérdéses az a design. Elég sokféle WordPress theme van, de ha valaki valami egyszerűbbre vágyik, amin könnyen lehet alakítgatni, akkor a Corporate Sandbox a nyerő.

Ezek után már csak annyi kell, hogy az admin oldalakat lehetőleg csak SSL alól, lehessen elérni.

Egy szerveren jó ha van tűzfal. Na de milyen?

Régebben a GIPTables volt a kedvencem. Mindent tud amit kell, és jól átlátható, úgyhogy tökéletesnek tűnt. És az is, csak az Ubuntuban nincs ilyen csomag, így újabban a Shorewall -t használom.

Ahoz, hogy elkezdjük használni kell néhány beállítás. Az /usr/share/doc/shorewall-common/examples könyvtár alatt többféle példa konfiguráció található, amiböl legtöbb esetben a one-interface -ből célszerű kiindulni.

A konfigurációs elvekről annyit, hogy célszerű úgy kezdeni, hogy mindent tíltunk (policy), és aztán megadjuk azokat a szolgáltatásokat, amiknek mindenképp mennie kell (rules). Vannak egyszerű dolgok pl.: levelezés, DNS lekérdezések, NTP, és magának a web szervernek az elérése, de akadnak alaposabb megfontolást igénylő dolgok pl.: a szerver elérése SSH -n és a kimenő HTTP kapcsolatok.

Ami biztos, hogy nem jó az az, ha az SSH portját megnyitjuk a világ felé. Vagy a portot (22) kell átrakni máshová, vagy Port knocking -ot használunk, vagy megadjuk a lehetséges forrás IP tartományokat.

A kimenő HTTP kapcsolatok engedélyezése a csomagok frissítése miatt szükséges. Ezt célszerű tapasztalati óton beállítani (amikor valami nem megy, akkor a tűzfal log -ból kiderül, hogy melyik IP -t kell még engedélyezni).

Végezetűl, még két szolgáltatás a shorewall -tól. /etc/shorewall/params -ban lehet deffiniálni változókat, amiket felhasznáhatunk a szabályok megadásánál. Pl.: itt lehet összegyűjteni azokat az IP -ket, amiket engedélyezni szeretnénk. A másik lehetőség az Action -ok használata, melyekkel például, korlátozni lehet az 1 IP -ről indított kapcsolatok számát.

A MaxMind GeoIP -nek létezik egy ingyenes változata a GeoLite Country ami egy nagyon jól használható eszköz. Mire jó ez?

Alapvetően az IP címekhez tartozó ország információt lehet vele kinyerni, így ezt vagy csupán információközlésre, vagy valamilyen orszáfüggő döntésre lehet felhasználni.

Én az SSL -el védett oldalaim láthatóságát szoktam ezzel szabályozni. Ezek általában olyan oldalak, amik csak néhány embernek szólnak, akiknek a földrajzi helyzete eleg behatárolt, így jól lehet ezt az alkalmazást használni.

Szerencsére létezik hozzá Apache modul. Használatára pedig íme egy példa:

<FilesMatch "^.*(|.php|.html|.htm)$">
    GeoIPEnable On
    GeoIPDBFile /usr/share/GeoIP/GeoIP.dat
    GeoIPOutput Env
    SetEnvIf GEOIP_COUNTRY_CODE HU OK_Country
    Order Deny,Allow
    Deny from all
    Allow from env=OK_Country
</FilesMatch>

A példa magáért beszél, néhány kiterjesztés (a sebesség miatt nem az összes) elérését csak magyarországról engedjük.

Mi alapján dolgozik a GeoIP?

Egy adatfile a GeoIP.dat alapján ami alapból a /usr/share/GeoIP/GeoIP.dat helyen található.

Itt egyböl látszik is egy hibalehetőség. Ha valakinek olyan IP címe van, amit csak nemrég osztottak ki, akkor annak nem lesz bejegyzése az adatfile -ban, tehát ország se tartozik hozzá, tehát nemfog tudni hozzáférni a védett oldalhoz. Szerencsére a MaxMInd havonta közreadja az adatbázis-frissítést amit célszerű letölteni.

• GeoIP adatbázis-frissítés

A DNS cache installálása nem nehéz, úgyhogy inkább arról írok, hogy mire is jó ez.

Ha valaki egy webszerverre felrak egy DNS cache -t akkor túl sok változást nem fog tapasztalni. Igaz, hogy a DNS lekérdezések felgyorsulnak, de mivel normál működés közben ilyenek nincsenek, így túl sok hatása nincs. Webes statisztikák készítésekor viszont már jól jöhet - bár ezek a programok általában maguk is végeznek valamilyen cache funkciót (pl.: webalizer).

Webszerverek álltalában levelezéssel is foglalkoznak valamilyen szinten és oda már hasznosabb lehet egy cache.

Összességében azt lehet mondani, hogy ritkán kell, viszont még ritkábban árt egy DNS cache :)
Mivel ezek általában kis erőforrás igényű alkalmazások, ezért ott ahol több DNS lekérdezés van elöbb utobb megtérül a használatuk

Én a DJB féle DNS Cache -re esküszöm. Ennek szerzője D. J. Bernstein aki elég különleges figura, tudniillik olyan programokat ír amik jók! És ez elég nagy szó, ugyanis az ő programjaiban évekkel késöbb se találnak hibákat, nincs szükség javító patchekre, nincsenek security fix -ek és egyéb macerás dolgok.Tehát ha valaki talál a művei közt olyat amit keres, akkor abban valószinűleg nem fog csalódni.

Ami a cache méretét illeti, én a wikiben megnöveltem azt, de erre a gyakorlatban ritkán van szükség, jó a default érték is.

Aki futtatta már az Apache -ot chroot -ban az minden bizonnyal szembe került a levélküldés problémájával. Ez elsőre nem tűnik túl bonyolult dolognak, de azért mégis kicsit zűrösebb mint azt az ember várná...

Első lépésnek gyorsan kiderül, hogy nyilván kell egy /usr/bin/sendmail. A legjobb megoldás ha ide egy külön erre a célra készített (rendkívül egyszerű) programot használunk és azt is lehetőleg statikussan fordítva. Én a mini sendmail -t szoktam használni, de jókat hallani az nbSMTP -ről is.

Ezek után jön a meglepetés, hogy még mindig nem működik a levélküldés. Az ok az, hogy hiányzik a /bin/sh. Sajnálatos módon erre is szükség van, úgyhogy célszerű iderakni egy statikus bash -t.

Végül azt érdemes még megnézni, hogy a kimenő leveleknek ki a feladója (From:). Itt a user adott (web szerver usere), de a domain az nem feltétlenül az mint amit az ember elvárna. Ha állítani kell rajta akkor a legegyszerűbb a php.ini sendmail_path változójában beállítani a "-f email" paramétert.
Ehez kapcsolódik ez a program amit ugyan sose próbáltam, de egyszer még jól jöhet.

Érdemes elgondolkodni alternatív megoldásokon is, kell e mindenképp a mail() függvény? Ha nem akkor van két shell nélül is működő megoldás:

• Pear::Mail
• PHPMailer

Apache -ot chroot -ban futtatni elég egyszerű, mivel mindent megold a mod-chroot. Az nginx -nél leírt könyvtár struktúra lérehozására itt nincs szükség, néhány apróságra kell csak odafigyelni:

• Mivel az Apache egy proxy mögött van ezért a REMOTE_ADDR változóban a szerver IP -je lesz. Ezt a legkönnyebben a mod-rpaf modullal lehet megoldani. Ennek segítségével a REMOTE_ADDR -ba a kliens IP -je kerül.
• Path -okra figyelni kell (tmp, PHP session helye).
• PHP -nál a locale adatoknak elérhetőknek kel lenni a chroot -on belül is (és persze Apache konfigban is szerepeljen: LANG, LC_).
• Ha socketen keresztül csatlakozunk a MySQL -hez akkor a socket file legyen elérhető chroot -on belül is.
• Az Apache tud logolni a chroot -on kívülre, de a PHP nem, tehát neki is létre kell hozni azt a helyet ahová joga van írni.

Ez az elmélet, de a gyakorlat azt mutatta, hogy az Apache indítoscriptjében (pid file helye) és a logrotate scriptben (reload helyett restart) is kell egy kis módosítás a helyes működéshez.

Jöjjön tehát a lényeg: nginx beállítása chroot környezetben.

Az nginx -nek nincs olyan konfigurációs opciója ami lehetővé tenné a chroot használatát, így nekünk kell megoldani azt.
Az nginx a start-stop-daemon segítségével indul és ennek szerencsére van chroot opciója, ugyhogy ezzel nincs baj. Ügyelni kel a .pid file elérési útjára.

Célszerű az nginx -et egy külön erre a célra létrehozott, nem privilegizált user nevében futtatni.

Az nginx configurációja jól látszik a wikiben, ugyhogy erről csak annyit, hogy a statikus - dinamikus tartalom szétválasztásának két különböző módját is alkalmaztam:

• a proxy továbbítja a dinamikus kéréseket (PHP), és minden mást ő szolgál ki,
• a proxy csak adott statikus tartalmakat szolgál ki, minden mást továbbít.

A legtöbb oldalnál jó az első megoldás, de néha ha a backend szerver (Apache) trükközik (pl.: rewrite rulok) akkor biztosabb a második megoldás.

Szintén az nginx kezeli a https kapcsolatot, melyhez az SSL certificate -et is el kell készíteni.

Mi is az a chroot és mire jó?

Alapesetben egy alkalmazás mindenhez hozzáfér, amihez az őt futtató user hozzáférhet. Ezt lehet leszűkíteni chroot alkalmazásával.
Linuxokon ez nem túl bonyolult dolog, vagy magának az alkalmazásnak van ilyen beépített lehetősége, vagy pedig a chroot parancsal lehet megoldani (ez mindig működik).

A jó chroot csak azt a minimumot tartalmazza, ami kell az adott alkalmazás futtatásához. Általában ez okozza a problémát is vele, nem mindig egyszerű összeszedni, hogy mi is az a minimum...

Mit érdemes chroot -ba rakni és mit nem?

• Webes alkalmazás-szerver: mindenképp. Tulajdonképpen ez a lényeg, itt esik be a legtöbb kérés és mivel mindenhonnan elérhetőnek kell lennie nemnagyon lehet másképp védeni.
• Web proxy: nem árt. Picit kapcsolódik az elöbbihez és elég könnyű megvalósítani.
• Adatbázis-szerver: általában nem kell. Ha az adatbázis-szerver nem érhető el kívülről akkor szerintem nem szükséges chroot -olni.
• Távoli elérés, SSH, FTP: user szintű chroot szükséges. Ezeknél magát az alkalmazást nem, viszont a belépett felhasználót mindenképp egy adott (user függő) helyre célszerű zárni. Mivel ezeknek a szolgáltatásoknak általában nem kell, hogy mindenhonnna elérhetőek legyenek, ezért tűzfallal is elég jól lehet őket védeni.
• Levelezés: lehet. Általában minden webszervernek kell tudni levelet küldeni és fogadni, úgyhogy nem árt ide is némi + védelem.

Chroot -hoz először is kell egy könyvtár, az új gyökér helye. Ezen belül kell létrehozni azt a minimális könyvtárstruktúrát ami az alkalmazásoknak kell. Az alkalmazás-szerver (Apache) és a proxy szerver (nginx) ugyan abba a könyvtárba (/var/www) lesz chroot -olva, de természetessen különböző user nevében futnak.
Mivel a /var olyan opciokkal van felmountolva, hogy nem engedi meg fájlok futtatását ezért közvetlenül nem lehet a chroot alá bemásolni a futtatandó fájlokat. A legegyszerűbb megoldás RAM diszkek alkalmazása erre a célra. (Ha valaki sajnálja a memóriát akkor másik partícióról néhány könyvtár be bind mount -olása is megoldás.) Természetessen a RAM diszkek tartalmát célszerű valahol a hdd -n is megőrizni és boot után a helyére másolni. Ilyen feladatokra jó az /etc/rc.local script (ez alapbol üres és tetszőlegessen bővíthető).

Részletes leírás a chroot létrehozásához a wikiben található.

A következő részekben először az nginx, majd pedig az apache chroot -jának részleteiről lesz szó.