Daniel Lopez APACHE ZSEBKÖNYV

Átírás

1 Daniel Lopez APACHE ZSEBKÖNYV Guy Montag

2

3 Daniel Lopez Jesus Blanco Apache zsebkönyv Budapest, 2007 SAMS KISKAPU Guy Montag

4 A fordítás a következő angol eredeti alapján készült: Daniel Lopez, Jesus Blanco: Apache Phrasebook Authorized translation from the English language edition, entitled APACHE PHRASEBOOK, 1st Edition, ISBN , by LOPEZ, DANIEL; BLANCO JESUS, published by Pearson Education, Inc, publishing as Sams. Copyright 2006 by Sams Publishing. Translation and Hungarian edition 2007 Kiskapu Kft. All rights reserved. No part of this book, including interior design, cover design, and icons, may be reproduced or transmitted in any form, by any means (electroníc, photocopying, recording, or otherwise) without the prior written permission of the publisher. Fordítás és magyar változat 2007 Kiskapu Kft. Minden jog fenntartva! A szerzők és a kiadó a lehető legnagyobb körültekintéssel járt el e kiadvány elkészítésekor. Sem a szerző, sem a kiadó nem vállal semminemű felelősséget vagy garanciát a könyv tartalmával, teljességével kapcsolatban. Sem a szerző, sem a kiadó nem vonható felelősségre bármilyen baleset vagy káresemény miatt, mely közvetve vagy közvetlenül kapcsolatba hozható e kiadvánnyal. Lektor: Rézműves László Fordítás: Gilicze Bálint Műszaki szerkesztés: Csutak Hoffmann Levente Tördelés: Kis Péter Borító: Bognár Tamás Felelős kiadó a Kiskapu Kft. ügyvezető igazgatója 2007 Kiskapu Kft Budapest, Csángó u. 8. Telefon: (+36-1) Fax: (+36-1) [email protected] ISBN: Készült az Aduprint Nyomdában. Felelős vezető: Tóth Béláné

5 Tartalomjegyzék Előszó Bevezetés Az Apache alapjai Az Apache felfedezése Az Apache jelenlétének vizsgálata Az Apache 1.3 telepítése Linux és Unix rendszereken Az Apache 2.0 telepítése Linux és Unix rendszereken Az Apache telepítése Windows rendszereken Telepíthetjük-e egyszerre az Apache különböző változatait egyetlen gépre? A beállítófájlokról Több beállítófájl használata Az Apache indítása, leállítása és újraindítása Az Apache IP címének és portjának megváltoztatása Az Apache-ot futtató felhasználó megváltoztatása A kiszolgáló nevének megadása lkon hozzárendelése weblapokhoz A kiszolgálón elérhető modulok felfedezése Modulok be- és kikapcsolása Modulok hozzáadása fordítás után újrafordítás nélkül Tartalom közzététele Utasítástárolók Az Apache alapértelmezett utasítástárolói Feltételesen kiértékelt utasítástárolók Hibaelhárítás Segítség! Nem működik az Apache kiszolgáló! A hibanapló A rendszernaplózó démon használata A naplóban rögzített adatok mennyiségének szabályozása Az Apache beállításainak vizsgálata Az Apache tesztelése a parancssorból Az Apache futásának ellenőrzése Az Apache leállításának lehetőségei Hibakeresés az Apache-ban az Apache segítségével Az indítás során felmerülő hibák Névfeloldási problémák Gondok a napló- és beállítófájlok elérésével V

6 Elérés megtagadva Belső kiszolgálóhibák További hibanaplók Nem működő átirányítás Hibaelhárítási teendők Naplózás és megfigyelés Bevezetés a naplózásba Az Apache alapértelmezett naplófájljai Naplóformátumok létrehozása Egyéni naplófájl létrehozása Naplók átirányítása külső programokhoz Kérelmek feltételes naplózása A webhelyre mutató hivatkozások figyelése Az Apache figyelése a mod_status modullal Az Apache megfigyelése az SNMP-vel Naplók elemzése nyílt forrású segédprogramokkal Naplók valósidejű megfigyelése Naplók forgatása és tárolása Az IP címek feloldásának szabályozása A naplózott IP címek feldolgozása Az Apache automatikus újraindítása lefagyás esetén Naplófájlok egyesítése és szétválasztása Külön naplók a virtuális kiszolgálók számára Jellemző naplóbejegyzések URL-megfeleltetés és dinamikus tartalom URL-megfeleltetés URL-ek megfeleltetése fájloknak az Alias utasítással URL-minták megfeleltetése fájloknak az AliasMatch utasítással Oldalak átirányítása Átirányítás a fájl legfrissebb változatához Hibás vagy nem engedélyezett kérelmek átirányítása Tartalomkezelők meghatározása A MIME típusokról A MIME típusok beállítása A CGI parancsfájlok futtatásának alapjai Erőforrások megjelölése futtatható CGI parancsfájlként Parancsfájlok hozzárendelése HTTPfüggvényekhez és MIME típusokhoz A CGI parancsfájlok teljesítményének növelése Az SSI használata Az SSI beállítása Környezeti változók beállítása VI

7 Környezeti változók dinamikus beállítása Különleges környezeti változók A tartalomegyeztetés beállításai Karakterkészletek és nyelvi beállítások megadása URL-megfeleltetés magasabb szinten a mod_rewrite modullal A záró perjelek problémája A gépelési hibák kijavítása Gondok a kis- és nagybetűkkel Virtuális kiszolgálók A virtuális kiszolgálókról Az IP alapú virtuális kiszolgálókról Az IP alapú virtuális kiszolgálók beállítása A név alapú virtuális kiszolgálókról A név alapú virtuális kiszolgálók beállítása Mi történik, ha a kérelem nem felel meg egyetlen virtuális kiszolgálónak sem?. 53 Alapértelmezett név alapú virtuális kiszolgáló beállítása Alapértelmezett IP alapú virtuális kiszolgáló beállítása A név és IP cím alapú virtuális kiszolgálók együttes használata Hibakeresés a virtuális kiszolgálók beállításaiban Az SSL és a név alapú virtuális kiszolgálók A virtuális kiszolgálók kezelésének további módjai Egyéb modulok a virtuális kiszolgálók kezelésére Könyvtárankénti beállítófájlok A könyvtárankénti beállítófájlok hatókörének szabályozása A könyvtárankénti beállítófájlok használatának kikapcsolása Biztonság és hozzáférés-szabályozás Különbségek az Apache változatai között Egyszerű és kivonatos hitelesítés Az Apache hozzáférés-szabályozása Az Apache hitelesítési és engedélyezési beállításai Felhasználó-adatbázis létrehozása Felhasználók és csoportok hitelesítése a Require utasítással Jelentős számú felhasználó kezelése A hozzáférés meghatározott IP címekre korlátozása A hozzáférés tiltása egyes IP címekről A hozzáférés-szabályozási módszerek együttes használata Az Elérés megtagadva oldal testreszabása Felhasználói szabályozás A rendszerfájlok és érzékeny fájlok elérésének megtagadása Programfuttatási korlátozások Mit tehetünk a visszaélések ellen? VII

8 A könyvtártartalom kiíratásának letiltása A Server: fejléc módosítása A képekre mutató közvetlen hivatkozások letiltása A HTTP-függvények korlátozása A hozzáférés korlátozása a böngésző alapján A <Location> és a <Directory> szakaszok használata További hitelesítési modulok A mod_security modul Apache Naprakész biztonsági beállítások Biztonsági teendők SSL/TLS Mi is az SSL? Hogyan működik az SSL? Az OpenSSL fordítása Titkosítási kulcsok Kulcspár készítése Jelszóval védett kulcspár készítése A kulcs jelszavas védelmének feloldása Tanúsítványok Tanúsítványkérelem létrehozása A tanúsítványkérelem tartalmának megjelenítése Saját tanúsítvány létrehozása Az SSL-támogatás biztosítása az Apache 1.3-ban Az SSL-támogatás biztosítása az Apache 2.x-ben Az Apache minimális beállításai Az Apache indítása SSL-támogatással SSLPassPhraseDialog Az SSL teljesítményének fokozása Átirányítás SSL-kapcsolatra Név alapú virtuális kiszolgálók és az SSL Az Apache hitelesítési moduljai és az SSL Figyelmeztető üzenetek SSL-képes webhelyek elérésénél Ügyféltanúsítványok készítése Hitelesítés ügyféltanúsítványokkal A mod_ssl-en túl Az SSL-képes webhelyek parancssori ellenőrzése Az SSL-megvalósítások hibáinak kezelése Összetett hozzáférés-szabályozás a mod_ssl modullal Kapcsolódó fejezetek VIII

9 8 Tartalom közzététele a DAV segítségével Tartalom közzététele az Apache segítségével Ismerkedés a WebDAV-val A mod_dav használatának előnyei A WebDAV és a HTTP protokoll A mod_dav telepítése Apache 2.0 kiszolgálókon A mod_dav telepítése Apache 1.3 kiszolgálókon A WebDAV alapbeállításai A WebDAV biztonsági beállításai DAV-erőforrások elérése a Microsoft Office-ból DAV-erőforrások elérése a Microsoft Windowsból DAV-erőforrások elérése a Firefoxból DAV-erőforrások elérése a parancssorból Hibás ügyfelek kezelése A mod_speling és a DAV A dinamikus tartalomkezelés és a DAV Felhasználói oldalak engedélyezése Egyéb módszerek a felhasználói könyvtárak kezelésére A DAVLockDB segít a bajban Teljesítmény és méretezhetőség Az Apache finomhangolása A teljesítményről és a méretezhetőségről A hardver finomhangolása Az operációs rendszer korlátainak tágítása Az operációs rendszer folyamatokkal szembeni korlátozásainak lazítása A fájlleírók számának növelése Külső folyamatok szabályozása A fájlrendszer teljesítményének növelése A hálózati és állapotbeállítások finomhangolása A visszaélések elkerülése A kapcsolatok és a sávszélesség korlátozása Mit kezdjünk a robotokkal? Fordított helyettes kiszolgálók és terheléselosztók Átmeneti tárolás és tömörítés Optimalizálás modulokkal Az Apache alternatívái Helyettes kiszolgálók és gyorsítótárak Miért van szükség gyorsítótárakra és helyettes kiszolgálókra? Egyszerű és fordított helyettes kiszolgálók Az Apache 1.3, 2.0 és 2.2 közti különbségek A mod_proxy támogatásának bekapcsolása IX

10 A hagyományos helyettesek támogatásának beállítása Az URL-tér egységesítése fordított helyettes alkalmazásával A háttérkiszolgálók elrejtése Fordított helyettesek alkalmazásának tiltása egyes URL-eken A teljesítmény növelése Az SSL-kérelmek terhelésének áthelyezése Helyettesek adatainak átadása fejlécekben Fejlécek kezelése Gyorsítótárazó helyettes kiszolgálók Gyorsítótárak az Apache 2-ben Terheléselosztás Kapcsolódás a Tomcathez Egyéb helyettesek Láthatatlan HTTP-helyettesek Protokollmodulok és MPM-ek Az Apache felépítésének fejlődéstörténete A megfelelő MPM kiválasztása Folyamat alapú MPM-ek A Prefork MPM beállításai Szálas és kevert MPM-ek A Worker MPM beállításai További MPM-ek Az Apache 2 szűrői Az Apache mint FTP-kiszolgáló Az Apache mint P0P3-kiszolgáló Dinamikus tartalomtömörítés X

11

12

13 Előszó A szerzőkről Daniel Lopez a BitRock alapítója és műszaki vezetője. Cége kereskedelmi és nyílt forrású programokhoz fejleszt több felületen működő telepítési és felügyeleti segédeszközöket. Korábban a Covalent Technologies, Inc. Mérnökcsapatában dolgozott, amely jelenleg cége számára biztosítja az Apache-programozási hátteret. Számos népszerű Apache- és Linux-útmutató szerzője, továbbá az ő nevéhez fűződik az Apache és a.net környezet együttműködését szolgáló mod_mono modul, valamint a Comanche, amely grafikus felületet biztosít az Apache beállításához. Daniel rendszeresen felszólal a nyílt forrás közösségének konferenciáin, így neve ismerősen csenghet a LinuxWorld, az ApacheCon, valamint az O ReílIy Open Source Conventíon résztvevői számára. MSc fokozatot szerzett a távközlés területén az Escuela Superior de Ingenieros de Sevilla és a Danmarks Tekniske Universitet képzésének keretein belül, és nem mellékesen az Apache Software Foundation tagja. Jesus Blanco a BitRock projektvezetője, aki korábban a Spanish Institute of Foreign Commerce megbízásából bejárta Brazíliát, Franciaországot, Németországot, Portugáliát és Délkelet-Ázsia nagy részét. Jesus részt vállal az Apache Documentation Project munkájában, és nagyrészt az ő nevéhez köthető az Apache leírásának spanyol fordítása. A Sevillai Egyetemen közgazdasági, az UNED képzésén pedig informatikai diplomát szerzett. 1

14 Ajánlás Ericának és Marisolnak, akik oly sok szeretetet és támaszt adtak. Köszönetnyilvánítás Mindenekelőtt szeretnék köszönetet mondani a szerkesztőnek, Shelley Johnstonnak, aki élő példáját adta annak, hogy az emberi türelem nem ismer határokat. Lelkesedése és lendülete nem engedte, hogy elhagyjam magam, akármilyen sűrű napirenddel és szoros határidőkkel is küzdöttem a mindennapokban. Hálás vagyok társszerzőmnek, Jesusnak, és üzlettársamnak, Ericának, akik időt és fáradságot nem sajnálva segédkeztek abban, hogy végül megszülessen ez a könyv. Főmunkaidőben végzett programfejlesztés mellett könyvet írni nem mentes a feszültségtől. Köszönettel tartozom barátnőmnek és családomnak, hogy mellettem voltak a nehéz időszakokban is. Végül pedig, hatalmas Hola és köszönet munkatársaimnak, akik miatt mindig élvezet a BitRocknál dolgozni! Olvasói visszajelzések A könyv olvasóinak észrevételei a legfontosabbak a számunkra. Adunk a véleményükre, és szívesen vesszük mind a pozitív, mind a negatív kritikát, illetve tippeket, hogy mi az, amit szívesen látnának még a könyvben, és más kikívánkozó hozzászólásokat. ben vagy levélben várjuk, hogy mi tetszett a könyvben és mi nem, és szívesen látunk a könyv jobbá tételére vonatkozó tanácsokat is. A könyv témájához kapcsolódó technikai tanácsadással nem szolgálhatunk, és tekintettel a beérkező ek igen nagy számára, előfordulhat, hogy nem tudunk minden üzenetre válaszolni. Kérjük, levelükben mindenképpen jelezzék a könyv címét és szerzőjét csakúgy, mint a hozzászóló nevét és elérhetőségét. A kiadó gondosan át fogja nézni a hozzászólásokat, és továbbítja azokat a zsebkönyv szerzőinek és szerkesztőinek. [email protected] Levelezési cím: Mark Taber Associate Publisher Sams Publishing 800 East 96th Street Indianapolis, IN USA Ügyfélszolgálat A címen bejegyeztethetjük példányunkat, így frissítésekhez és letölthető anyagokhoz juthatunk a könyvvel kapcsolatban, valamint elérhetjük a kötet hibajegyzékét. 2

15 Bevezetés Az Apache mindig ott volt, ahol a Világháló szíve dobogott - a kezdetektől, amikor az NCSA kiszolgáló szerény oldalhajtásaként megjelent, egészen napjainkig, amikor csak kapkodjuk a fejünket gazdag lehetőségei láttán. Az idők során az Apache képességei számottevően megnőttek, és a programcsomag igencsak összetetté vált - olyannyira, hogy manapság már-már félelmet keltően tornyosul a kezdő felhasználók fölé. Könyvünk célja, hogy rendet vágjon az Apache seregnyi beállítása között, bevezessen a kiszolgáló használatába, és példakódokkal segítse a gyakrabban felmerülő feladatok elvégzését. Ha idegen országba utazunk, egy útiszótár életmentő lehet - elég ha csak megéhezünk, vagy elvétjük a helyes irányt. Reményeink szerint az Apache zsebkönyv hasonlóan nagy segítséget nyújt majd a webkiszolgálók beállításainak érdekes és izgalmas világában. Az Apache zsebkönyv útmutatásokkal és kódrészletekkel segíti, hogy saját igényeinkhez igazítsuk webkiszolgálónk jellemzőit. Persze egy ilyen rövidke könyv elolvasása után még nem mondhatjuk el, hogy mindent tudunk az Apache-ról, ezért érdemes bejelentkeznünk a oldalon, így további olvasnivalóhoz juthatunk, amely megmutatja a kiszolgáló gyakrabban használt lehetőségeit és a ritkábban felszínre kerülő (jóllehet szintén hasznos) tulajdonságait is. 3

16 4

17 1 Az Apache alapjai Az Apache felfedezése Fejezetünkben rövid bevezetést kapunk az Apache webkiszolgáló használatába, megismerjük a felépítését, valamint a fő változatok (1.3 és 2.x) közti különbségeket. Megtanuljuk, hogyan töltsük és fordítsuk le az Apache forráskódját, illetve hogyan telepítsük a rendszert a bináris fájlok segítségével. Szó esik az ismertebb modulok ki- és bekapcsolásáról, a kiszolgálófájlokról, valamint a kiszolgáló beállítófájljainak felépítéséről és használatuk módjáról. Megtanuljuk azt is, miként indíthatjuk el, állíthatjuk meg, majd indíthatjuk újra Apache kiszolgálónkat, és melyek azok a minimális beállítási módosítások, amelyek a kiszolgáló gördülékeny futásához elengedhetetlenül szükségesek. Az Apache jelenleg a legnépszerűbb webkiszolgáló az Interneten; a Netcraft ( com) elemzése szerint a piac 68 százalékát tudhatja a magáénak. Az Apache a következő előnyös tulajdonságokkal bír: Hordozható Képes működni Linux, Windows, Mac OS X és sok más operációs rendszeren. Rugalmas - Moduláris, bővíthető szerkezettel rendelkezik, és számos módon beállítható. Nyílt forrású - Az Apache ingyenesen letölthető és használható, a forráskód nyíltsága emellett ráadásul azt is jelenti, hogy saját Apache-változatot is készíthetünk. Napjainkban az Apache 1.3 és 2.x változata használatos szélesebb körben. Az Apache 2.0 számos újdonságot tartalmaz az 1.3-as változathoz képest, hátránya azonban, hogy nem működik együtt az 1.3 változathoz készített modulokkal. Egy szó mint száz, az Apache 2.x-et az alábbi esetekben érdemes használnunk: Ha Windows operációs rendszert használunk Ha nagy mennyiségű statikus tartalmat kell mozgatnunk, és itt kihasználhatjuk a Unix szál alapú moduljainak lehetőségeit Ha olyan lehetőségekre van szükségünk, amelyek csak az Apache 2.0-ban állnak a rendelkezésünkre Ha csak most kezdünk ismerkedni az Apache rendszerrel Az 1.3-as változatot a következő esetekben használjuk: Ha olyan belső fejlesztésű vagy kereskedelemben beszerezhető modulokat szeretnénk használni, amelyeket még nem írtak át az új változathoz Olyan programot, például a PHP-t kell futtatnunk, amelynek bővítései nem szálbiztosak (jóllehet a kód a prefork MPM segítségével minden valószínűség szerint működhet az Apache 2.0-val is) Ha már otthonosan mozgunk az Apache 1.3 környezetében, és nincs szükségünk az új változat lehetőségeire 5

18 Az Apache jelenlétének vizsgálata rpm -q httpd rpm -q apache rpm -q apache2 Ha Linux rendszert használunk, az Apache minden valószínűség szerint jelen van a gépünkön. Amennyiben Linuxváltozatunk az rpm csomagkezelő rendszert alkalmazza, a fenti parancsokkal nyomban ellenőrizhetjük is az Apache jelenlétét. Példánkban azért szerepel több parancs, mert a rendszerek más és más néven nevezik a keresett programcsomagot. A legtöbb Unixhoz hasonló rendszerben, így a Mac OS X-en is ellenőrizhetjük az Apache bináris fájljainak jelenlétét az alábbi parancsok valamelyikével: httpd -v /usr/sbin/httpd -v Ha eredményes volt a keresés, ilyesmit kapunk eredményül: Server version: Apache/ Server built: Apr :25:31 Még részletesebb válaszra számíthatunk a következő paranccsal: httpd -V Windows rendszereken az Apache jelenlétét a Vezérlőpult, Programok hozzáadása/eltávolítása pontra kattintva ellenőrizhetjük. A telepített program elérési útja a C:\Program Files\Apache Group. Hol juthatunk hozzá az Apache-hoz? A legtöbb Linux-változattal, valamint a Mac OS X-szel automatikusan megkapjuk az Apache-ot is. Windows, illetve más rendszerek használata esetén pedig - mind a forráskód, mind a bináris fájlok tekintetében - keressük fel bátran az Apache webhelyét a címen. Az Apache 1.3 telepítése Linux és Unix rendszereken tar xvfz apache_ tar.gz cd apache_ /configure --prefix=/usr/local/apache --enable-shared=max make make install Operációs rendszerünk csomagkezelő eszközeinek segítségével a kiszolgáló előre lefordított változatait telepíthetjük. Gyakran érdemes ezt a megoldást választanunk, mivel így könnyebb együttműködni a meglevő fájlszerkezettel, valamint más cégek programcsomagjaival. Fontos azonban azzal is tisztában lennünk, miként építhetjük fel saját Apache-változatunkat a forráskódból. Így a kiszolgálót saját igényeink szerint alakíthatjuk, valamint a biztonsági javítócsomagokat ( foltokat ) közvetlenül a megjelenésüket követően beépíthetjük a rendszerbe. 6

19 Mindenekelőtt látogassunk el a címre, és töltsük le a kívánt forráskódot tartalmazó tar állományt. Az 1.3-as változat lehetőségeinek tárgyalásánál könyvünkben feltételezzük, hogy az Apache at telepítettük ez volt a könyv írásának idején a legfrissebb változat. A letöltendő fájl ennek megfelelően az apache_l.3.33.tar.gz nevet viseli. Ez után bontsuk ki, állítsuk be, fordítsuk le, majd telepítsük a kiszolgálót a fenti parancsokkal. A --prefix a kiszolgáló elérési útját határozza meg, az --enable-shared=max pedig lehetővé teszi a betölthető modulok használatát. Ezekre okvetlenül szükség van ahhoz, hogy a kiszolgáló lehetőségeit anélkül szabhassuk testre, illetve bővíthessük, hogy újra le kellene fordítanunk a forráskódot. Megjegyzés Előfordulhat, hogy Apache-kiadásunk fájlneve a.tar.bz2 végződéssel rendelkezik, ami azt jelenti, hogy a bzip2-vel tömörítették. Ez esetben mind a tömörítés, mind a kicsomagolás lassabb, de az eredményként kapott fájl mérete kisebb, emiatt számos nyílt forrású projektben szívesen használják ezt a formátumot. Az ilyen fájlok kicsomagolása napjaink legtöbb Linux rendszerében az alábbi paranccsal lehetséges: bunzip2 < apache_l.3.33.tar.bz2 tar xfv tar xfvj apache_ tar.bz2 Az Apache 2.0 telepítése Linux és Unix rendszereken tar xvfz apache_ tar.gz cd apache_ /configure --prefix=/usr/local/apache --enable-so - -enable-mods-shared=most make make install Az itt alkalmazott eljárás meglehetősen hasonlít az előzőekben bemutatotthoz, a betölthető modulok támogatásának beállításától eltekintve. Az Apache telepítése Windows rendszereken Az Apache telepítése ez esetben még egyszerűbb, mint Unix rendszereken. Az 1.3 és a 2.x változatok telepítése hasonló mindössze le kell töltenünk a futtatható telepítőcsomagot a címről, és elindítanunk. A megjelenő varázsló érdeklődik a telepítés helyéről, továbbá rákérdez az alábbiakra: A hálózati tartomány neve A kiszolgáló teljes tartományneve A rendszergazda elektronikus levélcíme A kiszolgáló nevét használhatják majd ügyfeleink a kiszolgáló elérésére, az elektronikus levélcímet pedig akkor jeleníti meg számukra a rendszer, ha valamilyen hibaüzenetet ír ki, így a felhasználók kapcsolatba léphetnek velünk a gondok megoldása érdekében. A varázsló felajánlja továbbá, hogy futtathatjuk a kiszolgálót szolgáltatásként. Erre akkor lehet szükség, ha például azt szeretnénk, hogy az Apache a kiszolgáló indításakor is fusson. Ha erre nincs szükségünk, egyszerűen elindíthatjuk az Apache-ot a parancssorból is. 7

20 Telepíthetjük-e egyszerre az Apache különböző változatait egyetlen gépre? Igen, ez lehetséges, sőt sok esetben szükség is van rá. Megvalósításához mindössze különböző telepítési előtagokat kell használnunk. Így például telepíthetjük az 1.3-as változatot a /usr/local/apache, a 2.0-t pedig a /usr/local/apache2 könyvtárba. Ha párhuzamosan szeretnénk működtetni a két kiszolgálót, csak arra kell ügyelnünk, hogy az IP cím-port kombinációjuk eltérő legyen. Ne feledjük, hogy nem kell több Apache kiszolgálót telepítenünk csak azért, hogy egyszerre több webhelyet üzemeltessünk. Ilyenkor is tökéletesen elboldogulunk egyetlen kiszolgálóval, ha virtuális kiszolgálókat alkalmazunk, amelyekről bővebben az 5. fejezetben szólunk. Használhatunk ugyanakkor egyszerre több kiszolgálót is, amelyek a webhely egyes részeiért felelősek. Így például üzembe állíthatunk egy Apache 2.0 kiszolgálót a com webhely főrészének kezelésére, ugyanakkor a részt rábízhatjuk egy Apache 1.3 kiszolgálóra, amely egy örökölt mod_perl alkalmazást futtat. Minderre a fordított helyettes kiszolgálók (reverse proxy) adnak lehetőséget, amelyekről a 10. fejezetben tudhatunk meg többet. A beállítófájlokról Az alábbi táblázatban bemutatjuk, hol található az Apache fő beállítófájlja a különböző operációs rendszereken. Ne feledjük, hogy a kiszolgáló 1.3-as és 2-es változata egyszerre is jelen lehet, így a fájl neve eltérhet az egyes változatok esetében. 1.1 táblázat A httpd.conf fájl helye a különböző operációs rendszereken Beállítófájl helye /etc/httpd/httpd.conf /etc/httpd/httpd2.conf /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd2.conf /usr/local/apache2/conf /usr/local/apache/conf c:\program Files\Apache Group \Apache2\conf\httpd.conf c:\program Files\Apache Group \Apache\conf\httpd.conf /private/etc/httpd/httpd.conf Operációs rendszer Suse, Mandrake és régebbi Red Hat rendszerek Újabb Red rendszerek, Fedora Core A forráskód fordítása esetén, a korábbiakban leírtak szerint Windows Mac OS X Az Apache fő beállítófájljának neve httpd.conf, helye pedig változó, attól függően, hogy Windows vagy Linux rendszert használunk, illetve hogy a forráskódból fordítjuk le a kiszolgálót, vagy a futtatható telepítőt választjuk. A lehetőségeket az előzőekben bemutatott táblázat foglalja össze. Az Apache beállításait egyszerű szövegfájlokban tárolja, amelyek utasításokat (direktívákat) és tárolókat (más néven szakaszokat ) tartalmaznak. Az adatok mellett megjegyzéseket is elhelyezhetünk: ha a sort egy # jellel kezdjük, annak tartalmát az Apache figyelmen kívül hagyja. Az utasítások többsorosak is lehetnek, ha a sorok végén a \ karakterrel jelöljük az összetartozásukat. 8

