Daniel Lopez

APACHE

ZSEBKÖNYV

G

uy Monta

g

Daniel Lopez • Jesus Blanco

Apache zsebkönyv

Budapest, 2007 SAMS KISKAPU

G

uy Monta

g

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 0672328364, 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álintMűszaki szerkesztés: Csutak Hoffmann LeventeTördelés: Kis PéterBorító: Bognár Tamás

Felelős kiadó a Kiskapu Kft. ügyvezető igazgatója

© 2007 Kiskapu Kft.1134 Budapest, Csángó u. 8.Telefon: (+36-1) 477-0443 Fax: (+36-1) 303-1619www.kiskapukiado.hue-mail: kiado@kiskapu.hu

ISBN: 978 963 9637 32 0

Készült az Aduprint Nyomdában.Felelős vezető: Tóth Béláné

V

TartalomjegyzékElőszó . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Bevezetés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1 Az Apache alapjai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Az Apache felfedezése. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Az Apache jelenlétének vizsgálata. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Az Apache 1.3 telepítése Linux és Unix rendszereken . . . . . . . . . . . . . . . . . . . . . . 6Az Apache 2.0 telepítése Linux és Unix rendszereken . . . . . . . . . . . . . . . . . . . . . . 7Az Apache telepítése Windows rendszereken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Telepíthetjük-e egyszerre az Apache különböző változatait egyetlen gépre? . . . . . 8A beállítófájlokról . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Több beállítófájl használata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Az Apache indítása, leállítása és újraindítása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Az Apache IP címének és portjának megváltoztatása . . . . . . . . . . . . . . . . . . . . . . 10Az Apache-ot futtató felhasználó megváltoztatása . . . . . . . . . . . . . . . . . . . . . . . . 11A kiszolgáló nevének megadása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11lkon hozzárendelése weblapokhoz. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11A kiszolgálón elérhető modulok felfedezése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Modulok be- és kikapcsolása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Modulok hozzáadása fordítás után újrafordítás nélkül . . . . . . . . . . . . . . . . . . . . . 13Tartalom közzététele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Utasítástárolók . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Az Apache alapértelmezett utasítástárolói . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Feltételesen kiértékelt utasítástárolók . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2 Hibaelhárítás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Segítség! Nem működik az Apache kiszolgáló! . . . . . . . . . . . . . . . . . . . . . . . . . . 17A hibanapló . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17A rendszernaplózó démon használata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17A naplóban rögzített adatok mennyiségének szabályozása . . . . . . . . . . . . . . . . . . 18Az Apache beállításainak vizsgálata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Az Apache tesztelése a parancssorból . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Az Apache futásának ellenőrzése. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Az Apache leállításának lehetőségei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Hibakeresés az Apache-ban az Apache segítségével . . . . . . . . . . . . . . . . . . . . . . . 21Az indítás során felmerülő hibák . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Névfeloldási problémák . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Gondok a napló- és beállítófájlok elérésével . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

VI

Elérés megtagadva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Belső kiszolgálóhibák . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24További hibanaplók . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Nem működő átirányítás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Hibaelhárítási teendők . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3 Naplózás és megfi gyelés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Bevezetés a naplózásba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Az Apache alapértelmezett naplófájljai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Naplóformátumok létrehozása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Egyéni naplófájl létrehozása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Naplók átirányítása külső programokhoz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Kérelmek feltételes naplózása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31A webhelyre mutató hivatkozások fi gyelése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Az Apache fi gyelése a mod_status modullal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Az Apache megfi gyelése az SNMP-vel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Naplók elemzése nyílt forrású segédprogramokkal. . . . . . . . . . . . . . . . . . . . . . . . 32Naplók valósidejű megfi gyelése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Naplók forgatása és tárolása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Az IP címek feloldásának szabályozása. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34A naplózott IP címek feldolgozása. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Az Apache automatikus újraindítása lefagyás esetén . . . . . . . . . . . . . . . . . . . . . . 35Naplófájlok egyesítése és szétválasztása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Külön naplók a virtuális kiszolgálók számára . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Jellemző naplóbejegyzések . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4 URL-megfeleltetés és dinamikus tartalom . . . . . . . . . . . . . . . . . . . . . . . . 39URL-megfeleltetés. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39URL-ek megfeleltetése fájloknak az Alias utasítással . . . . . . . . . . . . . . . . . . . . . . 39URL-minták megfeleltetése fájloknak az AliasMatch utasítással . . . . . . . . . . . . . 39Oldalak átirányítása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Átirányítás a fájl legfrissebb változatához. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Hibás vagy nem engedélyezett kérelmek átirányítása . . . . . . . . . . . . . . . . . . . . . . 40Tartalomkezelők meghatározása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41A MIME típusokról . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41A MIME típusok beállítása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41A CGI parancsfájlok futtatásának alapjai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Erőforrások megjelölése futtatható CGI parancsfájlként. . . . . . . . . . . . . . . . . . . . 42Parancsfájlok hozzárendelése HTTPfüggvényekhez és MIME típusokhoz . . . . . 42A CGI parancsfájlok teljesítményének növelése . . . . . . . . . . . . . . . . . . . . . . . . . . 43Az SSI használata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Az SSI beállítása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Környezeti változók beállítása. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

VII

Környezeti változók dinamikus beállítása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Különleges környezeti változók. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46A tartalomegyeztetés beállításai. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Karakterkészletek és nyelvi beállítások megadása . . . . . . . . . . . . . . . . . . . . . . . . 47URL-megfeleltetés magasabb szinten a mod_rewrite modullal . . . . . . . . . . . . . . 48A „záró perjelek’’ problémája . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48A gépelési hibák kijavítása. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Gondok a kis- és nagybetűkkel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5 Virtuális kiszolgálók . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51A virtuális kiszolgálókról. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Az IP alapú virtuális kiszolgálókról. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Az IP alapú virtuális kiszolgálók beállítása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51A név alapú virtuális kiszolgálókról . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52A név alapú virtuális kiszolgálók beállítása. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Mi történik, ha a kérelem nem felel meg egyetlen virtuális kiszolgálónak sem? . 53Alapértelmezett név alapú virtuális kiszolgáló beállítása . . . . . . . . . . . . . . . . . . . 53Alapértelmezett IP alapú virtuális kiszolgáló beállítása . . . . . . . . . . . . . . . . . . . . 54A név és IP cím alapú virtuális kiszolgálók együttes használata . . . . . . . . . . . . . . 54Hibakeresés a virtuális kiszolgálók beállításaiban. . . . . . . . . . . . . . . . . . . . . . . . . 55Az SSL és a név alapú virtuális kiszolgálók . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55A virtuális kiszolgálók kezelésének további módjai . . . . . . . . . . . . . . . . . . . . . . . 56Egyéb modulok a virtuális kiszolgálók kezelésére . . . . . . . . . . . . . . . . . . . . . . . . 56Könyvtárankénti beállítófájlok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57A könyvtárankénti beállítófájlok hatókörének szabályozása. . . . . . . . . . . . . . . . . 57A könyvtárankénti beállítófájlok használatának kikapcsolása. . . . . . . . . . . . . . . . 58

6 Biztonság és hozzáférés-szabályozás. . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Különbségek az Apache változatai között . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Egyszerű és kivonatos hitelesítés. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Az Apache hozzáférés-szabályozása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Az Apache hitelesítési és engedélyezési beállításai. . . . . . . . . . . . . . . . . . . . . . . . 60Felhasználó-adatbázis létrehozása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Felhasználók és csoportok hitelesítése a Require utasítással. . . . . . . . . . . . . . . . . 61Jelentős számú felhasználó kezelése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62A hozzáférés meghatározott IP címekre korlátozása . . . . . . . . . . . . . . . . . . . . . . . 63A hozzáférés tiltása egyes IP címekről . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63A hozzáférés-szabályozási módszerek együttes használata. . . . . . . . . . . . . . . . . . 64Az „Elérés megtagadva’’ oldal testreszabása. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Felhasználói szabályozás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65A rendszerfájlok és érzékeny fájlok elérésének megtagadása . . . . . . . . . . . . . . . . 66Programfuttatási korlátozások . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Mit tehetünk a visszaélések ellen?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

VIII

A könyvtártartalom kiíratásának letiltása. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67A Server: fejléc módosítása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67A képekre mutató közvetlen hivatkozások letiltása . . . . . . . . . . . . . . . . . . . . . . . . 67A HTTP-függvények korlátozása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68A hozzáférés korlátozása a böngésző alapján . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69A <Location> és a <Directory> szakaszok használata . . . . . . . . . . . . . . . . . . . . . 69További hitelesítési modulok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69A mod_security modul. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Apache 2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Naprakész biztonsági beállítások. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Biztonsági teendők. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