21 Az utasításokkal a kiszolgáló működésének minden apró részletét szabályozhatjuk. Elhelyezhetjük őket tárolókban is, így elérhetjük, hogy csak akkor fejtsék ki a hatásukat, ha egy meghatározott könyvtárból, illetve helyről szolgáltatunk tartalmat, vagy ha egy adott virtuális kiszolgáló szolgálja ki a kérelmet. Ha egy utasítás paramétereként relatív útvonalat adunk meg, ezt mindig a kiszolgáló telepítési könyvtárához (a telepítés gyökeréhez) viszonyítva értjük. Így ha a korábban bemutatott módon forráskódból telepítjük az Apache-ot, a kiszolgáló gyökérkönyvtára a /usr/local/apache, illetve a /usr/llocal/apache2 lesz. Az alapértelmezett értéket a ServerRoot utasítással változtathatjuk meg. Több beállítófájl használata Include /etc/httpd/conf/perl.conf Include conf.d/*.conf Include siteconf/ Adódhatnak olyan helyzetek, amikor érdemes a beállítási adatokat több fájlba szétosztani. Az Include utasítás segítségével - a fenti példáknak megfelelően - hivatkozhatunk egyes beállítófájlokra, egy könyvtár összes fájljára, illetve olyan fájlokra, amelyek egy bizonyos keresőkifejezést tartalmaznak. Amennyiben relatív útvonalat adunk meg, a rendszer azt automatikusan a ServerRoot utasítással megadott könyvtárhoz viszonyítja. Ezt a módszert leggyakrabban azoknál a Linux-változatoknál alkalmazzák, amelyek az Apache-modulokat RPMekben teszik elérhetővé. E programcsomagok mindegyike elhelyezi a saját beállítófájlját egy meghatározott könyvtárban, az Apache pedig automatikusan felcsipegeti az adatmorzsákat. Az Apache indítása, leállítása és újraindítása apachectl start apachectl stop apachectl restart apachectl graceful Az Apache indításához, leállításához, valamint újraindításához a fenti parancsokat használhatjuk. A telepítéstől függően előfordulhat, hogy meg kell adnunk az apachectl abszolút útvonalát, ami lehet például /usr/sbin/apachectl/ vagy /usr/local/apache/bin/apachectl. Lehetőségünk van ugyan arra is, hogy Unix rendszereken közvetlenül a httpd futtatható fájllal vezéreljük az Apache-ot, de ajánlatos inkább az apachectl eszközt használnunk, amely a gyakoribb lehetőségek kezelését egy könnyen áttekinthető parancsfájlban foglalja össze, és rendelkezésünkre áll az Apache részeként. Unix rendszereken, ha az Apache egy kitüntetett portot (1 és 1024 között) használ, a kiszolgáló indításához rendszergazdai jogosultságokra lesz szükségünk. Ha módosítjuk a beállítófájlokat, és szeretnénk, hogy módosításaink hatással is legyenek a rendszerre, valahogy jelezni kell ezt a helyzetet az Apache-nak. Ezt megtehetjük úgy, hogy leállítjuk és elindítjuk a kiszolgálót, újraindítási jelet küldünk, illetve elegáns újraindítást végzünk. Ilyenkor az Apache újra kiolvassa a tárolt beállításokat. A hagyományos és az elegáns újraindítás különbözősége némi magyarázatra szorul a következőkben erről is szólunk. 9

22 Az apachectl parancsfájl mellett a kill paranccsal közvetlenül is küldhetünk jelzéseket a szülőfolyamatoknak. Erről bővebben a második fejezetben olvashatunk. Windows rendszereken közvetlenül az apache.exe segítségével adhatunk jelzéseket: apache.exe -k restart apache.exe -k graceful apache.exe -k stop Ezek a parancsok ikonokon keresztül is elérhetők, amelyeket az Apache telepítője hoz létre a Start menüben. Ha az Apache-ot szolgáltatásként telepítettük, indítására és leállítására a következők szerint használhatjuk a Windows szolgáltatáskezelő eszközeit: Válasszuk a Vezérlőpult Felügyeleti eszközök lehetőségét, majd kattintsunk a Szolgáltatások ikonra. Az Apache 2.0 mindemellett egy Apache Monitor nevű programmal is a segítségünkre siet, amelyet a Tálcán érhetünk el. Ez egy egyszerű grafikus felület, amelyen közvetlenül, illetve szolgáltatásként is elindíthatjuk vagy leállíthatjuk a kiszolgálót. Ez a programocska elhelyezhető a rendszer indításakor elinduló programok között, de magunk is elindíthatjuk a Start menü Apache almenüjéből. Elegáns újraindítás A hagyományos újraindítás során egyszerűen leállítjuk az Apache kiszolgálót, majd újra elindítjuk. Ennek következtében a rendszer elveti az érvényben levő kérelmeket, és addig nem is fogad újakat, amíg a kiszolgáló ismét el nem indul. Így tehát a hagyományos újraindítás okvetlenül a szolgáltatás szüneteltetésével jár. Az elegáns újraindítás egész máshogy közelíti meg a helyzetet. Az egyes szálak, illetve folyamatok továbbra is feldolgozzák a kérelmeket, de ha elkészülnek, a program egy-egy olyan szállal, illetve folyamattal helyettesíti őket, amelyre már az új beállítások érvényesek. Ez lehetővé teszi a kiszolgáló szünet nélküli, gördülékeny működését. Unix rendszereken az elegáns újraindítást legegyszerűbben az alábbi paranccsal érhetjük el: # apachectl graceful Windowson alkalmazzuk a következő parancsot: Apache.exe -k graceful Az Apache IP címének és portjának megváltoztatása Listen :80 Listen 8080 Az Apache-nak tudnia kell, hogy milyen IP címeken és portokon (kapu) várja a beérkező kérelmeket - erről a Listen utasítással tájékoztathatjuk. Az utasításnak értelemszerűen egy portot kell megadnunk, amelyen az Apache figyelhet, valamint (ez nem kötelező) egy IP címet. Amennyiben ez utóbbit nem adjuk meg, az Apache minden elérhető IP címet figyel. Példánk kódjának hatására az Apache a 80-as porton, a IP címről érkező kérelmeket, valamint a 8080-as porton az összes elérhető IP címről érkező kérelmet figyeli. Több Listen utasítással több portot és IP címet is figyelhetünk egyszerre. 10

23 A portot önmagában is megadhatjuk a Port utasítással, de ha már a Listen-t használjuk, a rendszer figyelmen kívül hagyja a Port beállítását. A 4. fejezetben megtudhatjuk, miként hozhatunk létre a Port utasítással önhivatkozó URL-eket. Amennyiben név alapú virtuális kiszolgálókat használunk, további beállításokra is szükség lesz, amelyekről az 5. fejezetben olvashatunk bővebben. A Listen mellett az Apache 1.3 rendelkezésünkre bocsát egy hasonló, BindAddress nevű utasítást is, ez azonban elavult, ezért használata ellenjavallt. Az Apache-ot futtató felhasználó megváltoztatása User nobody Group nobody A User és a Group utasításokkal megadhatjuk, milyen felhasználó, illetve csoport nevében fusson az Apache kiszolgálónk. Biztonsági okokból nem szabad rendszergazdai jogokat adnunk neki, hiszen így egy apró programozási hiba az egész kiszolgálót védtelenné teheti. Az Apache rendszergazdai jogosultságok birtokában elvégezheti azokat a teendőket, amelyekhez ez a jogosultság kell (ilyen például a kapcsolódás a 80-as porthoz), majd az egyes kérelmeket a beállítások közt megadott felhasználó és csoport nevében szolgálja ki. Az itt szereplő felhasználói azonosító többnyire korlátozott jogokkal és lehetőségekkel rendelkezik. A kiszolgáló nevének megadása ServerName Az Apache-nak néha szüksége van önhivatkozó URL-ek létrehozására vagyis olyan URL-ekre, amelyek magára a kiszolgálóra hivatkoznak. Erre akkor lehet szükség, ha például egy másik oldalra szeretnénk átirányítani a felhasználót, vagy saját webhelyünk címét kívánjuk kiírni egy hibaüzenetben. Alapértelmezés szerint az itt szereplő tartományt a ServerName utasítás adja meg, a 2. fejezetben azonban megtanuljuk, miként használhatjuk ennek a viselkedésnek a szabályozására a UseCanonicalName és a Port utasításokat. Ha nem talál kiszolgálónevet, az Apache megpróbál szerezni egyet ehhez fordított DNS-keresést végez a kiszolgáló IP címén. Amennyiben a DNS-kiszolgáló beállítása nem megfelelő, ez meglehetősen hosszadalmas folyamat lehet, így a kérelmező várakozásra kényszerül. lkon hozzárendelése weblapokhoz AliasMatch /favicon.ico /usr/local/apache2/icons/site.ico Napjaink számos böngészője így az Internet Explorer, a Mozilla, vagy a Konqueror lehetővé teszi, hogy kedvenceinkhez ikont rendeljünk. Ha felveszünk egy oldalt a kedvenceink közé, a böngésző elkéri az oldallal azonos könyvtárban található favicon.ico fájlt, amely egy Windows-ikont tartalmaz. Az AliasMatch utasítással a fent bemutatott példához hasonlóan ezeket a kérelmeket egy közös területre irányíthatjuk át, amely a webhely összes ikonját tartalmazza. 11

24 A kiszolgálón elérhető modulok felfedezése # httpd -l Ezzel a paranccsal megkaphatjuk azoknak a moduloknak a listáját, amelyek beépültek kiszolgálónk futtatható kódjába. Az eredmény valahogy így fest: Compiled in modules: core.c prefork.c http_core.c mod_so.c Ha Apache-telepítésünk támogatja a betölthető modulokat, ezek megosztott könyvtárakba kerülnek, amelyek alapállapotban a modules/ (Apache 2.x), illetve a libexec/ (Apache 1.3) könyvtárban találhatók. Ha azt szeretnénk megvizsgálni, hogy futáskor milyen modulok kerülnek a kiszolgálóba, nyissuk meg a httpd.conf fájlt, és keressük meg a megfelelő LoadModule utasításokat. Az Apache 2.1/2.2-ben még ennyit sem kell tennünk a httpd -M parancs kiírja az összes alkalmazott modult, köztük azokat is, amelyek futásidőben kerültek a rendszerbe. Modulok be- és kikapcsolása./configure (...) --enable-status./configure (...) --disable-status A modulokat a fordítás során a configure parancs --enable-modul és --disable-modul kapcsolóival kapcsolhatjuk be, illetve ki. A fenti példában láthatjuk, miként tehetjük meg ezt az Apache részeként kapott mod_status modullal. Ha a kiszolgálót úgy fordítottuk le, hogy nem támogatja a betölthető modulok használatát, moduljainkat egyszerűen kikapcsolhatjuk, ha megjegyzéssé tesszük a betöltésükért felelős sorokat: #LoadModule mod_status_modules/mod_status.so Az Apache 1.3-ban a ClearModuleList utasítással törölhetjük az aktív modulok listáját (ide tartoznak a befordított modulok is). Ezt követően az AddModule utasítással adhatjuk meg azokat a modulokat, amelyeket valóban használni szeretnénk. A ClearModuleList a 2.x változatokban már nem érhető el. Ha kikapcsolunk egy modult, ügyeljünk arra, hogy eltávolítsuk a nevét a httpd.conf fájl hozzá kapcsolódó utasításaiból, vagy helyezzük át ezeket az utasításokat egy <ifmodule> blokkba (lásd alább). Ha ezt nem tesszük meg, előfordulhat, hogy a kiszolgáló el sem indul. <ifmodule mod_status.c> ExtendedStatus On </ifmodule> 12

25 Modulok hozzáadása fordítás után újrafordítás nélkül # apxs -cia mod_usertrack.c Lehetőségünk van arra is, hogy az Apache újrafordítása nélkül vegyünk használatba új modulokat ennek azonban az a feltétele, hogy a szóban forgó modul (legyen ez most a mod_so) már be legyen fordítva a kiszolgálóba. Ennek vizsgálatát elvégezhetjük a korábbiakban tanultak szerint (lásd A kiszolgálón elérhető modulok felfedezése című részben). Modulunkat a forráskódból az apxs nevű segédeszközzel építhetjük fel, amely a modulok felépítésére és telepítésére hivatott, és amelyet megkapunk az Apache-csal. Ahhoz, hogy egy modult az apxs segítségével lefordítsunk és telepítsünk, előbb be kell lépnünk abba a könyvtárba, amelyik a modult tartalmazza, majd be kell írnunk a következőket: # apxs -c mod_usertrack.c Ezzel a modul fordítását elvégeztük. Az eredményt másoljuk be az Apache modulkönyvtárába, és módosítsuk a beállítófájlt. Az alábbi paranccsal ezt az apxs elvégzi helyettünk: # apxs -cia mod_usertrack.c Ez az eljárás nagyszerűen működik egyszerű modulokkal, így például azokkal, amelyekhez hozzájutunk az Apache programcsomagjában, a bonyolultabb, külső gyártók által készített modulok, mint a PHP vagy a mod_python esetében azonban többnyire a --with-apxs vagy a --with-apxs2 kapcsolót kell átadnunk a beállító parancsfájlnak. Ha rendelkezésre áll a modul bináris változata, egyáltalán nincs szükség ilyen, az apxs-hez kapcsolódó lépésekre. Ilyesmi akkor fordulhat elő, ha a kiszolgáló felépítésekor nem csak az alapértelmezett modulokat fordítottuk le, illetve ha a kérdéses modul szerepel az adott Linux- vagy Windows-telepítőcsomagban. Ha az Apache 1.3-at használjuk, a modul hozzáadásához az alábbi sorokat kell beírnunk a httpd.conf fájlba: LoadModule usertrack_module libexec/mod_usertrack.so AddModule mod_usertrack.c Ha a rendszeren az Apache 2.2-es változata fut, csak a LoadModule utasítást kell használnunk, alapértelmezett modulkönyvtárként a /libexec helyett a /modules könyvtárat megadva. Tartalom közzététele DocumentRoot /usr/local/apache/htdocs Az Apache alapértelmezés szerint a telepítési könyvtár htdocs/ alkönyvtárából szolgáltatja a tartalmat (amelynek neve a HTML dokumentumokra utal). Az itt elhelyezett dokumentumok automatikusan megjelennek a megfelelő URL-nél. Így például, ha létrehozunk egy foo nevű könyvtárat a htdocs-on belül, és ebben elhelyezünk egy bar.html nevű fájlt, ezt kívülről az alábbi címen érhetjük el: 13

26 A dokumentumkönyvtárat a DocumentRoot utasítással módosíthatjuk, ahogy a fenti példában látható. Ha relatív útvonalat adunk meg, a kiszolgáló ezt a ServerRoot utasítással megadott könyvtárhoz viszonyítva értelmezi. A tartalmat azonban nem kell feltétlenül a dokumentumkönyvtárba helyeznünk. Az Apache egyik erőssége, hogy igen hatékony és rugalmas módszereket biztosít arra, hogy olyan fájloknak feleltessük meg az ügyfelek által kért URLeket, amelyek modulok által megadott lemezeken, illetve erőforrásokban találhatók. Minderről részletesebben a 4. fejezetben olvashatunk. Utasítástárolók Az utasítástárolók vagy szakaszok határozzák meg az utasítások hatókörét. Amennyiben egy utasítás nem sorolható egyetlen tárolóba sem, úgy a hatóköre kiszolgálószintű, vagyis a teljes kiszolgálóra hatással van. <Directory /usr/local/apache/htdocs >... </Directory> <Location /downloads/*.html >... </Location> <FilesMatch \.(gif jpg) >... </FilesMatch> Az Apache alapértelmezett utasítástárolói A következőkben felsoroljuk az Apache beállítófájljaiban használt alapértelmezett tárolókat. <VirtualHost> A VirtualHost utasítás egy virtuális kiszolgálót ad meg. Az Apache ugyanis lehetővé teszi, hogy egy telepítéssel több webhelyet is fenntartsunk. Erről bővebben az 5. fejezetben olvashatunk. <Directory> és <DirectoryMatch> Ezekkel a tárolókkal az utasítások hatását egy meghatározott könyvtárra vagy könyvtárcsoportra korlátozhatjuk. A DirectoryMatch még azt is lehetővé teszi, hogy a könyvtár megadásánál szabályos kifejezéseket használjunk. <Location> és <LocationMatch> Az utasítások hatását meghatározott URL-re vagy URL-ek csoportjára korlátozzák. Működésük hasonló a Directory utasításoknál látottakhoz. <Files> és <FilesMatch> Itt az utasítások hatását fájlokra, illetve fájlok csoportjaira korlátozhatjuk, hasonlóan a Directory és a Location utasításokhoz. Fontos megjegyeznünk, hogy a fentieken kívül vannak egyéb utasítástárolók is, hiszen a modulok amilyen például a mod_proxy saját tárolókat használhatnak (lásd a 10. fejezetben). A 8. fejezetben olvashatunk olyan tárolókról is, amelyek a HTTP-függvények alapján korlátozzák az elérést. Megjegyzés A Directory, a Files, valamint a Location utasítások szabályos kifejezéseket is fogadhatnak paraméterként, amennyiben a kifejezés elejére egy ~ ka- 14

27 raktert teszünk. A szabályos kifejezések karakterláncok meghatározott csoportját írják le, adott szabályok szerint. Így például a következő szabályos kifejezés magába foglal minden olyan fájlt, amelynek a kiterjesztése.jpg vagy.gif: <Files ~ \.gif jpg >. Mindazonáltal ilyen célokra a jobb áttekinthetőség érdekében használjuk inkább a DirectoryMatch, LocationMatch és FilesMatch utasításokat. A szabályos kifejezésekről bővebben olvashatunk a wiki/regular_expression címen. Feltételesen kiértékelt utasítástárolók Az Apache lehetővé teszi feltételes tárolók használatát is, amelyeknek a tartalma csak akkor érvényesül, ha bizonyos feltételek teljesülnek. <IfDefine> Az Apache csak akkor hajtja végre az ebben a tárolóban elhelyezett utasításokat, ha megadjuk a megfelelő parancssori kapcsolót. A következő példában ez a kapcsoló a DSSL lesz. A paramétert negálhatjuk is a! karakterrel (mint az <IfDefine!SSL> esetében); ilyenkor a utasítások csak akkor lesznek hatással a kiszolgálóra, ha nem adtuk meg a kérdéses kapcsolót a parancssorban. <IfModule> Az Apache csak akkor hajtja végre az IfModule tárolóban található utasításokat, ha a paraméterként átadott modul jelen van a kiszolgálóban. Ennek a módszernek az alkalmazására számos példát találhatunk az Apache alapértelmezett beállítófájljában az MPM modulok kapcsán. Tegyük fel például, hogy a httpd.conf fájlban az alábbi kódot látjuk: <IfDefine SSL> LoadModule ssl_module modules/mod_ssl.so </IfDefine> A tárolóban található utasítás életre hívására következőt írhatjuk a parancssorba: # httpd DSSL 15

28 16

29 2 Hibaelhárítás Fejezetünkben az Apache használata során leggyakrabban előforduló problémákkal és kezelésükkel foglalkozunk köztük a fájlműveleteket és a portokhoz való kapcsolódást érintő hibalehetőségekkel. Mindemellett bemutatunk néhány segédprogramot is, amelyekkel nyomára juthatunk a legtöbb hiba eredetének. Segítség! Nem működik az Apache kiszolgáló! Nincs annál dühítőbb, mint úgy olvasni egy informatikai könyvet, hogy közben újra és újra meg kell állnunk, mert a program, amelyről a könyv szól, nem hajlandó az elvárt módon működni. Nos, nem szeretnénk, ha ez is ilyen könyv lenne, ezért ebben a fejezetben sorra vesszük az Apache hibaelhárítási lehetőségeit, az egyszerűektől az összetettekig. Ha még nem vagyunk járatosak az Apache használatában, vagy egyes módszerekre jelenleg nincs szükségünk, nyugodtan ugorjuk át a leírásukat; ide később is visszatérhetünk. A hibanapló ErrorLog logs/error_log A hibanaplófájl nyomon követi a kiszolgáló életének fordulatait: az indításokat, az újraindításokat, a kiszolgáló működésével kapcsolatos figyelmeztetéseket és hibaüzeneteket, valamint a letiltott vagy érvénytelen kérelmeket. Ha gondjaink akadnak a kiszolgálóval, először ide érdemes ellátogatnunk. Unix rendszereken a hibanaplót tároló error_log fájl alapállapotban az Apache-telepítés logs/ könyvtárába kerül. Ha Apache kiszolgálónkat programcsomagban kaptuk meg, kicsit más a helyzet. Ilyenkor többnyire a /var/log/httpd könyvtárban érdemes keresgélnünk. A Windows hibanaplója az error.log névre hallgat, és a logs könyvtárban található. A hibanapló könyvtárát magunk is meghatározhatjuk az ErrorLog utasítással. A megadott útvonal elé egy cső karaktert írva a hibaüzeneteket egy másik program szabványos bemenetére küldhetjük. Erről a gyakran használt módszerről bővebben a 3. fejezetben olvashatunk. Érdemes megjegyeznünk, hogy a hibanapló fájlja csak az Apache első indítását követően jelenik meg. A rendszernaplózó démon használata ErrorLog syslog ErrorLog syslog:local7 Unix rendszereken, ha az ErrorLog utasítást a syslog paraméterrel használjuk, a rendszernaplózó démonnal rögzíthetjük a kiszolgáló hibaüzeneteit - ezt láthatjuk a fenti példában is. A kódban láthatjuk, hogy lehetőségünk van csatolni egy információs mezőt is (alapértelmezés szerint ez a local7). Ezek a mezők 17

30 tárolják, hogy honnan származik a hibaüzenet. A local0-local10 mezők foglaltak az rendszergazdák és az alkalmazások (köztük maga az Apache) számára. A naplóban rögzített adatok mennyiségének szabályozása LogLevel notice Az Apache által adott hibainformációkat fontosságuk szerint csoportokba sorolhatjuk. A LogLevel utasítást használva a 2.1. táblázatban felsorolt paraméterekkel megadhatjuk, mely hibaüzeneteket szeretnénk látni. Ezt követően csak a megadott fontosságú, illetve annál fontosabb hibaüzenetek jelennek meg. A legtöbb Apache-telepítés esetében az alapértelmezett warn (figyelmeztetés) szint tökéletesen megfelel. Ha azonban egy adott beállítás hibájának elhárítását szeretnénk elvégezni, lejjebb ereszkedhetünk a debug (hibakeresés) szintre, így részletesebb naplóadatokat kapunk táblázat A LogLevel utasítás paraméterei az Apache leírása alapján Paraméter Leírás Példa emerg Vészhelyzet - a rendszer használhatatlan Child cannot open lock file. Exiting. alert Azonnali cselekvésre van szükség getpwuid: couldn t determine user name from uid. crit Kritikus körülmények socket: Failed to get a socket, exiting child. error Hiba következett be Premature end of script headers. warn notice Figyelmeztető körülmények Veszélytelen, de jelentős események Child process 1234 did not exit, sending another SIGHUP. httpd: caught SIGBUS, attempting to dump core in... info Információk Server seems busy, (You may need to increase StartServers, or Min/ MaxSpareServ ers)... debug Hibakeresési adatok Opening config file... 18

31 Az Apache beállításainak vizsgálata # apachectl configtest Ezzel a paranccsal kiszűrhetjük a beállítófájl gyakori hibáit, mielőtt élesben használatba vennénk. Az Apache minden alkalommal elvégzi ezt a vizsgálatot, amikor az apachectl segítségével újraindítjuk. Ez biztosítja, hogy a kiszolgáló az újraindítást követően is fut majd az új beállítófájllal. Az Apache tesztelése a parancssorból $ telnet 80 Trying Connected to ajax-1.apache.org ( ). Escape character is ^]. HEAD / HTTP/1.0 HTTP/ OK Date: Sun, 04 Sep :42:02 GMT Server: Apache/ (Unix) mod_ssl/ OpenSSL/0.9.7a DAV/2 SVN/1.2.0-dev Last-Modified: Sat, 03 Sep :35:42 GMT ETag: 203a8-2de2-3ffdc7a6d3f80 Accept-Ranges: bytes Content-Length: Cache-Control: max-age=86400 Expires: Mon, 05 Sep :42:02 GMT Connection: close Content-Type: text/html; charset=iso Connection closed by foreign host. Mivel a HTTP egyszerű, szöveg alapú protokoll, egy telnet ügyfél egy olyan program, amely lehetővé teszi, hogy közvetlenül csatlakozzunk egy kiszolgálóhoz és egy porthoz segítségével a parancssorból is ellenőrizhetjük az Apache kiszolgáló jelenlétét. Ha a távoli telnet-kérelemre nem érkezik válasz, és biztosak vagyunk abban, hogy a hálózat beállításai megfelelőek, akkor az Apache nem figyeli a kérdéses címet és portot. Ez a vizsgálati módszer hasznos lehet olyan környezetekben, ahol nem áll rendelkezésünkre webböngésző - ilyen helyzet adódhat például akkor, ha a kiszolgálót távolról próbáljuk elérni SSH-n keresztül. Ha kapcsolatba tudunk lépni az Apache kiszolgálóval a localhost-ról a telnet segítségével, böngészővel viszont nem, az arra utalhat, hogy gondok vannak a tűzfallal, vagy nem megfelelően állítottuk be az Apache Listen utasítását. Kapcsolódjuk a telnettel a címhez (vagy kedvenc webhelyünkhöz) a 80-as porton, és írjuk be a következők valamelyikét: HEAD / HTTP/1.0 vagy GET / HTTP/1.0 Üssük le kétszer az ENTER billentyűt, így a példában látotthoz hasonló eredményt kapunk. 19

32 Ha Unix rendszerünkön elérhető a lynx parancssori böngésző, hasonló eredményt kaphatunk az alábbi paranccsal: lynx -head -dump A 7. fejezetben megismerkedünk a mod_ssl jellemzőivel, és megtanuljuk, miként kapcsolódjunk az előzőekhez hasonlóan egy SSL-képes webkiszolgálóhoz az openssl parancssori eszközzel. Az Apache futásának ellenőrzése ps -aux grep httpd 25297? S 0:00 /usr/local/www/bin/ httpd -k start 15874? S 0:06 /usr/local/www/bin /httpd -k start 14441? S 0:02 /usr/local/www/bin /httpd -k start... /usr/sbin/lsof grep httpd grep IPv httpd nobody 3u IPv TCP (LISTEN) Httpd root 3u IPv TCP (LISTEN) Httpd nobody 3u IPv TCP (LISTEN)... netstat -ltnp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp : :* LISTEN 25297/httpd tcp : :* LISTEN 1038/sshd Előfordulhat, hogy nem tudunk kapcsolódni a kiszolgálóhoz, így nem tudhatjuk, hogy a kiszolgáló fut-e, vagy hálózati gondok adódtak. Szerencsére a Unix rendszereken számos parancssori segédprogram áll rendelkezésünkre ilyen esetekre - néhányukat a fenti példakódban is láthatjuk. A ps segédprogram tájékoztat arról, hogy fut-e a rendszeren a httpd folyamat. A netstat és az lsof segédprogramokkal megtudhatjuk, milyen címet és portot figyel az Apache. Windows rendszereken a Feledatkezelőben (amelyet a CTRL+ALT+DEL billentyűkombinációval érhetünk el) győződhetünk meg arról, hogy fut-e az Apache.exe folyamat. Emellett az újabb kiadásokban a Tálcán rendelkezésünkre áll az Apache Monitor segédprogram, amellyel tájékoztatást kaphatunk az Apache állapotáról. 20

33 Az Apache leállításának lehetőségei # kill -HUP # kill Néha szükséges, de legalábbis kényelmesebb a kiszolgálót közvetlenül a kill paranccsal leállítani ahelyett, hogy az apachectl burkoló parancsfájlt használnánk. Ahhoz, hogy ezt megtegyük, először a ps vagy az lsof segítségével hozzá kell jutnunk a futó Apache kiszolgáló folyamatazonosítójához. Ezután nem kell mást tennünk, mint használatba venni a kill parancsot, első paraméterként a küldeni kívánt jelet, másodikként pedig az Apache folyamatazonosítóját (esetünkben ez a 25297) adva meg. A HUP megadásával leállíthatjuk, míg a SIGHUP paraméterrel újraindíthatjuk a kiszolgálót. Lehetőségünk van arra is, hogy a jelet a példában látható módon - számszerű megfelelőjével helyettesítsük. A további részletekért forduljunk a kill parancs dokumentációjához. A Linuxban jelet küldhetünk akár az összes httpd nevű folyamatnak - ezt a killall paranccsal tehetjük meg. Az összes httpd folyamat leállításához a következő parancsot írhatjuk: # killall -HUP httpd Ügyeljünk azonban arra, hogy ha egyszerre több Apachepéldány fut a gépünkön, ez a parancs mindegyiküket leállítja. Fontos, hogy rendelkezzünk a fenti parancsok futtatásához megfelelő jogosultságokkal. Ahhoz, hogy az Apache folyamatot leállítsuk, illetve újraindítsuk, csaknem minden esetben rendszergazdának, illetve a folyamat birtokosának kell lennünk. Hibakeresés az Apache-ban az Apache segítségével Számos olyan Apache-modul ismeretes, amely segíthet Apache kiszolgálónk, illetve webalkalmazásaink hibáinak megkeresésében. A mod_loopback webes hibakereső ügyfélprogram egyszerűen mindent visszaad a böngészőnek, amit HTTP-kérelemben kapott - ide tartozik minden POST és PUT adat. A program elérhetősége: A mod_tee és a mod_trace_output külső gyártóktól származó modulok, amelyek tárolják a szolgáltatott tartalmat. Letöltésük az alábbi címekről lehetséges: A mod_logio, amelyhez az Apache 2-vel automatikusan hozzájutunk, bemásol minden, a kiszolgáló által kapott, illetve visszaadott adatot a hibanaplóba, későbbi hibakeresés céljára. Nem hallgathatjuk el, hogy ezeknek a moduloknak a használata befolyásolja a kiszolgáló teljesítményét, de nagy segítséget jelenthetnek a hibakeresésben, például a fejlécekkel vagy a sütikkel kapcsolatos gondoknál. 21

34 Az indítás során felmerülő hibák A következőkben bemutatunk néhány gyakoribb hibát a hozzájuk tartozó hibaüzenetekkel együtt, amelyek meggátolhatják az Apache indulását. Syntax Error Syntax error on line xxx of /etc/httpd/httpd.conf: Invalid command PiidFile, perhaps misspelled or defined by a module not included in the server configuration Nyelvtani hiba, ami azt jelzi, hogy elgépeltünk egy utasítást (esetünkben ez a PidFile) a beállítófájlban, illetve az alkalmazott utasítás olyan modulhoz tartozik, amely nincs jelen a kiszolgálóban. Ellenőrizzük a beállítófájl jelzett területeinek nyelvtani helyességét. Ha egy modul hiánya okozza a gondokat, alkalmazzuk az 1. fejezetben megismert <ifmodule> utasítást, így feltételesen kizárhatjuk a hiányzó modul utasításait, vagyis a kiszolgáló akkor is futhat, ha nem találja a modult. Address already in use Address already in use: make_sock: could not bind to port Ha ezzel a hibával találkozunk, az azt jelenti, hogy egy másik alkalmazás már használja azt a portot, amelyikhez az Apache kapcsolódni szeretne. A megoldást az jelenti, ha leállítjuk ezt a programot még az Apache indítása előtt, illetve ha a httpd.conf fájlban módosítjuk az Apache által használt portot a Listen és a Port utasítások paramétereinek megváltoztatásával. Ez a hiba leggyakrabban akkor következik be, ha egy másik Apache kiszolgáló is fut a gépen, amely ugyanezt a portot használja, illetve Windows rendszereken az Internet Information Server, valamint a Microsoft Personal Web Server is beleszólhat a dolgokba. Más, gyakran használt programok például a Skype is előszeretettel használják egyes helyzetekben a 80-as portot. Could not bind to port [Mon Jan 9 20:09: ] [crit] (13)Permission denied: make_sock: could not bind to port 80 Ez a hibaüzenet azt jelzi, hogy nem rendelkezünk megfelelő jogosultságokkal ahhoz, hogy az általunk futtatott Apache kiszolgáló a beállítófájlban megadott porthoz kapcsolódjon. A Unix esetében csak a kitüntetett felhasználók kapcsolódhatnak az 1-től 1024-ig terjedő portokhoz. A gondok orvoslására lépjünk be rendszergazdaként, vagy írjuk be az su parancsot, majd kíséreljük meg ismét elindítani a kiszolgálót. Ha nem tudunk rendszergazdai jogokhoz hozzájutni, nyissuk meg a httpd.conf fájlt, és adjunk meg valamilyen 1024-nél nagyobb portértéket. Module not compatible module xxx is not compatible with this version of Apache Ezzel a hibával akkor találkozhatunk, ha az Apache olyan modult kísérel meg betölteni, amelyet a telepítettnél újabb (vagy régebbi) Apache-változathoz fordítottak. Ha rendelkezünk a forráskóddal, jó eséllyel újrafordíthatjuk az aktuális változathoz, az 1. fejezetben bemutatott módon. Ha nincs meg a forráskód, 22

35 illetve nem sikerül a fordítás, és a modul létfontosságú a munkánk szempontjából, kénytelenek vagyunk az Apache kiszolgáló egy újabb (vagy éppen régebbi) változatát telepíteni. Névfeloldási problémák Cannot determine hostname Számos Apache-utasítás létezik - köztük a ServerName és a Listen -, amelyek paraméterként gépneveket is elfogadnak. Ha azonban az Apache indításkor nem képes ezeket a gépneveket a DNS, illetve rendszerünk kiszolgálólistája segítségével IP címekké alakítani, a cannot determine hostname (a gépnév nem határozható meg) hibaüzenetet kapjuk. A gondok megoldására ellenőrizzük a DNS-kiszolgáló címét, valamint az /etc/hosts beállításait, továbbá a httpd.conf fájlban megadott gépnevek helyességét. Ahol csak lehetséges, gépnevek helyett használjunk IP címeket a Listen, a <VirtualHost> és más hasonló utasítások esetében. Gondok a napló- és beállítófájlok elérésével (13)Permission denied: httpd: could not open error log file /usr/local/ apache/logs/error_log. A permission denied (engedély megtagadva) hibaüzenet azt jelzi, hogy nem rendelkezünk megfelelő jogosultságokkal ahhoz, hogy olvassuk az Apache beállítófájljait, illetve írjunk a naplófájlokba. Ez többnyire akkor következik be, amikor nem az a felhasználó indítja el az Apache-ot, aki felépítette és telepítette. Ilyenkor indítsuk el a kiszolgálót rendszergazdaként, illetve annak a felhasználónak a segítségével, aki a telepítését végezte, vagy (amennyiben rendelkezünk hozzá megfelelő jogosultságokkal) változtassuk meg a hibaüzenetben szereplő fájl tulajdonosát a chmod paranccsal. Elérés megtagadva Forbidden/You don t have permission to access /xxx on this server Ha webböngészőnk a 403 Forbidden/Access Denied hibaüzenettel tér vissza, miután megkíséreltünk letölteni egy weboldalt az Apache kiszolgálón keresztül, ez azt jelenti, hogy a kérelmezett URL olyan elérési korlátozás alatt áll, amelynek kérelmünk nem felelt meg. Módosítsuk a kérelmezett webes tartalom, illetve fájlok jogosultságait, és győződjünk meg arról is, hogy az Apache kiszolgálófolyamat tulajdonosa rendelkezik olvasás és futtatási jogosultsággal a dokumentumhoz vezető könyvtárak mindegyikéhez. Unix rendszereken ezeket a jogosultságokat a chmod segédprogrammal módosíthatjuk. A hibanaplóban megjelenő Client denied by server configuration üzenet arra utal, hogy az elutasítás eredete Apache-beállítófájljaink adott URL-hez tartozó <Directory> vagy <Location> szakaszának hozzáférés-szabályozó utasításaiban (amilyen az Allow és a Deny) keresendő. A Directory index forbidden by rule üzenet azt jelzi, hogy egy olyan könyvtárat próbáltunk megnézni, amely nem tartalmaz indexfájlt. A könyvtárak indexeléséről és az indexfájlokról bővebben az Options utasítás Indexes lehetőségének bemutatásánál, a 6. fejezetben olvashatunk. 23

36 Options ExecCGI is off in this directory Ha egy CGI parancsfájlt próbálunk futtatni, és az Options ExecCGI is off in this directory hibaüzenetet kapjuk, az azt jelenti, hogy nem tettük futtathatóvá a CGI fájlokat az Apache beállítófájljában, illetve a kérdéses könyvtárból nem futtathatók CGI parancsfájlok. Minderről többet is megtudhatunk a ScriptAlias, valamint az Options utasítások leírásánál. Belső kiszolgálóhibák A belső kiszolgálóhibák lehetetlenné teszik, hogy az Apache kiszolgáljon bizonyos kérelmeket. Segmentation fault child pid xxx exit signal Segmentation Fault (11) Szegmentációs hiba akkor következik be, ha az Apache kiszolgáló olyan memóriaterületeket próbál elérni, amelyek más rendszerfolyamatokhoz tartoznak, illetve a rendszer hibás vagy nem végrehajtható utasítást talál az Apache folyamatban. A jelenség oka lehet programozási hiba, többnyire hanyagul kódolt vagy kísérleti könyvtárakban, illetve modulokban, de eredhet hardverhibából is, ami jobbára a rendszer memóriájában, lapkakészletében, buszában vagy processzorában található. Premature end of script headers [error] [client ] Premature end of script headers: /usr/ local/apache/cgi-bin/test-cgi A parancsfájlfejlécek idő előtti befejeztét nem teljesen lefuttatott CGI parancsfájlok okozzák. Az ilyen hibák elkerülése érdekében győződjünk meg arról, hogy minden CGI fájlhoz rendelkezünk futtatási jogosultsággal, és a parancsfájl első sorában megfelelő útvonalat adtunk meg az értelmezőhöz. A fenti hibaüzenetet például akkor kaphatjuk, ha parancsfájlunk a #!/usr/local/bin/perl sorral kezdődik, miközben Perl-értelmezőnk a /usr/bin/perl könyvtárban található. A Premature end of script headers hibaüzenetet legtöbbször az váltja ki, hogy a program futása megszakadt, még mielőtt adatok érkeztek volna vissza a parancsfájltól. A programhibáknak számos oka lehet magunk is elronthattuk valahol a kódolást, de az is előfordulhat, hogy egyes könyvtárak hiányoztak a program összeszerkesztésénél. Esetenként maga az operációs rendszer vagy az Apache is leállíthatja a programunkat, ha annak erőforrás-felhasználása (memória, processzoridő) meghalad egy bizonyos szintet (lásd a 9. fejezetben). Malformed header [error] [client ] malformed header from script. Bad header=xxx: /usr/local/apache/ cgi-bin/example.cgi A malformed header from script hibaüzenetet (többnyire valamilyen programozási hibából következő) hibás formátumú fejlécek esetén kapjuk. Az Apache olyan választ vár a parancsfájloktól, amelyek nulla vagy több fejléccel kezdődnek, majd egy üres sort is tartalmaznak. 24

37 További hibanaplók RewriteLog /usr/local/apache/logs/rewrite_log RewriteLogLevel warn SSLLog /usr/local/apache/logs/ssl_log SSLLogLevel warn ScriptLog logs/cgi_log Számos modul így az Apache 1.3 SSL modulja, a mod_rewrite vagy a mod_cgi saját utasítást nyújt arra, hogy a velük kapcsolatos eseményeket külön fájlokba naplózhassuk. Nem működő átirányítás UseCanonicalName off Ha Apache kiszolgálónk minden átirányításkor elérhetetlenné válik, lehetséges, hogy a gép kanonikus neve elérhetetlen a hálózatunkon kívülről, vagy egészen egyszerűen hibás. Így például ha a ServerName értéke localhost, vagy egy privát cím, a kiszolgáló elérhetetlenné válik, ha a felhasználót olyan URL-re próbálja átirányítani, ami ezen az értéken alapul. A probléma megoldására adjunk meg érvényes ServerName -értéket, vagy állítsuk a UseCanonicalName értékét off-ra, így a rendszer az önhivatkozó URL-eket az ügyfél által megadott gépnév alapján állítja elő. Ez gyakori probléma a fordított helyettes kiszolgálók mögött álló számítógépek esetében, amelyekről bővebben a 10. fejezetben olvashatunk. Hibaelhárítási teendők A következőkben összefoglaljuk az Apache kiszolgálókkal kapcsolatban leggyakrabban felmerülő problémákat és a hiba kijavításához szükséges teendőket. A kiszolgáló indítása Ha nem tudjuk sikeresen elindítani a kiszolgálót, nézzünk utána a hibanaplóban, hogy mi okozhatta a gondot. Ha már egy másik kiszolgáló is fut az adott címen, válasszunk más IP cím-port kombinációt saját kiszolgálónk számára. Ha nincs jogosultságunk az adott porthoz kapcsolódni, indítsuk el az Apache-ot rendszergazdaként, így hozzáférhetünk a kitüntetett portokhoz. Ha az Apache nem képes megnyitni a beállító-, illetve naplófájlokat, győződjünk meg róla, hogy ugyanannak a felhasználónak a birtokában vannak, aki az Apache-ot telepítette, és rendelkezik írási jogosultsággal ezekhez a fájlokhoz. 25

38 Kapcsolódás a kiszolgálóhoz Ha megpróbálunk elérni egy oldalt a kiszolgálón, de az nem jelenik meg, első feladatunk, hogy kiderítsük, hol vannak a gondok: a kiszolgálón, a hálózaton vagy a böngészőben. Először a ps, a netstat, illetve (Windowson) a Feladatkezelő segítségével győződjünk meg arról, hogy az Apache kiszolgáló fut. Előfordulhat ugyanis, hogy még ez sem teljesül! Ez után győződjünk meg arról, hogy képesek vagyunk kapcsolódni az Apache-hoz az adott gépről. Ehhez létesítsünk telnet-kapcsolatot, és küldjünk a kiszolgálónak egy próbakérelmet. Most ellenőrizzük, hogy az Apache a megfelelő cím-port párt használja-e. Ha a gépünkről elérjük a kiszolgálót, távolról azonban nem, az Apache valószínűleg egy helyi címet vagy egy olyan portot figyel, ami távolról nem érhető el. Vizsgáljuk meg a kérdéses címeket a netstat, illetve az lsof segédprogramokkal, és győződjünk meg róla, hogy a beállításuk helyes. Ellenőrizzük a tűzfal és az útválasztó beállításait. Ha az Apache a megfelelő címet figyeli, de a hálózatunkon kívülről elérhetetlen, valószínűleg tiltott a hálózati forgalom a kiszolgálónk felé. Vizsgáljuk meg a szóban forgó kiszolgálók közti kapcsolatot a traceroute (Windows rendszereken a tracert) segédprogrammal. Számos operációs rendszer alapértelmezés szerint tiltja a külső elérést néhány port kivételével. Ha kiszolgálónkat nem ezek valamelyikével használjuk, a rendszer letiltja a forgalmat. A helyzet megoldása az operációs rendszertől függ. Fedora rendszereken például a system-config-securitylevel segédprogramot használhatjuk, Windowson pedig a Vezérlőpult Tűzfal programja siet a segítségünkre. Végezetül, ha SSL protokollal kapcsolódunk a kiszolgálóhoz (lásd a 7. fejezetben), és régebbi böngészőt vagy szokatlan beállításokat használunk, érdemes utánanéznünk a hibanaplóban az SSL adattitkosításhoz kapcsolódó hibaüzeneteknek. Document not found Ha sikerül elérnünk a kiszolgálót, de Document not found hibaüzenetet kapunk, először is győződjünk meg arról, hogy a keresett dokumentum valóban létezik-e. Ez után ellenőrizzük, hogy a kérelem megérkezett-e a kiszolgálóhoz ehhez vizsgáljuk meg az access_ log fájlban a kérdéses kiszolgálóhoz tartozó kérelmeket. Ha egyszerre több Apache-példányt is futtatunk, előfordulhat, hogy az ügyfél nem a megfelelő kiszolgálóhoz kapcsolódott. Most győződjünk meg arról is, hogy az Alias utasítások a megfelelő helyre mutatnak vagyis oda, ahol a szóban forgó dokumentum található. Vigyázzunk, nehogy elgépeljük vagy véletlenül töröljük a célkönyvtárat! Végezetül nézzünk utána a hibás átirányításoknak, különös tekintettel a záró perjelekre, és ne feledkezzünk meg a ServerName kapcsán a korábbiakban tárgyalt hibalehetőségekről sem. Access forbidden Ha a dokumentum létezik, de a rendszer letiltja a hozzáférést, több gyakran előforduló hibára is gyanakodhatunk. Mindenekelőtt győződjünk meg róla, hogy az Apache folyamat tulajdonosa rendelkezik a fájl olvasásának jogával, és arról is, hogy az Apache folyamat tulajdonosa a fájl elérési útvonalában szereplő minden könyvtárhoz rendelkezik az olvasás és a tartalomkiíratás jogosultságával. 26

39 Ellenőrizzük, hogy nem arról van-e szó, hogy egy olyan könyvtárat szeretnénk elérni, amely nem rendelkezik indexfájllal, a könyvtártartalom kiíratását viszont letiltották az Apache beállítófájljában. Ellenőrizzük, hogy a kérelem megfelel-e minden követelménynek, amelyet az Apache beállítófájljának hozzáférésszabályozó utasításai támasztanak. Ha CGI parancsfájlt szeretnénk elérni, győződjünk meg róla, hogy rendelkezik olvasási és futtatási jogokkal. Internal server error Ha böngészőnkben az Internal server error (belső kíszolgálóhiba) hibaüzenetet kapjuk, amikor egy oldalt próbálunk letölteni a webkiszolgálóról, kezdjük a vizsgálódást az Apache error_log fájljában. Tegyük fel magunknak a következő kérdéseket: CGI programot próbálunk elérni? A program rendelkezik a megfelelő olvasási és futtatási jogokkal? Helyes az értelmező útvonala a parancsfájl első sorában? Megjelölték a fájlt CGI parancsfájlként a ScriptAlias utasítással vagy más hasonló módon? Ha semmi sem segít... Fejezetünkben azokkal a hibajelenségekkel foglalkoztunk, amelyekkel az átlagos Apache-felhasználó a leggyakrabban találkozhat. Ha olyasmivel kerülünk szembe, amiről itt nem esett szó, első lépésként vizsgáljuk meg a részleteket a hibanaplókban. Amennyiben szükséges, növeljük a kiszolgáló LogLevel-értékét, így több segítséget kaphatunk a problémák felgöngyölítéséhez. Keressük a megoldást az Apache leírásában, levelezőlistákon vagy a hibaadatbázisban. Végül, ha ez sem vezet eredményre, tegyük fel kérdésünket az Apache Users levelezőlistán, a következő címen: Fontos, hogy betartsuk a lista szabályait - előbb gondolkodjunk el magunk a megoldáson, és csak ha valóban nem jutunk egyről a kettőre, akkor fogalmazzuk meg a kérdéseinket. Írjunk le mindent részletesen, hiszen csak így számíthatunk valóban hathatós segítségre. 27

40 28

41 3 Naplózás és megfigyelés Bevezetés a naplózásba Az előző fejezetben bemutatott hibanaplózási lehetőségek mellett az Apache kiterjedt képességekkel bír a kérelmek minden részletének tárolására. A következőkben a kérelmek naplózásával kapcsolatos témakörökkel foglalkozunk, így megismerkedünk a feltételes naplózással, a naplók forgatásával, az IP címek feloldásával, valamint az átirányított naplózás módszerével. Mindemellett megtanuljuk számos, a programcsomaghoz tartozó, illetve külső gyártók által készített segédprogram használatát, amelyekkel megfigyelhetjük az Apache kiszolgálót, illetve elemezhetjük a naplókat. Az Apache alapértelmezett naplófájljai Az Apache számos megfigyelési és naplózási lehetőséget biztosít, amelyekkel nyomon követhetjük a kiszolgáló működését. Alapállapotban két naplófájlt kapunk, amelyeket a telepítési könyvtár logs alkönyvtárában találhatunk meg: Az access_log (Windowson access.log) a kiszolgáló által teljesített kérelmekről szolgáltat adatokat, így itt tájékozódhatunk a kérelmezett URL-ekről, az ügyfelek IP címéről, valamit arról, hogy egy adott kérelem teljesítése sikeres volt-e. Az error_log (Windowson error.log) a hibajelenségekről, valamint a kiszolgáló életciklusának egyes eseményeiről tájékoztat. Naplóformátumok létrehozása LogFormat %h %1 %u %t \ %r\ %>s %b common LogFormat %h %1 %u %t \ %r\ %>s %b \ %{Referer}i\ \ {User-agent}i\ combined A LogFormat utasítással megadhatjuk, hogy a kérelem mely részeit szeretnénk naplózni. Szükségünk van emellett további utasításokra is ahhoz, hogy meghatározzuk, hová kerüljenek az adatok, de ezzel a későbbiekben foglalkozunk. Példánkban a két legismertebb formátum, a Common Log Format és a Combined Log Format beállításait láthatjuk. Amikor az Apache fogad egy kérelmet, minden % jellel kezdődő paramétert a kérelem megfelelő részével helyettesít. Ha Common Log Format (CLF) formátumú naplót használunk, naplófájlunk bejegyzései így festenek: someuser [12/Jun/2005:08:33: ] GET /example.png HTTP/ Ha a Combined Log Format mellett döntünk, ilyen bejegyzéseket kapunk: someuser [12/Jun/2005:08:33: ] GET /example. png HTTP/ Mozilla/5.0 (Windows; U; Windows NT 5.1; en-us; rv:1.7.7) 29

42 Érdemes pár szóban leírnunk a legfontosabb naplómezők szerepét: %h: A kérelmet küldő ügyfél IP címe, vagy amennyiben bekapcsoltuk a HostNameLookups lehetőséget - a kiszolgáló neve (esetünkben ez a ). %u: A kérelmet küldő felhasználó azonosítója a HTTP-hitelesítés alapján (példánkban a someuser). A HTTP alapú hitelesítés beállításairól bővebben a 6. fejezetben olvashatunk. %t: A kérelem fogadásának időpontja. %r: Az ügyféltől kapott kérelem eredeti szövege, az alkalmazott HTTP-függvénnyel, a kért erőforrással és az ügyfél böngészője által használt HTTP protokoll verziószámával (példánkban ez a GET /example.png http/l. 0) %>s: A HTTP-kérelem végső állapotkódja, amelyet a kiszolgáló küld vissza az ügyfélnek (példánkban ez a kód a 200, ami azt jelenti, hogy a kiszolgáló sikeresen teljesítette a kérelmet). %b: A válaszként az ügyfélnek küldött objektum mérete (bájtban) a válasz fejléce nélkül (példánkban az 1234). A Combined Log Format két mezővel egészíti ki a Common Log Format lehetőségeit: %{Referer}i: A Referer HTTP-kérelemfejléc, vagyis az a weboldal, amelyik az aktuális dokumentumra hivatkozott (példánkban ez a %{User-agent}i: A User-agent HTTP-kérelemfejléc, amely az ügyfél böngészőjéről szolgál információkkal (példánkban ez a Mozilla/5.0 (Windows; U; Windows NT 5.1; en-us; rv:1.7.7)). Egyéni naplófájl létrehozása CustomLog logs/access_log common TransferLog logs/sample.log Szükségünk lehet olyan naplófájlokra is, amelyek nem szerepelnek az Apache alapértelmezett naplói között. Példánkban a CustomLog utasítással hozunk létre egy új naplófájlt, amelyben egy előzetesen meghatározott common naplóformátumban tároljuk a kérelmek adatait (a név helyett használhatjuk magát a formátummeghatározást is). Használhatjuk ilyen célokra az egyszerűbb TransferLog utasítást is, amely a legutóbbi LogFormat utasítás meghatározását veszi alapul. Naplók átirányítása külső programokhoz TransferLog bin/rotatelogs /var/logs/apachelog A CustomLog, valamint a TransferLog utasításokkal a naplózás kimenetét külső programokhoz is átirányíthatjuk. Ehhez a cső karakter ( ) után meg kell adnunk annak a programnak az elérési útját, amelyik a naplóadatokat a szabványos bemenetén fogadja. Példánkban ez a rotatelogs, amelyhez hozzájutunk az Apache programcsomagjával (lásd később). Külső programunk futtatója az a felhasználó lesz, aki a httpd-t elindította. Vigyázzunk, ha a rendszergazda indította el a kiszolgálót, a külső program is az ő jogosultságait kapja meg tehát legyünk nagyon óvatosak! Ügyeljünk arra is, hogy Unixtól eltérő rendszereken kizárólag előre álló perjeleket használjunk a fájl elérési útjában még akkor is, ha a rendszer egyébként megengedi a fordított perjeleket. A beállítófájlokban egyébként általánosságban is ajánlott az előre álló perjelek kizárólagos használata. 30

43 Kérelmek feltételes naplózása SetEnvIf Request_URI (\.gif \.jpg)$ image CustomLog logs/access_log common env=!image SetEnvIf Remote_Addr 192\.168\.200\.5 specialmachine CustomLog logs/special_access_log common env=specialmachine Egy kérelem naplózása felől dönthetünk egy meghatározott környezeti változó jelenlétének függvényében is. Ezt a változót előre beállíthatjuk több paraméter így az ügyfél IP címe, illetve bizonyos fejlécek jelenléte alapján. Amint a példában is láthatjuk, a CustomLog utasítás a harmadik paraméterben képes egy környezeti változó fogadására is. Amennyiben ez a változó jelen van, a kérelem bekerül a naplóba, ha nincs jelen, kimarad. Ha a környezeti változót a! karakterrel negáltuk, a bejegyzés akkor kerül be a naplóba, ha a környezeti változó nincs jelen. Példánk bemutatja, miként kerülhetjük el a GIF és JPEG formátumú képek naplózását, és hogyan naplózzuk az adott IP címről érkező kérelmeket külön fájlba. A következőkben egy újabb példát is láthatunk erre az eljárásra. A webhelyre mutató hivatkozások figyelése SetEnvIfNoCase Referer www\.example\.com internalreferral LogFormat %{Referer}i -> %U referer CustomLog logs/referer.log referer env=!internalreferral Ha szeretnénk nyomon követni, hogy ki hivatkozik a webhelyünkre, naplózhatjuk a kérelmek Referer: fejlécét ez tartalmazza ugyanis annak a weboldalnak a címét, amelyik a kérelmezett oldalra hivatkozott. A fejléc nem mindig van jelen, és sok esetben nem ad pontos tájékoztatást, de az esetek többségében jól használható. Példánkban azt mutatjuk be, miként naplózhatjuk egy környezeti változó segítségével a hivatkozási adatokat egy külön fájlba. Jelen esetben csak a külső hivatkozásokra vagyunk kíváncsiak, azokra nem, amelyek egy belső weboldalról származnak. Ez utóbbiak kiszűrésére megvizsgáljuk, hogy a hivatkozó címe a saját tartományunkban található-e. Az Apache figyelése a mod_status modullal <Location /server-status> SetHandler server-status Order Deny,Allow Deny from all Allow from </Location> A mod_status modul tájékoztatást ad a kiszolgáló tevékenységéről és teljesítményéről, és lehetővé teszi a rendszergazdának, hogy figyelje a kiszolgáló hatékonyságát. A modul működésének eredményeként egy HTML oldalt kapunk, amelyen a legfrissebb kiszolgálóadatok szerepelnek könnyen áttekinthető formában. Szerepel itt a kérelmeket kiszolgáló munkaszálak száma, a tétlen munkaszálak száma, a kiszolgáló indításának, illetve újraindításának időpontja és más egyebek. 31

44 Ha alkalmazzuk az ExtendedStatus On utasítást, további, részletesebb adatokat is kapunk, így az egyes munkaszálak állapotát, a hozzáférések teljes számát, az adott pillanatban kiszolgált kérelmek számát, és így tovább, de mindig tartsuk észben, hogy a széles körű adatrögzítés a kiszolgáló terhelésétől függően akár jelentősen is csökkentheti a teljesítményt. A példa azt mutatja be, hogy miként kapcsolhatjuk be a mod_status modult úgy, hogy egyúttal a kapott adatok elérését IP címek egy csoportjára korlátozzuk. A kiszolgáló teljesítményadatait a későbbiekben könnyedén elérhetjük, ha a böngészőben megadjuk a címet. Az Apache megfigyelése az SNMP-vel Jó pár olyan nyílt forrású modul létezik, amelyek biztosítják az SNMP lehetőségeit az Apache webkiszolgáló számára. Ezzel a protokollal legtöbbször egy központi konzolról szabályoznak hálózati kiszolgálókat és egyéb berendezéseket jó példa erre a HP OpenView és a Tivoli. Ezzel a modullal könnyűszerrel követhetjük Apache kiszolgálónk teljesítményét, valós időben, folyamatosan értesülve a kiszolgáló működési időtartamáról, az átlagos terhelésről, az adott időtartam alatt bekövetkezett hibák számáról, a kiszolgált bájtok és kérelmek számáról, és más egyebekről. Az SNMP-modulok képesek figyelmeztetni, ha a rendszer átlép bizonyos küszöbértékeket, vagy meghatározott típusú hiba következik be így jelezhet például a párhuzamos ügyfélkapcsolatok számának hirtelen növekedésekor. Az Apache 1.3 esetében a címről letölthető mod_snmp modult alkalmazhatjuk, amely támogatja az SNMP l-es és 2-es változatát. Használatához foltot kell alkalmazni az Apache magjára. Az Apache 2 esetében hasonlóan használható a mod_apache_snmp modul, amelyet megtalálhatunk a címen. Támogatja az SNMP l-es, 2-es és 3-as változatát, és DSO-ként (dinamikus megosztott objektumként) fordítható, anélkül, hogy foltoznunk kellene az Apache magját. Az SNMP-erőforrások kezelésére számos nyílt forrású segédprogram és környezet áll rendelkezésünkre, így a segédprogramjai, az OpenNMS ( valamint a Nagios ( Naplók elemzése nyílt forrású segédprogramokkal Rengeteg kereskedelmi és nyílt forrású segédprogram áll rendelkezésre, amelyek segíthetnek a naplók adatainak feldolgozásában és megjelenítésében. Működési elvük javarészt hasonló: bemenetként egy naplófájlt fogadnak, és weboldalak sorát adják vissza a kívánt statisztikákkal. Lássunk most két népszerű, ingyenesen elérhető, nyílt forrású programot a naplófájlok általános elemzésére: Webalizer - AWStats - Más programok bővebb szolgáltatáskészlettel rendelkeznek, például grafikusan jelenítik meg a látogatóink által bejárt útvonalakat: Visitors Pathalizer

45 Naplók valósidejű megfigyelése A mod_status, valamint a korábban bemutatott különféle SNMP-modulok mellett használhatjuk az apachetop parancssori segédprogramot is, amelyet letölthetünk a org/apachetop/ címről. A program működése hasonló a Unix top parancsáéhoz, de nem az operációs rendszer, hanem a webkiszolgáló állapotát mutatja meg valós időben. Ha Unix rendszeren futtatjuk az Apache-ot, és kis forgalmú webhelyet üzemeltetünk, a tail paranccsal ha kezdetleges formában is szintén valós időben megfigyelhetjük mind a hozzáférési, mind a hibanaplót: tail -f naplófájl Léteznek más programok is, amelyek átvizsgálják a hibanaplókat meghatározott hibák, rosszul megadott kérelmek és más hasonló jelenségek után kutatva, és eredményként jelentést adnak: A Logscan a következő címen található meg: A ScanErrLog segédprogramot az alábbi címről tölthetjük le: Kérelmek rögzítése adatbázisban Az Apache nem rendelkezik olyan segédprogramokkal, amelyek lehetővé tennék, hogy közvetlenül egy adatbázisba naplózzunk, de külső gyártók műhelyeiben születtek ilyen parancsfájlok és modulok: A mod_log_sql lehetővé teszi, hogy kérelmeinket közvetlenül egy MySQL adatbázisba naplózzuk: Ezt követően az Apache LogView SQL eszközével lekérdezhetjük ezt az adatbázist: A pglogd összegyűjti a naplókat, és a naplóbejegyzéseket egy PostgreSQL adatbázisban tárolja: Naplók forgatása és tárolása CustomLog bin/rotatelogs /var/logs/apachelog common Ha nagy forgalmú webhelyet üzemeltetünk, észrevesszük majd, hogy naplófájljaink mérete rohamosan nő. A naplókat persze saját kezűleg archiválhatjuk is, de számos módszer létezik a naplók automatikus forgatására, amelyek során a régi naplófájlok meghatározott időközönként tömörítve a lemezre kerülnek. Annak érdekében, hogy elkerüljék a kiszolgáló leállítását, illetve újraindítását a naplófájlok kezelése alatt, a rendszergazdák gyakran egy köztes programot alkalmaznak a kérelmek naplózására. Ez a program végzi el a naplók forgatását, tömörítését és archiválását. 33

46 Az Apache erre a célra a rotatelogs segédprogramot bocsátja a rendelkezésünkre, de hasonló programot találhatunk a címen is. A fenti példában egy új naplófájlt hozunk létre a rotatelogs segítségével, az aktuális naplót pedig naponta áthelyezzük a /var/logs/ könyvtárba (egy nap másodpercből áll). A program használatáról bővebben az Apache leírásában olvashatunk, ahol megtudhatjuk azt is, miként forgassuk naplófájljainkat a méretük alapján, és hogyan nevezzük el az archív fájlokat egy sablonból kiindulva. Figyelem! Ha a naplóforgató program elérési útja szóközöket is tartalmaz, előfordulhat, hogy egy \ jelet eléjük írva le kell védeni azokat. Ilyen problémák különösen a Windows rendszereken jelentkezhetnek. Az IP címek feloldásának szabályozása HostNameLookups on Ha a HostNameLookups utasításnak az on értéket adjuk, az Apache megkísérli meghatározni (feloldani) az ügyfél IP címéhez tartozó gépnevet a kérelem naplózásakor. A HostNameLookups off értéke esetén így festhet az access_log egyik bejegyzése: someuser [12/Jun/2005:08:33: ] GET /example.png HTTP/ Ha a utasítást on-ra állítjuk, ugyanez a bejegyzés így alakul: unitl2.example.com - someuser [12/Jun/2005:08:33: ] GET / example.png HTTP/ A következőkben bemutatjuk azt az eljárást is, amellyel a naplófájlokban talált IP címeket gépnevekkel helyettesítjük. A naplózott IP címek feldolgozása $ logresolve < access_log > resolved_log A HostNameLookups utasítás on értékre állítása hatással lehet a kiszolgáló teljesítményére, mert megnyújtja a válaszidőt. Ennek elkerülésére kikapcsolhatjuk a névfeloldást, és egy utófeldolgozó segédprogrammal később kicserélhetjük a naplófájlokban található IP címeket a hozzájuk tartozó gépnevekre. Ezek a segédprogramok hatékonyabbá teszik a munkát, hiszen képesek átmenetileg tárolni az eredményeket, és nem okoznak fennakadást az ügyfelek kiszolgálásában Az Apache rendelkezik ilyen segédprogrammal ez a logresolve (Windowson logresolve.exe), amely naplóbejegyzéseket fogad a szabványos bemenetén, a szabványos kimenetén pedig visszaadja az eredményt. Ha fájlt szeretnénk olvasni, illetve írni, akár Unix, akár Windows rendszeren, használjuk a példában is bemutatott átirányítást. 34

47 Fontos észben tartanunk, hogy az IP cím feloldásának eredménye nem mindig árulja el, hogy melyik gépről küldték a kérelmet. Ha például egy helyettes kiszolgáló vagy egy átjáró található az ügyfél és a webkiszolgáló között, a HostNameLookups, illetve a logresolve által visszaadott IP cím ennek a helyettes kiszolgálónak vagy átjárónak felel meg, így a helyettes kiszolgáló, illetve az átjáróhoz tartozó IP-blokk gépnevét kapjuk meg, nem pedig a kérelmet kiadó géphez tartozó nevet. Az Apache automatikus újraindítása lefagyás esetén #!/bin/bash if [ ps -waux grep -v grep grep -c httpd -lt 1 ]; then apachectl restart; fi Ha az Apache-ot szolgáltatásként telepítettük a Windowsban, a szolgáltatáskezelő automatikusan újraindítja lefagyás esetén. Unix rendszereken mindezt figyelő parancsfájlokkal (watchdog) valósíthatjuk meg, amelyek más programok futását figyelik, és ha a szemmel tartott program lefagy, újraindítják. Példánkban egy egyszerű Linuxparancsfájlt láthatunk, amely figyeli a rendszerfolyamatok listáját, számon tartva, hogy létezik-e a httpd folyamat, és újraindítva, ha esetleg lefagyott. Használatához futtatási jogosultságot kell adnunk a parancsfájlnak, és el kell helyeznünk a cron beállításai között, hogy meghatározott időszakonként újra és újra végrehajtsuk. Ha Solaris rendszert használunk, a ps -waux helyett alkalmazzuk a ps -ef parancsot. A címen egy kifinomultabb figyelő parancsfájlt találhatunk, amely elektronikus levelet küld, ha a kiszolgáló leállt, és képes egyes httpd-folyamatazonosítók figyelésére. A legtöbb Linux-kiadásban találhatunk olyan általános figyelő parancsfájlokat, amelyeket az Apache igényeinek megfelelően formálhatunk. Naplófájlok egyesítése és szétválasztása Ha több webkiszolgálónk szolgáltatja ugyanazt a tartalmat, gyakran szükség van arra, hogy az egyes naplófájlokat egyesítsük, mielőtt átadnánk azokat a naplóelemző eszközöknek. Más részről, ha egyazon Apache kiszolgáló több virtuális kiszolgálót üzemeltet, sok esetben jól jöhet, ha a naplófájlokat a virtuális kiszolgálók szerint szétbonthatjuk. Ezt megtehetjük a webkiszolgáló szintjén, de ugyanazt az eredményt érhetjük el a naplófájlok utófeldolgozásával is. Erre a célra alkalmas a split-logfile segédprogram, amelyet mind az Apache 1.3-ban, mind 2.x-ben megtalálhatunk a telepítési könyvtár support/ alkönyvtárában. A logtool projektben számos naplókezelő segédprogramot találhatunk az alábbi címen: A vlogger lehetővé teszi, hogy egyetlen naplófolyamot a virtuális gépekhez tartozó naplófájlokra bontsunk, emellett helyettesíthetünk vele más segédprogramokat is, mint a cronolog. A programot letölthetjük a címről. 35

48 Külön naplók a virtuális kiszolgálók számára <VirtualHost > ServerName vhost1.example.com CustomLog logs/vhost1.example.com_log combined ErrorLog logs/vhost2.example.com_log... </Virtual Host> A <vírtualhost> szakaszokon belül elhelyezett CustomLog utasításokkal a példában látható módon elérhetjük, hogy virtuális kiszolgálóink külön naplófájlokat használjanak. Azt is megtehetjük azonban, hogy az összes virtuális kiszolgáló műveleteit a globális kiszolgálókörnyezetben meghatározott access_log fájlban rögzítjük: LogFormat %v %h %l %u %t \ %r\ %>s %b common_virtualhost CustomLog logs/access_log common_virtualhost A %v rögzíti a kérelmet kiszolgáló virtuális kiszolgálót. A későbbiekben ennek alapján már könnyen szétválaszthatjuk az egyes virtuális gépek adatait a bemutatott utófeldolgozó eszközökkel. Ha sok virtuális kiszolgálót használunk, ez az ésszerű és gyakran az egyetlen járható út. Amennyiben egy kiszolgáló műveleteit egyáltalán nem szeretnénk naplózni, az alábbi utasítást használhatjuk: CustomLog /dev/null Jellemző naplóbejegyzések A 2. fejezetben bemutatottak mellett most felsorolunk néhány bejegyzést, amelyekre gyakran ráakadhatunk naplóink böngészése közben. Ezek azonban nem komoly hibák legtöbbjüket nyugodtan figyelmen kívül hagyhatjuk. File favicon.ico not found Napjaink böngészőinek többsége támogatja egy kis ikon megjelenítését a címsávban, illetve a könyvjelzők mellett. Az ikon kirajzolásához a böngésző egy fájlt (ez az a bizonyos favicon.ico) kér a webhelytől. Ha nem találja, ezt a hibaüzenetet kapjuk. Arról, hogy miként rendelhetünk magunk is ilyen ikont a webhelyünkhöz, az 1. fejezetben olvashattunk. File robots.txt not found A robots.txt fájlra egyes programoknak automatikus letöltőknek, pókoknak van szükségük a webhelyünk meglátogatásakor. Ezek a programok átvizsgálják a webhelyeket, és letöltenek minden hivatkozást, amit csak találnak. Többnyire keresőmotorok alkalmazzák őket, céljuk a kapott tartalom tárolása és indexelése. A címben szereplő hibaüzenetet akkor kapjuk, ha a robots.txt fájl nincs jelen. httpd.pid overwritten Unix rendszereken a httpd.pid fájl tartalmazza az adott Apache-példány folyamatazonosítóját a folyamat elindulásakor a rendszer létrehozza, a leálláskor pedig törli. Ha az Apache leállítása nem szabályos 36

49 körülmények között történt mondjuk saját kezűleg, a kill paranccsal, vagy lefagyott a gép, a rendszer nem törli a fájlt, így jelen lesz a következő rendszerindításkor, és ezt a hibaüzenetet eredményezi. Hosszú, furcsa kérelmek Előfordulhat, hogy hibanaplónkban az alábbihoz hasonló furcsa kérelmekkel találkozunk: SEARCH /\x90\x02\xb1\x02\xb1\x02\xb1\x02... GET/scripts/..%252f../winnt/system32/cmd.exe?/c+dir HTTP/ GET /default.ida?nnnnnnn NNNNNNNNNNNNNNNNN... Szerepelhetnek itt olyan futtatható fájlok, amelyek nem találhatók meg a webhelyünkön mint a cmd.exe, a root.exe, a dir és más hasonlók. Ezek a kérelmek automatizált támadások eredményei, amelyek megpróbálják kihasználni a webkiszolgálónk gyenge pontjait. Szerencsére többségüket olyan férgek vagy más rosszindulatú alkalmazások adják ki, amelyek kifejezetten a Windows rendszereken futó Microsoft Internet Information Servert támadják, így az Apache nincs veszélyben. Mindazonáltal olykor fény derül az Apache sebezhető területeire is, amelyek kiszolgáltatottá tehetik a távoli támadásokkal szemben, ezért legyünk résen, és szerezzük be a lehető leghamarabb az Apache legfrissebb változatát (lásd a 6. fejezetet). 37

50 38

51 4 URL-megfeleltetés és dinamikus tartalom URL-megfeleltetés Fejezetünkben bemutatjuk, miként állíthatjuk be az Apacheot úgy, hogy a kérelmeket fájloknak és könyvtáraknak feleltesse meg, illetve meghatározott oldalakra vagy kiszolgálókra irányítsa át azokat. Ezek az ismeretek jól jöhetnek, ha a webhely szerkezetének változásakor meg szeretnénk őrizni az eredeti URLeket, ha a kis- és nagybetűk különbségét is figyelembe kívánjuk venni, vagy ha több nyelvet is támogatni szeretnénk. Megtanuljuk továbbá, miként használjuk a CGI-t és az SSI-t az Apache-ban dinamikus tartalom összeállítására. URL-ek megfeleltetése fájloknak az Alias utasítással Alias /icons/ /usr/local/apache2/icons/ Webhelyünk felépítése nem feltétlenül kell megegyezzen a lemezünkön található könyvtárszerkezettel az Alias utasítás segítségével ugyanis könyvtárainkat URL-eknek feleltethetjük meg. Így a példában bemutatott utasítás használatakor a apache2/icons/ image.gif fájlra érkező kérelmek esetében az Apache az alapértelmezett dokumentumkönyvtárban, a / usr/local/apache2/htdocs/icons/image.gif útvonallal elérhető fájlt keresi. A befejező perjelek lényegesek az Alias utasításban amennyiben használjuk őket, a kérelemben is meg kell jelenjenek, egyébként az Apache nem találja meg a kívánt könyvtárat. Így ha az alábbi utasítást alkalmazzuk, majd a címet kérelmezzük, a kiszolgáló a 404 Document Not Found hibaüzenetet adja vissza: Alias /icons/ /usr/local/apache2/icons/ URL-minták megfeleltetése fájloknak az AliasMatch utasítással AliasMatch ^(docs help) /usr/local/apache/htdocs/manual Az AliasMatch utasítás használata igencsak hasonló az Alias-éhoz, azzal a különbséggel, hogy az URL helyett itt szabályos kifejezést is megadhatunk a lehetséges elérési utakat a kapott egyezések adják. A fent bemutatott utasítás például minden URL-t lefed a manual könyvtár /help, valamint /docs alkönyvtárában. A szabályos kifejezések olyan karakterláncok, amelyek meghatározott nyelvtani szabályok szerint kiértékelve több karakterláncnak felelnek meg. A témáról bővebben is olvashatunk (angolul) a címen. 39

52 Oldalak átirányítása Redirect /news Redirect /latest /3.0 A webhelyek felépítése rendszerint változik az idő előrehaladtával, erről azonban azok gyakran nem értesülnek, akik hivatkoznak az itt található tartalomra (gondoljunk csak a keresők elavult hivatkozásaira). Annak érdekében, hogy elejét vegyük a régi hivatkozások használatából eredő hibáknak, a Redirect utasítással átirányíthatjuk az eltévedt kérelmeket a friss tartalomhoz, legyen az azonos vagy eltérő kiszolgálón. Jóllehet paraméterként megadhatjuk az átirányítás típusát (ideiglenes vagy állandó), a Redirect utasítást leggyakrabban egyszerűen a forrás és a cél URL megadásával használják. A cél lehet ugyanazon a webkiszolgálón is, de semmi akadálya annak, hogy akár egy másik kiszolgálóra mutasson az átirányítás. Példánkban minden kérelmet, amely a címre érkezik, a címre irányítunk át. Átirányítás a fájl legfrissebb változatához RedirectMatch myapp-(1 2)\.([0-9])(\.[0-9])?-(.*) /myapp-3.0-$4 A RedirectMatch utasítás hasonló a Redirect-hez, azzal a különbséggel, hogy itt szabályos kifejezést is használhatunk a kiindulási URL helyett, ami rendkívüli rugalmasságot ad. Képzeljük el például, hogy egy programozó cég webhelyét üzemeltetjük, amelyen újabb és újabb programváltozatokat bocsátunk az ügyfelek rendelkezésére. Észrevesszük azonban, hogy ügyfeleink egy része továbbra is a régebbi változatokat tölti le, amelyeket külső webhelyek elavult hivatkozásain keresztül érnek el. A RedirectMatch segítségével a régi változatokra érkező kérelmeket könnyedén átirányíthatjuk az újakhoz. Tegyük fel, hogy a legfrissebb változat letölthető fájlja a myapp-3.0 névre hallgat. Példánk a com/myapp demo.tgz címre érkező kérelmeket átirányítja a com/myapp-3.0demo.tgz címre, a címre érkező kérelmeket pedig a címre továbbítja. A szabályos kifejezés első három eleme a fő- és az alváltozat számát adja meg, továbbá egy esetleges folt jelenlétét is vizsgálja a kapott eredményt helyettesítjük a 3.0-val. A szabályos kifejezés vége a fájlnév fennmaradó részével ad egyezést, az eredmény pedig a cél URL-be kerül. Hibás vagy nem engedélyezett kérelmek átirányítása ErrorDocument 404 /search.html Ha egy népszerű vagy bonyolultabb szerkezetű webhelyet üzemeltetünk, minden elővigyázatosság ellenére gyakran találkozunk olyan kérelmekkel, amelyek hibás URL-ekre hivatkoznak, illetve olyan dokumentumokra, amelyek már nem elérhetők. Sok esetben megoldást jelent egy jól megírt Redirect utasítás, de még így is rengeteg olyan kérelem érkezik, amelyekre válaszként csak a gyűlölt 404 Document Not Found hibaüzenet érkezik. Ennek elkerülésére érdemes lehet kicserélnünk az Apache alapértelmezett hibaüzenetoldalát, és átirányítanunk a felhasználókat a webhelyünk egy kellemesebb részére. Segíthetünk egy keresőoldallal mint példánkban is látható vagy oldaltérképpel. A 6. fejezet egy ide kapcsolódó megjegyzésében további útmutatást találhatunk az elérés megtagadva oldalak testreszabására. 40

53 Tartalomkezelők meghatározása AddHandler cgi-script.pl.cgi <Location /cgi-bin/*.pl > Options +ExecCGI SetHandler cgi-script </Location> A tartalomkezelők lehetővé teszik, hogy meghatározzuk, milyen műveletet végezzen az Apache a kérelmezett tartalmon. A tartalomkezelőket a modulokban érhetjük el, és megadhatjuk, hogy melyiküket alkalmazza adott tartalomtípus esetén a kiszolgáló. Ezt a lehetőséget leggyakrabban olyan tartalomelőállító modulok esetében használják ki, mint a PHP vagy a mod_cgi. Példánkban azt mutatjuk be, miként rendelhetjük hozzá a cgi_handler tartalomkezelőt azokhoz a fájlokhoz, amelyeket CGI parancsfájlként szeretnénk futtatni. Az AddHandler utasítás segítségével rendelhetjük hozzá a tartalomkezelőt a kívánt fájlkiterjesztésekhez, míg a RemoveHandler használatával megszabadulhatunk a régebbi hozzárendelésektől. A példánkban szereplő AddHandler utasítás arra utasítja az Apache-ot, hogy minden cgi vagy pl kiterjesztéssel rendelkező fájlt CGI parancsfájlként kezeljen. A SetHandler utasítással egy helyen, illetve könyvtárban található fájlokhoz rendelhetünk tartalomkezelőt. Végezetül, az Action utasítás, amelyről a későbbiekben még szólunk, lehetővé teszi, hogy meghatározott MIME típust vagy tartalomkezelőt rendeljünk egy CGI parancsfájlhoz. A MIME típusokról A MIME (Multipurpose Internet Mail Extensions) egy szabványgyűjtemény, amely egyebek mellett a dokumentumok azonosításának egy módját határozza meg. MIME típusok például a text/html, valamint az audio/mpeg. A típus első tagja a tartalom főkategóriája (text, audio, image, video - szöveg, hang, kép, videó), második tagja pedig maga a típus. Az Apache a MIME típusok segítségével dönti el, hogy milyen tartalomhoz milyen modult vagy szűrőt használjon, továbbá így jelöli válaszainak HTTP-fejlécében a visszaadott tartalom típusát. Ezeknek a fejléceknek az alapján az ügyfélprogramok képesek azonosítani a tartalmat, és helyes alakban megjeleníteni a felhasználó számára. A MIME típusok beállítása AddType text/xml.xml.schema <Location /xml-schemas/> ForceType text/xml </Location> A tartalomkezelőkhöz hasonlóan MIME típusokat is rendelhetünk egyes kiterjesztésekhez vagy URL-ekhez. Példánk bemutatja, miként kapcsoljuk a text/html MIME típust az.xml és a.schema kiterjesztésű fájlokhoz, valamint az /xml-schemas/ könyvtár alatti tartalomhoz. Alapértelmezésben az Apache-csal hozzájutunk egy mime.types nevű fájlhoz, amelyben megtalálhatjuk az ismertebb MIME típusokat és a hozzájuk tartozó kiterjesztéseket. 41

54 A CGI parancsfájlok futtatásának alapjai A CGI (Common Gateway Interface közös átjárófelület) egy szabványos protokoll, amelyet a webkiszolgálók arra használnak, hogy kapcsolatba lépjenek külső programokkal. A webkiszolgáló minden szükséges adatot megad a kérelemről a külső programnak, az pedig feldolgozza, majd visszaküldi a választ, amely végül visszajut az ügyfélhez. Eredetileg a CGI parancsfájlok biztosították a dinamikus tartalomszolgáltatást, vagyis azt, hogy minden kérelemre egyedi válasz érkezhessen, így szinte minden kiszolgáló támogatja ezt a szabványt. Az Apache CGI-támogatását a mod_cgi modul testesíti meg (illetve, ha szálas Apache kiszolgálót futtatunk, a mod_cgid modul). A rosszul kódolt vagy bemutató CGI programok biztonsági kockázatot jelenthetnek, így ha nem használjuk ezt a lehetőséget, akkor jobb, ha a 6. fejezetben bemutatott módon teljesen ki is kapcsoljuk. Erőforrások megjelölése futtatható CGI parancsfájlként ScriptAlias /cgi-bin/ /usr/local/apache2/cgi-bin A következőkben bemutatunk néhány módszert, amelyekkel tudathatjuk az Apache-csal, hogy a kérelem célfájlja egy CGI parancsfájl. Ez azért fontos, mert így a kiszolgáló nem magát a fájlt adja vissza az ügyfélnek, hanem a fájl futtatásának eredményét. A ScriptAlias hasonlít a korábban bemutatott Alias utasításhoz, azzal a különbséggel, hogy ez esetben az Apache a célkönyvtár minden fájlját CGI parancsfájlként kezeli. Persze a <Files>, a <Location> és a <Directory> szakaszokban a SetHandler utasítással is tisztázhatjuk, hogy ezek a szakaszok CGI parancsfájlokat tartalmaznak. Ilyenkor szükség van az Options +ExecCGI utasításra is, amely általánosságban lehetővé teszi CGI parancsfájlok futtatását. Az alábbi példában arra utasítjuk az Apache-ot, hogy minden.pl kiterjesztéssel végződő URL-t CGI parancsfájlként kezeljen: <Location /cgi-bin/*.pl > Options +ExecCGI SetHandler cgi-script </Location> Parancsfájlok hozzárendelése HTTPfüggvényekhez és MIME típusokhoz # Minden GIF képet egy CGI parancsfájl dolgoz fel, # mielőtt kiszolgálnánk őket Action image/gif /cgi-bin/filter.cgi # Adott HTTP-függvény társítása CGI # parancsfájlhoz Script PUT /cgi-bin/upload.cgi A korábbiakban bemutatottak mellett az Apache olyan utasításokat is kínál, amelyek egyszerűbbé teszik egyes MIME típusok, fájlkiterjesztések, sőt akár HTTP-függvények hozzárendelését is a CGI parancsfájlokhoz. A mod_actions modul, amely megtalálható a kiszolgáló alapkiadásában, és bekerül a lefordított változatba is, az Action és a Script utasításokat bocsátja rendelkezésünkre e célra szerepüket példánk is mutatja: 42

55 Az Action utasítás két paramétert vár: az első egy tartalomkezelő vagy MIME tartalomtípus, míg a második egy a kérelmet kezelő CGI programra mutat. A Script utasítással CGI programokat rendelhetünk egyes HTTP-kérelmi függvényekhez. Az eredetileg kérelmezett dokumentumhoz kapcsolódó adatok a path_info (a dokumentum URL-je), valamint a path_translated (a dokumentum elérési útja) környezeti változók útján jutnak el a CGI parancsfájlhoz. Hasonlóan az előző példánál elmondottakhoz, a CGI parancsfájlt tartalmazó könyvtárban lehetővé kell tennünk a CGI parancsfájlok futtatását egy ScriptAlias utasítással, illetve az Options utasítás ExecCGI paraméterének beállításával. Hibakeresés a CGI parancsfájlokban ScriptLog logs/cgi_log A 2. és 3. fejezetben bemutatott hibakeresési módszerek mellett a mod_cgi modul egy további lehetőséget ad a CGI parancsfájlok vizsgálatához, a ScriptLog utasítás alakjában. Ha bekapcsoljuk, minden sikertelen CGI-futtatás adatait rögzíti a HTTP-fejléceket, a POST-változókat és más egyebeket is. Ha nem figyelünk oda, a kapott fájl gyors növekedésnek indulhat, amit a ScriptLogBuffer, valamint a ScriptLogLength utasítással korlátozhatunk. A CGI parancsfájlok teljesítményének növelése A CGI parancsfájlok használatának legnagyobb hátulütője a teljesítménycsökkenés, amelyet az okoz, hogy minden kérelem kezelésénél el kell indítanunk, majd le kell állítanunk a megfelelő programot. A mod_perl, illetve a FastCGI két megoldást is ad ezekre a gondokra. Fontos tudnunk, hogy bármelyik módszert is alkalmazzuk, alaposan át kell vizsgálnunk a már meglevő kódot, mert a továbbiakban nem alapozhatunk arra, hogy a kérelem kiszolgálása után az operációs rendszer automatikusan felszabadítja a lefoglalt erőforrásokat. A mod_perl, amely mind az 1.3-as, mind a 2.0-s Apacheváltozatban elérhető, egy Perl-értelmezőt ágyaz a webkiszolgálóba. Az Apache-nak nyújtott nagyszerű API mellett a mod_perl CGI-megfelelő móddal is rendelkezik, amely olyan környezetet ad, amelyben Perl CGI parancsfájljainkat minimális módosítással vagy akár eredeti alakjukban is futtathatjuk. Mivel a parancsfájlok ilyenkor egy állandó, folyamatbeli értelmezőben futnak, nem kell súlyos időveszteséggel fizetnünk az újraindításért. A FastCGI egy olyan szabvány, amely lehetővé teszi, hogy CGI programunk egyetlen példánya egymást követően több kérelmet is kiszolgáljon. A szabvány leírását elolvashatjuk a com oldalon, ahol egyúttal le is tölthetjük a megfelelő modulokat az Apache 1.3 és 2.x változatokhoz. A FastCGI az utóbbi időben visszanyert valamicskét a népszerűségéből, ami annak köszönhető, hogy több webfejlesztő környezetben mint a Ruby-onRails is megjelent. 43

56 Az SSI használata Document on disk This document, <!--#echo var= DOCUMENT_NAME -->, was last modified <!--#echo var= LAST_MODIFIED --> Content received by the browser This document, sample.shtml, was last modified Sunday, 14-Sep :03:20 PST Az SSI (Server Side Includes, kiszolgálóoldali beágyazott kód) egy egyszerű, régimódi webes technológia, amely más HTML-be ágyazott megoldások, például a PHP elődjének tekinthető. Egyszerű és igen hatékony módot ad arra, hogy a kívánt dinamikus tartalmat jelentéktelen rendszerterhelés mellett adjuk át lehet itt szó például az oldalak közös láblécéről, amely tartalmazza a kiszolgálás dátumát és időpontját. Az Apache 2.0 az SSI-t használja arra, hogy hibaüzeneteit egyedivé tegye. A módszer lényege, hogy a weboldalak tartalmába különleges feldolgozási utasítások kerülnek, amelyeket a rendszer még azelőtt kiértékel, hogy visszaadná a tartalmat az ügyfélnek. Az Apache SSItámogatásáról bővebben a apache.org/ocs/2.0/howto/ssi.html címen olvashatunk. Az SSI beállítása AddType text/html.shtml AddHandler server-parsed.shtml Az SSI működésének lelke az Apache mod_include modulja. Beállításának legegyszerűbb módja, ha - amint a példában is láthatjuk - a megfelelő kiterjesztéshez hozzárendeljük a server-parsed tartalomkezelőt. Környezeti változók beállítása SetEnv foo bar UnSetEnv foo PassEnv foo A környezeti változók olyan értékek, amelyek több modul számára egyszerre elérhetők, sőt külső folyamatok így CGI parancsfájlok és SSI dokumentumok is hozzájuk férhetnek. Használhatjuk őket a modulok közti adatcserében, valamint arra, hogy jelezzük egyes kérelmek különleges feldolgozásának igényét. A környezeti változók értékét a SetEnv utasítással állíthatjuk be. Az így meghatározott változó elérhető minden CGI parancsfájl és SSI oldal számára, naplózható, valamint elhelyezhető a fejlécekben is. Vegyük például a következőt: SetEnv foo bar Ez a kód létrehozza a foo nevű környezeti változót, és a bar értéket rendeli hozzá. Ha egy környezeti változót el szeretnénk távolítani, használjuk az UnsetEnv utasítást. 44

57 Végezetül, a PassEnv utasítással környezeti változóinkat a kiszolgálófolyamaton kívülről is elérhetővé tehetjük: PassEnv LD_LIBRARY_PATH A fenti utasítás például elérhetővé teszi az LD_LIBRARY_PATH változót minden CGI parancsfájl és SSI oldal számára. Ez a változó egyébként arról nevezetes, hogy egyes Unix rendszereken közéjük tartozik a Linux is a betölthető dinamikus könyvtárak útvonalát tárolja. Környezeti változók elérése A foo nevű környezeti változónkat az alábbi kóddal érhetjük el egy SSI oldalról: <! #echo var= foo > Értékét a %{foo}e kapcsolóval naplózhatjuk (lásd a 3. fejezetben), HTTP-fejlécekbe pedig (10. fejezet) az alábbi kóddal illeszthetjük be: RequestHeader set X-Foo %{foo}e Környezeti változók dinamikus beállítása SetEnvIf HTTP_USER_AGENT MSIE iexplorer SetEnvIf HTTP_USER_AGENT MSIE iexplorer=foo SetEnvIf HTTP_USER_AGENT MSIE Ijavascript A SetEnvInf utasítás lehetővé teszi, hogy a kérelem adatai a felhasználónév, a kért fájl vagy egy HTTPfejlécérték alapján állítsuk be a környezeti változók értékét. Az utasítás egy kérelemparamétert és egy szabályos kifejezést vár, valamint azokat a változókat, amelyek értékét meg szeretnénk változtatni, ha egyezést találunk a kifejezéssel. Példánk kódja minden olyan esetben egyezést ad, ha az ügyfél Microsoft Internet Explorer böngészőt használ, és ilyenkor létrehoz egy környezeti változót, egy tetszőleges értéket (esetünkben ez a foo) rendel hozzá, sőt akár egy negált kifejezést is alkalmazhat. Később megvizsgálhatjuk ennek a környezeti változónak a létét és értékét, majd ennek függvényében naplózhatjuk az egyes kérelmeket, vagy más tartalmat szolgáltathatunk az alkalmazott böngészőtől függően. Így például megtehetjük, hogy a Lynxhez hasonló szöveges böngészők, valamint a PDA-k és mobiltelefonok böngészői számára egyszerűsített HTML oldalakat adunk vissza. Az ügyfél felhasználói ügynökének (vagyis böngészőjének) vizsgálata olyannyira gyakori, hogy a mod_ setenvinf külön utasítást is tartogat erre a célra. A BrowserMatch segítségével a böngésző vizsgálata röviden megoldható az alábbiak szerint: BrowserMatch MSIE iexplorer=1 Megjegyzés Mind a SetEnvInf, mind a BrowserMatch esetében rendelkezésünkre áll kis- és nagybetűket nem megkülönböztető változat is (SetEnvInfNoCase és BrowserMatchNoCase), amelyek egyes esetekben egyszerűsíthetik a szabályos kifejezések használatát. 45

58 Különleges környezeti változók BrowserMatch Mozilla/2 nokeepalive Az Apache rendelkezik néhány különleges környezeti változóval, amelyek hatással vannak a viselkedésére. Használatuk többnyire hibás ügyfelek esetén indokolt. A példánkban is bemutatott nokeepalive változó kikapcsolja a kapcsolatok életben tartásának (keepalive) támogatását az Apache-ban. Mindez ugyanakkor csökkenti a kiszolgáló teljesítményét, hiszen így nem tudunk több kérelmet fogadni ugyanazon a kapcsolaton, ezért csak akkor éljünk ezzel a lehetőséggel, ha olyan ügyféllel találkozunk, amely nem képes támogatni a kapcsolatok életben tartását az elkülönítést a BrowserMatch, illetve a SetEnvinf utasítással tehetjük meg, ahogy a példában is láthatjuk. Azt, hogy miként használhatók ezek a változók az SSL- és DAV-megvalósításokkal kapcsolatos hibajelenségek elkerülésére, a 7. és 8. fejezetben mutatjuk be. Tartalomegyeztetés AddCharset UTF-8.utf8 AddLanguage en.en AddEncoding gzip.gzip.gz A HTTP protokoll lehetővé teszi, hogy egy erőforrás különböző változatait tároljuk, majd ügyfeleink képességeinek és igényeinek megfelelően szolgáltassuk a tartalmat. Ügyfelünk közölheti például, hogy képes tömörített tartalom fogadására, valamint amellett, hogy legszívesebben angolul olvasná a tartalmat, megérti a spanyol nyelvet is. Az egyeztetés alapvetően három tulajdonságra korlátozódik: Kódolás: Az erőforrás tárolásának, illetve megjelenítésének formátuma, amely gyakorta meghatározható a kiterjesztés alapján. Így például a listing.txt.gz fájl MIME típusa text/ plain, kódolása pedig gzip. A kódolás értékét a rendszer a válasz ContentEncoding: fejlécében helyezi el. Karakterkészlet: Ez a tulajdonság írja le, hogya dokumentum milyen karakterkészletet használ. Értéke a MIME típussal együtt a válasz Content-Type: fejlécébe kerül. Nyelv: Ugyanazon erőforrásból több nyelvi változatot tárolhatunk - az Apache leírása esetében például létezik index.html.en, index.html.es, index.html.de, és így tovább. A nyelvi beállítás a válasz Content-Language: fejlécébe kerül. Példánkban azt láthatjuk, hogy miként feleltessünk meg karakterkészleteket, nyelvi beállításokat és kódolásokat egyes kiterjesztéseknek. A tartalomegyeztetés beállításai Options +Multiviews AddHandler type-map.var A tartalomegyeztetés az Apache-ban kétféleképpen lehetséges: nézetekkel (multiview) és típustérképekkel (type map). 46

59 A nézetek bekapcsolásához az Options +Multiviews utasítást kell elhelyeznünk a beállításaink között - ez azonban (a legegyszerűbb webhelyek kivételével) nem ajánlott, mivel csökkenti a rendszer hatékonyságát. E módszer alkalmazásánál ugyanis a rendszer minden kérelemnél megvizsgálja a fájlt tartalmazó könyvtárat, hasonló nevű, mindössze a kiterjesztésben eltérő dokumentumok után kutatva. A talált fájlokról listát készít, a kiterjesztés alapján megállapítja a megfelelő kódolást és karakterkészletet, majd visszaadja a kért tartalmat. Jobban járunk, ha e körülményes módszer helyett típustérképet használunk, így kevesebbet kell kutakodnunk a fájlrendszer bugyraiban. A típustérképek voltaképpen maguk is fájlok, amelyek összekötik a fájlneveket a hozzajuk tartozó adatokkal (metaadatokkal). Adott típusú erőforráshoz úgy készíthetünk típustérképet, ha létrehozunk egy azonos nevű fájlt.var kiterjesztéssel, valamint hasonlóan a példában látottakhoz használatba vesszük az AddHandler utasítást. A fájlban számos bejegyzés helyet kaphat ezek mindegyike az URI: kulcsszóval kezdődik, amely után a dokumentum neve áll. Ez után következhetnek a különböző tulajdonságok, mint a Content-type:, a Content-encoding: és a Content-language:. Az alábbiakban egy jellemző térképfájl tartalmát mutatjuk be: 4.1. példa Egy típustérképfájl tartalma URI: page.html.en Content-type: text/html Content-language: en URI: page.html.fr Content-type: text/html; charset=iso Content-language: fr Tipp Soha ne feledkezzünk meg arról, hogy bármilyen tartalomegyeztetést is végezzünk, az valamilyen mértékben mindig negatív hatással lesz a webkiszolgáló teljesítményére, hiszen az eredetinél többször kell elérnünk a fájlrendszert. Karakterkészletek és nyelvi beállítások megadása DefaultLanguage en AddDefaultCharset iso LanguagePriority en es de Ha egy dokumentumhoz még nem rendeltünk karakterkészletet, ezt a példában látható módon megtehetjük az AddDefaultCharset utasítással. Ha pedig azt szeretnénk, hogy a továbbiakban ne is lehessen dokumentumainkhoz karakterkészletet rendelni, az AddDefaultCharset Off utasítással elejét vehetjük minden ilyen próbálkozásnak. Az alapértelmezett nyelvi beállítás a DefaultLanguage utasítással adható meg. Ha webhelyünk angol nyelvű, a példához hasonlóan az en kapcsolót kell használnunk. Végezetül, ha ügyfelünk nem tájékoztat nyelvi igényeiről, a LanguagePriority utasítással magunk határozhatjuk meg a nyelvek használatának sorrendjét. Példánk esetében, amennyiben találunk angol változatot a dokumentumból, a kiszolgáló ezt adja vissza az ügyfélnek. Ha nem jár sikerrel, a spanyol változatnak néz utána, ha pedig ilyen sincs, beéri egy német nyelvű dokumentummal is. Erről a témakörről bővebben a 2.0/mod/mod_negotiation.html, valamint a címeken olvashatunk. 47

60 URL-megfeleltetés magasabb szinten a mod_rewrite modullal Az Apache a mod_rewrite modullal szinte korlátlanul kiterjeszti URL-megfeleltetési lehetőségeinket, hiszen lehetővé teszi a szabályos kifejezések használatát. Használatának összetettsége miatt ebben a könyvben nem tárgyaljuk részletesen, de elő-előbukkan majd fejezeteink példáiban, illetve hivatkozásaiban. Leginkább azért teszünk említést róla, hogy tudjuk, hová forduljunk, ha elérkeztünk a Redirect, az ErrorDocument, valamint az Alias utasítások képességeinek határához. A mod_rewríte részletes leírását megtalálhatjuk a mos/mod_rewrite.html címen. A záró perjelek problémája DirectorySlash On Megesik, hogy a rendszer csak akkor talál meg egyes címeket, ha az URL végére odabiggyesztjük a / karaktert. Ennek az lehet az oka, hogy nem töltöttük be a kiszolgálóba a mod_dir modult, vagy az általa kezelt átirányítások nem működnek megfelelően a ServerName utasításban megadott értékkel (lásd a 2. fejezetben). Ha olyan URL-eket szeretnénk elérni, amelyek könyvtáraknak felelnek meg, fontos elhelyeznünk a címek végén a / karaktert, hogy elérjük a könyvtár tartalmát, vagyis hozzájussunk a megfelelő indexfájlhoz vagy könyvtárindexhez. Ennek a karakternek az elhagyása gyakori hiba, de a mod_dir modul résen van, és ha ilyesmit észlel, azonnal elvégzi a megfelelő átirányítást. Így például, ha kiszolgálónkon használjuk a mod_dir modult, és dokumentumkönyvtárunknak létezik egy foo nevű alkönyvtára, a rendszer a címre érkező minden kérelmet átirányít a címre. A mod_dir használata esetén ez egyaránt alapértelmezett viselkedés az Apache 1.3-as és 2.0-s változatában, de az Apache 2 újdonsága, hogy ez a DirectorySlash utasítással ki is kapcsolható: DirectorySlash Off A gépelési hibák kijavítása CheckSpelling on A mod_speling modul igen hasznos segédeszköz az Apache-ban, hiszen felismeri az elgépelt URL-eket, és a megfelelő dokumentumhoz irányítja az eltévedt felhasználót. Képességei a kis- és nagybetűk eltérésének korrigálásáig, valamint egy betű kijavításáig terjednek ennél azonban nem is kell több, hiszen ha a felhasználó elgépeli a böngészőbe beírt címet, ennél jobban többnyire nem téved. 48

61 Ha felhasználónk például a file.html nevű fájl után érdeklődik, és az nincs jelen a kiszolgálón, a mod_ speling utánanéz a hasonló nevű dokumentumoknak - amilyen például a FILE.HTML vagy a file. htm -, és ha talál valamit, azt adja vissza. Ez a keresgélés persze hatással van a kiszolgáló sebességére, de ez még mindig jobb, mint ha kezelnünk kellene a nem létező hivatkozások miatt fellépő problémákat. A gépelési hibák ellenőrzését a példában is látható módon a CheckSpelling on utasítással kapcsolhatjuk be. Megjegyzés Ha a modul több olyan dokumentumot is talál, amelyeknek az elgépelése a kérelmezett nevet eredményezhette, ezek listáját adja vissza. Fontos, hogy gondoljunk az itt felmerülő biztonsági kockázatokra, hiszen előfordulhat, hogy egyes fájlokat jobb szeretnénk elrejteni a felhasználók elől. Gondok a kis- és nagybetűkkel NoCase on A Windows nem tesz különbséget a kis- és nagybetűk között, a Unix rendszerek azonban igen ez akkor jelenthet gondot, ha webhelyünk korábban Windowson üzemelt, majd később egy Unix gépre helyezzük át. Ilyenkor hirtelen azt vesszük észre, hogy a korábban minden további nélkül elérhető URL-ek, mint a most Document Not Found hibaüzenetet adnak, ugyanis az icon.png Unix rendszereken különbözik az icon.png fájltól. A gondokat persze megoldja, ha minden egyes hivatkozást átírunk, és használatba vehetjük a mod_speling modult is. Létezik azonban egy kifejezetten erre a célra készített modul is a mod_nocase, amely voltaképpen a mod_speling leszármazottja. Működése abban áll, hogy a GET kérelmekben kiküszöböli a kis- és nagybetűk megkülönböztetését. Először pontos egyezést keres a megadott URL-lel, ha azonban így nem jár sikerrel, megpróbálkozik a kis- és nagybetűk különbözőségének figyelmen kívül hagyásával. Ha így több egyezés is létezne, automatikusan az első találatot adja vissza. A mod_nocase használatához be kell töltenünk a modult a kiszolgálóba, valamint ahogy a példában is láthatjuk el kell helyeznünk a NoCase utasítást az Apache beállítófájljában. A mod_nocase modult letölthetjük a htm címről. Ne feledjük, hogy a mod_speling és a mod_nocase bekapcsolása egyaránt hatással van a kiszolgáló teljesítményére. Rendrakás a Tidy segítségével AddOutputFilterByType TIDY text/html application/xhtml+xml TidyOption char-encoding utf8 Akár magunk készítettük HTML oldalainkat, akár dinamikusan állt össze a tartalmuk, ha kódolási hibákat tartalmaznak, könnyen előfordulhat, hogy nem minden böngészőben kapjuk meg a várt eredményt. Ennek elkerülésére érdemes használatba vennünk a Tidy-t (letölthető a címről), amely ellenőrzi HTML és XML fájljainkat, kijavítja a gyakrabban előforduló hibákat, és a szabványoknak megfelelő végeredményt ad. 49

62 Statikus fájlok esetén ezt a programocskát a parancssorból használhatjuk, de a mod_tidy modul segítségével az Apache 2-ben már a dinamikusan előállított tartalmat is átvizsgálhatjuk. A példában azt mutatjuk be, hogy miként rendeljük hozzá a Tidy szűrőt XML és HTML fájljainkhoz a SetFilter utasítással, és hogyan végezzük el a program beállítását a TidyOption segítségével. Az Apache szűrőit és beállításaikat a 11. fejezetben tárgyaljuk bővebben. A mod_tidy letölthető a következő címről: Ide köthető az Apache 2 egy másik modulja, a mod_validator is, amelyet az alábbi címen érhetünk el: 50

63 5 Virtuális kiszolgálók Ebben a fejezetben azt mutatjuk be, hogy miként kezelhetünk egyszerre több webhelyet az Apache kiszolgáló egyetlen példányával. Szó esik az IP cím és a gépnév alapú virtuális kiszolgálókról, és olyan módszereket is bemutatunk, amelyekkel több felhasználó számára nyújthatunk webszolgáltatásokat, így megismerkedünk az alapkönyvtárak kezelésével, valamint az egyes könyvtárakra érvényes beállítófájlokkal. A virtuális kiszolgálókról Napjaink legtöbb webkiszolgálóján lehetőségünk nyílik virtuális kiszolgálók üzemeltetésére, így egyetlen kiszolgálóval több webhelyet is kiszolgálhatunk azonos vagy akár eltérő tartományokban. Mindez lehetővé teszi rendszerünk központosított felügyeletét, és az erőforrások felhasználása is hatékonyabbá válik. A webtárhely-szolgáltatók ily módon képesek egyetlen webkiszolgálóval több száz ügyfelet ellátni, ahelyett, hogy kiszolgálók sokaságát kellene üzembe állítaniuk. Az IP alapú virtuális kiszolgálókról <VirtualHost :80> (...) </VirtualHost> A virtuális kiszolgálók használatának legegyszerűbb módszere azon az IP cím-port kombináción alapul, amelyen keresztül az ügyfél eléri a kiszolgálót. Használatára a beállítófájl <VirtualHost> szakaszai adnak lehetőséget, amelyek utasításai a nyitó címkében megadott IP címre (és esetleg portra) érkező kérelmek esetén érvényesülnek. Mindehhez persze az is kell, hogy az Apache kiszolgálóval tudassuk: figyelnie kell ezeket az IP címeket. Megjegyzés Ha nem szabványos portokat fi gyelünk. fontos, hogy mindegyikükhöz jelen legyen a megfelelő Listen utasítás. Attól ugyanis, hogy felsoroljuk a portokat a <VirtualHost> szakaszokban, az Apache még nem fogja azokat fi gyelni. Az IP alapú virtuális kiszolgálók hátránya, hogy minden virtuális kiszolgálóhoz külön IP címet kell megadnunk. Az IP alapú virtuális kiszolgálók beállítása Az 5.1. példában három virtuális kiszolgáló meghatározását láthatjuk, amelyek a következő webhelyek számára szolgáltatnak tartalmat: a egy fejlesztői változata, valamint a A tárolókon belül látható ServerName utasítások az önhivatkozó URL-ek előállításánál kapnak szerepet. 51

64 A DocumentRoot utasításokkal különböző tárterületeket határozunk meg a webhelyek tartalma számára, sőt arra is lehetőségünk van, hogy az egyes virtuális kiszolgálókhoz érkező kérelmeket, illetve a fellépő hibákat külön fájlokban naplózzuk. Ehhez csak a megfelelő naplózó utasításokat mint a TransferLog vagy az ErrorLog - kell a tárolókban elhelyeznünk (lásd a 3. fejezetet). A <VirtualHost> tárolók nyitó címkéjében megadott címek és portok nincsenek hatással arra, hogy az Apache mely címeket és portokat figyeli, ezért ügyelnünk kell a megfelelő Listen utasítások használatára. Ha nem határoztunk meg portot a <VirtualHost> meghatározásában, az Apache a legutóbbi utasításban megadott portot veszi használatba. Használhatjuk a * karaktert is, amellyel az Apache által figyelt összes port forgalmát követhetjük ezt tesszük példánkban az example.net esetében példa IP alapú virtuális kiszolgálók beállításai Listen 8080 Listen 80 <VirtualHost > ServerName DocumentRoot /usr/local/apache/sites/example.com </VirtualHost> <VirtualHost :8080> ServerName DocumentRoot /usr/local/apache/sites/staging </VirtualHost> <VirtualHost :*> ServerName DocumentRoot /usr/local/apache/sites/example.net </VirtualHost> A név alapú virtuális kiszolgálókról Amint az előzőekben láthattuk, az IP alapú virtuális kiszolgálók használatához minden webhely esetében különböző IP címre van szükség. Ez olyankor okoz gondokat, ha sok webhelynek szeretnénk teret adni, de nem tudunk ennyi IP címet megszerezni vagy megfizetni. Jó példa erre a helyzetre, ha saját kiszolgálónkról egy DSL vonal végén több személyes weboldalt szeretnénk üzemeltetni. A név alapú virtuális kiszolgálók használatánál az ismertebb böngészők (sőt szinte az összes új változat) átad egy Host: fejlécet a HTTP-kérelmekben. Ez a viselkedés követelmény a HTTP/1.1 protokollnál, de jelen van a HTTP/1.0 legtöbb megvalósításában is. Így a kérelem adataira támaszkodva dönthetünk a felhasználónak adott válaszról, nem pedig a kapcsolatból kiindulva. Ez viszont lehetővé teszi, hogy egyszerre több virtuális kiszolgáló működjön ugyanazzal az IP cím-port kombinációval. A név alapú virtuális kiszolgálók beállítása A névvel ellátott virtuális kiszolgálók beállítása hasonló az IP címmel meghatározott társaikéhoz ezt mutatja az 5.2. példa is. Itt két virtuális kiszolgáló szerepel, amelyek megosztoznak a IP címen. 52

65 Az Apache a Host: fejléc alapján dönt arról, hogy hová irányítsa a HTTP-kérelmeket. A kiszolgáló a kapott nevet összehasonlítja a ServerName utasítás értékével, no meg esetleg a ServerAlias utasítással megadott másodnevekkel példa Név alapú virtuális kiszolgálók beállítása Listen 80 NameVirtualHost <VirtualHost > Serve rname ServerAlias example.com web.example.com DocumentRoot /usr/local/apache/sites/example.com </VirtualHost> <VirtualHost > ServerName DocumentRoot /usr/local/apache/sites/example.net </VirtualHost> A NameVirtualHost utasítással tudathatjuk az Apache kiszolgálóval, hogy adott IP címet név alapú virtuális kiszolgálók kezelésére szeretnénk használni. Ha minden elérhető IP címmel ezt szeretnénk tenni, az alábbit írhatjuk: NameVirtualHost * Természetesen ahhoz, hogy a az example.com, valamint a web.example.com egyaránt a IP címet adja, DNS kiszolgálóinkat is megfelelően kell beállítanunk. Mi történik, ha a kérelem nem felel meg egyetlen virtuális kiszolgálónak sem? Ha így áll a helyzet, IP alapú virtuális kiszolgálók használata esetén a fő kiszolgáló válaszol a kérelemre, név alapú virtuális kiszolgálók esetén pedig az első ilyen kiszolgáló adja a választ. A következőkben megtanulhatjuk, hogyan állítsunk össze egy olyan virtuális kiszolgálót, amely összeszedi ezeket a lepattanó kérelmeket. Alapértelmezett név alapú virtuális kiszolgáló beállítása NameVirtualHost * <VirtualHost *>... </VirtualHoat> Amint azt az előzőekben említettük, azon tartományok esetében, amelyek nem tartoznak egyetlen virtuális kiszolgálóhoz sem, a beállítófájl első virtuális kiszolgálója válaszol a kérelmekre. Ha több webhelyet is kiszolgálunk, hasznos lehet egy olyan virtuális kiszolgálót üzembe helyezni, amely közli az elérhető 53

66 webhelyek listáját, vagy tájékoztat arról, hogy miért nem ismerte fel a megadott webhelyet a kiszolgáló. Mindehhez csak annyit kell tennünk, hogy elhelyezünk egy a feladat elvégzésére alkalmas fájlt (az 5.3. példában ez a default.html) a dokumentumkönyvtárban, és az AliasMatch utasítással átirányítjuk hozzá a kérelmeket. Hasonló eredményt érhetünk el akkor is, ha az ErrorDocument utasítást használjuk: ErrorDocument 404 /default.html Sőt a RedirectMatch utasítással a felhasználókat közvetlenül is átirányíthatjuk egy másik webhelyre: RedirectMatch /* példa Alapértelmezett név alapú virtuális kiszlgáló beállítása NameVirtualHost * # Az alábbi szakasz a többi virtuális kiszolgáló # szakasza fölé kell helyeznünk <VirtualHost *> ServerName default.example.com DocumentRoot /usr/local/apache/sites/default AliasMatch /* /default.html </VirtualHost> Alapértelmezett IP alapú virtuális kiszolgáló beállítása <VirtualHost _default_ > ServerName default.example.com DocumentRoot /usr/local/apache/sites/default </VirtualHost> A _default_ paraméterrel egy olyan virtuális kiszolgálót határozhatunk meg, amely fogadja a más virtuális kiszolgálók által nem kezelt cím port kombinációkra érkező kérelmeket. A _default_ kulcsszó mellett egy portszámot is megadhatunk (lásd a következő példában, amelyet az Apache alapértelmezett mod_ssl-beállításaiból vettünk). Az utasítás így egy olyan virtuális kiszolgálót határoz meg, amely a megadott porton figyel minden olyan kérelmet, amely a más virtuális kiszolgálók által le nem fedett címre érkezik: <VirtualHost _default_:443> SSLEngine on ServerName secure.example.com:443 DocumentRoot /usr/local/apache/sites/default... </VirtualHost> A név és IP cím alapú virtuális kiszolgálók együttes használata Az IP cím és név alapú virtuális kiszolgálók egymás mellett is használhatók, amint az az 5.4. példában is látható. A NameVirtualHost * utasítás helyett azonban külön NameVirtualHost utasításokat kell írnunk minden olyan IP címhez, amelyhez név alapú virtuális kiszolgálókat rendelünk. Példánkban két ilyet is bemutatunk az egyik a , a másik pedig a IP címhez tartozik. 54

67 5.4. példa A név és IP cím alapú virtuális kiszolgálók együttes használata NameVirtualHost <VirtualHost > ServerName DocumentRoot /usr/local/apache/sites/example.com </VirtualHost> <VirtualHost > ServerName staging.example.com DocumentRoot /usr/local/apache/sites/staging </VirtualHost> <VirtualHost > ServerName DocumentRoot /usr/local/apache/sites/example.net </VirtualHost> Hibakeresés a virtuális kiszolgálók beállításaiban Amennyiben a httpd futtatható fájlt az -S kapcsolóval indítjuk el (lásd az 5.5. példát), az Apache elemzi a beállítófájlt, majd a virtuális kiszolgálók adatainak vizsgálata után tájékoztatást ad mindegyikükről a megfelelő értékekkel együtt. Ez a lehetőség igen jól jöhet, amikor bonyolultabb rendszereken végzünk hibakeresést példa A virtuális kiszolgálók beállításainak vizsgálata # httpd -S VirtualHost configuration: wildcard NameVirtualHosts and _default_ servers: * : * is a NameVirtualHost default server example.com (/usr/local/www/conf/httpd.conf:1055) port * namevhost example.com (/usr/local/www/conf/httpd.conf:1055) port * namevhost example.org (/usr/local/www/conf/httpd.conf:1082) port * namevhost example.net (/usr/local/www/conf/httpd.conf:1094) Syntax Ok Az SSL és a név alapú virtuális kiszolgálók Ha feltennénk a kérdést Használhatunk-e SSL-t név alapú kiszolgálókkal?, a rövid válasz egyszerűen a Nem lenne, hiszen napjaink ismertebb böngészői nem támogatják ezt a lehetőséget. Bővebben minderről a 7. fejezetben olvashatunk. 55

68 A virtuális kiszolgálók kezelésének további módjai UseCanonicalName Off VirtualDocumentRoot /usr/local/apache/vhosts/%0 VirtualScriptAlias \ /usr/local/apache/vhosts/%0/cgi-bin Ha nagyon sok virtuális kiszolgálót üzemeltetünk, érdemes lehet más megközelítést választanunk a kezelésükre. Különösen igaz ez az internetszolgáltatókra, akiknek több ezer előfizető számára kellene beírniuk az egyes virtuális kiszolgálók adatait a beállítófájlba, és minden változtatás után újra kellene indítaniuk a kiszolgálót. A mod_virtualhost_alias modul azonban lehetővé teszi, hogy dinamikusan rendeljünk különböző dokumentumkönyvtárakat az egyes virtuális kiszolgálókhoz. Vagyis, a rendszer a kérelmekhez adott útvonalat rendel a fájlrendszerben, közvetlenül a kérelem adatai (amilyen az IP cím vagy a gépnév) alapján. Példánk a megadott gépnévhez egy olyan útvonalat rendel, amelyben megtalálható ez a bizonyos gépnév (a kódban a %0 jelöli). Hasonlóan, a VirtualScriptAlias utasítás lehetővé teszi, hogy CGI parancsfájlokat futtassunk, amelyek útvonalát a kérelemben megadott gépnévből állítjuk elő. Ha felhasználónk a /manual/index.html fájlt kérelmezi a kiszolgálón, az utasítás átirányítja a / usr/local/apache/vhosts/ címre. Az IP címekkel is elvégezhető ez a megfeleltetés - ilyenkor a VirtualDocumentRootIP, illetve a VirtualScriptAliasIP utasításokat használhatjuk. A kérelmeket megfeleltethetjük a gépnév egyes részletei, a kapott IP cím, vagy éppen a kérelem portja alapján. Ehhez mindössze a % jel utáni karakterekkel kell bűvészkednünk: a %p a port számát takarja, a %1 a tartománynév első részét, a %2 a második részét, és így tovább. Egyéb modulok a virtuális kiszolgálók kezelésére Ha sok virtuális kiszolgálót szeretnénk kezelni, kézenfekvő megoldás a mod_vhost_alias modul használata, amely a népszerűségét jelentős részben annak köszönheti, hogy minden további nélkül megkapjuk az Apache telepítőcsomagjával. Mindazonáltal választási lehetőségeink ennél bővebbek léteznek erre a célra más modulok is: mod_vhost_ldap: Apache 2-modul, amely lehetővé teszi, hogy a virtuális kiszolgálók adatait egy LDAP könyvtárban tároljuk. A modul letölthető a modvhostldap/ címről. mod_vhost_dbi: Ezzel a modullal virtuális kiszolgálóink beállításait egy SQL adatbázisban tárolhatjuk, ami jelentős rugalmasságot nyújt a kiszolgáló számára. A modul az Apache 2 rendszerben fut, és a /mod_vhost_dbi/ címről tölthető le. A 11. fejezetben szót ejtünk az MPM-ekről (Multi-Processing Modulé), amelyek köztük a mod_perchild lehetővé teszik, hogy az egyes virtuális kiszolgálókat különböző felhasználói azonosítókkal futtassuk. 56

69 Könyvtárankénti beállítófájlok AcceasFilename.htaccess Ha több webhelynek biztosítunk tárterületet, gondolnunk kell arra, hogy az egyes ügyfelek különböző beállításokat igényelnek ha a számuk elegendően nagy, érdemes lehet könyvtáranként más-más beállítófájlt használni. Ezeket gyakran htaccess fájloknak is nevezik, mivel a feladatuk leggyakrabban a hozzáférés-szabályozás (access control). Ha bekapcsoljuk ezt a lehetőséget, az Apache a kért fájlhoz vezető útvonal minden könyvtárának beállítófájlját alkalmazza, így ha kiszolgálónktól a /usr/local/apache2/ htdocs/index.html fájlt kérelmezik, a kiszolgáló figyelembe veszi a /, a /usr/, a /usr/local/, a /usr/local/apache2/, valamint a /usr/local/apache2/htdocs/ könyvtárak beállítófájljait is, méghozzá ebben a sorrendben. A kiszolgáló, ha ráakad ezekre a beállítófájlokra, feldolgozza azokat, és egyesíti a tartalmukat az indításkor betöltött httpd.conf fájl beállításaival. Ez jelentős könnyebbséget ad a rendszergazdának, hiszen így a felhasználókra hagyhatja saját beállításaik meghatározását. Ráadásul a fájlok elemzése dinamikusan történik, vagyis nem kell minden változás után újraindítani a kiszolgálót. Nem szabad azonban elhallgatnunk a negatívumokat sem. A beállítófájlok felkutatásához a kiszolgálónak minden kérelemnél komoly keresést kell végrehajtania a lemezen, még akkor is, ha azok egyáltalán nincsenek jelen. Némi segítséget jelenthet az AccessFilename utasítás, amellyel megadhatjuk a könyvtárankénti beállítófájlok lehetséges neveinek listáját. A könyvtárankénti beállítófájlok hatókörének szabályozása AllowOverride Indexes Limit AuthConfig Az AllowOverride utasítással szabályozhatjuk, hogy milyen beállítási utasítások szerepelhessenek a könyvtárankénti beállítófájlokban. Így például lehetővé tehetjük a felhasználóknak, hogy módosítsák a könyv tárindexelési utasításokat, miközben távol tartjuk őket a hitelesítés beállításaitól. A lehetséges beállítások a következők: Authconfig: Hitelesítési utasítások. FileInfo: A dokumentumtípusokat szabályozó utasítások. Indexes: A könyvtárindexelést szabályozó utasítások. Limit: A kiszolgálók elérését szabályozó utasítások. Options: Az egyes könyvtárbeállításokat szabályozó utasítások. All: Bármely, a fenti csoportok valamelyikébe tartozó utasítás használható. None: Nem alkalmazhatunk könyvtárankénti beállítófájlokat ebben a könyvtárfában. 57

70 A könyvtárankénti beállítófájlok használatának kikapcsolása <Directory /> AllowOverríde None </Directory> Ha egyáltalán nincs szükségünk könyvtárankénti beállítófájlokra, a fenti kóddal kapcsolhatjuk ki a használatukat. Ezzel növeljük a kiszolgáló teljesítményét és biztonságát, de elesünk attól a kényelemtől és rugalmasságtól, amit ezek a beállítófájlok nyújtanak. 58

71 6 Biztonság és hozzáférésszabályozás A hozzáférés szabályozása számos webhelyen alapkövetelménynek számít. Segítségével elérhetjük, hogy a webhely bizonyos területeit csak meghatározott IP címekről érkező felhasználók látogathassák, illetve a tartalom megtekintéséhez érvényes azonosítót és jelszót kelljen megadniuk. A hozzáférés-szabályozást különböző szinteken valósíthatjuk meg az operációs rendszer szintjén csomagszűrő szabályokat alkalmazhatunk, míg az alkalmazások szintjén űrlapokkal, munkamenetekkel és sütikkel valósíthatjuk meg elképzeléseinket. Fejezetünkben az Apache telepítőcsomagjához tartozó modulok hozzáférés-szabályozási, hitelesítési és engedélyezési lehetőségeivel foglalkozunk. Emellett bemutatjuk, hogy miként befolyásolják az egyes beállítások a kiszolgáló biztonságát, és milyen lépéseket tehetünk azért, hogy ez a biztonság növekedjen. Az Apache számos modult biztosít a tartalom elérésének szabályozására. A legfontosabbak közülük a mod_access, amely a kérelem kiinduló IP címe és más adatai alapján szabályozza a hozzáférést, valamint a mod_auth, amely azonosító és jelszó alapján hitelesíti a felhasználókat. Rajtuk kívül rengeteg hasonló célú modul létezik néhányukról említést is teszünk a fejezetben -, de mivel viszonylag ritkán használatosak, a részletes tárgyalásuktól eltekintünk. Különbségek az Apache változatai között Az Apache hitelesítési és engedélyezési környezete a 2.2 változatban komoly változásokon ment keresztül. Jóllehet a módosítások többsége csak a forráskód szintjén érvényesült, voltak a felhasználók számára érzékelhető változások is. A tisztánlátás kedvéért (no meg annak tudatában, hogy az alapelvek nem változtak) fejezetünkben elsősorban az Apache 1.3-as és 2.0-s változataival foglalkozunk. A 2.2 változat újdonságairól az Apache 2.2 című részben olvashatunk. Egyszerű és kivonatos hitelesítés Webhelyünk felhasználóit többnyire azért hitelesítjük, hogy nyomon kövessük a tevékenységüket, illetve meghatározzuk, hogy milyen tartalmat érhetnek el. A HTTP szabvány két hitelesítési módszert kínál: az egyszerű hitelesítést, valamint a kivonatos hitelesítést. Alkalmazásuk mindkét esetben az alábbi lépésekkel történik: 1. Az ügyfél valamilyen korlátozott elérésű tartalomhoz próbál hozzáférni a webhelyen. 2. Az Apache utánanéz, hogy az ügyfél korábban megadott-e azonosítót és jelszót. Ha nem, a HTTP 401-es állapotkóddal tér vissza, ami azt jelzi, hogy szükség van a felhasználó hitelesítésére. 3. Az ügyfél fogadja a választ, és kéri a felhasználótól az azonosítót és a jelszót (többnyire egy előugró ablakban). 4. Az ügyfél ismét megpróbálja elérni a weboldalt, ezúttal a HTTP-kérelem részeként átadva az új azonosítót és jelszót. Az ügyfél megjegyzi ezt az azonosítót és jelszót, így a felhasználónak a későbbiekben nem kell minden kérelemnél újra és újra megadnia ezeket az adatokat. 5. Az Apache ellenőrzi az azonosító és a jelszó érvényességét, és megadja vagy megtagadja a hozzáférést a felhasználó kiléte és más hozzáférési szabályok figyelembe vételével. 59

72 Egyszerű hitelesítés esetén a felhasználónév és a jelszó szövegként utazik a HTTP-kérelmek fejléceiben. Ez persze komoly biztonsági kockázatot jelent, hiszen egy támadó könnyűszerrel lehallgathatja a böngésző és a kiszolgáló közti adatforgalmat, és így megszerezheti az azonosítót és a jelszót. A kivonatos hitelesítés már sokkal jobb megoldás, hiszen itt a jelszó helyett egy kivonat szerepel a kérelemben. A kivonatoló algoritmus egy matematikai művelet, amely szöveget vesz alapul, és szöveget is ad vissza ez az eredmény a kivonat, amely egyértelműen azonosítja az eredeti szöveget. Ha a szöveg változik, megváltozik a kivonat is. A kivonat számos paraméter alapján áll össze, így szerepel benne a felhasználónév, a jelszó, valamint a kérelmezés módszere. Az eljárás lényege, hogy ezt a kivonatot a kiszolgáló is képes előállítani, így anélkül is ellenőrizni tudja az ügyfél hitelességét, hogy annak át kellene küldenie magát a jelszót. Sajnálatos módon, bár a szabvány már jó ideje él a köztudatban, nem minden böngésző támogatja a kivonatos hitelesítést, vagy ha igen, akkor sem mindig a szabványnak megfelelően. Mindenesetre, akár egyszerű, akár kivonatos hitelesítésről van szó, maguk a kérelmezett adatok mindenféle védelem nélkül mennek át a hálózaton. Ha valóban biztonságban szeretnénk tudni az adatainkat, használjuk az SSL-t, amelyről a 7. fejezetben szólunk bővebben. Az Apache hozzáférés-szabályozása <Directory /usr/local/apache2/htdocs/private> Order Allow, Deny Allow from example.com Deny from guest-terminal.example.com </Directory> A példa azt mutatja be, miként használhatjuk a mod_access IP címeken, illetve gépneveken alapuló hozzáférés-szabályozását. Az Allow utasítások határozzák meg, mely IP címek, hálózatok és gépek férhetnek hozzá a tartalomhoz, míg a Deny utasítások azokat a helyeket mutatják, ahonnan tiltott az elérés. Végezetül, az Order utasítás azt határozza, meg, hogy milyen sorrendben értékelje ki a rendszer az Allow és a Deny utasításokat. Példánkban az Order Allow, Deny sor szerepel, ami azt jelenti, hogy a kiszolgáló előbb az Allow, majd ez után a Deny utasításokat értékeli ki. Ez a sorrend igen fontos, és jelen esetben azt mutatja, hogy a Deny felülbírálhatja az Allow beállításait. Az Order Allow, Deny sor ráadásul azt is biztosítja, hogy ha az ügyfél egyetlen Allow utasításnak sem felel meg, a rendszer alapértelmezés szerint megtagadja tőle a hozzáférést. Ne aggódjunk, ha a hozzáférésszabályozás az első pillanatban zavarosnak tűnik - ha megértjük a utasítások kiértékelését, minden egyszerűvé válik. Az Apache hitelesítési és engedélyezési beállításai <Directory /usr/local/apache2/htdocs/private> AuthType Basic AuthName Password Protected Area AuthUserFile /usr/local/apache2/conf/htusers Require user admin </Directory> A fenti példa egy rövid kódrészlet, amely egy könyvtárnak biztosít jelszavas védelmet. Az AuthType határozza meg a hitelesítés típusát: esetünkben egyszerű HTTP-hitelesítésről van szó. Az AuthName egy üzenetet rendel a jelszóval védett területhez ezt a szöveget látja majd a felhasználó (többnyire egy elő- 60

73 ugró ablakban), amikor a böngésző a jelszót kéri tőle. Az AuthUserFile a felhasználókat tartalmazó adatbázist adja meg, a Require pedig azoknak a felhasználóknak a körét határozza meg, akik egyáltalán hozzáférhetnek a kérdéses tartalomhoz. A következőkben részletesebben elemezzük a példát, emellett pedig megtanuljuk, miként hozhatjuk létre és kezelhetjük a felhasználók adatbázisát, és hogyan használhatjuk egyszerre az IP cím és felhasználó alapú hozzáférés-szabályozást (lásd A hozzáférés-szabályozási módszerek együttes használata című részt). Felhasználó-adatbázis létrehozása htpasswd -c file userid A felhasználó-adatbázis (vagy más néven jelszófájl) elkészítéséhez a htpasswd segédprogramot használhatjuk, amelyhez hozzájutunk az Apache kiszolgálóval. Példánk kódja Unix rendszeren elkészít egy új jelszófájlt, és el is helyez benne egy felhasználót. Windowson a következőt írhatjuk: htpasswd.exe -cm fájl azonosító Ha a jelszófájl már létezik, és új felhasználót szeretnénk adni hozzá, Unixon egyszerűen ezt a parancsot használhatjuk: htpasswd fájl azonosító Windowson pedig az alábbit: htpasswd.exe -m fájl azonosító A rendszer ekkor egy jelszót kér, amely bekerül a felhasználók adatbázisába. Fontos, hogy a jelszófájlt olyan könyvtárba helyezzük, amely nem érhető el a Webről. Figyeljünk oda arra is, hogy ne használjuk a -c kapcsolót, amikor már létező fájlhoz adunk új felhasználókat, ugyanis ezzel törölnénk az eredeti tartalmat. Utolsó példaként létrehozunk egy htusers nevű jelszófájlt, és elhelyezünk benne egy admin nevű felhasználót: htpasswd -c /usr/local/apache2/conf/htusers admin Felhasználók és csoportok hitelesítése a Require utasítással <Directory /usr/local/apache2/htdocs/private> AuthType Basic AuthName Password Protected Area AuthUserFile /usr/local/apache2/conf/htusers AuthGroupFile /usr/local/apache2/conf/groups Require roup administrators </Directory> 61

74 Ha azt szeretnénk, hogy egy sikeres belépést követően bármely, az adatbázisban megtalálható érvényes felhasználó hozzáférjen a tartalomhoz, az alábbi utasítást használhatjuk: Require valid-user Ha felhasználók egy meghatározott csoportját szeretnénk hitelesíteni, egyszerűen felsorolhatjuk őket a Require paramétereiként: Require user azonosító1 azonosító2 Ha azonban nagyobb csoportról van szó, kényelmesebb megoldást nyújthat az AuthGroupFile utasítás. Ez egy fájlt vesz alapul, amelyben a következő alakban sorolhatjuk fel a felhasználókat: csoportnév: azonosító1, azonosító2, azonosító3 [..] Lássunk egy példát, hogy is nézhet ki ennek a fájlnak a tartalma a való életben: administrators: admin boss users: admin boss user1 user2 A cím után bemutatott kóddal azoknak a felhasználóknak tesszük lehetővé a tartalom elérését, akik amellett, hogy sikeresen bejelentkeznek, az administrators csoportba tartoznak. A fenti példában ez az admin és a boss felhasználót jelenti. Jelentős számú felhasználó kezelése <DirectoryMatch /home/*/public_html> AuthType Basic AuthName Priváte Area AuthDBMUserFile /usr/local/apache2/conf/dbmusers AuthDBMGroupFile /usr/local/apache2/conf/dbmusers AuthDBMAuthoritative on Require group student faculty </DirectoryMatch> A mod_auth_dbm modul viselkedése megfelel a mod_auth-nál látottaknak, de a felhasználói adatokat egy adatbázisfájlban tárolja, ami jelentősen felgyorsítja a keresést, ha a felhasználók száma nagy. Egyebek mellett rendelkezésünkre áll az AuthDBMAuthoritative, az AuthDBMUserFile, valamint az AuthDBMGroupFile utasítás, amelyek használata és viselkedése megegyezik a mod_auth modulban található egyszerűbb társaikéval. A felhasználókat, illetve csoportokat tartalmazó fájlok kezeléséhez a htdbm, valamint a dbmmanage segédprogramokat használhatjuk, amelyek szintén mod_auth-beli társaikhoz hasonlóan viselkednek. Fontos megjegyeznünk, hogy amint az a fenti példában is látható a felhasználók és a csoportok adatai egyazon adatbázisban is tárolhatók. 62

75 A hozzáférés meghatározott IP címekre korlátozása <Directory /usr/local/apache2/htdocs/private> Order Allow, Deny Allow from </Directory> Előfordul, hogy bizonyos tartalmak (például egy cég belső webhelye) elérését érdemes meghatározott IPcímtartományra korlátoznunk például azokra a címekre, amelyek a belső hálózaton találhatók. Példánkban a /usr/local/apache2/htdocs/private könyvtár és alkönyvtárai elérését csak azoknak az ügyfeleknek tesszük lehetővé, akik a IP-címtartományba esnek. A Directory tárolónak átadott paraméternek pontosan meg kell egyeznie azzal a fájlrendszerbeli útvonallal, amelyen az Apache eléri a fájlokat. Az Order Allow, Deny sorral alapértelmezés szerint letiltjuk a tartalom elérését, és csak azok a felhasználók juthatnak be, akik megfelelnek az Allow utasítás paramétereinek. Itt megadhatunk több IP címet vagy akár címtartományt is a részletekért olvassuk el a utasítás leírását. Ugyanezt az eredményt érjük el, ha a fenti kód magját a /usr/local/apache2/htdocs/private könyvtár.htaccess fájljában alkalmazzuk: Order Allow, Deny Allow from A hozzáférés tiltása egyes IP címekről <Directory /usr/local/apache2/htdocs/private> Order Deny,Allow Deny from </Directory> Adódhat olyan helyzet is, amikor általában lehetővé szeretnénk tenni a tartalom elérését, de bizonyos IP címeket vagy címtartományokat le szeretnénk tiltani. Ezzel meggátolhatjuk egyes gépek behatolási kísérleteit, vagy megakadályozhatjuk a webpókok tevékenykedését, ha gondok adódnak a sávszélesség felhasználásával. Példánk kódja a és a IP címek kivételével mindenkinek lehetővé teszi a /usr/ local/apache2/htdocs/private könyvtár és alkönyvtárai elérését. Az Allow és a Deny utasításokkal környezeti változók figyelembe vételével is korlátozhatjuk a tartalom elérését erről fejezetünk későbbi részében, A hozzáférés korlátozása a böngésző alapján címnél olvashatunk. A 9. fejezetben további lehetőségeket ismerhetünk meg a nemkívánatos ügyfelek hozzáférésének korlátozására, illetve lassítására. 63