7 SSL/TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Mi is az SSL?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Hogyan működik az SSL? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Az OpenSSL fordítása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Titkosítási kulcsok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Kulcspár készítése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Jelszóval védett kulcspár készítése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77A kulcs jelszavas védelmének feloldása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Tanúsítványok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Tanúsítványkérelem létrehozása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78A tanúsítványkérelem tartalmának megjelenítése . . . . . . . . . . . . . . . . . . . . . . . . . 79Saját tanúsítvány létrehozása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Az SSL-támogatás biztosítása az Apache 1.3-ban. . . . . . . . . . . . . . . . . . . . . . . . . 80Az SSL-támogatás biztosítása az Apache 2.x-ben. . . . . . . . . . . . . . . . . . . . . . . . . 80Az Apache minimális beállításai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Az Apache indítása SSL-támogatással. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81SSLPassPhraseDialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Az SSL teljesítményének fokozása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Átirányítás SSL-kapcsolatra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Név alapú virtuális kiszolgálók és az SSL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Az Apache hitelesítési moduljai és az SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Figyelmeztető üzenetek SSL-képes webhelyek elérésénél . . . . . . . . . . . . . . . . . . 83Ügyféltanúsítványok készítése. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Hitelesítés ügyféltanúsítványokkal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84A mod_ssl-en túl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Az SSL-képes webhelyek parancssori ellenőrzése . . . . . . . . . . . . . . . . . . . . . . . . 85Az SSL-megvalósítások hibáinak kezelése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Összetett hozzáférés-szabályozás a mod_ssl modullal . . . . . . . . . . . . . . . . . . . . . 85Kapcsolódó fejezetek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

IX

8 Tartalom közzététele a DAV segítségével . . . . . . . . . . . . . . . . . . . . . . . . . 87Tartalom közzététele az Apache segítségével . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Ismerkedés a WebDAV-val . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87A mod_dav használatának előnyei. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88A WebDAV és a HTTP protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88A mod_dav telepítése Apache 2.0 kiszolgálókon . . . . . . . . . . . . . . . . . . . . . . . . . 88A mod_dav telepítése Apache 1.3 kiszolgálókon . . . . . . . . . . . . . . . . . . . . . . . . . 89A WebDAV alapbeállításai. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89A WebDAV biztonsági beállításai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89DAV-erőforrások elérése a Microsoft Offi ce-ból. . . . . . . . . . . . . . . . . . . . . . . . . . 90DAV-erőforrások elérése a Microsoft Windowsból . . . . . . . . . . . . . . . . . . . . . . . . 90DAV-erőforrások elérése a Firefoxból . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91DAV-erőforrások elérése a parancssorból . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Hibás ügyfelek kezelése. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93A mod_speling és a DAV. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93A dinamikus tartalomkezelés és a DAV. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Felhasználói oldalak engedélyezése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Egyéb módszerek a felhasználói könyvtárak kezelésére . . . . . . . . . . . . . . . . . . . . 94A DAVLockDB segít a bajban. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

9 Teljesítmény és méretezhetőség . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Az Apache fi nomhangolása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97A teljesítményről és a méretezhetőségről . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97A hardver fi nomhangolása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Az operációs rendszer korlátainak tágítása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Az operációs rendszer folyamatokkal szembeni korlátozásainak lazítása. . . . . . . 98A fájlleírók számának növelése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Külső folyamatok szabályozása. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99A fájlrendszer teljesítményének növelése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99A hálózati és állapotbeállítások fi nomhangolása . . . . . . . . . . . . . . . . . . . . . . . . . 101A visszaélések elkerülése. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102A kapcsolatok és a sávszélesség korlátozása . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Mit kezdjünk a robotokkal? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Fordított helyettes kiszolgálók és terheléselosztók . . . . . . . . . . . . . . . . . . . . . . . 104Átmeneti tárolás és tömörítés. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104Optimalizálás modulokkal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Az Apache alternatívái. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

10 Helyettes kiszolgálók és gyorsítótárak . . . . . . . . . . . . . . . . . . . . . . . . . 107Miért van szükség gyorsítótárakra és helyettes kiszolgálókra? . . . . . . . . . . . . . . 107Egyszerű és fordított helyettes kiszolgálók . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Az Apache 1.3, 2.0 és 2.2 közti különbségek . . . . . . . . . . . . . . . . . . . . . . . . . . . 107A mod_proxy támogatásának bekapcsolása. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

X

A hagyományos helyettesek támogatásának beállítása . . . . . . . . . . . . . . . . . . . . 108Az URL-tér egységesítése fordított helyettes alkalmazásával. . . . . . . . . . . . . . . 109A háttérkiszolgálók elrejtése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Fordított helyettesek alkalmazásának tiltása egyes URL-eken . . . . . . . . . . . . . . .110A teljesítmény növelése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .110Az SSL-kérelmek terhelésének áthelyezése . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111Helyettesek adatainak átadása fejlécekben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111Fejlécek kezelése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111Gyorsítótárazó helyettes kiszolgálók . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112Gyorsítótárak az Apache 2-ben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112Terheléselosztás . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113Kapcsolódás a Tomcathez . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113Egyéb helyettesek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114Láthatatlan HTTP-helyettesek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114

11 Protokollmodulok és MPM-ek. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Az Apache felépítésének fejlődéstörténete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115A megfelelő MPM kiválasztása . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115Folyamat alapú MPM-ek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115A Prefork MPM beállításai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .116Szálas és kevert MPM-ek. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .116A Worker MPM beállításai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117További MPM-ek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117Az Apache 2 szűrői . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118Az Apache mint FTP-kiszolgáló . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118Az Apache mint P0P3-kiszolgáló . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119Dinamikus tartalomtömörítés. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119

1

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 bizto-sí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 grafi kus 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.

2

AjánlásEricának és Marisolnak, akik oly sok szeretetet és támaszt adtak.

KöszönetnyilvánításMindenekelő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ésekA 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. E-mailben 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ő e-mailek 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.

E-mail: webdev@samspublishing.comLevelezési cím: Mark Taber

Associate PublisherSams Publishing800 East 96th StreetIndianapolis, IN 46240 USA

ÜgyfélszolgálatA www.samspublishing.com/register 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.

3

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 webki-szolgálónk jellemzőit. Persze egy ilyen rövidke könyv elolvasása után még nem mondhatjuk el, hogy min-dent tudunk az Apache-ról, ezért érdemes bejelentkeznünk a www.samspublishing.com/register 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.

4

5

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 ismer-tebb 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ör-dülékeny futásához elengedhetetlenül szükségesek.