76 A hozzáférés-szabályozási módszerek együttes használata <Location /restricted> Allow from / AuthType Basic AuthUserFile /usr/local/apache2/conf/htusers AuthName Restricted Resource AuthAuthoritative on Require valid-user Satisfy any </Location> A Satisfy utasítás lehetőséget ad arra, hogy együttesen használjuk a különböző hozzáférés-szabályozó módszereket. A fenti beállítással például azt követeljük meg a felhasználótól, hogy egy belső, hitelesített címmel rendelkezzen, ellenkező esetben pedig adja meg a felhasználónevét és a jelszavát. Ha egyszerre szeretnénk megkövetelni a belső IP címet, valamint a felhasználónevet és a jelszót, a Satisfy all utasítást kell használnunk. Az Elérés megtagadva oldal testreszabása Ha egy kérelemre az Elérés megtagadva (access denied) válasz érkezik a kiszolgálótól, a felhasználó egy rögzített, a kiszolgáló által előállított hibaüzenetet kap. Szerencsére az ErrorDocument utasítással ez az üzenet háromféleképpen is testreszabható: Megjeleníthetünk egy saját üzenetet az alábbi módon (az Apache 2-ben): ErrorDocument 403 Nem rendelkezik jogosultsággal a kért fájl eléréséhez Illetve így (az Apache 1.3-ban - vegyük észre, hogy itt csak a karakterlánc elején áll idézőjel): ErrorDocument 403 Nem rendelkezik jogosultsággal a kért fájl eléréséhez Átirányíthatjuk a kérelmet egy helyi URL-re is, ahol saját üzenetet írhatunk ki: ErrorDocument 401 /login_failed.html Ilyenkor a második paraméterként átadott fájl előtt álló perjel (/) a DocumentRoot utasításban megadott útvonalra utal. Végezetül, a kérelmet egy külső URL-re is átirányíthatjuk: ErrorDocument