Az Apache jelenleg a legnépszerűbb webkiszolgáló az Interneten; a Netcraft (http://www.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

6

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őrizhet-jü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/2.0.54 Server built: Apr 16 2005 14: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 kat-tintva 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 http://www.apache.org címen.

Az Apache 1.3 telepítése Linux és Unix rendszereken

tar xvfz apache_1.3.33.tar.gzcd apache_1.3.33./confi gure --prefi x=/usr/local/apache --enable-shared=maxmakemake install

Operációs rendszerünk csomagkezelő eszközeinek segítségével a kiszolgáló előre lefordított változatait telepít-hetjük. Gyakran érdemes ezt a megoldást választanunk, mivel így könnyebb együttműködni a meglevő fájlszer-kezettel, valamint más cégek programcsomagjaival. Fontos azonban azzal is tisztában lennünk, miként építhet-jü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.

7

Mindenekelőtt látogassunk el a http://httpd.apache.org 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 1.3.33-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 --prefi x 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 ren-delkezik, 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_1.3.33.tar.bz2

Az Apache 2.0 telepítése Linux és Unix rendszereken

tar xvfz apache_2.0.54.tar.gzcd apache_2.0.54./confi gure --prefi x=/usr/local/apache --enable-so --enable-mods-shared=mostmakemake install

Az itt alkalmazott eljárás meglehetősen hasonlít az előzőekben bemutatotthoz, a betölthető modulok támo-gatá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 http://httpd.apache.org 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 kiszol-gá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.

8

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 kiszol-gá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 al-kalmazunk, 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 www.example.com webhely főrészének kezelésére, ugyanakkor a www.example.com/signup/ 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 rendszere-ken. 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 Operációs rendszer/etc/httpd/httpd.conf/etc/httpd/httpd2.conf Suse, Mandrake és régebbi Red Hat rendszerek

/etc/httpd/conf/httpd.conf/etc/httpd/conf/httpd2.conf Újabb Red rendszerek, Fedora Core

/usr/local/apache2/conf/usr/local/apache/conf

A forráskód fordítása esetén, a korábbiakban leírtak szerint

c:\Program Files\Apache Group \Apache2\conf\httpd.confc:\Program Files\Apache Group \Apache\conf\httpd.conf

Windows

/private/etc/httpd/httpd.conf 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 fi gyelmen 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.

9

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ár-hoz 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 megha-tá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 te-lepí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 kiol-vassa 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.

10

Az apachectl parancsfájl mellett a kill paranccsal közvetlenül is küldhetünk jelzéseket a szülőfo-lyamatoknak. 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ű grafi kus 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 192.168.200.4:80Listen 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, ame-lyen az Apache fi gyelhet, valamint (ez nem kötelező) egy IP címet. Amennyiben ez utóbbit nem adjuk meg, az Apache minden elérhető IP címet fi gyel. Példánk kódjának hatására az Apache a 80-as porton, a 192.168.200.4 IP címről érkező kérelmeket, valamint a 8080-as porton az összes elérhető IP címről érkező kérelmet fi gyeli. Több Listen utasítással több portot és IP címet is fi gyelhetünk egyszerre.

11

A portot önmagában is megadhatjuk a Port utasítással, de ha már a Listen-t használjuk, a rendszer fi -gyelmen 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 szol-gá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 www.example.com

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 sze-rint 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 hosszadal-mas 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 oldal-lal 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.

12

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 futtat-ható kódjába. Az eredmény valahogy így fest:

Compiled in modules: core.cprefork.chttp_core.cmod_so.c

Ha Apache-telepítésünk támogatja a betölthető modulokat, ezek megosztott könyvtárakba kerülnek, ame-lyek 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, ame-lyek futásidőben kerültek a rendszerbe.

Modulok be- és kikapcsolása

./confi gure (...) --enable-status

./confi gure (...) --disable-status

A modulokat a fordítás során a confi gure parancs --enable-modul és --disable-modul kapcso-ló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, ame-lyeket 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á kapcso-ló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>

13

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ít-suk 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értel-mezett 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 megje-lennek 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:

http://www.example.com/foo/bar.html

14

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ít-va é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 ügy-felek á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 le-hetővé teszi, hogy egy telepítéssel több webhelyet is fenntartsunk. Erről bővebben az 5. fejezetben olvas-hatunk.

<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 cso-portjá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 kife-jezéseket is fogadhatnak paraméterként, amennyiben a kifejezés elejére egy ~ ka-

15

raktert teszünk. A szabályos kifejezések karakterláncok meghatározott csoportját ír-já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 hasz-náljuk inkább a DirectoryMatch, LocationMatch és FilesMatch utasításokat. A szabályos kifejezésekről bővebben olvashatunk a http://en.wikipedia.org/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.

<IfDefi ne> – Az Apache csak akkor hajtja végre az ebben a tárolóban elhelyezett utasításokat, ha meg-adjuk 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 <IfDefi ne !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 pa-ramé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:

<IfDefi ne SSL>LoadModule ssl_module modules/mod_ssl.so</IfDefi ne>

A tárolóban található utasítás életre hívására következőt írhatjuk a parancssorba:

# httpd –DSSL

16

17

2 Hibaelhárítás

Fejezetünkben az Apache használata során leggyakrabban előforduló problémákkal és kezelésükkel foglal-kozunk 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 áll-nunk, 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ód-szerekre 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 kiszol-gáló működésével kapcsolatos fi gyelmezteté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önyv-tá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

18

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 uta-sí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” (fi gyelmezteté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.

2.1. táblázat A LogLevel utasítás paraméterei az Apache leírása alapján

Paraméter Leírás Példaemerg Vészhelyzet - a rendszer

használhatatlanChild cannot open lock fi le.Exiting.

alert Azonnali cselekvésrevan szükség

getpwuid: couldn’tdetermine username 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 Figyelmeztető körülmények

Child process 1234 did not exit, sending another SIGHUP.

notice Veszélytelen, de jelentős események

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 confi g fi le...

19

Az Apache beállításainak vizsgálata

# apachectl confi gtest

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 www.apache.org 80Trying 192.87.106.226...Connected to ajax-1.apache.org (192.87.106.226).Escape character is ‘^]’.HEAD / HTTP/1.0

HTTP/1.1 200 OKDate: Sun, 04 Sep 2005 20:42:02 GMTServer: Apache/2.0.54 (Unix) mod_ssl/2.0.54

OpenSSL/0.9.7a DAV/2 SVN/1.2.0-dev Last-Modifi ed: Sat, 03 Sep 2005 11:35:42 GMT ETag: ″203a8-2de2-3ffdc7a6d3f80″ Accept-Ranges: bytes Content-Length: 11746 Cache-Control: max-age=86400 Expires: Mon, 05 Sep 2005 20:42:02 GMT Connection: closeContent-Type: text/html; charset=ISO-8859-1 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 bizto-sak vagyunk abban, hogy a hálózat beállításai megfelelőek, akkor az Apache nem fi gyeli 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 ke-resztül. Ha kapcsolatba tudunk lépni az Apache kiszolgálóval a localhost-ról a telnet segítségével, bön-gé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 www.apache.org 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.

20

Ha Unix rendszerünkön elérhető a lynx parancssori böngésző, hasonló eredményt kaphatunk az alábbi paranccsal:

lynx -head -dump http://www.apache.org

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 httpd25297 ? 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 IPvhttpd 14441 nobody 3u IPv4 136524

TCP www.example.com:http (LISTEN) Httpd 25297 root 3u IPv4 136524

TCP www.example.com:http (LISTEN) Httpd 30277 nobody 3u IPv4 136524

TCP www.example.com:http (LISTEN)

...netstat -ltnpActive Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program nametcp 0 0 192.168.1.151:80 0.0.0.0:* LISTEN 25297/httpdtcp 0 0 0.0.0.0:22 0.0.0.0:* 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 ren-delkezé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 fi gyel 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 álla-potáról.

21

Az Apache leállításának lehetőségei

# kill -HUP 25297# kill -9 25297

Néha szükséges, de legalábbis kényelmesebb a kiszolgálót közvetlenül a kill paranccsal leállítani ahe-lyett, 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 meg-adá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, il-letve 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:

http://www.snert.com/Software/mod_loopback/index.shtml

A mod_tee és a mod_trace_output külső gyártóktól származó modulok, amelyek tárolják a szolgál-tatott tartalmat. Letöltésük az alábbi címekről lehetséges:

http://apache.webthing.com/mod_tee http://trace-output.sourceforge.net

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.

22

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 –, ame-lyek 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 defi ned by a module not included in the server confi guration

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, ame-lyikhez 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 ugyan-ezt 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:50 2005] [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 fut-tatott 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 gon-dok 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,

23

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ép-neveket 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 fi le /usr/local/apache/logs/error_log.

A „permission denied” (engedély megtagadva) hibaüzenet azt jelzi, hogy nem rendelkezünk megfelelő jo-gosultsá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 te-lepí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öl-teni 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 rendel-kezik olvasás és futtatási jogosultsággal a dokumentumhoz vezető könyvtárak mindegyikéhez. Unix rend-szereken ezeket a jogosultságokat a chmod segédprogrammal módosíthatjuk.

A hibanaplóban megjelenő „Client denied by server confi guration” üzenet arra utal, hogy az elutasítás ere-dete 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.

24

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ér-dé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 192.168.200.3] 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ág-gal, é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 össze-szerkesztésénél. Esetenként maga az operációs rendszer vagy az Apache is leállíthatja a programunkat, ha an-nak erőforrás-felhasználása (memória, processzoridő) meghalad egy bizonyos szintet (lásd a 9. fejezetben).

Malformed header

[error] [client 192.168.200.3] 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.

25

További hibanaplók

RewriteLog /usr/local/apache/logs/rewrite_logRewriteLogLevel warnSSLLog /usr/local/apache/logs/ssl_logSSLLogLevel warnScriptLog 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, 127.0.0.1 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 gon-dot. 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 ugyanan-nak a felhasználónak a birtokában vannak, aki az Apache-ot telepítette, és rendelkezik írási jogosultsággal ezekhez a fájlokhoz.

26

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 kiszol-gálót, távolról azonban nem, az Apache valószínűleg egy helyi címet vagy egy olyan portot fi gyel, 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 fi gyeli, de a hálózatun-kon 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éd-programmal. 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-confi g-securitylevel se-gé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 gyanakod-hatunk.

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önyv-tárhoz rendelkezik az olvasás és a tartalomkiíratás jogosultságával.

27

Ellenőrizzük, hogy nem arról van-e szó, hogy egy olyan könyvtárat szeretnénk elérni, amely nem rendelke-zik 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 leg-gyakrabban 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:

http://httpd.apache.org/lists.html#http-users

Fontos, hogy betartsuk a lista szabályait - előbb gondolkodjunk el magunk a megoldáson, és csak ha va-ló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.

28

29

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ök-kel 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 programcsomag-hoz tartozó, illetve külső gyártók által készített segédprogram használatát, amelyekkel megfi gyelhetjük az Apache kiszolgálót, illetve elemezhetjük a naplókat.

Az Apache alapértelmezett naplófájljai

Az Apache számos megfi gyelési és naplózási lehetőséget biztosít, amelyekkel nyomon követhetjük a kiszol-gá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őbbi-ekben 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:

192.168.200.4 - someuser [12/Jun/2005:08:33:34 +0500] ″GET /example.png HTTP/1.0″ 200 1234

Ha a Combined Log Format mellett döntünk, ilyen bejegyzéseket kapunk:

192.168.200.4 - someuser [12/Jun/2005:08:33:34 +0500] ″GET /example.png HTTP/1.0″ 200 1234 http://www.example.com/index.html ″Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7)″

30

É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 192.168.200.4).

• %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 http://www.example.com/index.html).

• %{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 meg-hatá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 86400″

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 rendszergaz-da indította el a kiszolgálót, a külső program is az ő jogosultságait kapja meg – tehát legyünk nagyon óva-tosak! Ü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.

31

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 jelen-lé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 fi gyelése

SetEnvIfNoCase Referer www\.example\.com internalreferralLogFormat ″%{Referer}i -> %U″ refererCustomLog 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 hasz-ná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, ame-lyek 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 fi gyelése a mod_status modullal

<Location /server-status> SetHandler server-status Order Deny,Allow Deny from all Allow from 192.168.0</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 fi gyelje 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.

32

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 ada-tok 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 http://www.example.com/server-status címet.

Az Apache megfi gyelé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 webkiszol-gá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 fi gyelmeztetni, 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ár-huzamos ügyfélkapcsolatok számának hirtelen növekedésekor.

Az Apache 1.3 esetében a http://www.mod-snmp.com címről letölthető mod_snmp modult al-kalmazhatjuk, 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 http://modapache-snmp.sourceforge.net/ címen. Támogatja az SNMP l-es, 2-es és 3-as vál-tozatá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 http://www.netsnmp.org segédprogramjai, az OpenNMS (http://www.opennms.org), valamint a Nagios (http://www.nagios.org).

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 ada-tainak 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 - http://ww.mrunix.net/webalizer/• AWStats - http://awstats.sf.net

Más programok bővebb szolgáltatáskészlettel rendelkeznek, például grafi kusan jelenítik meg a látogatóink által bejárt útvonalakat:

• Visitors — http://www.hping.org/visitors/• Pathalizer - http://pathalizer.bzzt.net/

33

Naplók valósidejű megfi gyelé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 http://clueful.shagged.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 megfi gyelhetjü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: http://www.garand.net/security.php• A ScanErrLog segédprogramot az alábbi címről tölthetjük le:

http://www.librelogiciel.com/software/

Kérelmek rögzítése adatbázisbanAz 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:

http://www.outoforder.cc/projects/apache/mod_log_sql

• Ezt követően az Apache LogView SQL eszközével lekérdezhetjük ezt az adatbázist:

http://freshmeat.net/projects/apachelogviewsql

•A pglogd összegyűjti a naplókat, és a naplóbejegyzéseket egy PostgreSQL adatbázisban tárolja:

http://www.digitalstraturo.com/pglogd/

Naplók forgatása és tárolása

CustomLog ″|bin/rotatelogs /var/logs/apachelog 86400″ 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.

34

Az Apache erre a célra a rotatelogs segédprogramot bocsátja a rendelkezésünkre, de hasonló progra-mot találhatunk a http://cronolog.org/ 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 na-ponta áthelyezzük a /var/logs/ könyvtárba (egy nap 86 400 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:

192.168.200.4 - someuser [12/Jun/2005:08:33:34 +0500] ″GET /example.png HTTP/1.0″ 200 1234

Ha a utasítást on-ra állítjuk, ugyanez a bejegyzés így alakul:

unitl2.example.com - someuser [12/Jun/2005:08:33:34 +0500] “GET /example.png HTTP/1.0″ 200 1234

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 meg-nyújtja a válaszidőt. Ennek elkerülésére kikapcsolhatjuk a névfeloldást, és egy utófeldolgozó segédprog-rammal 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él-dában is bemutatott átirányítást.

35

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 webkiszol-gá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/bashif [ ’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ít-ja lefagyás esetén.

Unix rendszereken mindezt fi gyelő parancsfájlokkal (watchdog) valósíthatjuk meg, amelyek más progra-mok futását fi gyelik, és ha a szemmel tartott program lefagy, újraindítják. Példánkban egy egyszerű Linux-parancsfájlt láthatunk, amely fi gyeli 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 parancs-fá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 http://perl.apache.org/docs/general/control/control.html címen egy kifi no-multabb fi gyelő parancsfájlt találhatunk, amely elektronikus levelet küld, ha a kiszolgáló leállt, és képes egyes httpd-folyamatazonosítók fi gyelésére.

A legtöbb Linux-kiadásban találhatunk olyan általános fi gyelő 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-logfi le 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:

http://www.coker.com.au/logtools/

A vlogger lehetővé teszi, hogy egyetlen naplófolyamot a virtuális gépekhez tartozó naplófájlokra bont-sunk, emellett helyettesíthetünk vele más segédprogramokat is, mint a cronolog. A programot letölthet-jük a http://n0rp.chemlab.org/vlogger/ címről.

36

Külön naplók a virtuális kiszolgálók számára

<VirtualHost 192.168.200.3>ServerName vhost1.example.comCustomLog logs/vhost1.example.com_log combinedErrorLog 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_virtualhostCustomLog 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ét-vá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 fi gyelmen 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 webhe-lyü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 web-helyü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 indexe-lé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 fo-lyamat elindulásakor a rendszer létrehozza, a leálláskor pedig törli. Ha az Apache leállítása nem szabályos

37

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/1-0...″ ″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ő legha-marabb az Apache legfrissebb változatát (lásd a 6. fejezetet).

38

39

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önyv-tá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 URL-eket, ha a kis- és nagybetűk különbségét is fi gyelembe 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 bemu-tatott utasítás használatakor a http://www.example.com/icons/local/ 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 alkalmaz-zuk, majd a http://www.example.com/icons 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 al-kö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 http://en.wikipedia.org/wiki/Regular_expression címen.

40

Oldalak átirányítása

Redirect /news http://news.example.com Redirect /latest /3.0

A webhelyek felépítése rendszerint változik az idő előrehaladtával, erről azonban azok gyakran nem ér-tesü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ő kiszol-gá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 http://www.example.com/news/today/index.html címre érkezik, a http://news.example.com/today/index.html 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 kife-jezé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álto-zatokat 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 http://www.example.com/myapp-2.5.1-demo.tgz címre érkező kérelmeket átirányítja a http://www.example.com/myapp-3.0demo.tgz címre, a http://www.example.com/myapp-1.2-manual.pdf címre érkező kérelmeket pedig a http://www.example.com/myapp-3.0-manual.pdf 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 dokumentu-mokra, 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ó meg-jegyzésében további útmutatást találhatunk az „elérés megtagadva” oldalak testreszabására.

41

Tartalomkezelők meghatározása

AddHandler cgi-script .pl .cgi<Location ″/cgi-bin/*.pl″>Options +ExecCGISetHandler cgi-script</Location>

A tartalomkezelők lehetővé teszik, hogy meghatározzuk, milyen műveletet végezzen az Apache a kérelme-zett 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 ese-té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 ren-delkező fájlt CGI parancsfájlként kezeljen.

A SetHandler utasítással egy helyen, illetve könyvtárban található fájlokhoz rendelhetünk tartalomkeze-lő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 doku-mentumok 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.

42

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 webkiszol-gá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 kiszol-gá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él-nek, 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 eset-ben 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/fi lter.cgi# Adott HTTP-függvény társítása CGI# parancsfájlhozScript 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áj-lokhoz. 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:

43

• 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 ten-nü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 fi gyelü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 értel-mezőben futnak, nem kell súlyos időveszteséggel fi zetnü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 http://www.fastcgi.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.

44

Az SSI használata

Document on diskThis document, <!--#echo var=″DOCUMENT_NAME″ -->,was last modifi ed <!--#echo var=″LAST_MODIFIED″ -->

Content received by the browserThis document, sample.shtml,was last modifi ed Sunday, 14-Sep-2005 12:03:20 PST

Az SSI (Server Side Includes, kiszolgálóoldali beágyazott kód) egy egyszerű, „régimódi” webes techno-ló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 webol-dalak 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 http://httpd.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 barUnSetEnv fooPassEnv 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ő folyama-tok – í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.

45

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=fooSetEnvIf 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 HTTP-fejlé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 nap-ló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 mobiltelefo-nok 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ünk-re á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 ki-fejezések használatát.

46

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 kapcso-laton, ezért csak akkor éljünk ezzel a lehetőséggel, ha olyan ügyféllel találkozunk, amely nem képes támo-gatni 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 hibajelen-ségek elkerülésére, a 7. és 8. fejezetben mutatjuk be.

TartalomegyeztetésAddCharset 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ódo-lásokat egyes kiterjesztéseknek.

A tartalomegyeztetés beállításai

Options +MultiviewsAddHandler 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).

47

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ékony-sá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 kutakod-nunk a fájlrendszer bugyraiban. A típustérképek voltaképpen maguk is fájlok, amelyek összekötik a fájlne-veket 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 tartal-mát mutatjuk be:

4.1. példa Egy típustérképfájl tartalmaURI: page.html.en

Content-type: text/html

Content-language: en

URI: page.html.fr

Content-type: text/html; charset=iso-8859-2Content-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 enAddDefaultCharset iso-8859-1LanguagePriority 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 do-kumentumainkhoz 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álto-zatot a dokumentumból, a kiszolgáló ezt adja vissza az ügyfélnek. Ha nem jár sikerrel, a spanyol változat-nak néz utána, ha pedig ilyen sincs, beéri egy német nyelvű dokumentummal is. Erről a témakörről bőveb-ben a http://httpd.apache.org/docs/ 2.0/mod/mod_negotiation.html, valamint a http://httpd.apache.org/docs/2.0/mod/mod_mime.html címeken olvashatunk.

48

URL-megfeleltetés magasabb szinten a mod_rewrite modullal

Az Apache a mod_rewrite modullal szinte korlátlanul kiterjeszti URL-megfeleltetési lehetőségein-ket, 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ásai-ban. 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 http://httpd.apache.org/docs/2.0/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 / ka-raktert. 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 http://example.com/foo címre érkező minden kérelmet átirányít a http://example.com/foo/ 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.

49

Ha felhasználónk például a fi le.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 fi le.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 kapcsol-hatjuk 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 http://www.example.com/images/icon.PNG, 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 fi gyelmen 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 http://www.misterblue.com/Software/mod_nocase.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évelAddOutputFilterByType TIDY text/html application/xhtml+xmlTidyOption 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 http://tidy.sourceforge.net 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.

50

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:

http://home.snafu.de/tusk/mod_tidy/

Ide köthető az Apache 2 egy másik modulja, a mod_validator is, amelyet az alábbi címen érhetünk el:

http://www.webthing.com/software/mod_validator/

51

5 Virtuális kiszolgálók

Ebben a fejezetben azt mutatjuk be, hogy miként kezelhetünk egyszerre több webhelyet az Apache kiszol-gá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ódsze-reket is bemutatunk, amelyekkel több felhasználó számára nyújthatunk webszolgáltatásokat, így megismer-kedü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 lehe-tő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 192.168.200.4: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érel-mek esetén érvényesülnek. Mindehhez persze az is kell, hogy az Apache kiszolgálóval tudassuk: fi gyelnie 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 meg-adnunk.

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: www.example.com, a www.example.com egy fejlesztői változata, vala-mint a www.example.net. A tárolókon belül látható ServerName utasítások az önhivatkozó URL-ek előállításánál kapnak szerepet.

52

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 fi gyeli, 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 fi gyelt összes port forgalmát követhetjük – ezt tesszük példánkban az example.net esetében.

5.1. példa IP alapú virtuális kiszolgálók beállításai

Listen 8080Listen 80<VirtualHost 192.168.200.2> ServerName www.example.com DocumentRoot /usr/local/apache/sites/example.com</VirtualHost>

<VirtualHost 192.168.200.2:8080> ServerName www.example.com DocumentRoot /usr/local/apache/sites/staging </VirtualHost>

<VirtualHost 192 .168.200.4:*> ServerName www.example.net 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 megfi zetni. 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 fel-haszná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 mu-tatja az 5.2. példa is. Itt két virtuális kiszolgáló szerepel, amelyek megosztoznak a 192.168.200.2 IP címen.

53

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 ka-pott nevet összehasonlítja a ServerName utasítás értékével, no meg esetleg a ServerAlias utasítással megadott másodnevekkel.

5.2. példa Név alapú virtuális kiszolgálók beállításaListen 80NameVirtualHost 192.168.200.2<VirtualHost 192.168.200.2>Serve rName www.examp1e.comServerAlias example.com web.example.comDocumentRoot /usr/local/apache/sites/example.com</VirtualHost>

<VirtualHost 192.168.200.2> ServerName www.example.net 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 www.example.com, az example.com, valamint a web.example.com egyaránt a 192.168.200.2 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 meg-tanulhatjuk, 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ő

54

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 /* http://www.example.com

5.3. 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.comDocumentRoot /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 vir-tuá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 fi gyel minden olyan kérelmet, amely a más virtuális kiszolgálók által le nem fedett címre érkezik:

<VirtualHost _default_:443>SSLEngine onServerName secure.example.com:443DocumentRoot /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 192.168.200.2, a másik pedig a 192.168.200.4 IP címhez tartozik.

55

5.4. példa A név és IP cím alapú virtuális kiszolgálók együttes használataNameVirtualHost 192.168.200.2 <VirtualHost 192.168.200.2> ServerName www.example.com DocumentRoot /usr/local/apache/sites/example.com</VirtualHost>

<VirtualHost 192.168.200.2> ServerName staging.example.com DocumentRoot /usr/local/apache/sites/staging </VirtualHost>

<VirtualHost 192.168.200.4> ServerName www.example.net 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.

5.5. példa A virtuális kiszolgálók beállításainak vizsgálata

# httpd -S VirtualHost confi guration: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.

56

A virtuális kiszolgálók kezelésének további módjai

UseCanonicalName OffVirtualDocumentRoot /usr/local/apache/vhosts/%0VirtualScriptAlias \ /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 keze-lésükre. Különösen igaz ez az internetszolgáltatókra, akiknek több ezer előfi zető 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 út-vonalat 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 parancs-fá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 www.example.com kiszolgálón, az utasítás átirányítja a /usr/local/apache/vhosts/ www.example.com/manual/index.html 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 hasz-ná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 http://alioth.debian.org/projects/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 http://www.outoforder.cc/projects/apache /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.

57

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ő útvo-nal 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ó fi gyelembe 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 AuthConfi g

Az AllowOverride utasítással szabályozhatjuk, hogy milyen beállítási utasítások szerepelhessenek a könyv-tá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ár-indexelé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övet kezők:

• Authconfi g: 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.

58

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 rugal-masságtól, amit ezek a beállítófájlok nyújtanak.

59

6 Biztonság és hozzáférés-szabá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 alkal-mazhatunk, míg az alkalmazások szintjén űrlapokkal, munkamenetekkel és sütikkel valósíthatjuk meg el-ké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álato-sak, 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 meg-hatá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 fi gyelembe vételével.

60

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ó al-goritmus 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 192.168.0 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ó hoz-zá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 BasicAuthName ″Password Protected Area″AuthUserFile /usr/local/apache2/conf/htusersRequire 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ő-

61

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ódsze-rek együttes használata című részt).

Felhasználó-adatbázis létrehozása

htpasswd -c fi le userid

A felhasználó-adatbázis (vagy más néven jelszófájl) elkészítéséhez a htpasswd segédprogramot használhat-juk, 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ű fel-haszná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>

62

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 modul-ban 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.

63

A hozzáférés meghatározott IP címekre korlátozása

<Directory /usr/local/apache2/htdocs/private> Order Allow, Deny Allow from 192.168.0</Directory>

Előfordul, hogy bizonyos tartalmak (például egy cég belső webhelye) elérését érdemes meghatározott IP-cí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 ügy-feleknek tesszük lehetővé, akik a 192.168.0.1 – 192.168.1.254 IP-címtartományba esnek.

A Directory tárolónak átadott paraméternek pontosan meg kell egyeznie azzal a fájlrendszerbeli útvo-nallal, 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 fel-haszná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 192.168.0

A hozzáférés tiltása egyes IP címekről

<Directory /usr/local/apache2/htdocs/private> Order Deny,Allow Deny from 192.168.0.2 192.168.0.5 </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ér-leteit, vagy megakadályozhatjuk a webpókok tevékenykedését, ha gondok adódnak a sávszélesség felhasz-nálásával.

Példánk kódja a 192.168.0.2 és a 192.168.0.5 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 fi gyelembe vételével is korlátozhatjuk a tarta-lom 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áto-zására, illetve lassítására.

64

A hozzáférés-szabályozási módszerek együttes használata

<Location /restricted> Allow from 192.168.200.0/255.255.255.0 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 404http://www.example.com/page_not_found.html

65

Példáink különböző 400-as HTTP-visszatérési kódokat alkalmaztak, amelyek jelzik, hogy a kérelem fel-dolgozá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 http://support.microsoft.com/default.aspx?scid=kb;en-us;Q294807 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 AuthConfi g Limit

Ez lehetővé teszi a felhasználóknak, hogy elkészítsék saját .htaccess beállítófájljaikat, és ezekben elhe-lyezzé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 fi nomabb 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).

66

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 hoz-zá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 el-gé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 ol-vasható legyen. Ezzel ugyanis megakadályozható, hogy a támadó egy fájlt – például egy PHP fájlt egy PHP-ké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 megje-lenjenek a keresőmotorokban, vagy azt vesszük észre, hogy egy elszabadult webpók túl sok erőforrásunkat

67

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ára-inkhoz. Ha ügyfelünk kérelme egy könyvtár útvonalára vonatkozik, a kiszolgáló először ezeket az indexfáj-lokat (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 hasz-nos 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ó mo-dulok, í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átoz-hatjuk 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 fi gyelmen 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} !^http://(www\.)?example\.com/ [NC] RewriteCond %{HTTP_REFERER} ^http:// [NC] RewriteCond %{HTTP_REFERER} !^$ RewriteRule \.{jpg|jpeg|gif|png|bmp)$ - [F]

68

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 kereske-dőt, aki egyszer csak arra lett fi gyelmes, hogy forgalmának (és így a sávszélességért fi zetett 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érel-mek 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ézhe-tünk annak is, hogy a mező http:// 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 AuthConfi g 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átoz-hatjuk a kiszolgáló elérését. Példánkban, amelyet az Apache alapértelmezett beállítófájljából ollóz-tunk 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 tartalmaz-hatnak (lásd a 8. fejezetben). A következő két sorban meghatározzuk, mely adatokat módosíthatják a fel-haszná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).

69

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 uta-sí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 alkal-mazhatjuk 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 fi gyelembe azt is, hogy a közvetett hivatkozások és az Alias utasítások hatással lehetnek a hite-lesí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 ki-vonatos 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ál-hatjuk a http://modules.apache.org, valamint a http://freshmeat.net címeken.

70

A hitelesítést mindig elvégezhetjük az alkalmazások szintjén. Ez többnyire abból áll, hogy egy webes űr-lapon 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 fel-haszná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 fi gyeljü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 http://www.modsecurity.org címen olvashatunk.

Apache 2.2

<Location /combined> AuthType Basic AuthName ″Restricted Access″ AuthBasicProvider fi le 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ál-tozá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_fi le szövegfájlokkal végzi a hitelesítést, míg a mod_auth_dbm adatbázisfáj-lokkal dolgozik. Mindkettő használható a mod_auth_basic, valamint a mod_auth_digest modu-lokkal, 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ódsze-rekről. Ehhez nagy segítséget jelenthetnek az alábbi címek:

71

• Az Apache-bejelentések levelezőlistája: http://httpd.apache.org/lists.html• Biztonsági kérdések az Apache-ban: http://httpd.apache.org/security_report.

html• Apache Week: http://www.apacheweek.com• Apache Security Típs: http://httpd.apache.org/docs-2.O/misc/security-

tips.html

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 fi gyelnü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_defl ate, 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 mo-dulokat, az AddModule segítségével pedig újra bekapcsolhatjuk a valóban használtakat.

72

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 bizton-sá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 rendszer-parancsok 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él-dá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átoz-nunk 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

73

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 doku-mentum 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.

74

75

7 SSL/TLS

Ebben a fejezetben röviden bemutatjuk az SSL alapelveit, és útmutatót adunk az Apache mod_ssl mo-duljá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 fi zetési tranzakciókat irányítják, vagy éppen ér-zé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 https:// előtagot kap-nak. 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 https://www.example.com címet adja meg, a böngésző a https:// 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.

76

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, hi-szen 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*# ./confi g --prefi x=/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 (http://www.openssl.org). 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 for-rá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 azon-ban a birtokosa titokban tartja. A két kulcs kiegészíti egymást: amit az egyikkel titkosítottak, az a másikkal oldható fel.

77

Kulcspár készítése

# ./usr/local/ssl/bin/openssl genrsa -rand fi le1:fl le2:fi le3 \ -out www.example.com.key 1024 625152 semi-random bytes loaded Generating RSA private key, 1024 bit long modulus.....++++++.........................++++++e is 65537 (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 algorit-mussal. 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 fi le1, fi le2 stb. helyére írjunk több nagy, viszonylag véletlen-szerű ö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 fi lel:fi le2:fi le3 \ -out www.example.com.key 1024

A des3 kapcsoló hatására a program titkosítja magát a titkos kulcsunkat, és jelszóval védi, amelyet a pa-rancs 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 www.example.com.key \ -out www.example.com.key.unsecure

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 bizo-nyosodjunk 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?

78

A megoldást egy megbízható harmadik fél, a tanúsító hatóság (Certifi cation 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 tartal-muk 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 www.example.com.key -out www.example.com.csr

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 megtehet-jük a 7.1. példában látható paranccsal, amely a kérelem kiadásához különböző adatokat kér.

7.1. példa Tanúsítványkérelem létrehozása az openssl segítségével

Using confi guration from/usr/local/ssl/openssl/openssl.cnfEnter PEM pass phrase:You are about to be asked to enter information thatwill be incorporatedinto your certifi cate request.What you are about to enter is what is called aDistinguished Name or a DN.There are quite a few fi elds but you can leave someblankFor some fi elds there will be a default value,If you enter ’.’, the fi eld will be left blank.-----Country Name (2 letter code) [AU]:USState or Province Name (full name) [Some-State]:CALocality Name (eg, city) []: San FranciscoOrganization Name (eg, company) [Internet WidgitsPty Ltd]:.Organizational Unit Name (eg, section) []:.Common Name (eg, YOUR name) []:www.example.comEmail Address []:administrator@example.comPlease enter the following ’extra’ attributesto be sent with your certifi cate requestA challenge password []:An optional company name []:

79

Fontos, hogy a Common Name mező tartalma megegyezzen azzal a címmel, amelyet a webhelyünk látoga-tó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 fi gyelmeztető ü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 http://www.pki-page.org/ 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 to-vábbá a közösségi tanúsító hatóságokról - ilyen például a http://www.cacert.org/ 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 www.example.com.csr

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 www.example.com.csr 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 www.example.com.csr -signkey \ www.example.com.key -out www.example.com.cert

Tanúsítványunkat (származzék tőlünk vagy egy tanúsító hatóságtól), amely ez esetben a www.example.com.cert névre hallgat, át kell másolnunk a /usr/local/ssl/openssl/certs/, kulcsunkat pe-dig a /usr/local/ssl/openssl/private/ könyvtárba.

A kulcsfájlt célszerű védeni az alábbi paranccsal:

# chmod 400 www.example.com.key

80

Az SSL-támogatás biztosítása az Apache 1.3-ban$ gunzip < mod_ssl-2.8.23-1.3.33.tar.gz | tar xvf -$ gunzip < apache_1.3.33.tar.gz | tar xvf -$ cd mod_ssl-2.8.23-1.3.33$ ./confi gure --with-apache=../apache_1.3.33$ cd ../apache_1.3.x$ SSL_BASE=/usr/local/ssl/ ./confi gure --enable-module=ssl --prefi x=/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 kiszol-gá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 1.3.33 változatát építjük fel a mod_ssl 2.8.23 változatával, fel-tételezve, hogy a forráskódok ugyanazon a szinten helyezkednek el a könyvtárszerkezetben. A --with-apache 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ít-ványaival és kulcsaival kapcsolatban leírtakat, valamint olvassuk el fejezetünk Az Apache minimális beál-lí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 certifi cate parancsot még a make install előtt.

Az SSL-támogatás biztosítása az Apache 2.x-benAz 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 programcso-mag 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ásaiA 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

81

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 80Listen 443<VirtualHost _default_:443>ServerName www.example.comSSLEngine onSSLCertifi cateFile \/usr/local/ssl/openssl/certs/www.example.com.cert SSLCertifi cateKeyFile \/usr/local/ssl/openssl/certs/www.example.com.key </VirtualHost>

A Listen utasítások egyike arra utasítja az Apache-ot, hogy a HTTPS alapértelmezett portját, a 443-ast fi gyel-je. Az SSLEngine On bekapcsolja az SSL-t az adott kiszolgáló esetén, míg az SSLCertifi cateFile és az SSLCertifi cateKeyFile 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 SSL-utasításokat minden bizonnyal egy <IfDefi ne 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 rendel-kezik 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 fi gyeli. 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 https://www.example.com (vagy a fentiekben említett esetben a https://www.example.com:8443) 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 – en-nek körülményeit szabályozza az SSLPassPhraseDialog. Alapértelmezett értéke a builtin, amely-

82

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:

SSLPassPhraseDialogexec:/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 meg-gyorsíthatja az adott ügyfél kérelmeinek kiszolgálását. Amennyiben SSL-kiszolgálók fürtjét használjuk, ér-demes 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 http://www.distcache.org 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érkiszol-gá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 192.168.200.4:80> ServerName prívate.example.com Redirect / https://private.example.com/</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 fi gyeli 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 http:// helyett https:// előtagot kell használniuk.

83

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 hoz-zá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ázisok-ban – 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 fi gyelmeztető ablak jelenik meg, amely közli, hogy valami nincs rendjén a weboldallal. Az okok leggyakrabban az alábbi három cso-portba 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 rendelke-zik-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élta-núsítványok – jóllehet kezelésük és kiadásuk körülményes – nagyszerű módot adnak céges webhelyek és

84

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ényel-mes 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 beol-vashassá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él-dá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 requireSSLCACertifi cateFile \/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 uta-sítás megköveteli az ügyfelektől az érvényes ügyféltanúsítvány bemutatását. Az SSLCACertifi cateFile 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 http://www.apache-ssl.org címről. Számos gyártó, köztük az IBM, saját SSL-modulokat 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 http://www.stunnel.org 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.

85

Az SSL-képes webhelyek parancssori ellenőrzése

# openssl s_client -connect www.ibm.com:443

A biztonságos webkiszolgálók ellenőrzésére használhatjuk az openssl-t vagy egy másik SSL alapú esz-közt, amilyen például az stunnel (http://www.stunnel.org). A fenti paranccsal az IBM web-helyé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üld-hettü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álto-zókkal azonban kikényszeríthetünk bizonyos viselkedésmódokat – ez különösen akkor hasznos, ha kereske-delmi 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 tar-talmazza 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 megszok-hattuk, 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.

86

Kapcsolódó fejezetek

Amennyiben az Apache-ot fordított helyettes kiszolgálóként használjuk, az ügyfelek tanúsítványai és SSL-kapcsolatokhoz 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.

87

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 kezelhes-sék a hozzájuk tartozó tartalmat. Fejezetünk középpontjában az a mod_dav modul áll, amellyel biztosíthat-juk 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élyez-zü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 rendszer-gazdá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 kifi nomult 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éj-elé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 pa-rancsfá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 webki-szolgáló szerkezetébe. A HTTP protokollt kiegészítve új műveleteket tesz elérhetővé az erőforrások létre-hozá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.

88

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 egye-beket. 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ód-szerek 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áltozatkeze-lő 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 adat-cseréjét. Bővebb tartalmat ad a HTTP eredeti függvényeinek, de újabbakat is elérhetővé tesz – ezeket mutat-juk 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

./confi gure --enable-dav

Az Apache 2.0 programcsomagjában szerepel a mod_dav, jóllehet alapértelmezés szerint kikapcsolt álla-potban. 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 megad-hatunk – így szóba jöhet a Subversion forráskezelő rendszer vagy különféle adatbázisok.

89

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-1.0.3-1.3.6.tar.gzcd mod_dav-1.0.3-1.3.6./confi gure --with-apxs=/usr/local/apache/bin/apxsmakemake 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: //www.webdav.org mod_dav/ és http://www.webdav.org/mod_dav/win32/.

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 rendelke-zik, 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ágos-sá 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 meg-tehetjük az Apache szabványos hozzáférésszabályozó moduljaival. Példánkban bemutatjuk, miként köve-

90

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.

8.1. példa A DAV-elérés védelme

<Location />Dav OnAuthType basicAuthName ″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ál-lí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 biz-tonsá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 Offi ce-ból

A Microsoft Offi ce újabb változatában – amilyen az Offi ce 2000 vagy az Offi ce XP – közvetlenül megnyit-hatjuk é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önnye-dé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 map-pá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 DAV-erő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 www.example.com 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 olvas-hatunk 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.

91

Írjuk be a http://www.example.com/davdocs/ 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 csat-lakozik 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 kat-tintva. 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 http://openwebfolder.mozdev.org címen.

A telepítéshez kattintsunk a Firefoxban a http://openwebfolder.mozdev.org/installa-tion.html 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

./cadaverdav:!> open http://example.com

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 hason-ló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.

./cadaverdav:!> open http://example.comdav:/> lsListing collection ’/’: succeeded.Coll: images 0Dec 7 2004Coll: styles 0Dec 12 2004 Home.html 4816Aug 14 14:19 company.html 5352Dec 7 2004 partners.html 6087Dec 7 2004 solutions.html 3037

92

Dec 7 2004dav:/> edit solutions.htmlLocking ’solutions.html’: succeeded.Downloading ’/solutions.html’ to /tmp/cadaver-editzEzdL9.htmlProgress: [===========================>] 100.0% of6230 bytes succeeded.Running editor: ’vi /tmp/cadaver-editzEzdL9.html...Changes were made.Uploading changes to ’/solutions.html’Progress: [===========================>] 100.0% of6232 bytes succeeded.Unlocking ’solutions.html’: succeeded.dav:/>

A cadaver a http://www.webdav.org/cadaver 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 alkal-mazásával – szerepel köztük a DAV is - hangolhatunk össze a távoli kiszolgáló tartalmával. A program letölthető a http://www.lyra.org/sitecopy címről.

93

Hibás ügyfelek kezelése

BrowserMatch ″Microsoft Data Access InternetPublishing Provider″ redirect-carefullyBrowserMatch ″^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/1.1″ 301

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 – egy-szerű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_fi lesAlias /php-source /usr/local/apache/php_fi les<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.

94

Felhasználói oldalak engedélyezése

UserDir enabledUserDir public_html

Bizonyára találkoztunk már ilyen típusú webcímekkel:

http://www.example.com/~joe

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, fel-sorolhatjuk ő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 http://www.example.com/~user/ 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 http://www.example.com/~user/index.html 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önyv-tá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 http://www.example.com/~user/index.html címről a http://www.example.com/user/index.html címre irányít át:

UserDir http://www.example.com

Egyéb módszerek a felhasználói könyvtárak kezelésére

RewriteEngine OnRewriteCond %{HTTP_HOST} !^(www\.)RewriteCond %{HTTP_HOST} ^([^.]+)\.example\.comRewriteRule ^(.*)$ /home/%1/public_html$1

Ha nem szeretnénk bekapcsolni a mod_dir modult, vagy nem pontosan az általa biztosított lehetőségek-re 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.

95

A DAVLockDB segít a bajban

No such fi le or directory: A lock database was not specifi ed with the DAVLockDB directive. One must be specifi ed 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.

96

97

9 Teljesítmény és méretezhetőség

Az Apache fi nomhangolá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 fi nomhangolá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 ál-talá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, lelkiis-meretes 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 fi nomhangolá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 mo-dult. 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 jelen-tő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 procesz-szorral 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ére-tezhetőségét, így közepes vagy nagy terheléssel járó feladatokhoz érdemes ilyen gépeket használni.

98

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 kapcso-ló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 vo-natkozó 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 le-hetnek. 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 mennyi-ségét is. A beállítás módosítása rendszerfüggő - Linux rendszereken a /proc/sys/fs/fi le-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ál-hatók). Solaris rendszerek esetében az /etc/system fájl rlim_fd_max beállításával érhetünk célt.

99

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 http://httpd.apache.org/docs/misc/descriptors.html weboldalt.

Külső folyamatok szabályozása

RlimitCPURLimitMemRLimitNProc

Az Apache számos utasítással segíti a külső folyamatok által felhasználható erőforrások mennyiségének sza-bá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 RLimitCPU-hoz 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át-szik a kiszolgáló sebességének meghatározásában. Ha valahogyan elérjük, hogy az Apache, illetve az ope-rációs rendszer kevesebb alkalommal olvasson a lemezről vagy írjon rá, jelentősen növelhetjük a teljesít-mé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 gyak-ran 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 ír-tá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 1 1

100

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 szeret-né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áso-kat, ezzel ugyanis áthághatóvá tenne bizonyos biztonsági szabályokat, és a fájlrendszer olyan részeihez biz-tosítana elérést, amelyeket egyébként nem szerettünk volna nyilvánossá tenni. Így például semmi sem aka-dá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 meg-lehető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 visszaad-ni 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_confi g 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

101

a naplóbejegyzéseket, ahelyett, hogy a lemezre írna – ezzel is javítva a teljesítményt. Ezt a modult letölthet-jük a http://www.backhand.org/mod_log_spread címről.

A hálózati és állapotbeállítások fi nomhangolá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ép-nevé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 procesz-szorok számától. Minderről bővebben a http://httpd.apache.org/docs/2.0/misc/perf-tuning.html 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 hiba-keresésnél megfi zethetetlen segítséget jelenthet, de nem szabad elhallgatnunk, hogy emellett lassítja a ki-szolgá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 fi gyelő csatolókhoz meg-hatá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 le-hető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 1.3.22-ben megjelent. A csatolók beállításáról részletesebben tájékozódhatunk az AcceptFilter súgóoldalán.

102

Kapcsolatok életben tartása

KeepAlive OnKeepAliveTimeout 5MaxKeepAliveRequests 500

A HTTP 1.1-ben több kérelmet is kiszolgálhatunk egyetlen kapcsolattal. Ugyanezt a HTTP 1.0-ban is meg-tehetjü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éretezhe-tő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

TimeOutLimitRequestBodyLimitRequestFieldsLimitRequestFieldSizeLimitRequestLineLimitXMLRequestBody

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 kiszol-gá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 egyi-kü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 fi gyeltünk oda, ügy-felünk webhelye népszerű zene- és fi lmletö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 rendelke-zé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.

103

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:

http://www.cohprog.com/mod_bandwidth.html

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:

http://www.topology.org/src/bwshare/README.html

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:

http://www.snert.com/Software/mod_throttle/index.shtml

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:

http://www.robotcop.org/

A mod_require_host olyan ügyfelek (ezek gyakran HS-férgek) elérését korlátozza, amelyek nem ad-já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:

http://www.snert.com/Software/mod_require_host/index.shtml

A mod_choke az IP címenkénti párhuzamos kapcsolatok száma alapján korlátozza a sávszélességet, csök-kentve az ügyfél felé irányuló adatforgalom sebességét. Címe:

http://os.cyberheatinc.com/modules. 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:

http://sourceforge.net/projects/mod_tsunami

Mit kezdjünk a robotokkal?

http://www.robotstxt.org/

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 programok-kal, 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.

104

A jószándékú robotok egy robots.txt nevű fájlt kérelmeznek, amely leírja, hogyan érhető el a webhe-lyü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 http://www.robotstxt.org 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 fi gyelmen 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_httpmod_backhandhttp://www.backhand.org/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 egy-szerű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ók-hoz 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 HTTP-ké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 ér-vé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 di-namikusan 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ök-kenté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 (http://www.imagemagick.org). Mindezek mel-lett 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_defl ate 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

105

é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 se-gítségünkre siethetnek. Itt van mindjárt a FastCGI és a mod_perl, amelyekkel felgyorsíthatjuk CGI pa-rancsfá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: http://www.lighttpd.net/• thttpd: http://www.acme.com/software/thttpd/• Boa: http://www.boa.org

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.

106

107

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, amely-nek 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áb-bí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.

108

A mod_proxy támogatásának bekapcsolása

Apache 1.3

--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áltozata-iban 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,allowDeny from allAllow from 10.0.0.0/255.255.255.0</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, va-lamint 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 enge-dé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.

109

Az URL-tér egységesítése fordított helyettes alkalmazásával

ProxyPass /crm http://crm.example.com/ProxyPass /bugzillahttp://backend.example.com/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 http://www.example.com/crm/login/index.html címre, azonnal kérelmezi a http://crm.example.com/login/index.html címet a hát-té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 http://crm.example.com/</Location>

Végezetül meg kell említenünk, hogy a ProxyPass utasítást sokszor érdemes a ProxyPassReverse-zel együtt alkalmaznunk, amint azt a következőkben láthatjuk.

A háttérkiszolgálók elrejtése

ProxyPass /crm http://crm.example.com ProxyPassReverse /crm http://crm.example.com 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 www.example.com) szerepeljen bennük. A ProxyPassReverseCookiePath és a ProxyPassReverseCookieDomain működése hason-ló, 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 kiszol-gáló hibaoldalait jeleníthetjük meg a háttérkiszolgálók megfelelő oldalai helyett. Ezzel még jobban elrejt-hetjü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.

110

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 http://apache.webthing.com/mod_proxy_html/ címen juthatunk hozzá.

Fordított helyettesek alkalmazásának tiltása egyes URL-eken

ProxyPass /images/ !ProxyPass / http://crm.example.com

Ha egy ProxyPass utasítás távoli webhelyet megadó paramétere helyett felkiáltójelet írunk, azzal meg-tilthatjuk 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, ame-lyeket helyben szolgál ki.

A teljesítmény növelése

ProxyIOBufferSize 1024000

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 se-gí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 fi gyeljé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.

111

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 telje-sí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 elhe-lyezzü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 átad-hatunk (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 meg-adottal 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.

112

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ör-nyezeti 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 ada-tait 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ókCacheRoot /usr/local/apache/cache CacheSize 500000 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 rendelke-zésére. A gyorsítótár viselkedésének fi nomhangolá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-benCacheEnable 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ájlrend-szert 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 meg-adott háttértárolóban, amelyekben szerepel ez az URL-előtag. A CacheDisable segítségével megtilthat-juk 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_fi le_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.gifMMapFile /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ó.

113

Terheléselosztás

<Location /balancer-manager>SetHandler balancer-managerOrder deny,allowDeny from allAllow from localhost</Location><Proxy balancer://balancer/stickysession=PHPSESSIONID>BalancerMember http://wwwl.example.com/BalancerMember http://www2.example.com/BalancerMember http://www3.example.com/</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 pro-tokollok 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ámo-gatá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://127.0.0.1:8009/myappProxyPassReverse /myapp ajp://127.0.0.1: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 alkal-mazhatjuk, í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 http:// előtagokat az ajp:// karakterlánccal a helyettes kiszolgáló beállításaiban (terheléselosztás esetén is).

114

Egyéb helyettesek

Squid http://www.squid-cache.org/Pound http://www.apsis.ch/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ük-ség van az ügyfelek megfelelő beállítására - léteznek azonban „láthatatlan” (transparent) helyettesek, ame-lyek enyhítenek ezen a követelményen. Működésük abban áll, hogy a hálózati rétegben elfogják a HTTP-ké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 sze-retné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 ki-szű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 helyet-tes 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:

http://www.tldp.org/HOWTO/TransparentProxy.html

115

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 érde-ké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ál-tatott 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éretezhe-tő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ó prog-ramcsomagjá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üg-getlen kiszolgálására. Mindez jelentősen javítja a rendszer stabilitását, hiszen ha valamelyik gyermekfo-lyamat 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áb-bi 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.

116

Az Apache 1.3 eleve folyamat alapú, míg az Apache 2 rendelkezik egy korai elágazású (prefork) MPM-mel, 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 5MinSpareServers 5MaxSpareServers 10MaxClients 150MaxRequestsPerChild 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, ame-lyek 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, ugyan-akkor 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.

117

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 2MaxClients 150MinSpareThreads 25MaxSpareThreads 75ThreadsPerChild 25MaxRequestsPerChild 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 adhat-juk 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 folya-matokat. 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ár-huzamosan 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 legna-gyobb 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 fi gyelő 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 http://www.metux.de/mpm címről).

118

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 fe-lelnek 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 10.0.0.1:21<VirtualHost 10.0.0.1:21>FTP OnDocumentRoot /usr/local/apache/ftpdocsErrorLog /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.

119

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 http://incubator.apache.org/projects/mod_ftp.html címről.

Az Apache mint P0P3-kiszolgáló

Listen 110<VirtualHost *:110>POP3Protocol onPOP3MailDrops /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 Offi ce 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 Postfi x. 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 http://svn.apache.org/viewcvs.cgi/httpd/mod_pop3/ címről.

Dinamikus tartalomtömörítés

#Apache 2 mod_defl ateAddOutputFilterByType DEFLATE text/html text/plain text/xmlSetEnvIfNoCase Reguest_URI \.(?:gif|jpe?g|png)$ no-gzip dont-varyBrowserMatch ^Mozilla/4 gzip-only-text/html#Apache 1.3 mod_gzipmod_gzip_static_suffi x .gzAddEncoding gzip .gz mod_gzip_item_include fi le \.html$

Az Apache 2 mod_defl ate 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 bi-zonyulhat 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.

120

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él-dában is látható módon megakadályozza, hogy a mod_defl ate 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:

http://sourceforge.net/projects/mod-gzip/

G

uy Monta

g

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