77 Példáink különböző 400-as HTTP-visszatérési kódokat alkalmaztak, amelyek jelzik, hogy a kérelem feldolgozásánál akadtak gondok így lehet, hogy a felhasználó nem adott meg megfelelő azonosítót és jelszót. Persze ugyanígy használhatunk más HTTP-kódokat is, például a belső kiszolgálóhibák jelzésére. Megjegyzés A Microsoft Internet Explorer (MSIE) egyes változatai fi gyelmen kívül hagynak minden, 512 bájtnál rövidebb, kiszolgáló által meghatározott hibaüzenetet, ezért ügyeljünk arra, hogy ennél hosszabb hibaüzenetet adjunk meg. Minderről többet is megtudhatunk a Microsoft Knowledge Base oldalán a microsoft.com/default.aspx?scid=kb;en-us;q címen. Felhasználói szabályozás Ha Apache kiszolgálónkon több felhasználó is közzéteszi a saját weboldalát, érdemes lehetővé tennünk a számukra, hogy az 1. fejezetben bemutatott.htaccess fájlok révén jelszóval védhessék a könyvtáraikat. Ez persze némiképp terheli a rendszert, de még mindig kevesebb gondunk van vele, mint ha magunknak kellene a hozzáférést szabályoznunk, valamint módosítanunk az Apache beállítófájlját, illetve felhasználói adatbázisát minden változtatást követően. Apache-beállítófájlunk megfelelő könyvtárszakaszaiban az alábbi utasítást kell elhelyeznünk: AllowOverride AuthConfig Limit Ez lehetővé teszi a felhasználóknak, hogy elkészítsék saját.htaccess beállítófájljaikat, és ezekben elhelyezzék a kívánt hozzáférés-szabályozási és hitelesítési utasításaikat. Előállhat fordított helyzet is, amikor kifejezetten meg akarjuk akadályozni a könyvtárankénti beállítások érvényesítését. Ezt az alábbi kóddal tehetjük meg: <Directory /> AllowOverride none </Directory> Ha így döntünk, a kiszolgáló teljesítménye is javul, hiszen nem kell minden kérelmezett fájl esetében a könyvtárankénti beállítófájlok után kutatnia. Az AllowOveride utasítás azonban finomabb beállításokat is lehetővé tesz, így korlátozhatjuk a könyvtárankénti beállítások típusát is (erről bővebben az utasítás leírásában tájékozódhatunk). 65

78 A rendszerfájlok és érzékeny fájlok elérésének megtagadása <Files ~ ^\.ht > Order allow,deny Deny from all </Files> Vannak bizonyos típusú fájlok, amelyekhez egyáltalán nem szeretnénk, ha a látogatók hozzáférnének. Ilyenek a jelszavakat vagy más érzékeny adatokat tartalmazó fájlok, a Unix szövegszerkesztők által készített biztonsági másolatok, a könyvtárankénti beállítófájlok, és más hasonlók. Elérésüket érdemes lehet közvetlenül erre a célra megadott beállításokkal megtiltani ezt tettük példánkban is, amely megtiltja a hozzáférést a.htaccess és a.htpasswd fájlokhoz (ez a kód alapértelmezésben megtalálható az Apache beállítófájljában). Emellett megakadályozhatjuk, hogy a kiszolgáló nem kívánt tartalmat továbbítson, ha megtiltjuk számára a közvetett hivatkozások követését. Ehhez az Options utasítás FollowSymLinks és SymLinksIfOwnerMatch paramétereit használhatjuk a leírásban megadott módon. Esetenként érdemes lehet kikapcsolni a 4. fejezetben megismert mod_speling modult is, amely egy elgépelt URL kapcsán esetleg olyan fájlok neveit is közzéteheti, amelyeket nem erre szántunk. Ide kapcsolódik továbbá a könyvtártartalom-kiíratás letiltásának lehetősége, amelyről hamarosan bővebben is szólunk. Programfuttatási korlátozások A CGI programok komoly biztonsági kockázatot jelenthetnek, ezért ajánlatos letiltani a futtatásukat, vagy ha mindenképpen szükség van a használatukra, csak bizonyos könyvtárakra korlátozni. Az sem túl jó ötlet, ha az AddHandler utasítással bizonyos kiterjesztésekhez globális futtatási jogokat rendelünk. A mod_include hasonló veszélyt jelent, hiszen az SSI-n keresztül lehetővé teszi a CGI parancsfájlok és más külső programok futtatását. Ez a lehetőség alapértelmezés szerint nem érhető el erről az Options -IncludesNoExec utasítás gondoskodik. Amennyiben lehetséges, érjük el, hogy a CGI parancsfájlokat tartalmazó könyvtárban kizárólag a rendszergazda rendelkezzen írási jogosultsággal, rajta kívül senki más - különösen nem az a felhasználó, akinek a nevében az Apache kiszolgáló fut. Mindemellett fontos, hogy ha lehetőség van rá, biztosítsuk, hogy a dokumentumkönyvtár tartalma csak olvasható legyen. Ezzel ugyanis megakadályozható, hogy a támadó egy fájlt például egy PHP fájlt egy PHPképes kiszolgálón hozzon létre, amelyet később futtathat. Védjük jelszóval DAV-képes könyvtárainkat, és semmiképpen se tegyük elérhetővé webhelyünk tartalmát más szolgáltatásokon, például FTP-n keresztül. Mit tehetünk a visszaélések ellen? Számos módszer ismeretes arra, hogy miként tilthatjuk le vagy lassíthatjuk a hozzáférést webhelyünk egy részéhez vagy egészéhez. Ez olyankor lehet hasznos, ha nem szeretnénk, hogy bizonyos tartalmak megjelenjenek a keresőmotorokban, vagy azt vesszük észre, hogy egy elszabadult webpók túl sok erőforrásunkat 66

79 emészti fel. Mindezekről bővebben a 9. fejezetben szólunk, ahol szó esik arról is, miként kerüljük el vagy legalábbis szorítsuk vissza az elárasztásos (DoS, denial-of-service) támadásokat, amelyek igen nehézzé vagy akár lehetetlenné is tehetik saját felhasználóink kérelmeinek kiszolgálását. E gondok kiküszöbölésére számos Apache-modul áll rendelkezésre. A könyvtártartalom kiíratásának letiltása <Directory /usr/local/apache2/htdocs/private> Options -Indexes </Directory> Az Apache lehetővé teszi, hogy a DirectoryIndex utasítással indexfájlokat hozzunk létre a könyvtárainkhoz. Ha ügyfelünk kérelme egy könyvtár útvonalára vonatkozik, a kiszolgáló először ezeket az indexfájlokat (nevük többnyire index.html vagy home.html) keresi, és ha talál ilyet, visszaadja a böngészőnek. Ha nincs ilyen fájl a könyvtárban, a könyvtár tartalmát kiíró HTML oldalt ad vissza. Ez a viselkedés hasznos lehet a fejlesztés során, illetve ha fájltárolásra használjuk a könyvtárainkat, de így olyan fájlok nevei is nyilvánosságra kerülhetnek, illetve megjelenhetnek a keresőkben, amelyeket meg szerettünk volna tartani magunknak (ilyenek például a biztonsági másolatok). A könyvtártartalom kiíratását a mod_autoindex modul kikapcsolásával, valamint a fent bemutatott Options utasítással tilthatjuk le. Amennyiben használhatunk könyvtárankénti beállítófájlokat, a fenti példakódot a.htaccess fájlban is elhelyezhetjük. A Server: fejléc módosítása ServerTokens Prod Az Apache minden kérelem nyomán visszaküld egy Server: fejlécet, amely alapértelmezés szerint a kiszolgáló nevéről, verziószámáról és az operációs rendszerről tartalmaz adatokat. A kiszolgálón futó modulok, így az SSL, a PHP vagy a mod_perl további bejegyzésekkel egészíthetik ki a fejlécet, átadva a modul nevét és verziószámát. A ServerTokens utasítással magunk is módosíthatjuk, illetve korlátozhatjuk a Server: fejlécben foglaltakat. Persze mindig érdemes arra törekedni, hogy a lehető legkevesebb adatot szivárogtassuk ki a kiszolgálóról, de ez esetben nem sokat érünk az elővigyázatossággal: a legtöbb automatikus kutató- és támadóprogram egyszerűen figyelmen kívül hagyja a fejléc adatait, és egymás után végigpróbálgatja a sebezhető parancsfájlokat és modulokat, függetlenül attól, hogy milyen verziószámokat adtunk meg a fejlécben. A képekre mutató közvetlen hivatkozások letiltása RewriteEngine On RewriteCond %{HTTP_REFERER}!^ [NC] RewriteCond %{HTTP_REFERER} ^ [NC] RewriteCond %{HTTP_REFERER}!^$ RewriteRule \.{jpg jpeg gif png bmp)$ - [F] 67

80 Előfordul, hogy más webhelyek közvetlenül hivatkoznak kiszolgálónk erőforrásaira, például képekre vagy futtatható fájlokra. Ez a közvetlen hivatkozásnak (hotlinking) nevezett módszer sok esetben káros hatásokkal is járhat, így érdemes tennünk ellene valamit. Példaként elég megemlíteni azt az internetes kereskedőt, aki egyszer csak arra lett figyelmes, hogy forgalmának (és így a sávszélességért fizetett díjának) feléért voltaképpen más webhelyek felelősek, amelyek közvetlenül hivatkoznak az egyes hitelkártyacégeket és országokat jelölő képekre. A közvetlen hivatkozást könnyen megakadályozhatjuk, ha megköveteljük, hogy a képekre irányuló kérelmek a kiszolgálónktól érkezzenek ezt pedig a mod_rewrite modullal tehetjük meg. A példakód minden olyan kérelem esetén Forbidden (tiltott) válasszal tér vissza, amely képre vonatkozik (az azonosítást a képek kiterjesztése teszi lehetővé, lásd a negyedik RewriteCond sort), és amelynek HTTP_REFERER fejléce nem felel meg saját tartománynevünknek (az első RewriteCond sor). Mivel egyes böngészők nem szabályos Referer: mezőt adnak át, illetve egyáltalán nem szolgáltatnak ilyen adatot, utánanézhetünk annak is, hogy a mező előtaggal kezdődik-e, és hogy egyáltalán van-e benne valami (lásd a második és harmadik RewriteCond sorban). A HTTP-függvények korlátozása <Directory /home/*/public_html> AllowOverride FileInfo AuthConfig Limit Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec <Limit GET POST OPTIONS PROPFIND> Order allow,deny Allow from all </Limit> <LimitExcept GET POST OPTIONS PROPFIND> Order deny,allow Deny from all </LimitExcept> </Directory> A <Limit> és a <LimitExcept> utasításokkal a kérelem HTTP-függvénye alapján is korlátozhatjuk a kiszolgáló elérését. Példánkban, amelyet az Apache alapértelmezett beállítófájljából ollóztunk ki, látható, hogyan engedélyezhetjük a csak olvasó függvényeket, és miként utasíthatunk vissza minden más olyan kérelmet, amelynek függvénye ilyen például a PUT módosítaná a fájlrendszert. A <Directory> szakaszban a felhasználói könyvtárakra szorítkozunk, amelyek weboldalakat tartalmazhatnak (lásd a 8. fejezetben). A következő két sorban meghatározzuk, mely adatokat módosíthatják a felhasználók, és teszünk még pár biztonsági lépést. A <Limit> szakasz alapértelmezés szerint lehetővé teszi a csak olvasó HTTP-függvények amilyen a GET vagy a POST - használatát. A <LimitExcept> éppen ellenkezőképpen jár el: kizárólag a megadott függvények számára biztosít elérést, és minden mást letilt, anélkül, hogy fel kellene sorolnunk őket. Mindez különösen akkor hasznos, ha lehetővé szeretnénk tenni a felhasználóinknak, hogy felügyeljék az általuk elhelyezett tartalmakat (lásd a 8. fejezetben). 68

81 A hozzáférés korlátozása a böngésző alapján SetEnvIf User-Agent ^EvilSearchEngine broken_crawler <Directory /usr/local/apache2/htdoca> Order Deny,Allow Deny from env=broken_crawler </Directory> Az Allow és a Deny utasítások, illetve a környezeti változók segítségével a hozzáférést a böngésző típusa vagy bármely más fejlécadat, illetve kapcsolati jellemző alapján korlátozhatjuk. Esetünkben minden olyan kérelmet elutasítunk, amelyekben a böngésző User-Agent fejléce az EvilSearchEngine karakterlánccal kezdődik, a többit pedig teljesítjük. Mindezt a SetEnvInf utasítással érhetjük el, amelyben feltételesen megadunk egy broken_crawler nevű környezeti változót a változó akkor lesz jelen, ha a kérelem User-Agent fejléce (első paraméter) megfelel egy szabályos kifejezésnek (második paraméter). Később már ennek a környezeti változónak a meglétére alapozva alkalmazhatjuk az Allow és Deny utasításokat; csak az env= előtagot kell beírnunk. Sose feledjük azonban, hogy a fejléceket maguk az ügyfelek küldik, így jóllehet sok esetben használható ez a módszer nem tekinthető teljesen megbízhatónak. A <Location> és a <Directory> szakaszok használata Az Order utasítás a kiszolgáló beállításainak elemzése során csak az egyes szakaszokon belül határozza meg a hozzáférési utasítások sorrendjét. Ez azt jelenti, hogy a <Location> szakaszokban megjelenő Allow és Deny utasítások kiértékelése mindig csak a <Directory> szakasz, illetve a.htaccess fájl Allow és Deny utasításai után kerül sorra, függetlenül az Order utasítás beállításaitól. Vegyük figyelembe azt is, hogy a közvetett hivatkozások és az Alias utasítások hatással lehetnek a hitelesítési eljárásokra, így például a <Location> tárolókban elhelyezett hozzáférés-szabályozó utasítások kikerülhetők, ha ugyanez a tartalom egy URL-megfeleltetés útján is elérhető. További hitelesítési modulok Az eddigiekben megismert, IP alapú hozzáférés-szabályozást biztosító modulok, valamint az egyszerű és kivonatos hitelesítés mellett az Apache programcsomagjával további, hasonló célú modulokhoz is hozzájutunk: mod_auth_anon: FTP-szerű névtelen felhasználói hozzáférést biztosít a fájlok letöltéséhez. mod_auth_ldap: Ez az Apache 2-től elérhető modul LDAP könyvtárakkal teszi lehetővé a hitelesítést. mod_ssl: Tanúsítvány alapú ügyfélhitelesítést tesz lehetővé; bővebb tárgyalására a 7. fejezetben kerül sor. Az Apache nagy erénye a modularitása és a bővíthetősége. Mindez lehetőséget adott a külső gyártóknak, hogy olyan modulokat készítsenek, amelyek felületet nyújtanak a különböző hitelesítési környezetek, így a Windows-tartományok, az LDAP, a PAM vagy a NIS, továbbá a különböző adatbázisokban MySQL, PostgreSQL, Oracle stb. tárolt felhasználói adatok számára. Ezeknek a moduloknak a többségét megtalálhatjuk a valamint a címeken. 69

82 A hitelesítést mindig elvégezhetjük az alkalmazások szintjén. Ez többnyire abból áll, hogy egy webes űrlapon elkérjük a felhasználónevet és a jelszót, majd ezek ellenőrzése után egy sütivel hitelesítjük a felhasználót a munkamenet további időtartamára. A népszerű portálok és elektronikus kereskedelmi oldalak rendszerint ezzel a módszerrel végzik a felhasználók hitelesítését. A mod_security modul Külön meg kell említenünk a mod_security modult, amely lényegében egy HTTP szintű tűzfal. Lehetővé teszi, hogy figyeljük a HTTP-kérelmeket, és különféle módon vizsgáljuk és rögzítsük azokat, valamint hozzáférés-szabályozó műveleteket végezzünk velük. Ennek a modulnak a segítségével meghiúsíthatjuk az alkalmazásszintű támadások - így az SQL-befecskendezésre, valamint az útvonalmegfordításra épülő támadások nagy részét. A modul lehetőségeiről bővebben a címen olvashatunk. Apache 2.2 <Location /combined> AuthType Basic AuthName Restricted Access AuthBasicProvider file ldap AuthUserFile /usr/local/apache2/conf/htusers AuthLDAPURL ldap://example.com/o=sample Require valid-user </Location> Az Apache 2.2-vel jelentős fordulat következett be a hitelesítés és az engedélyezés megvalósításában. A változások már létező modulokban és javarészt a módszerek (egyszerű és kivonatos hitelesítés), valamint a szolgáltatók (fájlok, LDAP vagy SQL háttéradatbázisok) szétválasztásában érhetők tetten korábban ugyanis ezek összekeveredtek az egyes modulok megvalósításában. Így például a mod_auth_file szövegfájlokkal végzi a hitelesítést, míg a mod_auth_dbm adatbázisfájlokkal dolgozik. Mindkettő használható a mod_auth_basic, valamint a mod_auth_digest modulokkal, amelyek az egyszerű, illetve a kivonatos HTTP-hitelesítést valósítják meg. Léteznek ugyanakkor további modulok is, amelyekkel a hitelesítést LDAP vagy SQL adatbázisokkal, fájlokkal, illetve a fájlok tulajdonosai vagy a kiinduló IP cím alapján végzik. A különböző szolgáltatókat használhatjuk egymás mellett is, amint ezt a fenti példa is mutatja. Mindemellett az új mod_auth_alias modul lehetővé teszi, hogy bonyolult hitelesítési összeállításokat tároljunk, és ezekre nevükkel hivatkozzunk a beállítófájl távolabbi részeiben. Így egy erőforrás hitelességét két különböző LDAP-kiszolgálóval is ellenőrizhetjük. Naprakész biztonsági beállítások Ahogy más kiszolgálóprogramoknál, úgy az Apache esetében is fontos, hogy lépést tartsunk a frissítésekkel, és hogy mindig tájékozódjunk a veszélyekről és az elérhető biztonsági foltokról, illetve megoldási módszerekről. Ehhez nagy segítséget jelenthetnek az alábbi címek: 70

83 Az Apache-bejelentések levelezőlistája: Biztonsági kérdések az Apache-ban: html Apache Week: Apache Security Típs: Biztonsági teendők Gyakran mondják, hogy a biztonság nem adott dolog, amelyet birtokolni lehet, hanem inkább folyamat. Ahhoz, hogy Apache kiszolgálónk biztonságosan működjön, lépést kell tartanunk az Apache biztonsági irányelveivel, és folyamatosan figyelnünk kell az elérési és hibanaplókat. Mivel az Apache nem választható el a környezetétől, ugyanilyen elővigyázatosnak kell lennünk az operációs rendszer és az alkalmazások szintjén is. Sőt, itt talán még nagyobb körültekintésre van szükség, hiszen ismert, hogy a legtöbb biztonsági rés az alkalmazások szintjén nyílhat meg elég egy sebezhető oldal, egy PHP könyvtár, vagy valamilyen gyengén megírt összetevő. Az általános útmutató után következzék a biztonsági teendők listája lépésről lépésre. Kapcsoljuk ki a használaton kívüli modulokat! Első lépésként kapcsoljunk ki minden olyan modult, amelyet nem használunk. Ha a betölthető modulok támogatásával fordítottuk az Apache kiszolgálónkat, a betöltésért felelős utasításokat kell felkutatnunk és kiiktatnunk. Ilyenkor előfordulhat, hogy más utasítások kikapcsolására is szükség lesz, amelyek a kérdéses modulhoz kapcsolódnak. A következőkben felsoroljuk azokat a modulokat, amelyek kikapcsolása lényeges a biztonság szempontjából (sorrendjük nagyjából tükrözi a szerepük jelentőségét): A PHP, mod_python, mod_mono, mod_perl és más, kiszolgálóoldali nyelveket megvalósító modulok. Mondanunk sem kell, hogy a PHP-t csak akkor kapcsoljuk ki, ha nem futtatunk a kiszolgálón PHP alapú alkalmazásokat. A mod_include, amely az SSI-támogatást adja. A mod_cgi, amellyel külső programokat futtathatunk. A mod_ssl, amely az Apache és a böngésző közti biztonságos adatcserét megvalósító SSL/TLS protokollt támogatja. A mod_proxy, amely hibásan beállítva lehetőséget ad a támadóknak arra, hogy a kiszolgálónkat kérelmek továbbítására használjak. A mod_deflate, az Apache 2 szűrője, amely a tartalom dinamikus tömörítését biztosítja. A mod_suexec, amellyel külső programokat futtathatunk az Apache-ot üzemeltetőtől eltérő felhasználó nevében. A mod_userdir, amely lehetővé teszi, hogy a Unix-felhasználók kezeljék a saját oldalaikat. A mod_rewrite, amelynek segítségével a bejövő URL-eket tetszőlegesen átírhatjuk, és megfeleltethetjük más címeknek. Mindezek mellett az Apache 1.3-ban a ClearModuleList utasítással kikapcsolhatjuk a befordított modulokat, az AddModule segítségével pedig újra bekapcsolhatjuk a valóban használtakat. 71

84 Távolítsuk el a mintaparancsfájlokat! A legtöbb webes programcsomaggal és fejlesztőkörnyezettel hozzájutunk jó pár mintaparancsfájlhoz és példaprogramhoz, amelyek a lehetőségek bemutatását, illetve a programok tesztelését szolgálják. Ezek a programocskák persze hasznosak, de megírásuknál a szerzők általában nem sokat gondolkodnak biztonsági kérdéseken, így sokszor védtelenek a támadásokkal szemben, különösen a felhasználói bemenet nem megfelelő kezelése miatt. Ezek a hibák oda vezethetnek, hogy a támadó képessé válik tetszőleges rendszerparancsok kiadására, fájlok tartalmának megtekintésére és adatbázisok módosítására. Ezért távolítsunk el minden mintaparancsfájlt és bemutatófiókot, amelyet alkalmazáskiszolgálónkkal, fejlesztőkörnyezetünkkel, és egyáltalán, bármilyen internetes programcsomagunkkal kaphattunk. Korlátozzuk vagy tiltsuk meg a CGI parancsfájlok futtatását és az SSI használatát! Ha nincs szükségünk a CGI-támogatásra, kapcsoljuk ki a mod_cgi modult. Ha szükségünk van rá, korlátozzuk a CGI parancsfájlok futtatását meghatározott könyvtárakra. Érdemes például átfésülnünk a beállítófájlokat, és megkeresnünk a ScriptAlias, valamint az ExecCGI paraméterrel alkalmazott Options utasításokat, és ellenőriznünk a helyességüket. Győződjünk meg arról, hogy a futtatható parancsfájlokat tartalmazó könyvtárakba mások nem írhatnak. Érdemes lehet használatba venni az Apache részét képező suexec CGI-burkolót is. Hasonló elvek vonatkoznak a mod_include modul által biztosított SSI lehetőségeire is, ami ha nem kapcsoljuk ki az Options -IncludesNoExec utasítással - lehetővé teszi külső programok futtatását. Ellenőrizzük a fájlok engedélyeit! Unix rendszereken az Apache általában rendszergazdai jogokkal indul, végrehajt néhány műveletet - például kapcsolódik a megfelelő porthoz, majd belebújik a User utasítással megadott felhasználó bőrébe. Mivel a kiszolgáló bizonyos műveleteket rendszergazdaként hajt végre, igen fontos, hogy a napló- és beállítófájlokba, valamint az ezeket tartalmazó könyvtárakba más ne írhasson. Győződjünk meg arról is, hogy azok a könyvtárak, amelyek PHP parancsfájlokat vagy egyáltalán, bármilyen futtatható parancsfájlt tartalmazhatnak, nem általánosan írhatók, és nem érhetők el például FTP-n vagy WebDAV-on keresztül. Korlátozzuk vagy kapcsoljuk ki a helyettes kiszolgálói szolgáltatásokat! A CGI parancsfájlokhoz hasonlóan érdemes az Apache helyettes kiszolgálói támogatását is korlátoznunk vagy kikapcsolnunk. Egyébként egy nyitott helyettes kiszolgáló (proxy) könnyen használható más webhelyek elleni támadásra vagy levélszemét továbbítására. Ha az Apache-ot fordított helyettes kiszolgálóként futtatjuk, a hagyományos helyettes kiszolgálói szolgáltatásokat az alábbi utasítással kapcsolhatjuk ki: ProxyRequests off 72

85 Alapértelmezés szerint korlátozzuk a kiszolgáló elérését! A kiszolgálónkat úgy kell beállítanunk, hogy alapértelmezés szerint tagadja meg minden rajta tárolt dokumentum elérését, hacsak ez kifejezetten nem engedélyezett. Az alábbi kódrészlettel, amelyet az Apache leírásából ollóztunk ki, éppen ezt tesszük: <Directory /> Order Deny,Allow Deny from all </Directory> <Directory /usr/local/apache2/htdocs> Order Deny,Allow Allow from all </Directory> A könyvtártartalom kiíratásának letiltásáról fejezetünk korábbi részeiben olvashattunk bővebben. 73

86 74

87 7 SSL/TLS Ebben a fejezetben röviden bemutatjuk az SSL alapelveit, és útmutatót adunk az Apache mod_ssl moduljának telepítéséhez lépésről lépésre. Megtanuljuk, hogyan kezeljük az SSL-lel kapcsolatos kérdéseket, továbbá szó esik a kiszolgálókulcsok és tanúsítványok létrehozásáról, aláírásáról és telepítéséről. Mi is az SSL? Az SSL/TLS egy protokollcsalád, amely biztonságos adatátvitelt tesz lehetővé két végpont többnyire egy kiszolgáló és egy ügyfél között. Ha böngészőnk a HTTP protokollal éri el a webkiszolgálót, az adatok teljesen nyílt formában utaznak a hálózaton. Amennyiben valakinek sikerül az átviteli útvonal bármely pontján bekapcsolódni az adatcserébe, képessé válik az adatok elérésére, sőt akár módosítására is, ezért számos alkalmazásnak amelyek például az elektronikus fizetési tranzakciókat irányítják, vagy éppen érzékeny céges adatokhoz férnek hozzá - a HTTP protokoll által biztosítottnál magasabb szintű biztonságra van szüksége. A HTTPS vagy Secure HTTP (biztonságos HTTP) protokollt éppen e célból fejlesztették ki. A biztonság növelését az alábbi tulajdonságai garantálják: Bizalmasság: az adatok kódolása oly módon történik, hogy illetéktelenek nem képesek értelmezni. Adatépség: biztosítja az adatok épségét az átvitel során. Hitelesítés: a protokoll ellenőrzi a kiszolgáló (és az ügyfél) kilétét. A HTTPS lényegében az SSL/TLS családra (a továbbiakban csak SSL-ként hivatkozunk rá) épülő HTTP protokoll, amelynek alapértelmezett portja a 443-as, a HTTPS URL-ek pedig előtagot kapnak. Amint azt bizonyára már tapasztaltuk, a legtöbb böngésző valamilyen képi jelét is adja annak, hogy a HTTPS protokollal kapcsolódunk egy webhelyhez többnyire egy kis lakat ikon formájában. Hogyan működik az SSL? Ha a felhasználó a címet adja meg, a böngésző a előtag alapján azonnal tudja, hogy a HTTPS protokollal kell kapcsolódnia a kiszolgálóhoz. Ha nem adtunk meg portot, a program az alapértelmezett 443-as porttal próbálkozik. Ha a kapcsolat létrejött, az ügyfél tanúsítványt kér a kiszolgálótól. A tanúsítvány egy elektronikus adatsor, amely az SSL-kapcsolat résztvevőinek kilétét hivatott igazolni hogy miként, arról hamarosan bővebben is szólunk. A rendszer megvizsgálja a tanúsítvány érvényességét. Az érvényesség megállapításának eredményétől függően a kapcsolat létrehozásának folyamata folytatódik, vagy a felhasználó tájékoztatást kap a helyzetről, és a rendszer a beleegyezését kéri a folytatáshoz. Az ügyfél is adhat tanúsítványt (bár ritkábban fordul elő) - ilyenkor a kiszolgáló az előzőekhez hasonlóan megvizsgálja ennek érvényességét. 75

88 Ha tisztázódott a kiszolgáló (és esetleg az ügyfél) kiléte, a következő lépésben a két fél megegyezik egy titkosítási kulcsban. Mindkét oldal nyilvános kulcsokat ad át, és ezzel végül előállítanak egy szimmetrikus kulcsot. Pillanatnyilag nem megyünk bele jobban a részletekbe, a titkosítási kulcsokról és elkészítésük módjáról ugyanis még szót ejtünk a fejezetben. Az egyeztetés folyamata védett a támadókkal szemben, hiszen a kiszolgáló nyilvános kulcsával titkosított adatokat csak maga a kiszolgáló képes értelmezni. Miután az egyeztetés véget ért, a kiszolgáló és az ügyfél megkezdhetik a tényleges adatcserét. Ezt az állapotot a legtöbb böngésző képileg is megjeleníti, jobbára egy zárt lakattal. Az OpenSSL fordítása # gunzip < openssl*.tar.gz tar xvf - # cd openssl* #./config --prefix=/usr/local/ssl --openssldir=/usr/local/ssl/openssl # make # make install Az Apache a mod_ssl segítségével valósítja meg a HTTPS támogatását, míg az OpenSSL az alapvető titkosítási könyvtárakat biztosítja a mod_ssl számára, továbbá a kiszolgálói tanúsítványok létrehozásához és kezeléséhez szükséges parancssori eszközöket. A Windows rendszerhez készített futtatható telepítőt letölthetjük az OpenSSL webhelyének megfelelő részéről ( Napjaink legtöbb Unix-szerű rendszerében alapállapotban jelen van az OpenSSL, de könnyedén telepíthetjük a csomagkezelő segédeszközökkel is. Ha nem ilyen egyszerű a helyzet, vagy a rendszerünkön találhatónál újabb változatra van szükségünk, töltsük le az OpenSSL forráskódját, és telepítsük a fenti példában látható módon. A fejezet további részében feltételezzük, hogy az OpenSSL-t a /usr/local/ssl könyvtárba telepítettük. Az openssl parancssori eszközhöz hozzájutunk az OpenSSL programcsomaggal a /usr/local/ ssl/bin/ könyvtárban akadhatunk rá. Titkosítási kulcsok Titkosítás alatt azt a folyamatot értjük, amelynek során egy egyszerű szöveges üzenetből titkosat készítünk, amely egy kívülálló számára értelmezhetetlen. A titkosítás feloldása a fordított folyamatra utal ez esetben a titkosított szövegből visszaállítjuk az eredetit. A titkosításhoz és feloldásához többnyire szükség van még egy összetevőre: ez a kulcs. Ha a küldő és a fogadó fél ugyanazt a kulcsot használja, szimmetrikus kulcsról beszélünk, míg ha a kulcsuk különböző, és kiegészítik egymást, aszimmetrikus vagy nyilvános kulcsú titkosításról van szó. Ilyenkor a kulcspár egyik tagja nyilvános, a másik pedig titkos. Az előbbi a nevének megfelelően szabadon elérhető, az utóbbit azonban a birtokosa titokban tartja. A két kulcs kiegészíti egymást: amit az egyikkel titkosítottak, az a másikkal oldható fel. 76

89 Kulcspár készítése #./usr/local/ssl/bin/openssl genrsa -rand file1:flle2:file3 \ -out semi-random bytes loaded Generating RSA private key, 1024 bit long modulus e is (0x10001) Példánk azt mutatja be, hogy miként készíthetünk el egy kulcspárt az openssl parancssori eszközzel. A genrsa paranccsal tudatjuk az OpenSSL-lel, hogy egy kulcspárt szeretnénk készíteni az RSA algoritmussal. A rand kapcsolóval véletlen adatokat biztosítunk az OpenSSL számára, hogy a készített kulcsaink egyediek és kitalálhatatlanok legyenek. A file1, file2 stb. helyére írjunk több nagy, viszonylag véletlenszerű összetételű fájlt (rendszermaglenyomat, tömörített naplófájlok, vagy más hasonlók). Ezt a kapcsolót Windowson nem kell használnunk, ugyanis itt a program más forrásból automatikusan hozzájut a szükséges véletlen adatokhoz. Az out kapcsolóval adhatjuk meg, hogy hová kerüljön az eredmény. Az 1024 az elkészült kulcs bitjeinek számát adja meg. Jelszóval védett kulcspár készítése #./usr/local/ssl/bin/openssl genrsa -des3 -rand filel:file2:file3 \ -out A des3 kapcsoló hatására a program titkosítja magát a titkos kulcsunkat, és jelszóval védi, amelyet a parancs végrehajtásakor meg kell adnunk. A rendszer a kiszolgáló minden indításánál kéri majd ezt a jelszót, amint azt az SSLPassPhraseDialog tárgyalásánál láthatjuk. A kulcs jelszavas védelmének feloldása #./usr/local/ssl/bin/openssl rsa -in \ -out A fenti kóddal megszüntethetjük a kulcsunk jelszavas védelmét. Ennek a lépésnek természetesen vannak biztonsági kockázatai, amelyekről az SSLPassPhraseDialog tárgyalásánál szólunk. Tanúsítványok A nyilvános kulcsú titkosítással üzeneteinket digitális aláírással láthatjuk el. Mindez nagyon egyszerű: ha üzenetünket saját titkos kódunkkal titkosítjuk, a fogadó fél biztos lehet benne, hogy tőlünk származik, ha nyilvános kulcsunkkal képes feloldani a titkosítást. Egy aprócska részlet azonban hibádzik. Hogyan bizonyosodjunk meg olyasvalakinek a kilétéről, akivel személyesen soha nem találkoztunk? Más szóval, miként ellenőrizzük, hogy valójában kihez tartozik a kapott nyilvános kulcs? 77

90 A megoldást egy megbízható harmadik fél, a tanúsító hatóság (Certification Authority, CA) adja. Ez lehet a cégünk vagy egyetemünk egyik szerve, de lehet kereskedelmi szervezet is, amely tanúsítási szolgáltatást nyújt az Interneten működő cégeknek. A tanúsító hatóság tanúsítványokat ad ki, vagyis olyan elektronikus dokumentumokat, amelyek egy adott nyilvános kulcshoz rendelik a tulajdonos adatait, például a nevét és a címét. Ezeket a tanúsítványokat a hatóság digitálisan aláírja a saját titkos kulcsával, ami biztosítja a tartalmuk eredetiségét. Ahhoz, hogy ez a rendszer működjön, mindenekelőtt meg kell bíznunk a tanúsítványt kiadó hatóságban. Emellett hozzá kell jutnunk valahogy a tanúsító hatóság nyilvános kulcsához, amelyet annak úgynevezett gyökértanúsítványában érhetünk el. Az ismertebb böngészők, mint az Internet Explorer, a Firefox vagy a Safari eleve rendelkeznek jó pár gyökértanúsítvánnyal az általánosan elismert tanúsító hatóságoktól. Ez lehetővé teszi a számukra, hogy anélkül ismerjenek fel és fogadjanak el hitelesnek számos webhelyet, hogy a felhasználónak akár a kisujját meg kellene mozdítania. Tanúsítványkérelem létrehozása #./usr/local/ssl/bin/openssl req -new -key -out Ahhoz, hogy egy tanúsítványt kapjunk egy hatóságtól, először be kell nyújtanunk hozzá egy tanúsítványkérelmet, amely tartalmazza a kérelmező szervezet adatait, valamint a nyilvános kulcsot. Mindezt megtehetjük a 7.1. példában látható paranccsal, amely a kérelem kiadásához különböző adatokat kér példa Tanúsítványkérelem létrehozása az openssl segítségével Using configuration from /usr/local/ssl/openssl/openssl.cnf Enter PEM pass phrase: You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter., the field will be left blank Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:CA Locality Name (eg, city) []: San Francisco Organization Name (eg, company) [Internet Widgits Pty Ltd]:. Organizational Unit Name (eg, section) []:. Common Name (eg, YOUR name) []: Address []:[email protected] Please enter the following extra attributes to be sent with your certificate request A challenge password []: An optional company name []: 78

91 Fontos, hogy a Common Name mező tartalma megegyezzen azzal a címmel, amelyet a webhelyünk látogatói a böngészőjükbe írnak. A böngésző a látogatás során ellenőrzi ezt a címet a tanúsításhoz, és ha a két név eltér, ezt egy figyelmeztető üzenetben jelzi. Ha a parancs futása véget ért, a tanúsítványkérelem fájlját elküldhetjük a tanúsító hatóságnak. A pontos folyamat esetenként eltérő lehet. A címen kiterjedt listát találhatunk a tanúsító hatóságokról. Érdemes megemlítenünk párat a legismertebbek közül: a Verisign, a Thawte, a GeoTrust és az Equifax mind széles körben elfogadott kereskedelmi szervezetek. Említést kell tennünk továbbá a közösségi tanúsító hatóságokról - ilyen például a címen elérhető szervezet is. A tanúsítványkérelem tartalmának megjelenítése #./usr/local/ssl/bin/openssl reg -noout \ -text -in A tanúsítványkérelmeket a rendszer tömörített alakban tárolja, és megtekintésükre a fenti példában látható parancs szolgál (esetünkben a fájlt jelenítettük meg). Amint korábban már említettük, a kérelem tartalmazza a kérelmező adatait, a nyilvános kulcsot, valamint egy a titkos kulccsal készített aláírást. Saját tanúsítvány létrehozása Tanúsítványkérelmünket nemcsak egy tanúsító hatóságnak küldhetjük el mindig lehetőségünk van arra, hogy saját magunk hitelesítsük. Ilyenkor magunk játsszuk a kérelmező és a tanúsító szerepét is. Persze egy kereskedelmi webhely számára ez nem túl hasznos, de lehetővé teszi, hogy ellenőrizzük a mod_ssl működését, vagy legalábbis biztonságos webkiszolgálóval rendelkezzünk, amíg a hivatalos tanúsítványra várakozunk. #./usr/local/ssl/bin/openssl x509 -req \ -days 30 -in -signkey \ -out Tanúsítványunkat (származzék tőlünk vagy egy tanúsító hatóságtól), amely ez esetben a com.cert névre hallgat, át kell másolnunk a /usr/local/ssl/openssl/certs/, kulcsunkat pedig a /usr/local/ssl/openssl/private/ könyvtárba. A kulcsfájlt célszerű védeni az alábbi paranccsal: # chmod

92 Az SSL-támogatás biztosítása az Apache 1.3-ban $ gunzip < mod_ssl tar.gz tar xvf - $ gunzip < apache_ tar.gz tar xvf - $ cd mod_ssl $./configure --with-apache=../apache_ $ cd../apache_1.3.x $ SSL_BASE=/usr/local/ssl/./configure --enable-module=ssl --prefix=/usr/ local/apache $ make # make install A mod_ssl meglehetősen népszerű modul, amely biztosítja az SSL támogatását mind az Apache 1.3, mind a 2.x változatok számára. Bizonyos történeti okok miatt (korábban az USA-ban tilalmak voltak érvényben a titkosítási eljárások kivitelére) a modul Apache 1.3-hoz készült változatához nem jutunk hozzá a kiszolgáló programcsomagjával, sőt ahhoz, hogy ezt a modult használjuk, meg is kell foltoznunk az Apache 1.3 forráskódját. Éppen ezt tesszük a mod_ssl felépítési folyamatában, a fenti kódrészletben. Hogy egészen pontosak legyünk, példánkban az Apache változatát építjük fel a mod_ssl változatával, feltételezve, hogy a forráskódok ugyanazon a szinten helyezkednek el a könyvtárszerkezetben. A --withapache parancssori kapcsolóval adjuk meg az Apache 1.3 forráskódjának könyvtárát, amelyet később újrafordítunk olyan alakban, amely már támogatja a mod_ssl modult. Amennyiben a rendszer OpenSSL-könyvtárával végezzük a felépítést, az Apache beállítási lépései közül elhagyhatjuk az SSL_BASE=/usr/local/ssl/ részt. Ha az Apache már tartalmazza az EAPI foltokat, és támogatja a betölthető modulokat, alkalmazhatjuk az 1. fejezetben bemutatott általános APXS felépítési módszert. Ez olyankor lehet hasznos, ha egy már létező mod_ssl telepítést frissítünk. Ha most elindítjuk az Apache-ot, hibaüzenetet kapunk, amelyben a rendszer közli velünk, hogy nem képes elolvasni a kiszolgáló tanúsítványát. A zökkenőmentes indulás érdekében nézzük át a kiszolgálók tanúsítványaival és kulcsaival kapcsolatban leírtakat, valamint olvassuk el fejezetünk Az Apache minimális beállításai című részét. Ha szükségét érezzük, a mod_ssl létrehozhat egy kiszolgálótanúsítványt kifejezetten a felépítési folyamat ellenőrzéséhez, ehhez azonban ki kell adnunk a make certificate parancsot még a make install előtt. Az SSL-támogatás biztosítása az Apache 2.x-ben Az Apache 2-t már a titkosítási eljárások kiviteli korlátozásainak feloldása után adták ki, így a programcsomag moduljai között megtaláljuk a mod_ssl-t is. Amennyiben az Apache-ot a forráskódból építjük fel, a mod_ssl-t már ilyenkor üzembe állíthatjuk az --enable-ssl beállítási kapcsolóval. Ha az OpenSSL-t is a forráskódból kiindulva telepítjük, szükségünk lesz a --with-ssl=/usr/local/ssl/openssl kapcsolóra is. Az Apache minimális beállításai A kulcsok és a tanúsítványok beszerzése után - legyen szó akár saját, akár tanúsító hatóság által kiállított tanúsítványokról - a következő lépés az Apache beállítása. A mod_ssl a telepítés folyamán létrehoz egy 80

93 bemutató SSL-beállításhalmazt, amelyet az Apache 1.3-ban az alapértelmezett httpd.conf fájlban, az Apache 2.0 esetében pedig egy különálló, ssl.conf nevű fájlban helyez el (erre egy Include utasítás hivatkozik a httpd.conf fájlban). Zavarba ejtő lehet a kapott temérdek beállítás, de valójában csak az alábbi lista elemeire kell összpontosítanunk: Listen 80 Listen 443 <VirtualHost _default_:443> ServerName SSLEngine on SSLCertificateFile \ /usr/local/ssl/openssl/certs/ SSLCertificateKeyFile \ /usr/local/ssl/openssl/certs/ </VirtualHost> A Listen utasítások egyike arra utasítja az Apache-ot, hogy a HTTPS alapértelmezett portját, a 443-ast figyelje. Az SSLEngine On bekapcsolja az SSL-t az adott kiszolgáló esetén, míg az SSLCertificateFile és az SSLCertificateKeyFile a tanúsítvány és a titkos kulcs helyét adja meg. Az Apache indítása SSL-támogatással Ha telepítettük és beállítottuk a mod_ssl modult, az alábbi paranccsal indíthatjuk az Apache-ot: apachectl start Amennyiben az alapértelmezett, illetve a gyártó által biztosított SSL-beállítófájlokat használjuk, az SSLutasításokat minden bizonnyal egy <IfDefine SSL> szakaszban találjuk meg. Ezeket a szakaszhatárokat elhagyhatjuk, de elindíthatjuk a kiszolgálót így is: apachectl startssl Ez a parancs a -DSSL jelzőt adja át a kiszolgáló futtatható fájljának, így engedélyezi az SSL-beállításokat. Ezt azonban csak az Apache 1.3-as és 2.0-s változatában kell megtennünk, ugyanis az Apache 2.2 már nem rendelkezik a startssl lehetőséggel, és az SSL-utasításokat pontosan úgy kezeli, mint egyszerű társaikat. Ha titkos kulcsunkat jelszóval védtük, most meg kell adnunk ezt a jelszót. Amennyiben egyszerű felhasználóként telepítettük az Apache-ot, előfordulhat, hogy alapértelmezés szerint a 8443-as portot figyeli. Ennek az az oka, hogy a 443-as port - mint arról az 1. fejezetben említést tettünk - kitüntetett. A telepítés ellenőrzéséhez próbáljuk meg elérni a kiszolgálót a (vagy a fentiekben említett esetben a címen. SSLPassPhraseDialog SSLPassPhraseDialog builtin Amennyiben kiszolgálónk titkos kulcsát jelszóval védtük, a rendszer indításakor meg kell adnunk ezt ennek körülményeit szabályozza az SSLPassPhraseDialog. Alapértelmezett értéke a builtin, amely- 81

94 nek beállítása esetén az Apache minden indításakor rákérdez a jelszóra. Ha nem szeretnénk ezzel bajlódni, ki is kapcsolhatjuk a kulcs védelmét, ezzel azonban felvállaljuk azt a kockázatot, hogy ha a kiszolgálót feltörik, a kulcsunk is a támadók kezébe kerül. Az SSLPassPhraseDialog beállítható úgy is, hogy meghívjon egy külső programot, amely azután a szabványos bemenetére küldi a jelszót: SSLPassPhraseDialog exec:/usr/local/apache/bin/sslpp Ha helyesen írjuk meg ezt a parancsfájlt, nagyobb biztonságban leszünk, mintha egyáltalán nem védenénk a kulcsot (de ez sem igazán biztos módszer). Az SSL teljesítményének fokozása Az SSL működését biztosító algoritmusok meglehetősen igénybe veszik a számítógép processzorát, így különösen, ha több párhuzamos ügyfélkapcsolat működik a kiszolgáló jelentősen lelassulhat. Ráadásul a kiszolgáló és az ügyfél közti egyeztetés (kézfogás) további késedelmet okozhat a kérelmek kiszolgálásában. Szerencsére azonban számos lehetőség kínálkozik a webhely reakcióidejének csökkentésére. Mindenekelőtt engedélyezzük a munkamenetek adatainak átmeneti tárolását, ez ugyanis jelentősen meggyorsíthatja az adott ügyfél kérelmeinek kiszolgálását. Amennyiben SSL-kiszolgálók fürtjét használjuk, érdemes távoli tárolót (distcache) alkalmaznunk, így akkor is tárolhatjuk a kapcsolati adatokat, ha az ügyfél több kiszolgálóhoz kapcsolódik. Az Apache programcsomaggal automatikusan hozzájutunk a távoli tárolás támogatásához magáról az eljárásról pedig a címen tudhatunk meg többet. Esetleg érdemes lehet egy külön gépet beállítanunk az SSL-adatok feldolgozására. Igényeinktől függően ez lehet egy egyszerű terheléselosztó eszköz vagy egy erre a célra üzembe állított, fordított helyettes kiszolgálóként működő gép (olyan webkiszolgáló, amely az ügyféltől származó kérelmeket más webkiszolgálóknak továbbítja). Mindez lehetővé teszi az Apache és az operációs rendszer leghatékonyabb beállítását a gépen, ami nem volna lehetséges, ha más szolgáltatások - mint a PHP, a Tomcat vagy a MySQL - is futnának rajta. A fordított helyettes kiszolgálók (reverse proxy) használata számos előnnyel jár, hiszen a terheléselosztás mellett lehetővé teszi, hogy az ügyfelek a megfelelő tanúsítványok birtokában egyszerre több háttérkiszolgálót is elérjenek. Minderről bővebben a 10. fejezetben olvashatunk. Végezetül, használhatunk titkosító kártyát is, amely kifejezetten arra hivatott, hogy az SSL-műveletek terhét levegye a kiszolgáló válláról. Az Apace 2.2 képes kezelni ezt az eszközt - ennek mikéntjéről az SSLCryptoDevice utasítás leírása árulkodik. Átirányítás SSL-kapcsolatra <VirtualHost :80> ServerName prívate.example.com Redirect / </Virtualhost> Ha egy weboldalt kizárólag az SSL-en keresztül szeretnénk elérhetővé tenni, egy Redirect utasítást alkalmazhatunk a <VirtualHost> tárolón belül, amely figyeli a HTTPkérelmeket, és a fenti példához hasonló módon átirányítja azokat a biztonságos webhelyre. Ez hasznos lehet, hiszen a felhasználók gyakran elfeledkeznek arról, hogy helyett előtagot kell használniuk. 82

95 Név alapú virtuális kiszolgálók és az SSL A mod_ssl felhasználói körében gyakran felmerül a kérdés: lehetséges-e név alapú virtuális kiszolgálókat használni SSL-kapcsolattal? Nos, a rövid válasz: nem. A problémát az okozza, hogy a név alapú virtuális kiszolgálók kezelése az ügyfelek HTTP-kérelmeinek Host: fejlécén alapul, hiszen egy IP címhez több ilyen virtuális kiszolgáló is tartozhat. Az SSL kapcsolat azonban a TCP protokoll szintjén épül ki, még mielőtt a HTTP-kérelmek egyáltalán létrejöhetnének. A kiszolgáló így a kapcsolódás során képtelen megállapítani, melyik virtuális kiszolgálóhoz kíván csatlakozni az ügyfél, és így melyik tanúsítványt és kulcsot kell használnia. Mindazonáltal létezik egy szabvány (nevezetesen az RFC 2817), amely lehetővé teszi, hogy egy már meglevő HTTP-kapcsolatot HTTPS-kapcsolattá alakítsunk. Ez persze megoldaná a gondokat, de e könyv írásának idején még egyetlen komolyabb böngésző sem valósította meg ezt a lehetőséget. A kiszolgálóoldalon nagyobb a fogadókészség, hiszen az Apache 2.2 mod_ssl modulja, valamint a Netware Apache SSL-modulja, a mod_nw_ssl is támogatja az RFC 2817-es szabványt. Az Apache hitelesítési moduljai és az SSL SSLOptions +FakeBasicAuth Ha a fenti beállítást bekapcsoljuk, a kiszolgáló az ügyfél tanúsítványának Subject Distinguished Name mezőjéből az egyszerű HTTP-hitelesítésénél megismert felhasználónevet hoz létre. Ilyenkor a hozzáférés-szabályozásra a 6. fejezetben megismert egyszerű hitelesítési módszerek alkalmazhatók. Ezeknek a hitelesítési moduloknak a számára úgy fest a helyzet, mintha a felhasználó érvényes azonosítót és jelszót adott volna meg. A beállítás használatához el kell végeznünk néhány módosítást a felhasználói adatbázisokban a részletekről az SSLOptions utasítás leírásából tájékozódhatunk. Figyelmeztető üzenetek SSL-képes webhelyek elérésénél Esetenként, ha SSL-képes webhelyeket látogatunk meg, előfordul, hogy egy figyelmeztető ablak jelenik meg, amely közli, hogy valami nincs rendjén a weboldallal. Az okok leggyakrabban az alábbi három csoportba sorolhatók: A tanúsítvány lejárt. A kereskedelmi tanúsítványok többnyire csak meghatározott időtartamig érvényesek, majd ezt követően elévülnek. A tanúsítványban szereplő tartománynév nem egyezik a böngészőbe írttal. Ilyesmi akkor következik be, ha a tanúsítványt nem a szóban forgó webhelyhez adták ki. A tanúsítványt olyan tanúsító hatóság írta alá, amelyet a böngésző nem ismer, vagy nem tart megbízhatónak. Ez történhet például akkor, ha egy tesztelési célokra készített saját tanúsítványt használunk. Ügyféltanúsítványok készítése Ügyféltanúsítványok használatánál a kiszolgáló a kézfogás során ellenőrzi, hogy az ügyfél rendelkezik-e érvényes tanúsítvánnyal, és azt a kiszolgáló által elismert tanúsító hatóság adta-e ki. Az ügyféltanúsítványok jóllehet kezelésük és kiadásuk körülményes nagyszerű módot adnak céges webhelyek és 83

96 webszolgáltatások elérésének korlátozására. Ez biztosabb módszer, mint a felhasználónevek és a jelszavak használata, mivel a tanúsítványokat nem lehet egyszerűen kitalálni vagy ellopni. Ha saját magunk tanúsító hatósága szeretnénk lenni, először is létre kell hoznunk egy gyökértanúsítványt. Ezt megtehetjük közvetlenül az openssl ca paraméterének használatával vagy a hozzá tartozó kényelmes CA.pl burkoló parancsfájllal. Új tanúsító hatóság létrehozásához az alábbi parancsot használhatjuk: CA.pl -newca A parancsfájl létrehoz egy titkos kulcsot, egy kiszolgálótanúsítványt, valamint további szükséges elemeket, végezetül pedig létrehozza a democa könyvtárat, amely a kapott fájlokat tárolja. A következő lépésben elkészítünk egy tanúsítványkérelmet, és alá is írjuk: CA.pl -newreq CA.pl -signreq A kapott CA fájl PEM formátumú, de érdemes átalakítanunk, hogy a böngészők kényelmesebben beolvashassák: CA.pl -pkcs12 A tanúsítvány beolvasásának módszere a böngészőtől függően változó lehet - az Internet Explorerben például egyszerűen a tanúsítvány fájljára kell kattintanunk, és követni a kapott utasításokat. Hitelesítés ügyféltanúsítványokkal SSLVerifyClient require SSLCACertificateFile \ /usr/local/ssl/openssl/certs/ca.crt Ha ügyfeleink rendelkeznek a megfelelő tanúsítványokkal, a következő lépés, hogy az Apache kiszolgálóval is tudassuk: esetükben SSL alapú hitelesítésre van szükség, A fenti kódban látható SSLVerifyClient utasítás megköveteli az ügyfelektől az érvényes ügyféltanúsítvány bemutatását. Az SSLCACertificateFile a megbízható tanúsító hatóság tanúsítványának útvonalát tartalmazza ezzel ellenőrizhetjük az ügyfelek tanúsítványainak érvényességét. A mod_ssl-en túl A mod_ssl mellett számos más lehetőség is rendelkezésünkre áll az SSL protokoll használatára. Mindjárt itt van az Apache 1.3 Apache-SSL modulja - az a modul, amelyből a mod_ssl származik. Az Apache- SSL letölthető a címről. Számos gyártó, köztük az IBM, saját SSLmodulokat ad Apache alapú webkiszolgáló csomagjaihoz, amelyek többnyire nem az OpenSSL eszközeire épülnek. Végezetül, használhatunk önálló eszközöket is, mint az stunnel, amelyekkel az SSL-kapcsolatokat már létező Apache kiszolgálókhoz köthetjük (bővebben lásd a címen). Ez a módszer nem olyan rugalmas, mint a mod_ssl használata, de jól jöhet olyan helyzetekben, amikor nem lehetséges vagy erősen ellenjavallt a futó kiszolgáló beállításainak megváltoztatása. 84

97 Az SSL-képes webhelyek parancssori ellenőrzése # openssl s_client -connect A biztonságos webkiszolgálók ellenőrzésére használhatjuk az openssl-t vagy egy másik SSL alapú eszközt, amilyen például az stunnel ( A fenti paranccsal az IBM webhelyéhez kapcsolódunk a HTTPS protokollal. A futás eredményeként részletes adatokat tudhatunk meg az SSL protokoll működéséről, és hozzájutunk a kapcsolat kiszolgálótanúsítványához. A következőkben megnézhetjük, milyen választ kapunk egy GET / HTTP/1.0 parancsra - éppúgy, mint az 1. fejezetben, amikor a Telnet segítségével kapcsolódtunk egy hagyományos webkiszolgálóhoz, és így közvetlenül küldhettünk neki parancsokat. Az SSL-megvalósítások hibáinak kezelése SetEnvIf User-Agent.*MSIE.* nokeepalive \ ssl-unclean-shutdown downgrade-1.0 \ force-response-1.0 Egyes böngészőknek (illetve kiszolgálóknak, ha fordított helyettes kiszolgálót használunk) köztudottan gondjaik vannak a SSL protokoll bizonyos változataival, illetve lehetőségeivel. Megfelelő környezeti változókkal azonban kikényszeríthetünk bizonyos viselkedésmódokat ez különösen akkor hasznos, ha kereskedelmi webhelyet üzemeltetünk, és szükségünk van a régebbi böngészők támogatására is. A fent bemutatott kódrészlet, amelyet az alapértelmezett beállítófájlból ollóztunk ki, például az Internet Explorer böngészők SSL-megvalósításának egy hibáját orvosolja. Ha az ügyfél böngészőjének leírása tartalmazza az MSIE karakterláncot, kikapcsoljuk a kapcsolatok életben tartásának támogatását, és a HTTP protokoll egy korábbi változatát használjuk. Összetett hozzáférés-szabályozás a mod_ssl modullal SSLRequire ( %{SSL_CIPHER}!~ m/^(exp NULL)-/ \ and %{SSL_CLIENT_S_DN_O} eq Snake oil, Ltd. \ and %{SSL_CLIENT_S_DN_OU} in { Staff, CA, Dev }\ and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \ and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \ or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/ Ez a példa azt mutatja be, hogy miként érvényesíthetünk tetszőleges hozzáférési korlátozásokat az SSLRequire utasítás paramétereinek beállításával. Amint azt a mod_rewrite modulnál már megszokhattuk, az SSLRequire beállítása meglehetősen összetetté válhat, de a lehetőségei éppen ezért szinte határtalanok. Példakódunk a következőket ellenőrzi: Az SSL-kapcsolat nem használ gyenge vagy NULL titkosítást, a tanúsítványt egy meghatározott tanúsító hatóság adta ki egy adott csoport számára, a hozzáférés munkanapon (hétfőtől péntekig) és munkaidőben (reggel 8 és este 8 között) történt. Az ügyfél egy belső, megbízható hálózatról kapcsolódik (ezt adja meg a REMOTE_ADDR paraméter). Ha minderről bővebben is szeretnénk tájékozódni, olvassuk el az SSLRequire utasítás leírását. 85

98 Kapcsolódó fejezetek Amennyiben az Apache-ot fordított helyettes kiszolgálóként használjuk, az ügyfelek tanúsítványai és SSLkapcsolatokhoz köthető adatai nem érhetők el a háttérkiszolgálók számára. A 10. fejezetben megmutatjuk, mit tehetünk ezeknek a problémáknak az elhárítása érdekében. 86

99 8 Tartalom közzététele a DAV segítségével Tartalom közzététele az Apache segítségével Ha más felhasználók webhelyeit üzemeltetjük, lehetőséget kell adnunk arra, hogy feltölthessék és kezelhessék a hozzájuk tartozó tartalmat. Fejezetünk középpontjában az a mod_dav modul áll, amellyel biztosíthatjuk felhasználóinknak az előbb említett lehetőségeket. Megtanuljuk, hogyan korlátozzuk egyes erőforrások írásának jogát, miként állítsuk be a különféle ügyfeleket (ide tartoznak a Windows webmappái is), és szó esik a gyakrabban felmerülő problémák megoldási módozatairól, valamint arról is, hogy miként engedélyezzük a felhasználói könyvtárakat, amelyekkel külön webtárhelyet biztosíthatunk minden felhasználónknak. Ismerkedés a WebDAV-val A WebDAV a Web-based Distributed Authoring and Versioning (webes elosztott tartalom- és változatkezelő rendszer) kifejezés rövidítése. De hogy mi is valójában? Nos, a WebDAV egy protokoll, amely a HTTP bővítéseként lehetővé teszi a felhasználóknak, hogy távolról tartalmat töltsenek fel és kezeljenek. Ahhoz azonban, hogy megértsük a WebDAV hihetetlen előnyeit, előbb meg kell ismerkednünk a korábbi közzétételi eljárások korlátaival. A Web hőskorában a kiszolgálón található tartalmat a webmesterek és a rendszergazdák szerkesztették, közvetlenül a héjból, a vi, az emacs és más hasonló szövegszerkesztőkkel. Ahogy azonban a hálózat növekedett, a szerepek megváltoztak: a rendszergazdák karban tartották a kiszolgálót, magát a tartalmat azonban a programozók és a felhasználók adták. Mindez szükségszerűvé tette olyan módszerek megjelenését, amelyekkel a felhasználók feltölthetik és kezelhetik a tartalmat. A feladatok ilyen szétválasztásával ugyanakkor megjelent az igény a hozzáférés-korlátozási módszerekre, valamint olyan eljárásokra, amelyekkel a technikailag kevésbé képzett felhasználók is kezelhetik a webhelyük tartalmát. Az egyszerű szövegszerkesztőkből kifinomult közzétételi eszközök lettek, amelyek lehetőségeik sokrétűségében és használatuk kényelmében utolérték hagyományos környezetekben használt társaikat. Sajnos a tartalom feltöltésére nem volt semmiféle szabványos módszer. Voltak rendszerek, amelyekben héjelérést biztosítottak a felhasználóknak, másutt az FTP-t vagy más egyedi protokollokat használtak erre a célra. A héjeléréshez azonban szükség van arra, hogy a felhasználó legalább alapjaiban tisztában legyen a Unix parancssorának műkődésével, és még így is nyakába szakadnak a kiszolgáló közvetlen elérésének nehézségei és biztonsági kockázatai. Az FTP ügyfél használatához le kell tölteni és telepíteni egy újabb segédprogramot, nem is beszélve arról, hogy üzemeltetni kell egy FTP kiszolgálót is. Végezetül, a saját parancsfájlok, a feltöltő űrlapok és az egyedi protokollok (amilyen például a Microsoft FrontPage-é) számos együttműködési és biztonsági kérdést vetnek fel. A WebDAV átvágja a gordiuszi csomót, és egy szabványos protokollt nyújt, amelyet beépíthetünk a webkiszolgáló szerkezetébe. A HTTP protokollt kiegészítve új műveleteket tesz elérhetővé az erőforrások létrehozására, törlésére, valamint zárolására. A WebDAV a mod_dav alakjában érhető el az Apache-ban, amely az 1.3-as változatban külső, míg a 2.0-ban beépített modulként jelenik meg. 87

100 A mod_dav használatának előnyei Amint az előzőekben már említettük, a mod_dav egy a HTTP protokollt bővítő Apache-modul ennek köszönhetően képes kihasználni az Apache számos lehetőségét, így a titkosítás és a tanúsítványok kezelése kapcsán az SSLtámogatást, a HTTP egyszerű hitelesítési módszerét, a helyettes kiszolgálókat és más egyebeket. Az egység az Apache-ba építve más lehetőségeket is ad, így a közös hozzáférés-szabályozási módszerek használatát, valamint az együttműködést az olyan parancsfájlmotorokkal, mint a mod_perl vagy a PHP. Maga a DAV protokoll is bővíthető. Jóllehet az általa elért erőforrások jobbára a fájlrendszerben találhatók, a DAV képes szabványos felületként viselkedni számos háttértároló adatbázisok, változatkezelő rendszerek, egyedi dokumentumkezelő környezetek felé. Példaként megemlíthetjük a gyűjtemény fogalmát, amely a DAV-ban fájlok csoportját jelenti. Ez többnyire egy könyvtárnak felel meg a kiszolgálón, de más háttértároló esetén teljesen új jelentést kaphat. Végezetül, fontos elmondanunk, hogy a WebDAV-ot napjaink szinte minden webes közzétételi környezete, irodai programcsomagja és asztali rendszere megvalósítja. A WebDAV és a HTTP protokoll A DAV a szabványos HTTP protokollra épül, amely lehetővé teszi a böngészők és a webkiszolgálók adatcseréjét. Bővebb tartalmat ad a HTTP eredeti függvényeinek, de újabbakat is elérhetővé tesz ezeket mutatjuk be a következőkben. Ismeretükre feltétlenül szükség lesz, ha szabályozni szeretnénk a DAV által kezelt erőforrások elérését. COPY: Fájlokat, illetve gyűjteményeket (a fájlrendszerben: könyvtárakat) másol. További fejlécek segítségével alkalmas egymásba ágyazott gyűjtemények mélységi másolására is. MOVE: Fájlokat, illetve gyűjteményeket helyez át. MKCOL: Új gyűjteményt hoz létre. Amennyiben nem létezik szülőgyűjtemény, hibaüzenetet ad a szülőgyűjteményeket közvetlenül, a PUT függvénnyel kell létrehoznunk. PROPFIND: Korábban megtanultuk, hogy a DAV-erőforrásokhoz tartozhatnak metaadatok is ezek lekérdezésére alkalmas a PROPFIND. PROPPATCH: Ezzel a módszerrel metaadatokat hozhatunk létre, illetve módosíthatjuk vagy törölhetjük azokat. LOCK és UNLOCK: Ezekkel a függvényekkel zárolhatjuk erőforrásainkat, illetve feloldhatjuk a zárolást. Ez a lehetőség olyankor lehet hasznos, amikor szerkesztjük az erőforrást, és nem szeretnénk, hogy eközben más is hozzányúlhasson. A DAV protokoll módosítja az eredeti HTTP-függvényeket (amilyen a GET és a PUT), hogy azok észleljék a zárolást. Az OPTIONS bővített változata a DAV lehetőségeiről is tájékoztat. A mod_dav telepítése Apache 2.0 kiszolgálókon./configure --enable-dav Az Apache 2.0 programcsomagjában szerepel a mod_dav, jóllehet alapértelmezés szerint kikapcsolt állapotban. Bekapcsolásához ugyanazt kell tennünk, mint más beszerkesztett modulok esetében. A mod_dav eredetileg a fájlrendszert használja háttértárolóként (--enable-dav-fs), de más tárolótípust is megadhatunk így szóba jöhet a Subversion forráskezelő rendszer vagy különféle adatbázisok. 88

101 Amennyiben az Apache 2.0 Windows-kiadását használjuk, a mod_dav egy DLL alakjában már jelen van, mindössze a megfelelő LoadModule utasításokat kell bekapcsolnunk a httpd.conf beállítófájlban: LoadModule dav_module modules/mod_dav.so LoadModule dav_f s_module modules/mod dav_fs.so A mod_dav telepítése Apache 1.3 kiszolgálókon tar xvfz mod_dav tar.gz cd mod_dav /configure --with-apxs=/usr/local/apache/bin/apxs make make install Az Apache 1.3 nem rendelkezik beépített DAV-támogatással, így le kell töltenünk és telepítenünk a mod_ dav-ot, ugyanúgy, ahogy más külső modullal tennénk. A Unix rendszerre írt forráskódot, valamint a windowsos telepítőfájlokat letölthetjük a következő címekről: http: // mod_ dav/ és A WebDAV alapbeállításai DAVLockDB /usr/local/apache/var/davlock <Location /> Dav On </Location> A DAV beállítása nem nehéz, mindössze a DAV on utasítást kell elhelyeznünk abban a <Location> vagy <Directory> tárolóban, amelynek a tartalmát elérhetővé szeretnénk tenni a DAV-on keresztül. Példánk azt mutatja, miként tehetünk egy teljes webhelyet DAV-képessé. A DAV saját zárolási rendszerrel rendelkezik, amely nem hagyatkozik a háttérben meghúzódó fájlrendszer lehetőségeire. A zárolást szabályozó fájl helyét a DAVLockDB utasítással határozhatjuk meg. Ha összetettebb DAV-környezetet építünk ki, szükségünk lesz pár további beállításra is: biztonságossá kell tennünk a rendszert, és meg kell oldanunk az együttműködést az esetleg hibás külső ügyfelekkel. Mindezekről a következőkben bővebben is olvashatunk. A WebDAV biztonsági beállításai <LimitExcept GET HEAD OPTIONS> require user davuser </LimitExcept> A DAV működésének engedélyezése alapesetben komoly biztonsági kockázatokkal jár, hiszen a felhasználók így olvashatják és módosíthatják a webes tartalmakat. E tartalmak között szerepelhetnek CGI és PHP parancsfájlok forráskódjai, amelyekben akár felhasználónevek és jelszavak is rejtőzhetnek, ezért fontos, hogy védelmet biztosítsunk a DAVképes erőforrások számára. Mivel a DAV a HTTP-re épül, mindezt megtehetjük az Apache szabványos hozzáférésszabályozó moduljaival. Példánkban bemutatjuk, miként köve- 89

102 telhetünk meg érvényes felhasználónevet és jelszót ahhoz, hogy a felhasználó írási jogosultságot szerezzen a DAVerőforrásokhoz, amilyen az MKCOL. A hozzáférés-szabályozást a 6. fejezetben megismert módon a mod_auth modul és a <LimitExcept> utasítás segítségével valósítjuk meg példa A DAV-elérés védelme <Location /> Dav On AuthType basic AuthName DAV Resource AuthUserFile /usr/local/apache2/conf/htusers <LimitExcept GET HEAD OPTIONS> require user davuser </LimitExcept> </Location> A <Limit> és a <LimitExcept> tárolóutasítások, amelyek lehetővé teszik, hogy a megadott beállításokat egyes kérelmi módszerekre alkalmazzuk. Az egyszerű HTTP-függvények esetében ez nem túl hasznos lehetőség, de a DAV-nál annál inkább. Példánk kódja mindenki számára elérhetővé teszi a webes tartalmat, aki egyszerű HTTP-függvényeket használ, a DAV-eléréshez azonban hitelesítést igényel. Életbe léptethetünk egyéb óvintézkedéseket is, így futtathatjuk a DAV-ot egy különálló, erre a célra üzembe állított Apache-példányon. Ez a kiszolgáló egy külön portot használhat, így könnyen elvágható a külvilágtól, és biztonságossá tehető. A további védelem érdekében megkövetelhetjük az SSL vagy IP cím alapú hitelesítést is. DAV-erőforrások elérése a Microsoft Office-ból A Microsoft Office újabb változatában amilyen az Office 2000 vagy az Office XP közvetlenül megnyithatjuk és szerkeszthetjük a DAV-képes kiszolgálók (köztük az Exchange újabb változatai) dokumentumait. Nem kell mást tennünk, mint megadni egy DAV-képes terület URL-jét a Megnyitás párbeszédablakban, de létrehozhatunk számára egy új hálózati helyet is. Ha ez utóbbi mellett döntöttünk, a későbbiekben könnyedén létrehozhatjuk, szerkeszthetjük és megoszthatjuk a távoli kiszolgáló dokumentumait. DAV-erőforrások elérése a Microsoft Windowsból A Microsoft operációs rendszereinek újabb változatai, amilyen a Windows 2000 vagy a Windows XP, a webmappák révén háttértámogatást nyújtanak a DAV számára. A rendszerben ezek egyszerű asztali mappákként jelennek meg; a felhasználók a szokásos módon elhelyezhetik bennük a fájljaikat, duplán rájuk kattintva szerkeszthetik őket, és más hasonló műveleteket végezhetnek velük. A Windows 2000-ben a DAVerőforrásokat webmappaként elérhetjük az Internet Explorerből, illetve egy varázsló használatával. A következőkben feltételezzük, hogy Apache kiszolgálónk a tartományban üzemel, a DAV-támogatás pedig a /davdocs könyvtárban engedélyezett. Győződjünk meg arról, hogy működik a megfelelő RedirectCarefully utasítás erről fejezetünk Hibás ügyfelek kezelése címszavánál olvashatunk bővebben. Nyissuk meg az Internet Explorert. Kattintsunk a File (Fájl) menüre, és válasszuk az Open (Megnyitás) pontot, így egy párbeszédablakba jutunk. 90

103 Írjuk be a címet. Kapcsoljuk be az Open as Web Folder (Megnyitás webmappaként) jelölőnégyzetet, majd kattintsunk az OK gombra. Az Internet Explorer csatlakozik az erőforráshoz, és ezt követően egy hagyományos mappa kezelőfelületéhez jutunk, amelyben új könyvtárakat hozhatunk létre, továbbá mozgathatjuk és szerkeszthetjük a fájlokat. A mappa bekerül a hálózati helyek közé, és a későbbiekben elérhetjük az Asztal megfelelő ikonjára kattintva. Ha új webmappát szeretnénk a rendszerünkbe illeszteni, megtehetjük azt is, hogy megnyitjuk a My Network Places (Hálózati helyek) mappát, és ott az Add Network Place (Hálózati hely hozzáadása) ikonra kattintunk, majd követjük a varázsló útmutatásait. DAV-erőforrások elérése a Firefoxból A könyv írásának idején a Firefox még nem rendelkezett beépített DAV-támogatással. Mindazonáltal a Windowsra írt openwebfolder bővítmény segítségével csatlakozhatunk a Microsoft Windows WebDAVösszetevőjéhez, és így hozzáférhetünk a DAV-erőforrásokhoz a Firefoxból. Ez elérhető a openwebfolder.mozdev.org címen. A telepítéshez kattintsunk a Firefoxban a oldal XPI hivatkozására, és kövessük a kapott útmutatást. Miután újraindítottuk a Firefoxot, a weboldalakra az egér jobb gombjával kattintva kapott helyi menüben megjelenik az Open as Web Folder pont, amellyel az adott oldalt a WebDAV-on keresztül érhetjük el. DAV-erőforrások elérése a parancssorból./cadaver dav:!> open A DAV-erőforrások elérésére számos parancssori eszközt használhatunk, amelyek egyrészt biztosítják az interaktivitást, másrészt könnyen beépíthetők a felügyeleti parancsfájlokba, és nagyszerűen helyettesítik FTP és scp alatt működő társaikat. A legnépszerűbb nyílt forrású ügyfelek a cadaver és a sitecopy. Az előbbi egy interaktív héjat biztosít olyan FTP-szerű parancsokkal, mint az ls, a put, a get és más hasonlók. Az alábbi példában bemutatjuk, miként érhetünk el a cadaver segítségével egy DAV-képes kiszolgálót, hogyan jeleníthetjük meg az elérhető erőforrásokat, és hogyan szerkeszthetünk egy távoli fájlt../cadaver dav:!> open dav:/> ls Listing collection / : succeeded. Coll: images 0 Dec Coll: styles 0 Dec Home.html 4816 Aug 14 14:19 company.html 5352 Dec partners.html 6087 Dec solutions.html

104 Dec dav:/> edit solutions.html Locking solutions.html : succeeded. Downloading /solutions.html to /tmp/cadaver-editzezdl9.html Progress: [===========================>] 100.0% of 6230 bytes succeeded. Running editor: vi /tmp/cadaver-editzezdl9.html... Changes were made. Uploading changes to /solutions.html Progress: [===========================>] 100.0% of 6232 bytes succeeded. Unlocking solutions.html : succeeded. dav:/> A cadaver a címről tölthető le. A sitecopy segítségével egy helyi könyvtárfát tarthatunk fenn, amelyet különböző protokollok alkalmazásával szerepel köztük a DAV is - hangolhatunk össze a távoli kiszolgáló tartalmával. A program letölthető a címről. 92

105 Hibás ügyfelek kezelése BrowserMatch Microsoft Data Access Internet Publishing Provider redirect-carefully BrowserMatch ^gnome-vfs redirect-carefully Tegyük fel, hogy képtelenek vagyunk DAV-kiszolgálónkhoz kapcsolódni a Microsoft webmappáin keresztül vagy a Gnome virtuális mappáinak régebbi változataival, és elérési naplónkban valami ilyesmit találunk: OPTIONS /davdocs HTTP/ Ilyen esetben bizony belefutottunk egy aprócska hibába, amely jelen van a WebDAV néhány ügyféloldali megvalósításában. Az Apache átirányítja az ügyfelet (vagyis a 301-es HTTP kódot küldi neki), az azonban összezavarodik, és nem követi ezt. Szerencsére az Apache-nak van megoldása erre a helyzetre is egyszerűen kihagyja az átirányítást, ha beállítottuk a redirect-carefully környezeti változót. Példánk, amelyet az Apache alapértelmezett beállítófájljából ollóztunk ki, két olyan WebDAV-ügyfélre állítja be a redirect-carefully környezeti változót, amelyekről köztudott, hogy ilyen problémáktól szenvednek. A mod_speling és a DAV Amennyiben a DAV-ot használjuk, mindenképpen ki kell kapcsolnunk a mod_speling modult. Erre azért van szükség, mert számos DAV-hoz kötődő művelettel ütközik újonnan létrehozott erőforrásainkat például (tévesen) megfeleltetheti más, hasonló nevű fájloknak. A mod_speling feladata a felhasználók gépelési hibáinak kijavítása; bővebben a 4. fejezetben olvashattunk róla. A dinamikus tartalomkezelés és a DAV Alias /php /usr/local/apache/php_files Alias /php-source /usr/local/apache/php_files <Location /php-source> DAV On ForceType text/plain </Location> Amikor dinamikusan létrehozott, például PHP vagy CGI parancsfájlokkal előállított tartalmat próbálunk elérni, előfordulhat, hogy az Apache magát a dinamikus tartalmat, nem pedig a forráskódot adja vissza. Más szóval, a fájl feldolgozás utáni tartalmát kapjuk meg, amelyet a kiszolgáló már értelmezett, nem pedig az eredeti forráskódot. Ennek elkerülésére üzembe állíthatunk egy párhuzamos webkiszolgálót, amely nem rendelkezik PHP-támogatással (lásd korábban). A probléma megoldásának másik módja, ha ugyanazt a fájlrendszerbeli útvonalat különböző URL-eknek feleltetjük meg, és esetenként eldöntjük, hogy ki- vagy bekapcsoljuk az adott modult. Példánk, amely a DAV leírásából származik, bemutatja, hogyan tehetjük meg ezt. A kódrészlet minden tartalmat, amelyet a /php-source URL-en keresztül szolgáltatunk, a txt/plain típusba kényszerít, így megakadályozza a PHP-motor működését. 93

106 Felhasználói oldalak engedélyezése UserDir enabled UserDir public_html Bizonyára találkoztunk már ilyen típusú webcímekkel: Nos, ezeket nevezik felhasználói weboldalaknak. A rendszer minden felhasználóhoz rendel egy URL-t, amelyben a ~ karakter után a felhasználó neve áll. Amikor az Apache egy ilyen kérelemmel találkozik, egy a felhasználó alapkönyvtárában található alkönyvtárnak felelteti meg így minden felhasználónak lehetősége nyílik arra, hogy saját tartalmat tegyen közzé. Mindezt a mod_userdir modullal valósíthatjuk meg, be- és kikapcsolását pedig a UserDir enabled, illetve a UserDir disabled utasításokkal érhetjük el. Ha az egyes felhasználók esetében külön szeretnénk engedélyezni vagy megtiltani ezt a viselkedést, felsorolhatjuk őket a következőhöz hasonló módon: UserDir disabled mysql root Amennyiben a UserDir utasítás első paramétere nem enabled vagy disabled, azt határozhatjuk meg vele, hogy hol tároljuk az egyes felhasználói könyvtárakat. Így például a UserDir public_html utasítással a kiszolgáló a címre érkező kérelmeket a /home/user/ public_html/ könyvtárhoz irányítja át. Az útvonal tartalmazhat helyettesítő karaktereket is, mint az alábbi példában: UserDir /home/*/web Ilyenkor a kiszolgáló a címnek a /home/ user/web/index.html fájlt felelteti meg. Fontos, hogy a felhasználó, akinek a nevében az Apache fut, képes legyen olvasni a felhasználói könyvtárakat. Végezetül, a UserDir utasítással meghatározott URL-ekre is átirányíthatjuk ügyfeleinket. Az alábbi sor például a címről a example.com/user/index.html címre irányít át: UserDir Egyéb módszerek a felhasználói könyvtárak kezelésére RewriteEngine On RewriteCond %{HTTP_HOST}!^(www\.) RewriteCond %{HTTP_HOST} ^([^.]+)\.example\.com RewriteRule ^(.*)$ /home/%1/public_html$1 Ha nem szeretnénk bekapcsolni a mod_dir modult, vagy nem pontosan az általa biztosított lehetőségekre van szükségünk, alkalmazhatjuk helyette a mod_vhost_alias vagy a mod_rewrite modult is. A példa azt mutatja be, hogy miként irányíthatjuk át a user.example.com címre érkező kérelmeket a megfelelő felhasználói könyvtárhoz a mod_rewrite segítségével. 94

107 A DAVLockDB segít a bajban No such file or directory: A lock database was not specified with the DAVLockDB directive. One must be specified to use the locking functionality. [500, #401] Ha ilyen üzenettel találkozunk, az arra utal, hogy beállítófájlunkban el kell helyeznünk egy DAVLockDB utasítást, valahogy így: DAVLockDB /usr/local/apache/var/davlock Ha az utasítást elhelyeztük ugyan, de a kiszolgáló nem képes írni a zárolási fájlt tartalmazó könyvtárba, az alábbihoz hasonló üzenetet kapunk: The lock database could not be opened, preventing access to the various lock properties for the PROPFIND. [500, #0] Gondjaink megoldódnak, ha írási engedélyt adunk a könyvtárra annak a felhasználónak, akinek a nevében az Apache fut. 95

108 96

109 9 Teljesítmény és méretezhetőség Az Apache finomhangolása Ebben a fejezetben azt mutatjuk be, hogy mely beállításokkal befolyásolhatjuk az Apache teljesítményét és méretezhetőségét, és milyen módok kínálkoznak ezeknek a tulajdonságoknak a finomhangolására. A jó hír ugyanakkor az, hogy erre legtöbbször nincs is szükség. A méretezhetőséggel és a sebességgel kapcsolatos kérdések általában a dinamikus tartalmat készítő motorokhoz, valamint az adatbázis rétegéhez kötődnek, nem pedig az Apache webkiszolgálóhoz. A következőkben egyes problémákat és megoldásukat olyan általánosságban tárgyaljuk majd, hogy a leírtak egyéb kiszolgálókra is alkalmazhatók legyenek, míg más esetekben kifejezetten az Apache-ra jellemző módszereket mutatunk be. A teljesítményről és a méretezhetőségről A számítógépes rendszerek e két jellemzőjének javításához egyszerre van szükség tapasztalatra, lelkiismeretes felderítő munkára és a kiszolgáló belső folyamatainak mély megértésére. Fejezetünk ezért nem vállalkozhat többre annál, mint hogy apró gondolatmorzsákat adjon, amelyeket felcsipegetve elindulhatunk a hosszú úton. Kezdetnek a tisztánlátás kedvéért - rögzítsük, hogy a teljesítmény a kérelmek kiszolgálásának gyorsaságát jelenti, míg a méretezhetőség az egyszerre kiszolgálható kérelmek számának függvénye. A hardver finomhangolása vmstat Kiszolgálónk teljesítményét sok esetben drámaian növelhetjük, ha egyszerűen veszünk néhány RAM modult. Ez lehetővé teszi az operációs rendszernek a gyakran olvasott fájlok átmeneti tárolását, és így több Apachegyermekfolyamatot is futtathat párhuzamosan. A második megfontolandó tényező a merevlemez sebessége. Ha a lemezegység gyors, ráadásul jelentős méretű beépített gyorsítótárral rendelkezik, érezhetően növekedhet a fájlok betöltésének sebessége. Érdemes lehet a meghajtó egyes paramétereit is módosítani, így például lehetővé tenni a DMA (közvetlen memóriaelérés) támogatását. Linuxon ehhez a hdparm segédprogramot használhatjuk. A szűk keresztmetszetek felkutatásában komoly segítséget adhat a Unix rendszerek cmstat eszköze, amely adatokat szolgáltat a folyamatokról, a memóriáról, a lapozásról, a bemeneti-kimeneti blokkműveletekről, a csapdákról, valamint a processzor tevékenységéről. Az SSL használata egyszerre sok felhasználó kiszolgálása mellett komoly igényeket támaszthat a proceszszorral szemben. Ilyenkor egy gyorsabb processzor vagy egy kifejezetten erre a célra gyártott titkosító kártya jelenthet megoldást. Az itt alkalmazható egyéb beállításokról a 7. fejezetben, valamint a 10. fejezet hatékonyságnövelésről szóló részében olvashatunk. Végül, meg kell említenünk, hogy a több processzort vagy egy többmagos processzort használó gépek jelentősen javítják a folyamat alapú webkiszolgálók méretezhetőségét, így közepes vagy nagy terheléssel járó feladatokhoz érdemes ilyen gépeket használni. 97

110 Az operációs rendszer korlátainak tágítása ulimit Az Apache méretezhetőségét az operációs rendszerek számos tulajdonsága gátolhatja, amelyek kapcsolódhatnak a folyamatok létrehozásához, a memóriakorlátozásokhoz, valamint ahhoz, hogy hány fájl vagy kapcsolat lehet egyszerre nyitva. A Unix ulimit segédprogramja lehetővé teszi, hogy folyamatonként feltérképezzük ezeket a korlátozásokat, és tegyünk valamit ellenük. A parancs használati alakjáról az operációs rendszer leírásából tájékozódhatunk. Az operációs rendszer folyamatokkal szembeni korlátozásainak lazítása Léteznek olyan beállítások az Apache-ban, amelyeknek a szerepe abban áll, hogy megakadályozzák, hogy a kiszolgálófolyamatok és szálak száma meghaladjon egy korlátot. Ezzel természetesen befolyásolják a méretezhetőséget, hiszen egyúttal a párhuzamos kapcsolatok számát is korlátozzák, ami közvetlenül befolyásolja az egyszerre kiszolgálható látogatók számát. Ezek a beállítások ráadásul MPM-enként különbözőek lehetnek - erről azonban csak a 11. fejezetben szólunk bővebben. Az Apache MPM-beállításainak ugyanakkor az operációs rendszer szab határt a folyamatok számára vonatkozó korlátozásokkal. A módosításhoz szükséges lépések az operációs rendszertől függően eltérőek lehetnek. A 2.4-es és 2.6-os maggal rendelkező Linux rendszereken a korlátozást futásidőben elérhetjük és módosíthatjuk a /proc/sys/kernel/threads-max fájl szerkesztésével. A fájl tartalmát az alábbi paranccsal tekinthetjük meg: cat /proc/sys/kernel/threads-max És a következővel írhatunk bele: echo érték > /proc/sys/kernel/threads-max A Linuxban (eltérően a legtöbb Unix-változattól) megfeleltetés áll fenn a szálak és a folyamatok között, így az operációs rendszer szempontjából ezek hasonlóan kezelhetők. Solaris rendszereken a fenti paraméterek az /etc/system fájlban módosíthatók. Ilyen változtatások után nem kell újra felépítenünk a magot, de az érvényesítésükhöz újra kell indítanunk a rendszert. A folyamatok összesített számának felső korlátját a max_nprocs, míg az adott felhasználó által futtatható folyamatok számát a maxuproc bejegyzésben állíthatjuk be. A fájlleírók számának növelése Ha egy folyamat megnyit egy fájlt (vagy csatolót), a rendszer egy fájlleírót rendel hozzá, amely mindaddig jelen van, amíg a fájlt be nem zárják. Az operációs rendszer korlátozza az egy folyamat által megnyitható fájlleírók számát, következésképpen a webkiszolgáló párhuzamosan fenntartott kapcsolatainak mennyiségét is. A beállítás módosítása rendszerfüggő - Linux rendszereken a /proc/sys/fs/file-max fájl szolgál erre a célra (olvasásához és írásához az előzőekben bemutatott cat és echo parancsok használhatók). Solaris rendszerek esetében az /etc/system fájl rlim_fd_max beállításával érhetünk célt. 98

111 A módosítások életbe léptetéséhez újra kell indítanunk a rendszert. Bővebb tájékoztatásért látogassuk meg a weboldalt. Külső folyamatok szabályozása RlimitCPU RLimitMem RLimitNProc Az Apache számos utasítással segíti a külső folyamatok által felhasználható erőforrások mennyiségének szabályozását vonatkozik ez a kiszolgáló által indított CGI parancsfájlokra éppúgy, mint az SSI révén futtatott programokra. Az alábbi utasításokat csak Unix rendszereken alkalmazhatjuk, és használatuk meglehetősen rendszerfüggő, de mindenképpen hasznosak lehetnek, ha meg szeretnénk akadályozni, hogy rosszindulatú vagy csak egyszerűen rosszul megírt programok szabadon garázdálkodjanak a gépünkön: RLimitCPU: Két paramétert vár - egy lágy és egy kemény korlátot arra nézve, hogy hány másodpercnyi processzoridő jusson egy folyamatra. Konkrét értékek helyett használhatjuk a max kulcsszót is, amely az operációs rendszer által megengedett leghosszabb futásidőt takarja. A kemény korlát megadása nem kötelező, a lágy korlát értéke változhat az egyes újraindítások között, felső határát a kemény korlát határozza meg. Ha mindez kissé zavarosnak tűnik, hasonló működési elvet találhatunk a 11. fejezetben a ServerLimit és a MaxClients tárgyalásánál. RLimitMem: Az utasítás használati alakja megegyezik az RLimitCPU utasításéval, itt azon ban a folyamatok által legfeljebb felhasználható memória (bájtban megadott) mennyiségét szabályozhatjuk. RLimitNProc: Itt a folyamatok számára érvényes felső korlátot adhatunk meg, az RLimitCPUhoz hasonló alakban. A fájlrendszer teljesítményének növelése A lemez elérése igencsak erőforrásigényes művelet, így hát nem meglepő, hogy meghatározó szerepet játszik a kiszolgáló sebességének meghatározásában. Ha valahogyan elérjük, hogy az Apache, illetve az operációs rendszer kevesebb alkalommal olvasson a lemezről vagy írjon rá, jelentősen növelhetjük a teljesítményt. Tudjuk tehát, hogy mit tegyünk azt pedig, hogy milyen paraméterekkel tehetjük, a következőkben áruljuk el. Mindemellett napjaink operációs rendszerei rendkívül hatékony átmeneti tárolási eljárásokkal rendelkeznek, így ha elegendő mennyiségű RAM-ot építünk a gépünkbe, drámaian felgyorsíthatjuk a gyakran használt fájlok elérését. Fájlrendszerek csatlakoztatása a noatime beállítással A noatime kapcsolóval számos Linux-fájlrendszert csatlakoztathatunk. Ilyenkor az operációs rendszer nem rögzíti a fájlok legutóbbi olvasásának időpontját, azt azonban továbbra is számon tartja, hogy mikor írták őket legutoljára. Mindez jelentős sebességnövekedést vonhat maga után, különösen leterhelt kiszolgálók esetén. Az alábbi sorban az /etc/fstab egy lehetséges bejegyzését mutatjuk be: /dev/hda3 /www ext2 defaults,noatime

112 Közvetett hivatkozások kezelése Options FollowSymLinks Unix rendszereken a közvetett (szimbolikus) hivatkozások különleges típusú fájlok, amelyek más fájlokra mutatnak. Létrehozásuk a Unix ln parancsával lehetséges, használatuk pedig akkor indokolt, ha azt szeretnénk, hogy egy fájl különböző helyeken jelenjen meg. Az Options utasítás két paraméterrel is segíti a közvetett hivatkozások beállításait; ezek a FollowSymLink és a SymLinksIfOwnerMatch. Alapértelmezés szerint az Apache nem követi a közvetett hivatkozásokat, ezzel ugyanis áthághatóvá tenne bizonyos biztonsági szabályokat, és a fájlrendszer olyan részeihez biztosítana elérést, amelyeket egyébként nem szerettünk volna nyilvánossá tenni. Így például semmi sem akadályozza meg, hogy egy olyan közvetett hivatkozást hozzunk létre a webhelyünk nyilvános részén, amely egy korlátozott elérésű fájlra vagy könyvtárra mutat. Így tehát, szintén az alapértelmezésnek megfelelően, az Apache-nak minden fájl esetében ellenőriznie kell, hogy esetleg közvetett hivatkozással áll-e szemben. Amennyiben a SymLinkIfOwnerMatch beállítással éltünk, a kiszolgáló csak akkor követ egy közvetett hivatkozást, ha ugyanaz a felhasználó hozta létre, aki a célfájlt is birtokolja. Mivel ezeket a vizsgálatokat a fájlrendszer minden útvonalán, továbbá az útvonal minden elemén el kell végezni, ez a viselkedés meglehetősen költséges lehet. Ha ellenőrzésünk alatt tartjuk a tartalmak létrehozását, érdemes az Options +FollowSymLinks beállítást használnunk, elhagyva a SymLinksIfOwnerMatch paramétert. Így a rendszer nem végez költséges vizsgálatot, és nem romlik a kiszolgáló teljesítménye. A könyvtárankénti beállítófájlok kikapcsolása <Directory /> AllowOverride none </Directory> Amint a korábbi fejezetekben már említettük, a könyvtárankénti beállítófájlok kényelmes módot adnak kiszolgálónk beállítására, és emellett bizonyos mértékig rábízzák a felhasználókra a felügyelet terheit. Mindazonáltal ha bekapcsoljuk ezt a lehetőséget, az Apache-nak a kiszolgált útvonal minden könyvtárában utána kell néznie ezeknek a beállítófájloknak, ami meglehetősen időigényes feladat. Ha meg szeretnénk szabadulni ettől a viselkedéstől, helyezzük el beállításaink között az AllowOverride none utasítást. A tartalomegyeztetés beállításai Amint a 4. fejezet azonos című részében láthattuk, az Apache képes egy fájl különböző változatait visszaadni az ügyfél választott nyelve vagy egyéb igényei szerint. Erről gondoskodhatunk a fájlok kiterjesztéseivel, de így a kiszolgálónak minden kérelemnél át kell kutatnia a fájlrendszert a megfelelő kiterjesztésű fájlok után. Ha tehát szükségünk van a tartalomegyeztetésre, legalább egy típusmegfeleltetési fájlt használjunk annak érdekében, hogy a lehető legkisebbre csökkentsük a lemezelérések számát. A naplózás kikapcsolása, illetve visszaszorítása BufferedLogs On A jelentős terheléssel bíró webhelyek esetében a naplózás nagy mértékben lelassíthatja a kiszolgáló működését. Ezt a hatást csökkenthetjük azzal, ha nem rögzítjük a képek, de legalábbis bizonyos képek elérését (köztük például a navigációs gombokét). Mindemellett a BufferedLogs utasítással, amely az Apache 2-től elérhető a mod_log_config modulban, a naplókat lemezre írás előtt a memóriában tárolhatjuk. Végül, használhatjuk a mod_log_spread-et vagy más hasonló modult, amely a hálózaton helyezi el 100

113 a naplóbejegyzéseket, ahelyett, hogy a lemezre írna ezzel is javítva a teljesítményt. Ezt a modult letölthetjük a címről. A hálózati és állapotbeállítások finomhangolása Sok esetben az Apache hálózati beállításai is ronthatnak a rendszer teljesítményén a legfontosabbakról a következőkben szólunk. A HostnameLookups utasítás HostnameLookups off Ha a HostnameLookups utasításnak az on vagy a double értéket adjuk, az Apache az ügyfél gépnevének kiderítésére DNS-keresésbe kezd, ami lassítja a kérelem kiszolgálását. A HostnameLookups alapértelmezett beállítása off és érdemes is így hagynunk, hiszen a naplóban rögzített kérelmek címeit a későbbiekben bármikor feloldhatjuk (lásd a 3. fejezetben). A DNS-keresést azonban bizonyos események még a HostnameLookups off értéke mellett is elindíthatják éppen ez történik olyankor, ha az Allow, illetve a Deny utasítások paramétereként gépneveket használunk (lásd a 6. fejezetben). A kérelmek elfogadásának menete Az Apache-ban különböző módszerek ismeretesek a gyermekfolyamatok kérelemkezelésének szabályozására. Az, hogy melyiküket érdemes választanunk, nagyban függ az alkalmazott rendszertől és a proceszszorok számától. Minderről bővebben a címen tájékozódhatunk. A mod_status modul Ennek a modulnak a feladata az adatgyűjtés a kiszolgálóról, a kapcsolatokról és a kérelmekről. A hibakeresésnél megfizethetetlen segítséget jelenthet, de nem szabad elhallgatnunk, hogy emellett lassítja a kiszolgálót. Kiszolgálónk hatékony működése érdekében érdemes kikapcsolnunk ezt a modult, de legalábbis győződjünk meg arról, hogy az ExtendedStatus az alapértelmezett off értéken áll. Az AcceptFilter utasítás AcceptFilter http data AcceptFilter https data Több operációs rendszer, így a Linux és a FreeBSD is lehetővé teszi, hogy egyes figyelő csatolókhoz meghatározott protokollokat rendeljünk. Így utasíthatjuk a magot, hogy csak akkor továbbítson egy kérelmet az Apache-nak, ha a HTTP-kérelem teljes tartalma megérkezett ez pedig növeli a teljesítményt. Ez a lehetőség csak az Apache 2.l-es és későbbi változataiban áll rendelkezésre, bár meg kell említenünk, hogy az AcceptFilter BSD-n működő változata már az Apache ben megjelent. A csatolók beállításáról részletesebben tájékozódhatunk az AcceptFilter súgóoldalán. 101

114 Kapcsolatok életben tartása KeepAlive On KeepAliveTimeout 5 MaxKeepAliveRequests 500 A HTTP 1.1-ben több kérelmet is kiszolgálhatunk egyetlen kapcsolattal. Ugyanezt a HTTP 1.0-ban is megtehetjük, de itt szükség van a kapcsolatok életben tartását szabályozó (keepalive) bővítmények használatára. A KeepAliveTimeout utasítással megadhatjuk, hogy másodpercben mérve milyen hosszú időtartamot kell várnia a kiszolgálónak, mielőtt bezár egy inaktív kapcsolatot. Amennyiben növeljük ezt az időtartamot, több és több esélyt adunk annak, hogy kiszolgálónk újra használja a kapcsolatot. Ugyanakkor egy kapcsolat fenntartása lefoglal egy Apache-folyamatot is, ami a korábban említetteknek megfelelően a méretezhetőségre van rossz hatással. A MaxKeepAliveRequest utasítással meghatározhatjuk, hogy legfeljebb hányszor használható újra egyazon kapcsolat. A visszaélések elkerülése TimeOut LimitRequestBody LimitRequestFields LimitRequestFieldSize LimitRequestLine LimitXMLRequestBody Az elárasztásos (DoS, denial of service) támadások során webhelyünket párhuzamos kérelmek özöne önti el, ami lelassítja a kiszolgáló működését, vagy akár teljesen lehetetlenné teszi a valódi kérelmek kiszolgálását. Az ilyesfajta támadások kivédése igen nehéz, leghatékonyabban általában a hálózat, illetve az operációs rendszer szintjén kezelhetők. Megtilthatjuk például, hogy bizonyos címekről kérelmek érkezzenek kiszolgálónkhoz - ezeket a címeket persze a webkiszolgáló szintjén is elvethetjük, de hatékonyabb, ha a hálózati tűzfal vagy útválasztó bánik el velük, vagy fennakadnak az operációs rendszer szűrőin. A támadók módszerei változatosak: előfordulhat, hogy túlméretes kérelmekkel bombáznak, máskor pedig egyszerre igen sok kapcsolatot nyitnak meg. E támadások hatásának csökkentése érdekében korlátozhatjuk a kérelmek méretét és elévülésük idejét. A kérelmek elévülésének alapértelmezett időtartama 300 másodperc, de ezt a beállítást megváltoztathatjuk a TimeOut utasítással. A kérelem törzsének méretét, valamint a fejlécek hosszát a következő utasításokkal korlátozhatjuk: LimitRequestBody, LimitRequestFields, LimitRequestFieldSize, LimitRequestLine, LimitXMLRequestBody. A kapcsolatok és a sávszélesség korlátozása Ha több ügyfélnek nyújtunk webes tárolási szolgáltatásokat, előfordulhat, hogy észrevesszük, hogy az egyikük webhelye kiugró mértékben emészti fel a webkiszolgáló erőforrásait. A jelenség oka lehet az, hogy a webhelyre egy nagy forgalmú hírportál hivatkozik, de az sem kizárt, hogy amíg nem figyeltünk oda, ügyfelünk webhelye népszerű zene- és filmletöltő oldallá nőtte ki magát. A kapcsolatok számának, valamint a sávszélesség igénybe vételének mérésére és korlátozására az Apache számos modult bocsát a rendelkezésünkre, amelyekkel elérhetjük, hogy a rakoncátlankodó felhasználók ne gyakoroljanak negatív hatást társaik és az egész kiszolgáló teljesítményére. A tartalom kiszolgálását lelassíthatjuk a kért fájl, a megadott IP cím, a párhuzamosan beérkező kérelmek száma vagy más paraméterek alapján. 102

115 Az Apache 1.3 mod_bandwidth modulja lehetővé teszi, hogy korlátozzuk a teljes kiszolgáló, illetve az egyes kapcsolatok számára rendelkezésre álló sávszélességet a megadott könyvtár, a fájlok mérete, illetve a távoli IP cím vagy tartomány alapján. A modul a következő címen érhető el: A bandwidth.share modul a sávszélesség csökkentésében és az ügyfelek IP címei szerinti kiegyensúlyozásában segít. Alkalmazására az Apache 1.3-ban, illetve az Apache 2 korai változataiban van módunk. A modul a következő címen érhető el: A mod_throttle az Apache 1.3-ban elérhető modul, amellyel leszoríthatjuk egyes virtuális kiszolgálók, illetve felhasználók sávszélességét. A modul címe: A Robotcop modul megakadályozza, hogy a webpókok túlmerészkedjenek a kijelölt területük határain a webhelyünk szerkezetében. A modul címe: A mod_require_host olyan ügyfelek (ezek gyakran HS-férgek) elérését korlátozza, amelyek nem adják meg a Host: fejlécet, és így próbálnak az IP címünkhöz kapcsolódni. A modul a következő címen érhető el: A mod_choke az IP címenkénti párhuzamos kapcsolatok száma alapján korlátozza a sávszélességet, csökkentve az ügyfél felé irányuló adatforgalom sebességét. Címe: php?name=content&pa=showpage&pid=7 A mod_tsunami lehetővé teszi, hogy az egyes virtuális kiszolgálókra vonatkozóan korlátozzuk az Apache gyermekfolyamatainak számát. A modul címe: Mit kezdjünk a robotokkal? Robotok, webpókok - programok, amelyek oldalakat töltenek le a webhelyünkről, lépésről lépésre haladva a hivatkozások láncán. A gazdáik webes keresőmotorok, amelyek ezeknek a programoknak a segítségével kutatják fel a webkiszolgálókat, töltik le a tartalmukat, és indexelik az eredményt. A robotok hétköznapi használatuk során részben vagy teljesen letöltik a kiszemelt webhelyek tartalmát, így a kapott eredmény kapcsolat nélkül is böngészhető. Az esetek túlnyomó többségében semmi gond nincs ezekkel a programokkal, de néhanapján felbukkannak agresszív példányaik is, amelyek párhuzamos kérelmekkel önthetik el a webhelyünket, vagy megrekedhetnek egy-egy végtelen ciklusban. 103

116 A jószándékú robotok egy robots.txt nevű fájlt kérelmeznek, amely leírja, hogyan érhető el a webhelyünk, és mely részeit nem kívánjuk közzétenni. A fájl elkészítésének szabályait megtalálhatjuk a címen. A kérelmeket megállíthatjuk az útválasztó vagy az operációs rendszer szintjén. Előfordulhat, hogy a keresőrobotok nem viselkednek jó fiú módjára, és figyelmen kívül hagyják a robots.txt tartalmát. Ilyenkor jelenthet nagy segítséget a korábban már említett Robotcop modul. Fordított helyettes kiszolgálók és terheléselosztók mod_proxy_http mod_backhand Az eddigiekben a függőleges méretezhetőséggel foglalkoztunk, vagyis azzal, hogy miként növelhetjük rendszerünk teljesítményét, ha egyetlen kiszolgálót használunk. A rendszer terhelése azonban elosztható több kiszolgáló között is ez a vízszintes méretezhetőség. Ilyenkor rendszerünk befogadóképességét egyszerűen azzal növelhetjük, hogy újabb és újabb gépeket veszünk használatba, emelve a kezelhető forgalom mértékét és egyúttal a rendszer megbízhatóságát. A 10. fejezetben részletesen tárgyaljuk majd a fordított helyettes kiszolgálók (reverse proxy) működését, érdemes azonban már most pár szóban megemlékeznünk róluk. E módszer alkalmazásánál egy vagy több könnyűsúlyú kiszolgáló foglalkozik az előtérben a statikus tartalmakkal, az SSL-kérelmekkel és a lassú kapcsolatokon érkező adatokkal, míg az egyes URL-ekre érkező kérelmeket a megfelelő háttérkiszolgálókhoz továbbítja. Számos olyan hardvereszköz van kereskedelmi forgalomban, amely ezeknek a feladatoknak a kezelését hivatott megoldani. Végezetül, említést kell tennünk az Apache 1.3 mod_backhand moduljáról, amely képes a HTTPkérelmek dinamikus átirányítására kiszolgálók egy csoportján belül, az elérhető erőforrások alapján. Átmeneti tárolás és tömörítés A tartalom szolgáltatásának leggyorsabb módja, ha egyáltalán nem szolgáltatunk semmit. Ezt a megfelelő HTTP-fejlécekkel érhetjük el, amelyekkel tájékoztatjuk az ügyfeleket és helyetteseket a kért erőforrások érvényességéről. Így azokat az erőforrásokat, amelyek több oldalon is megjelennek, de csak ritkán változnak ilyenek például az emblémák vagy a navigációs gombok meghatározott időtartamon belül csak egyszer kell átadnunk az ügyfeleknek. Mindemellett a mod_cache modullal (bővebben lásd a 10. fejezetben) a memóriában tárolhatjuk a dinamikusan előállított tartalmakat, így ezeket nem kell minden kérelem esetén újra és újra létrehoznunk. Ez elviekben jelentős teljesítménynövekedést eredményezhet, hiszen a dinamikus tartalom előállításához általában adatbázisok elérésére, sablonok feldolgozására és más hasonló erőforrásigényes műveletekre van szükség. A kiszolgálók tehermentesítésének következő módja az ügyfeleknek küldött adatok mennyiségének csökkentése - ez ügyfeleink számára teszi gyorsabbá a webhely elérését, különösen lassabb kapcsolatok esetén. Sokat segíthetünk azzal, ha csökkentjük az átadott képek számát és méretét. Ezen a téren komoly segítséget nyújtanak az ImageMagick parancssori eszközei ( Mindezek mellett tömöríthetjük a letölthető fájlokat, sőt akár a HTML oldalakat is, csak a korábbi fejezetekben megismert tartalomegyeztetést kell használnunk. A 11. fejezetben részletesebben is szólunk arról, hogy miként tömöríthetők a HTML fájlok a mod_deflate szűrőmodullal. Ez a módszer akkor ad igazán jó eredményt, ha elegendő processzorteljesítmény áll rendelkezésünkre, az ügyfelek viszont lassú kapcsolatokon keresztül 104

117 érik el a kiszolgálót. A tartalom így gyorsabban célba jut, és a kiszolgálófolyamat hamarabb készen áll új kérelmek kezelésére. Optimalizálás modulokkal Amint a fejezet elején említettük, a webkiszolgáló rendszerének szűk keresztmetszetét leggyakrabban a tartalomelőállítás, valamint az adatbázis-elérés adja. Léteznek azonban olyan modulok, amelyek itt is segítségünkre siethetnek. Itt van mindjárt a FastCGI és a mod_perl, amelyekkel felgyorsíthatjuk CGI parancsfájljaink futását (lásd a 4. fejezet A CGI parancsfájlok teljesítményének növelése című részét), és nem szabad megfeledkeznünk az Apache rendszerek legnépszerűbb webes nyelvéről, a PHP-ről sem, amelyhez számos kódoló és optimalizáló eszköz áll rendelkezésre. Az Apache alternatívái lighttpd: thttpd: Boa: Az Apache hordozható, biztonságos és rendkívül rugalmas webkiszolgáló, ezért nem biztos, hogy minden helyzetben a lehető legjobb megoldást adja. A fentebb felsoroltak mindannyian optimalizált, könnyűsúlyú kiszolgálók, amelyek teljesítménye, illetve méretezhetősége egyes feladatok tekintetében meghaladja az Apache-ét. Így például egyes népszerű webhelyek - köztük a Slashdot - az Apache-t és a mod_perl modult használják a tartalom előállítására, a statikus képek szolgáltatásához azonban egy Boa kiszolgálót állítanak üzembe. A feladatok elválasztásához elegendő a képeket egy másik tartományból (példánkban ez az images.slashdot.org) szolgáltatnunk. A fentiek némelyike magában foglalja az Apache más népszerű lehetőségeit is, így például az URL-átírást, valamint a PHP-támogatást. 105

118 106

119 10 Helyettes kiszolgálók és gyorsítótárak Miért van szükség gyorsítótárakra és helyettes kiszolgálókra? A HTTP egyszerű, de igen hatékony protokoll. Ebből a fejezetből megtudjuk, miként használjuk ki az Apache gyorsítótárazási és helyettes kiszolgálói szolgáltatásait, hogy méretezhető, rugalmas rendszerhez jussunk. A gyorsítótárak használatával egyszerre csökkentjük a kiszolgáló terhelését, és növeljük a webhely elérésének sebességét, hiszen így a gyakran kért tartalmakat gyorsabban át tudjuk adni az ügyfeleknek. A helyettes kiszolgálói szolgáltatásokkal ellenőrzőpontot állíthatunk fel a HTTP-kérelmek számára, amelynek segítségével egységesíthetjük a különböző háttérkiszolgálókról származó tartalmakat, és növelhetjük a rendszer teljesítményét. Egyszerű és fordított helyettes kiszolgálók A webhelyetteseknek két alaptípusa ismeretes. A hagyományos HTTP-helyettesek fogadják az ügyfelek kérelmeit, kapcsolódnak a távoli kiszolgálóhoz, majd visszaadják a kapott válaszokat. A fordított helyettes ugyanakkor egy olyan webkiszolgáló, amelyhez más webkiszolgálók csatlakoznak számukra teremt közös felületet, és voltaképpen átjáróként működik. A böngészők szempontjából a fordított helyettes az igazi kiszolgáló, hiszen csak vele tudnak kapcsolatba lépni kérelmeiket pedig ő továbbítja a háttérkiszolgálóknak. Az Apache 1.3, 2.0 és 2.2 közti különbségek Az Apache 1.3-ban a gyorsítótárak támogatását a mod_proxy adta, így használatukat nem lehetett elválasztani a helyettes kiszolgálói szolgáltatásoktól. A 2.0-s változatban már külön modulokat készítettek e lehetőségek számára, ám ezek még kísérleti jellegűek voltak. A 2.l-es és 2.2-es változatban azután helyreállt a rend - megszülettek az érett modulok. 107

120 A mod_proxy támogatásának bekapcsolása Apache enable-module=proxy Apache 2 --enable-proxy --enable-proxy-connect --enable-proxy-ftp --enable-proxy-http --enable-proxy-balancer (apache 2.1 and later) --enable-proxy-ajp (apache 2.1 and later) Ahhoz, hogy helyettes kiszolgálói szolgáltatásokat használhassunk az Apache-ban, be kell kapcsolnunk a fő helyetteskezelő modult, valamint legalább egyet a háttérprotokollok (HTTP, CONNECT és FTP) közül. A CONNECT használata lehetővé teszi, hogy az SSL-kapcsolatok érintetlenül átjussanak a helyettesen, az FTP pedig lehetőséget ad arra, hogy kiszolgálónk átjáróként működve elérést biztosítson a háttérben levő FTP-kiszolgálókhoz az egyszerű HTTPböngészők számára. Az Apache 2.l-es és későbbi változataiban két további helyetteskezelő modult is megtalálhatunk: a balancer a terheléselosztásban lehet a segítségünkre, míg az ajp az AJP protokoll támogatásával lehetővé teszi a Tomcat és más kiszolgálóoldali parancsfájlmotorok elérését. A hagyományos helyettesek támogatásának beállítása ProxyRequests on <Proxy *> Order deny,allow Deny from all Allow from / </Proxy> A hagyományos helyettesek az Internet hőskorában igen nagy népszerűségnek örvendtek, hiszen segítségükkel több gép osztozhatott egyetlen, a külvilág felé kiépített kapcsolaton. A legtöbb helyettes kiszolgáló egyúttal gyorsítótárat is alkalmaz, ami lassú kapcsolatoknál életmentő lehet, továbbá nagy előnyük, hogy elszigetelik a háttérben működő gépeket a külvilágtól. A kapcsolatok sebességének növekedésével, valamint az átjárókban alkalmazott NAT (Network Address Translaton, hálózati címfordítás) elterjedésével azonban egyre csökken az igény a hagyományos helyettesekre. Napjainkban legtöbbször cégek helyeznek üzembe ilyen kiszolgálókat, hogy szabályozott mederben tartsák az alkalmazottak böngészését, naplózva és megszűrve a webhelyek elérését, esetenként hitelesítést is megkövetelve. A helyzet azonban változóban van, hiszen a kémprogramok és vírusok egyre gyakrabban tűnnek fel a színen, így mind népszerűbbek a szűrőként működő helyettesek, amelyek leszámolnak ezekkel a támadókkal, mielőtt eljutnának a felhasználó gépéig. A drót nélküli világban pedig új szerepre leltek a helyettesek ők biztosítják az átjárókat. A hagyományos helyettesek működését a példának megfelelően a ProxyRequests On utasítással engedélyezhetjük. A 6. fejezetben leírtak fényében azonban érdemes lehet a helyettesek támogatását a megfelelő módon hitelesített ügyfelekre korlátozni ezt a <Proxy> utasítással tehetjük meg. A példa azt mutatja be, hogyan korlátozhatjuk a helyettesek hozzáférését egyes hálózati területekhez. 108

121 Az URL-tér egységesítése fordított helyettes alkalmazásával ProxyPass /crm ProxyPass /bugzilla A fordított helyettesek használatával közös felületet biztosíthatunk háttérkiszolgálóink számára, az előtérben álló gép egyes URL-jeit megfeleltetve a különböző háttérkiszolgálóknak. Képzeljük el például, hogy egyik kiszolgálónk egy CRM alkalmazást, míg egy másik egy hibanyomkövetőt futtat. Ha felhasználóink ezek valamelyikét szeretnék elérni, különböző címeket kell megadniuk. Ezeket a szolgáltatásokat a ProxyPass segítségével a kódban látható módon beépíthetjük központi webhelyünk szerkezetébe. Ezután, ha a fordított helyettes egy kérelmet kap a html címre, azonnal kérelmezi a címet a háttérkiszolgálótól, majd a kapott dokumentumot visszaadja a böngészőnek. A ProxyPass utasítást használhatjuk önállóan, vagy <Location> tárolóba ágyazva, mint az alábbi példában: <Location /crm> ProxyPass </Location> Végezetül meg kell említenünk, hogy a ProxyPass utasítást sokszor érdemes a ProxyPassReversezel együtt alkalmaznunk, amint azt a következőkben láthatjuk. A háttérkiszolgálók elrejtése ProxyPass /crm ProxyPassReverse /crm ProxyErrorOverride On Az előzőekben leírt folyamat során a fordított helyettessel kapcsolatba lépő ügyfél nem szerez tudomást a háttérkiszolgálókról. Előfordul azonban, hogy a háttérkiszolgálók olyan átirányítást alkalmaznak, illetve olyan hibaüzeneteket adnak, amelyekkel saját magukra hivatkoznak, például a Location: fejlécben. Ilyenkor segít a ProxyPassReverse, amely észreveszi ezeket a fejléceket, és a tartalmukat úgy írja át, hogy már a fordított kiszolgáló (példánkban a szerepeljen bennük. A ProxyPassReverseCookiePath és a ProxyPassReverseCookieDomain működése hasonló, de ezek az utasítások a Set-Cookie: fejlécekben található útvonalakat és tartományokat vizsgálják. Az Apache 2-ben rendelkezésünkre áll a ProxyErrorOverride utasítás is, amellyel a helyettes kiszolgáló hibaoldalait jeleníthetjük meg a háttérkiszolgálók megfelelő oldalai helyett. Ezzel még jobban elrejthetjük a háttérkiszolgálókat, és még egységesebb felülethez juthatunk, amely immár a hibaüzenetek terén sem tartalmaz kivételeket. 109

122 Megjegyzés Fontos megjegyeznünk, hogy a ProxyPassReverse utasítás kizárólag a HTTP-fejlécek szintjén működik - nem képes a HTML dokumentumok hivatkozásainak vizsgálatára vagy módosítására. Ha ilyen terveink vannak, az Apache 2-ben a mod_ proxy_html modult használhatjuk, amely lehetővé teszi a helyettesen keresztül szolgáltatott HTML dokumentumok elemzését és tartalmuk dinamikus átírását. A modulhoz a címen juthatunk hozzá. Fordított helyettesek alkalmazásának tiltása egyes URL-eken ProxyPass /images/! ProxyPass / Ha egy ProxyPass utasítás távoli webhelyet megadó paramétere helyett felkiáltójelet írunk, azzal megtilthatjuk a megadott cím átvezetését a fordított helyettesen. Fontos, hogy az ilyen utasításokat minden más ProxyPass utasítás előtt helyezzük el a beállításaink sorában. A példánkban szereplő beállítások mellett a fordított helyettes minden kérelmet továbbít a háttérkiszolgálóknak, kivéve a képekre vonatkozókat, amelyeket helyben szolgál ki. A teljesítmény növelése ProxyIOBufferSize A fordított helyettesek olyankor is hasznunkra lehetnek, ha web- és alkalmazáskiszolgálóink túlterheltek. A lassú, modemes ügyfelek, a hibáktól terhelt böngészők és a nagy multimédiafájlok jelentős erőforrásokat emészthetnek fel a tartalmat átadó kiszolgálón. Ha ügyfelünk egy nagy, statikus fájlt kérelmez, és lassan tölti le, az Apache megfelelő gyermekfolyamata, illetve szála mindaddig vele foglalkozik, amíg a letöltés be nem fejeződik. Hasonló helyzet áll elő, ha a TCP/IP megvalósításának hibája miatt az átvitel végeztével a rendszer nem zárja le a kiszolgálóval fenntartott kapcsolatot. Ez az elhúzódó lezárás mindaddig leköti az erőforrásokat, amíg végül a kapcsolat elévül, és a rendszer felszámolja. A fenti helyzetek nehezen kerülhetők el - az igazi probléma azonban akkor jelentkezik, ha folyamat alapú MPM-eket használunk (ilyen a prefork MPM). Tegyük fel például, hogy az Apache 1.3-ban a mod_perl modult futtatjuk más Perlmodulokkal együtt, az adatok egy részét gyorsítótárban tárolva az Apache gyermekfolyamatai ilyenkor egyenként több megabájtosak is lehetnek. Ha valamelyikük vesztegeti az idejét, vagyis statikus fájlokat ad át, vagy arra vár, hogy egy kapcsolat bezáródjon, azzal a többi kérelem kiszolgálásától von el erőforrásokat. Itt segíthet egy fordított helyettes. Munkába állíthatunk egy vagy több szál alapú, könnyűsúlyú előtérbeli Apache kiszolgálót, amelyek kezelik a statikus fájlokat, valamint a lassú vagy hibás ügyfeleket. A háttérkiszolgálók így már zavartalanul végezhetik a dinamikus tartalomelőállítást. A ProxyIOBufferSize hangolásával elérhetjük, hogy a nagy fájlok hamarabb átkerüljenek a fordított helyetteshez, és a háttérkiszolgálóval létesített kapcsolat a lehető leghamarabb felszabaduljon. Ezzel csökkentjük a háttérkiszolgálók terhelését a helyettes gép memóriafelhasználásának növekedése árán. Az Apache 2.1 újabb MPMjei lehetővé teszik az Apache gyermekfolyamatai számára, hogy több kapcsolatot is kialakítsanak, és külön szállal figyeljék, melyik kapcsolatot lehet már bezárni. Idővel, ahogy egyre kiforrottabbá válnak, ezek az MPM-ek számos helyzetben jelentősen javíthatják majd az Apache méretezhetőségét. 110

123 Az SSL-kérelmek terhelésének áthelyezése Amint azt a 7. fejezetben láthattuk, az SSL protokoll használata meglehetősen igénybe veszi a rendszer erőforrásait ez viszont az előzőekben mondottak szerint komoly hatással lehet a háttérkiszolgálók teljesítményére. Az egyik megoldás, ha kifejezetten erre a célra szánt, optimalizált működésű gépeket állítunk be, amelyek fordított helyettest működtetnek, SSL-támogatással. Ez a gép vállalja magára az SSL-kérelmek kezelését és esetleg a tanúsítvány alapú hitelesítést, a kérelmeket pedig egyszerű HTTP formátumban adja tovább a háttérkiszolgálóknak. A válasz ezután visszakerül a fordított helyetteshez, amely elvégzi rajta a titkosítás erőforrásigényes műveletét. Mivel az SSL protokoll végpontja fordított helyettes, egyes adatok köztük a tanúsítványhoz kapcsolódóak nem jutnak el a háttérkiszolgálókhoz. Ez azonban orvosolható, és erről is szót ejtünk a következőkben. Helyettesek adatainak átadása fejlécekben ProxyPreserveHost on Ha az Apache kiszolgáló a fordított helyettes szerepét tölti be, a hozzá érkező kérelmek Host: fejlécét úgy módosítja, hogy az eredmény megfeleljen a ProxyPass utasításban leírtaknak. Ne aggódjunk, az eredeti Host: fejléc sem vész el csak átkerül egy másik fejlécbe, amelynek neve X-Forwarded-Host. Bizonyos esetekben azonban szükség van a fejléc eredeti értékének megtartására. Ezt elérhetjük, ha elhelyezzük a ProxyPreserveHost on utasítást a beállítófájlban. Fordított helyettes használata esetén a kérelem egyes adatai elvesznek, a kiszolgáló azonban néhányukat megőrzi, és az alábbi fejlécekben adja át őket a háttérkiszolgálóknak: X-Forwarded-For: Az ügyfél IP címe vagy gépneve. X-Forwarded-Host: Az eredetileg kérelmezett kiszolgáló. X-Forwarded-Server: A helyettes kiszolgáló gépneve. Emellett, ha kedvünk úgy tartja, a Header és a RequestHeader utasításokkal további adatokat is átadhatunk (lásd a következőkben). Fejlécek kezelése Header set fejlécnév fejlécérték Ha további adatokat szeretnénk átadni a háttérkiszolgálóknak, megtehetjük a mod_headers modul Header utasításával. Ennek a modulnak a segítségével egyébként tetszőleges fejléceket helyezhetünk el, illetve távolíthatunk el a HTTP-kérelmekből és válaszokból. A fenti példakóddal elhelyezhetünk a válaszban egy új HTTP-fejlécet, felülírva minden, az utasításban megadottal egyező nevű korábbi értéket. Amennyiben teljesen új fejlécet szeretnénk létrehozni, alkalmazzuk a Header set helyett inkább a Header add utasítást. Szükségünk lehet arra is, hogy hozzáfűzzünk egy értéket egy már meglevő fejléchez, eltávolítsunk bizonyos fejléceket, vagy a kérelem egyik fejlécét elhelyezzük a válaszban ezekre a feladatokra (ebben a sorrendben) az append, az unset és az echo parancsok alkalmazhatók. 111

124 Ha nem a válasz, hanem a kérelem fejléceit szeretnénk módosítani, a Header helyett a RequestHeader utasítást kell használnunk. Az utasítás fejlécérték paraméterében a %{változónév}e alakban környezeti változók értékeit is elhelyezhetjük, hasonlóképpen, mint ahogy azt a 3. fejezetben a LogFormat utasításnál láthattuk. Ezzel a módszerrel könnyedén átadhatjuk az SSL-kapcsolat és a tanúsítványok adatait a háttérkiszolgálóknak. Mindehhez először utasítanunk kell a mod_ssl modult az SSLOptions +StdEnvVars utasítással arra, hogy környezeti változókban rögzítse ezeket az adatokat. Az Apache 2.1-es és későbbi változataiban erre a lépésre már nincs szükség, mert az SSL környezeti változói közvetlenül elérhetők a %{változónév}s alakban. Gyorsítótárazó helyettes kiszolgálók CacheRoot /usr/local/apache/cache CacheSize CacheGcInterval 6 CacheMaxExpire 12 A helyettesek kézenfekvő lehetőséget adnak a feldolgozott adatok tárolására. Így, ha ügyfelünk korábban már tárolt tartalmat kérelmez, és az még jelen van a gyorsítótárban, azt közvetlenül át lehet neki adni. Az Apache 1.3-ban a gyorsítótárak lehetőségeit a mod_proxy modul valósítja meg - az itt elérhető utasításokat láthatjuk a példában is. A CacheRoot segítségével meghatározhatjuk a tárolt fájlok helyét, míg a CacheSize lehetőséget ad arra, hogy meghatározzuk, hány kilobájtnyi hely álljon a gyorsítótár rendelkezésére. A gyorsítótár viselkedésének finomhangolására is kapunk jó néhány utasítást. Fontos szerepet kap közülük a CacheGcInterval, amellyel azt adhatjuk meg, hogy hány óránként ürítse ki a rendszer a tárat, hogy megfeleljen a CacheSize beállításának. A CacheMaxExpire utasítással azt adhatjuk meg, hogy meddig tekintünk érvényesnek egy dokumentumot a gyorsítótárban. Ha még ezen az időtartamon belül vagyunk, a kiszolgáló a tárolt adatokat adja vissza, és nem néz utána az eredeti forrásnak. Gyorsítótárak az Apache 2-ben CacheEnable disk / CacheRoot /usr/local/apache/cache A gyorsítótárak és a helyettes kiszolgálói szolgáltatások támogatása az Apache 2-től elkülönül egymástól. A 2.0-s változatban a gyorsítótárak támogatását ugyan még kísérleti jellegűnek mondták, az Apache 2.1/2.2 azonban már megbízható megoldásokat hozott. Az Apache 2-ben a gyorsítótárak kezelésének központi modulja a mod_cache, amelynek működését két háttérmodul támogatja. A mod_mem_cache az erőforrások memóriabeli tárolásáért felel, míg a mod_disk_cache a fájlrendszert használja erre a célra. A CacheEnable utasítással megadhatjuk az alkalmazni kívánt háttértárolót (mem vagy disk), valamint egy URL-előtagot. A rendszer ettől fogva azokat a kérelmeket tárolja a megadott háttértárolóban, amelyekben szerepel ez az URL-előtag. A CacheDisable segítségével megtilthatjuk a gyorsítótárak használatát egyes URL-ek esetén, a htcacheclean parancssori segédprogrammal pedig lemezes gyorsítótár esetén meghatározott időközönként törölhetjük a tárolt adatokat. Előfordulhat, hogy egyes fájlokról biztosan tudjuk, hogy nem változnak a kiszolgáló élettartama alatt. Ezeket a mod_file_cache segítségével rögzíthetjük a memóriában vagy a lemez gyorsítótárában: CacheFile /usr/local/apache/htdocs/navigationbar.gif MMapFile /usr/local/apache/htdocs/button_left.png Ha módosítjuk e statikus fájlok valamelyikét, a változás csak a kiszolgáló újraindítása után tapasztalható. 112

125 Terheléselosztás <Location /balancer-manager> SetHandler balancer-manager Order deny,allow Deny from all Allow from localhost </Location> <Proxy balancer://balancer/ stickysession=phpsessionid> BalancerMember BalancerMember BalancerMember </Proxy> ProxyPass /content balancer://balancer/ Az Apache 2.2-ben a mod_proxy egy új háttérszolgáltatással egészült ki, amely lehetővé teszi a terhelés elosztását. Az ezt megvalósító kód elegendően általános ahhoz, hogy a HTTP mellett egyidejűleg más protokollok forgalmával is foglalkozzon. A terheléselosztás beállításához mindenekelőtt meg kell határoznunk egy csoportnyi háttérkiszolgálót a <Proxy balancer://...> tárolóban (lásd a példakódot). Ha ez megtörtént, a terheléselosztó kiszolgálók azonosítóit használhatjuk a hagyományos ProxyPass utasításokban. Az egyes azonosítók, illetve kiszolgálók számára meghatározhatjuk a terheléselosztás stratégiáját (a forgalom alapján), a teendőket rendszerleállás után, a kapcsolatgyűjtés, valamint a munkamenetek támogatását. Végezetül, terheléselosztó rendszerünk állapotát a már megismert status kezelővel mérhetjük fel, és a balance-manager segítségével módosíthatjuk a beállításait. Kapcsolódás a Tomcathez ProxyPass /myapp ajp:// :8009/myapp ProxyPassReverse /myapp ajp:// :8009/myapp Az Apache 2-ben a mod_proxy modul kibővült az AJP protokoll támogatásával is. Ennek a protokollnak a jelenléte az Apache-ban nem újdonság, hiszen egy másik modul a mod jk - korábban is használta adatcserére az alkalmazáskiszolgálókkal és kiszolgálóoldali parancsfájl- (servlet-) motorokkal, amilyen a Tomcat vagy a Jetty. Most azonban a mod_jk helyett a mod_proxy és a mod_proxy_ajp modult alkalmazhatjuk, így kihasználhatjuk a mod_proxy néhány friss lehetőségét, köztük az előzőekben bemutatott terheléselosztást. Amint a példában is láthatjuk, a mod_proxy AJP-támogatása igen egyszerűen elérhető csak helyettesítsük a előtagokat az ajp:// karakterlánccal a helyettes kiszolgáló beállításaiban (terheléselosztás esetén is). 113

126 Egyéb helyettesek Squid Pound Amint a 9. fejezetben is említettük, vannak olyan helyzetek, amikor nem feltétlenül az Apache a legjobb választás. Szerencsére léteznek külön erre a célra készített helyettes kiszolgálók is, amelyek bizonyos igények esetén jobban teljesíthetnek az Apache-nál. A nyílt forrású helyettes kiszolgálók legismertebbjei közé tartozik a Pound és a Squid előbbi egy könnyű helyettes kiszolgáló, amelyet gyakran SSL fordított helyettesként használnak, a Squid pedig, amely nagyjából az Apache első kiadásának idején jelent meg, rengeteg beállítási lehetőséget ad, és nagyszerű gyorsítótárazási lehetőségeket biztosít. Láthatatlan HTTP-helyettesek Amint a korábbiakban említettük, a hagyományos gyorsítótárazó helyettesek helyes működéséhez szükség van az ügyfelek megfelelő beállítására - léteznek azonban láthatatlan (transparent) helyettesek, amelyek enyhítenek ezen a követelményen. Működésük abban áll, hogy a hálózati rétegben elfogják a HTTPkérelmeket, és egy helyettes kiszolgálón keresztül továbbítják azokat, anélkül, hogy erről a felhasználó értesülne. A láthatatlan helyettesek napjainkban is népszerűek az internetszolgáltatók körében, akik szeretnék csökkenteni a sávszélesség-használatból eredő költségeiket, vagy szabályozni akarják az ügyfeleik böngészési lehetőségeit. Vannak olyanok is, akik a láthatatlan helyetteseket vírusok és kémprogramok kiszűrésére használják (erről már szó esett fejezetünk A hagyományos helyettesek támogatásának beállítása című részében). Ehhez egy olyan kiszolgálóra van szükség, amely képes megvalósítani a láthatatlan helyettes feladatait (ilyen például a Squid), továbbá módosítanunk kell az operációs rendszer csomagtovábbítási szabályait. A láthatatlan HTTPhelyettesek beállításairól bővebben a Linux Documentation Project alábbi oldalán olvashatunk: 114

127 11 Protokollmodulok és MPM-ek Az Apache felépítésének fejlődéstörténete Az Apache nem egyetlen tömbből álló kiszolgáló. Új modulok hozzáadásával bővíthetjük a képességeit, de el is távolíthatunk egyes modulokat a kiszolgáló méretének csökkentése és teljesítményének növelése érdekében. Az Apache 2-ben a modularitás új formái jelentek meg, három friss lehetőséget kínálva a kiszolgáló bővítésére: Többfeladatos modulok (Multi Processing Module, MPM): Lehetővé teszik, hogy megváltoztassuk a kérelmek kezelésének módját, javítva a kiszolgáló teljesítményét és méretezhetőségét. Szűrőmodulok: Módot adnak moduljainknak arra, hogy feldolgozzák a más modulok által szolgáltatott tartalmat. Protokollmodulok: A protokollréteg elvont, ami lehetővé teszi, hogy más protokollokkal (például az FTP-vel) is szolgáltathassunk tartalmat. A megfelelő MPM kiválasztása --with-mpm=worker --with-mpm=prefork Jóllehet az MPM-ek kiválasztása rengeteg tényezőtől, így a külső modulok támogatásától és a megvalósítandó lehetőségektől függhet, sok esetben mégis el lehet mondani, hogy egyes MPM-ek jobban működnek a társaiknál bizonyos rendszereken. Így például az ADC-ben a folyamatok nehézsúlyúak, így a méretezhetőség igénye a szálas MPM-ek használatát indokolja. Az Apache 1.3-ban nincs lehetőségünk megváltoztatni a kérelmek feldolgozásának módját, az Apache 2-ben azonban a beállításnál, illetve a felépítés folyamata során a --with-mpm kapcsolóval kiválaszthatjuk, hogy melyik MPM-et szeretnénk használni. Jelenleg a Windows saját szál alapú MPM-et használ, míg Unix rendszereken két stabil MPM a Prefork és a Worker áll rendelkezésre. Ezek mellett sok más ilyen célú modulhoz is hozzájutunk a kiszolgáló programcsomagjával, de ezek jelenleg még kísérleti jellegűek. A következőkben megismerkedünk az egyes MPM-ek lehetőségeivel, valamint a beállításaikkal. Folyamat alapú MPM-ek A folyamat alapú kiszolgálók több gyermekfolyamatra ágaznak el ilyenkor a szülőfolyamat másolatokat készít önmagáról. Ezek a másolatok a gyermekfolyamatok, amelyek alkalmasak kérelmek egymástól független kiszolgálására. Mindez jelentősen javítja a rendszer stabilitását, hiszen ha valamelyik gyermekfolyamat rosszul kezd viselkedni (mondjuk túl sok memóriát fogyaszt), anélkül leállítható, hogy ez hatással lenne a kiszolgáló többi részére. A stabilitásnövekedés azonban a teljesítmény rovására megy, hiszen minden újabb gyermekfolyamat további memóriát emészt fel, és az operációs rendszer is egyre több időt tölt a környezetváltással. Ráadásul ez a viselkedés a folyamatok közti adatcserét és az adatok megosztását is megnehezíti. 115

128 Az Apache 1.3 eleve folyamat alapú, míg az Apache 2 rendelkezik egy korai elágazású (prefork) MPMmel, amely lehetővé teszi, hogy folyamat alapú kiszolgálóként működjön. A prefork kifejezés arra utal, hogy a gyermekfolyamatok még a kiszolgáló indításakor szétválnak, nem csak a kérelmek beérkeztekor. Az Apache lehetővé teszi a kezdetben létrehozott gyermekfolyamatok számának, illetve számuk maximumának meghatározását (lásd a következőkben). A Prefork MPM beállításai StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 150 MaxRequestsPerChild 0 Az indításkor elágazó folyamatok számát a StartServers utasítással határozhatjuk meg használata igen egyszerű, hiszen egyetlen paramétert fogad: a folyamatok számát. Alapértelmezett értéke 5, ami a legtöbb webhelyen megfelel csak akkor módosítsuk, ha nagyon forgalmas webhelyet üzemeltetünk. A MaxClients segítségével megadhatjuk, hogy legfeljebb hány folyamat keletkezhet (persze az operációs rendszer, illetve az Apache korlátja fölé így sem mehetünk). Az Apache 1.3-ban a beépített felső korlát 256-os értéke rögzített; ha meg szeretnénk változtatni, a httpd.h állomány HARD_SERVER_LIMIT értékét kell átírnunk, majd újrafordítani a kiszolgáló kódját. Az Apache 2-ben könnyebb dolgunk van, ugyanis ez az érték itt a beállítófájlban is megváltoztatható a ServerLimit utasítással. A MinSpareServers utasítással a tétlen folyamatok (amelyek nem szolgálnak ki kérelmet) legkisebb számát határozhatjuk meg. Ha ennél kevesebb tétlen folyamat van a rendszerben, az Apache azonnal újabb gyermekfolyamatokat hoz létre. Megadhatjuk a tétlen folyamatok számának maximumát is, méghozzá a MaxSpareServers utasítással. Értelemszerűen, ha ezeknek a folyamatoknak a száma meghaladja ezt az értéket, az Apache leállítja néhányukat. Példánkban az utasítások alapértelmezett értékeit láthatjuk, amelyek a legtöbb esetben tökéletesen megfelelnek. Végezetül, a MaxRequestsPerChild utasítással korlátozhatjuk az egy folyamat által kiszolgálható kérelmek számát is (ebbe nem számítanak bele azok a kérelmek, amelyek újra felhasználják ugyanazt a kapcsolatot). Ennek a korlátnak az a jelentősége, hogy megakadályozza a hosszan működő folyamatoknál előbb-utóbb bekövetkező memóriaelszivárgást, így a kiszolgáló meghatározott számú kérelem feldolgozása után az elhasznált folyamatot egy újra cseréli ki. Ha nem szeretnénk alkalmazni ezt az eljárást, állítsuk a MaxRequestsPerChild értékét 0-ra. Szálas és kevert MPM-ek A szálak hasonlóak a folyamatokhoz, de képesek memóriát és adatokat megosztani más szálakkal. Mindez azzal az előnnyel jár, hogy nincs szükség környezetváltásra, hiszen a szálak egyazon folyamat részei, ugyanakkor hátránya, hogy egy hibás kódrészlet az egész kiszolgálót magával ránthatja. Ez sajnos megtörténhet, hiszen egy rakoncátlankodó szál képes átírni és tönkretenni más szálak adatait és kódját. 116

129 A Windowson futó Apache-MPM nagyszerű példát ad a szál alapú kiszolgálóra. Mind a szál alapú, mind a folyamat alapú kiszolgálók rendelkeznek előnyös és hátrányos tulajdonságokkal. Az Apache fejlesztői azonban megpróbáltak továbblépni ezen a kettősségen, és létrehoztak egy Worker MPM nevű szál alapú kiszolgálót, amely a két modell egyesítését valósítja meg. Itt a kiszolgáló több folyamatot indíthat, amelyek önmagukon belül szálakat használnak. A Worker MPM beállításai Startservers 2 MaxClients 150 MinSpareThreads 25 MaxSpareThreads 75 ThreadsPerChild 25 MaxRequestsPerChild 0 A Worker MPM lehetőséget ad az Apache 2-ben a folyamatok és a szálak előnyeinek egyesítésére. A Prefork MPM-hez hasonlóan a kezdéskor indított gyermekfolyamatok számát a StartServers utasítással adhatjuk meg. Ezek a folyamatok egyenként több szállal is rendelkezhetnek hogy menynyivel, azt a ThreadsPerChild utasítással határozhatjuk meg. A folyamatokon belüli szálak száma rögzített. A rendszer úgy tartja a kijelölt határok között a szálak összesített számát, hogy folyamatokat állít le vagy hoz létre. A szálak számának korlátait a MinSpareThreads és a MaxSpareThreads utasításokkal adhatjuk meg ezek a folyamat alapú kiszolgálóknál megismert MinSpareServers és MaxSpareServers utasítások megfelelői. Az Apache nyomon követi a szálak összesített számát, és ennek megfelelően állít le vagy hoz létre folyamatokat. A Prefork MPM-hez hasonlóan a folyamatok számát a MaxClients utasítással korlátozhatjuk felülről. Mivel azonban a Worker MPM-ben minden folyamathoz meghatározott számú szál tartozik, a párhuzamosan kiszolgálható ügyfelek számát a MaxClients és a ThreadsPerChild utasítások értékének szorzata adja meg. A MaxThreadsPerChild a gyermekfolyamatokban megengedett szálak legnagyobb számát adja meg; értéke az újraindítások között megváltoztatható, míg a ThreadLimit értéke nem. A StartServers és a MaxClients utasítások működése megegyezik a Prefork MPM-nél látottakkal. További MPM-ek --with-mpm=event --with-mpm=perchild Az Apache 2-ben az előzőekben bemutatottak mellett további MPM-eket is találhatunk, ezek azonban még kísérleti szakaszban vannak. Kettőt emelnénk ki közülük: az Event MPM-et és a Perchild MPM-et. Az előbbi, amely a Worker MPM egy változata, kizárólag az Apache 2.l-ben található meg. Jellemzője, hogy külön szálat biztosít a figyelő csatolók és az életben tartott kapcsolatok kezelésére. Ez jelentősen javítja a méretezhetőséget, hiszen így a többi szál nyugodtan feldolgozhatja a kérelmeket, és nem kell arra várniuk, hogy az ügyfél lezárjon egy kapcsolatot, vagy kiadjon egy új kérelmet. Mindez megoldást ad jó néhány, a 10. fejezetben felvetett kérdésre. A Perchild MPM lehetővé teszi, hogy az Apache a virtuális kiszolgálókat különböző felhasználók nevében futtassa. Ez növeli a rendszer biztonságát, és szükségtelenné teszi, hogy külön kiszolgálópéldányokat futtassunk. Érdemes még szólnunk a Metux MPM-ről, amely nagyszerűen használható a Perchild helyett (letölthető a címről). 117

130 Az Apache 2 szűrői <Directory /usr/local/apache/htdocs/> SetOutputFilter INCLUDES;PHP </Directory> AddOutputFilter INCLUDES.inc.shtml Az Apache szűrőkezelő rendszerére úgy tekinthetünk, mint egy futószalagra a gyárcsarnokban. A szűrők felelnek meg a munkásoknak, a kérelmek és a válaszok pedig a futószalagon haladó alkatrészeknek. Az egyes szűrők feldolgozzák a kapott tartalmat, aztán továbbadják a következő szűrőnek. A feldolgozás módja igen változatos lehet olyannyira, hogy egyes modulok (mint az SSL, az SSI, vagy a tömörítést megvalósító modul) szűrőként is működhetnek. A modulok szűrői futásidőben automatikusan működésbe léphetnek, de magunk is használatba vehetjük őket a beállítófájlokban. Példánkban a SetOutputFilter utasítással két szűrőt rendelünk egy könyvtár minden dokumentumához, majd az AddOutputFilter segítségével kiterjesztéseknek feleltetünk meg egy szűrőt. Mindemellett az AddOutputFilterByType utasítással a szűrőket meghatározott fájltípusokhoz is hozzárendelhetjük. Ha egyazon fájlra több szűrőkezelő utasítás - például a SetOutputFilter és az AddOutputFilter is hat, a rendszer egyesíti a kapott szűrőlistákat. A bemeneti szűrőket az AddInputFilter, az AddInputFilterByType és a SetInputFilter utasításokkal adhatjuk meg, amelyek használati alakja megegyezik az előbb megismert kimeneti társaikéval. Az Apache 2.1/2.2-ben rendelkezésünkre áll a mod_f ilter modul is, amely nagyobb rugalmasságot ad a szűrőláncok meghatározásában és beállításában. Itt lehetőségünk nyílik arra, hogy ezeket a beállításokat például egy HTTP-fejléc vagy környezeti változó meglétéhez kössük. Az Apache mint FTP-kiszolgáló Listen :21 <VirtualHost :21> FTP On DocumentRoot /usr/local/apache/ftpdocs ErrorLog /usr/local/apache/logs/ftp_error_log <Locatlon /> AuthName FTP AuthType basic AuthUserFile /usr/local/apache/conf/htusers Require valid-user </Location> </VirtualHost> Amint fejezetünk egy korábbi részében említettük, az Apache 2 több egyszerű webkiszolgálónál - inkább egyfajta általános kiszolgálókörnyezetnek tekinthető. Aki az Apache-ra építi a webkiszolgálóját, egyúttal kihasználhatja a rendszer megbízható, hordozható felépítését, bővítési módjait, valamint a rengeteg külső modul használatának lehetőségét. A mod_f tp esetében, amely az FTP-elérést biztosítja az Apache-ban, pontosan ez a helyzet. A legtöbb beállítási lehetőség, így a hitelesítési utasítások közösek a kiszolgáló többi részével. Az FTP-támogatás bekapcsolásához mindössze az FTP On utasítást kell elhelyeznünk a megfelelő Virtual Host tárolóban. Az FTP-kiszolgálók szokásos beállítási lehetőségeit pedig további utasítások FTPUmask, FTPTimeoutLogin, FTPBannerMessage és FTPMaxLoginAttempts biztosítják. 118

131 Könyvünk írásának idején a mod_ftp a legjobb úton halad afelé, hogy hivatalos ASF projekt váljék belőle. A modul letölthető a címről. Az Apache mint P0P3-kiszolgáló Listen 110 <VirtualHost *:110> POP3Protocol on POP3MailDrops /usr/local/apache/pop <Directory /usr/local/apache/pop> AuthUserFile /usr/local/apache/conf/htusers AuthName pop3 AuthType Basic Require valid-user </directory> </VirtualHost> A mod_pop3 modullal az Apache 2 POP3-kiszolgálóként is képes működni. A POP3 (vagyis Post Office Protocol 3) protokoll lehetővé teszi a levelezőprogramok (például az Outlook, a Eudora, vagy a Netscape Mail) számára, hogy üzeneteket töltsenek le egy központi kiszolgálóról. Fontos megjegyeznünk, hogy ez a modul levelek küldésére nem alkalmas ehhez egy SMTP (Simple Mail Transfer Protocol) kiszolgálóra van szükségünk, amilyen például a Sendmail vagy a Postfix. A POP3 támogatásának bekapcsolásához mindössze a POP3Protocol On utasítást kell a megfelelő virtuális kiszolgáló tárolójában elhelyeznünk. A POP3MailDrops segítségével meghatározhatjuk, hogy hová kerüljenek a felhasználó levelesládái. Fontos, hogy az így megadott könyvtárakat az Apache-ot futtató felhasználó képes legyen olvasni és írni. A mod_pop3 modult letölthetjük a címről. Dinamikus tartalomtömörítés #Apache 2 mod_deflate AddOutputFilterByType DEFLATE text/html text/plain text/xml SetEnvIfNoCase Reguest_URI \.(?:gif jpe?g png)$ no-gzip dont-vary BrowserMatch ^Mozilla/4 gzip-only-text/html #Apache 1.3 mod_gzip mod_gzip_static_suffix.gz AddEncoding gzip.gz mod_gzip_item_include file \.html$ Az Apache 2 mod_deflate szűrőmodulja egy DEFLATE nevű szűrőt bocsát a rendelkezésünkre, amellyel tömöríthetjük a kimenő adatokat. A tömörítés kétélű fegyver: egyrészt jelentős terhet jelent a processzor számára, másrészt viszont csökkenti az ügyfélnek elküldött adatok mennyiségét. Ez különösen akkor bizonyulhat előnyösnek, ha ügyfeleink lassú internetkapcsolattal rendelkeznek, és a tartalom jól tömöríthető (a HTML oldalak jellemzően ilyenek). Az eleve tömörített tartalom, mint a ZIP fájlok vagy a JPEG képek esetében nem sokat (vagy egyáltalán semmit sem) nyerünk a további tömörítéssel. A módszer sikerességéhez természetesen szükség van arra is, hogy ügyfelünk képes legyen kicsomagolni a kapott tartalmat ez azonban napjaink böngészőinek általában nem jelent gondot. 119

132 Ha tudunk róla, hogy valamelyik ügyfelünknek gondjai vannak bizonyos típusú tömörített tartalmakkal, a SetEnvInf, illetve a BrowserMatch utasítással beállíthatjuk a no-gzip környezeti változót. Ez a példában is látható módon megakadályozza, hogy a mod_deflate tömörítse az ügyfélnek küldött tartalmat. Az Apache 1.3 megfelelő modulja, a mod_gzip egyaránt képes statikus és dinamikus tartalmak tömörítésére. Letöltéséhez látogassunk el az alábbi címre: 120

133 Guy Montag Ez a könyv az Apache: Phrase Book: Essential Code and Commands magyar kiadásának scannelt, majd karakterfelismert, újratördelt változata, B5 méretben. Az eredetihez képest elhagytam az indexet (lévén kereshető PDF), a néhány benne szereplő képet (melyek semmitmondóak), valamint a zsebkönyv formátumot. A címoldalt megváltoztattam, és a tartalomjegyzéket hozzáigazítottam az áttördelt verzióhoz. Guy Montag