Előszó

Tisztelt Olvasó! Elöljáróban csak annyit szeretnék megjegyezni, hogy az itt olvasott dokumentum a diplomamunkám, illetve a továbbfejlesztett változata. A jövőben folytatom az Apache webszerver bemutatását, ez azt jelenti, hogy idővel megváltozik a kinezete a tartalomjegyzéke stb stb, addig is kellemes olvasgatást kivánok. Erre a dokumentumra teljes mértékben a GNU General Public License vonatkozik, tehát ha ezt a dokumentumot felhasználod későbbiek során, akkor kérlek az Irodalomjegyzékben tüntesd fel.

Barka Ferenc

Bevezetés

A kezdetben ARPANET-nek nevezett kommunikációs rendszer fejlesztésének az 1960-as évek elején az USA-ban kezdtek neki a Védelmi Minisztérium támogatásával, az ARPA kutatási program keretében. A program célja egy olyan kommunikációs rendszer kialakítása volt, amely akkor is képes tovább mûködni, amikor egyes részei valamilyen oknál fogva kiesnek. Az adatok átvitelére csomagkapcsolt átvitelt használtak. Ezt a hálózatot később más kutatók, állami szervezetek, oktatási intézmények részére is elérhetővé tették és a neve is megváltozott: Internet lett. Ez a szó az első időkben csak levelezést, telnet-et jelentett, később jött az ftp, news, a web és a gopher, wais, archie. Ekkor még az Internet szöveges felület volt, kép és hang nélkül. Aztán a 1990-es évek elején megjelentek a multimédiát (kép, hang) támogató protokollok, leírónyelvek. Majd a világot egy szempillantás alatt meghódította a web. A weben képek, hangok, videók, animációk, 3dimenziós világok jelentek meg. Ez a hirtelen robbanásszerû fejlődés magával hozta a felhasználók számának eddig még soha-nem-látott növekedését. Alig pár év leforgása alatt 2 milliárd ember használja már az Internetet. A felhasználók igényei közben fokozatosan nőttek, és ismét technikai fejlődés következett be (élő adások, Javascript, Java). A felhasználók száma a mai napig folyamatosan növekszik, míg a jelenlegi technika az elérhető határokat súrolja. A technika fejlődésének az szab határt, hogy az Internet protokoll számára kitalált számozási rendszer elavult, a 32 bites címtartomány a jelenlegi fejlődés mellet 2001-2002 környékén elfogy. Ezt a problémát az Internet2 illetve az Internet Protokol új verziója az IPv6 látszik megoldani. A web, mint már említettem, hatalmasat fejlődött, ám azt kevesen tudják, hogy ezek az oldalak nem maguktól kerülnek a képernyőre, hanem a webszerverek segítségével. Ez a szakdolgozat éppen ezért a webszerverek fejlődését kívánja bemutatni, azt a folyamatot, hogyan jutott el a világ a szöveges megjelenéstől a multimédiás megjelenésig. A bemutatandó webszerver az Apache webszerver lesz Linux operációs rendszeren (Debian disztribúció) és az Apache verziószáma 1.3.6. a php3 verziószáma 3.0.11 valamint a MySQL szerver verziója 3.22.

A jelenlegi rendszer kritikai bemutatása

A webszerverek az Internet kezdetekor még nem álltak rendelkezésre, ezért a legtöbb információ e-mailen cserélt gazdát. Amint megjelent a web, azonnal megjelentek az interneten az újságok is. Az Internetet használók így egy megadott oldal lehívása után el tudták olvasni az aznapi híreket, és minden olyan informácíót, ami érdekelte őket. m a sok szöveg nem volt elegendő, a felhasználók képeket is akartak látni. Az igény felmerülését tett követte, és megjelent a HTML leíró nyelv újabb változata, ami már a képek megjelenését is támogatta, megjelentek az új böngészők és az új webszerverek is. A későbbiekben további igények merültek fel, amit a HTML nyelv újabb verziója oldott meg ismét újabb böngészők jelentek meg. Eközben a webszerverek is fejlődtek (szerveroldali programok futtatása, számlálók, adatbázis kapcsolatok).

Webszerverek száma (1995. augusztus-1999. július):

A vezető webszerverek száma, és aránya:

webszerver	1999 Július	%
Apache	3713470	56.28
Microsoft-IIS	1452333	22.01
Netscape-Enterprise	386927	5.86
CnG	147211	2.23
Rapidsite	113025	1.71
WebSitePro	87293	1.32
Stronghold	79580	1.21
Zeus	79206	1.20
Thttpd	70414	1.07
WebSTAR	79580	1.21

A webszerverek külső kapcsolatai

Az elsődleges amit a webszervereknek tudniuk kell az a kliensekkel való kommunikáció, és adatátvitel. Ezeknek a folyamatoknak meghatározott formái, szabályai vannak. Néhány olyan szabványt sorolok fel amit egy mai webszervernek tudnia kell:

– Természetesen a HTTP protokoll (a későbbiekben lesz még szó ezekről a protokollokról).

A virtuális szerverek kezelése (több önálló domainnévvel rendelkező web egy gépen), az ebből adódó párhuzamos kiszolgálás.
Szerveroldali programok futtatása, adatbázis kapcsolat (akár közvetlen, akár közvetett módon).
Gyors, egyszerû konfigurálhatóság, nagy terhelhetőség.
A titkosított adatátvitel HTTPS.

A webszerverek folyamatai, részfolyamatai

Az 1990-es évben jelent meg a HTTP/0.9-es verziója. Ettől az időponttól kezdve van HTTP, illetve web. Mégsem ez az alap protokoll, amit egy webszervernek, illetve egy modern böngészőnek tudnia kell, hanem az 1.0 verzió. A HTTP (Hypertext Transfer Protocol) webszerverek alap protokollja. Ez a TCP/IP és a OSI réteg-megfeleltetési rendszerben az alkalmazási rétegben lévő protokollok csoportjába tartozik, akárcsak a telnet, SMTP, FTP. Ezen a protokollon keresztül kéri le a böngésző a szervertől a látni kívánt oldalt, illetve ezen a protokollon keresztül válaszol a webszerver. A HTTP protokollt gyors és hatékony megjelenítésre tervezték. Ez a protokoll állapotmentes azaz egymástól függetlenül az ügyfél több lekérdezést is indíthat. Ez az állapotmentesség biztosítja azt is, hogy a protokoll mindenki számára egyformán elérhető és gyors legyen. Az 1.0-s verzió az úgymond alapverzió, mert csak a legalapvetőbb dolgokra képes.

A HTTP kapcsolat négy lépésben írható le:

A kapcsolat felépítése és megnyitása; az ügyfél meghívja a kiszolgálót az adott címen és porton (80 port általában).
A kérés elküldése; az ügyfél elküldi az üzenetet a kiszolgálónak, amelyben valamilyen kiszolgálást kér. A kérés HTTP-fejlécből, a kiszolgáló számára küldött adatokból áll (ha kell ilyen). A fejléc tartalmazza azt az információt, ami a szerver számára leírja,hogy milyen típusú a lekérés, valamint megadja, hogy az ügyfélnek milyen lehetőségei vannak.
A kiszolgáló válasza; ez tartalmazza a lekérés sikeres vagy sikertelen voltát, a küldött adatok típusát és végül magukat az adatokat.
A kiszolgáló zárja, bontja a kapcsolatot;mindezaz adatok átküldése után történik meg.

Amíg az adatok a HTTP/0.9 verzióban raw dataként (ez azt jelenti, hogy binarys fájlként kezelte a dokumentumokat) érkeztek meg a klienshez, addig az újabb verziókban a szabvánnyá vált MIME (Multipurpose Internet Mail Extensions) -t használják arra ,hogy a szerver tudatja, milyen típusú fájlt küld át.A raw dataként való adatfogadásnak sok hátránya volt, például az, hogy nem tudta a kliens milyen hosszú is lesz a fájl és azt sem, hogy milyen típusú.

A HTTP 1.0 verzió az alábbi módon küldi el ezeket az információkat:

HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Length: 26012
Content-Type: image/gif

Természetesen az adatokat továbbra is raw dataként szolgáltatja ki a szerver, úgy ahogyan azt tárolja. Nem próbálja meg értelmezni, és úgy átküldeni. Ennek az az előnye, hogy minden kliens ugyanazt az adatot kapja meg, bármilyen webszerver is szolgálja ki ugyanazt a weboldalt, grafikát. A hátránya az, hogy aki elkészíti a weboldalt, annak tudnia kell, milyen kódlapra írja meg. Ez azért fontos, mert a különböző kódlapok, különböző módon értelmezik ugyanazt a karaktert. Természetesen azt, hogy milyen karakterkészlettel készült el az oldal, azt a HTML leíró nyelv segítségével az oldal tartalmazza, így a kliens tudja, milyen kódkészletet használjon.

Az 1.1 -es verzió az 1.0-s továbbfejlesztett változata. Ez a változat például már képes arra, hogy egyszerre több fájlt is átküldjön, ezzel csökkentve a kliens várakozási idejét. A PROXY szerverek számára megmondja, mikor volt utoljára frissítve az adott oldal, így kevesebb adatforgalmat kell bonyolítani. Ennek az az oka, hogy ha már egyszer le lett töltve az oldal és az nem változott, akkor azt cache-ből gyorsabb beolvasni, mint újra letölteni a á-t. Megadja. milyen kódkészlettel van kódolva a lekért állomány, így azt a böngésző már helyesen tudja megjeleníteni. Ezt a Content-Language változó adja meg a webszerver a lekért oldal fejlécében.

Virtuális szerver:

A virtuális szerverek azt jelentik, hogy egy adott gépen több, egymástól független könyvtárstruktúrában lévő oldalt, egymástól független domainként kezelnek. gy lehetséges az, hogy egyetlen gépen akár több tucat webhely található.

Szerveroldali programok:

A szerveroldali programok futtatása főleg akkor fontos, ha olyan adatokat kérünk be, amelyeket a webszerveren később is meg akarunk jeleníteni.

( Például egy vendégkönyv, egy látogatottsági számláló.)

Ezenkívül a programokkal mást is végre lehet hajtatni

(pl: adatbázishoz csatlakozást, adatbázis lekérést).

CGI:

A CGI- specifikációk (Common Gateway Interface) írják le, hogy a HTTP kiszolgálók hogyan kommunikálnak a küldött információkat ténylegesen feldolgozó programokkal.

HTTPS:

A HTTPS egy olyan titkosított protokoll, amely a nyiltkulcsú titkosítást használja, ezt a protokollt főleg a bankok és más pénzügyeket intéző weboldalak, programok használják.

( A későbbiekben erre is bővebben kitérek még.)

Értékelés, problémalista

Az alábbi ábra azt mutatja, hogy egyes webszerverek aránya csökken. Ez a jelenség főleg abból adódik, hogy bizonyos operációs rendszerek jobban elterjedtek, illetve más operációs rendszerek a háttérbe szorultak. Vannak olyan webszerverek, amelyek több operációs rendszerre is át vannak ültetve. A egyes webszerverek eltûnésének másik oka a zsákutcába jutás. Ebben az esetben a webszerver nem fejlődik tovább, mert a fejlesztők szétszéledtek, nem tudják kielégíteni a felhasználók igényeit, vagy egyszerûen késve adják ki az újabb verziót, amikor is a felhasználók már átpártolnak egy másik webszerverhez.

webszerverek aránya %-ban 1995. augusztus 1999. július

Ebből a szempontból a legjobb az Apache, amely sokféle operációs rendszerre készül.

A felmerülő igényeket hamar kielégíti, a fejlesztők hamar kihozzák az újabb verziót, és ami nagyon lényeges: az egyes operációs rendszereknek alaprészei, igy az operációs rendszer árában benne van a webszerver is. (Linux esetén ingyenes az Apache webszerver.)

Megoldási javaslatok

A jelenlegi helyzet a következőképpen foglalható össze: az operációs rendszerek háborújába erősen beleszól az internet, illetve a webszerverek. Az az operációs rendszer, amely nem támogatja az internet elérést, az a szakértők szerint halálra van ítélve. A webszerverek Windows 95, 98 operációs rendszereken igen elvétve találhatók, de a Windows NT, a Windows 2000 operációs rendszerek egyes változatain (a szerver változat esetén) már alapból feltelepíthető. Unix rendszereken is telepítés esetén alapértelmezett a webszerver telepítése (természetesen nem minden operációs rendszerhez jár webszerver, de ingyen letölthető és használható Apache webszerver felinstallálható). A feltelepített webszervereket könnyebb-nehezebb módon a felhasználónak, rendszeradminisztrátornak kell bekonfigurálnia. A Microsoft operációs rendszer esetén minden grafikusfelületen történik, míg unix rendszerek esetén legtöbbször szöveges módon. A webszerverek jelentős része gyorsan fejlődik illetve specializálódik. Adatbázis kapcsolatra specializált az Oracle webszervere, amely közvetlen módon képes az Oracle adatbázishoz csatlakozni. Mások a keresésre specializálódtak, amíg megint mások a terhelhetőség, adatbiztonság felé. A webszerverek piaca lassan megtelik, úgy tûnik azonban, hogy a webszerverek versenyében az Apache utolérhetetlen előnyre tett szert. Mitől is olyan népszerû ez a szerver? A válasz igen egyszerû. Az Apache ingyenes, a folyamatos fejlesztések mindenkor azt a célt szolgálják, hogy gyors, megbízható webszerver legyen a felhasználó kezében, ezért ügyelnek a biztonságra, a skálázhatóságra, a gyors, egyszerû telepíthetőségre, hogy a lehető leghamarabb implementálják hozzá az új technológiákat. (Jó beállítással elérhető az, hogy egy Intel Pentium 166Mhz processzoros gép 64Mbyte RAM-al napi 20000-30000 lekérést kiszolgáljon.)

A javasolt rendszer bemutatása

Az Apache webszerver bemutatása:

Az Apache webszerver legfőbb célkitûzése az, hogy a lehető legegyszerûbb megoldástól a különböző speciális igényekig mindent ki lehessen elégíteni. Természetesen ennek is megvannak a maga korlátai amelyek azonban mindenféle kiegészítővel kitolhatóak. Az alapbeállítás arra alkalmas, hogy az átlagos (egyéni és kis) felhasználók igényeit kielégítse. A nagyvállalatok, igen nézett oldalak, szerverek természetesen már változtatott konfigurációt használnak.

Alapbeállítás:

Az Apache webszerver feltelepítése után a következő httpd.conf alapbeállítást kapjuk, ennek magyarázata:

ServerType standalone

A ServerType értéke standalone vagy inetd lehet. A standalone azt jelenti, hogy a kiszolgálást teljes egészében az Apache végzi. Az inetd pedig azt, hogy egy külső program hívja meg az apache-ot, hogy a bejövő kérésre válaszoljon. Az inetd természetesen csak unix rendszereken mûködik.

Port 80

Az alapértelmezett TCP port, amin a webszerver van, ez ebben az esetben a 80 port. Ez nemzetközileg elfogadott szabvány. Természetesen ettől el lehet térni, de a böngésző programok itt keresik.. Még ismert és hellyel-közzel szabványnak elfogadott port a 8080.

Ezenkívül használják még adminisztrációs célokra a 88-as portot, a 8888, illetve a 8887-es portot.

HostnameLookups off

Ezzel azt lehet megadni, hogy a kliens domain nevét leellenőrizze a szerver. Ennek értéke lehet on, off vagy double. A double azt jelenti, hogy az IP cím alapján megkeresi a kliens nevét, majd a kapott nevet visszaellenőrzi IP-re. Ha a kapott IP egyezik a kliens által először megadottéval, akkor válaszol a kérésre. Ez a névellenőrzés természetesen lassítja a válaszadási időt, de biztonsági szempontból nagyon hasznos, gond csak akkor adódik, amikor olyan gépről jön a lekérés, melynek nincs a névszerver szerint host neve, csak IP címe.

User www-data
Group www-data

Ez a beállítás adja meg azt, hogy milyen felhasználóként fusson a webszerver. Ez biztonsági szempontból nagyon fontos. Régebben root felhasználóként, azaz a rendszer szuperfelhasználójaként futott a webszerver. Ebben az esetben, ha biztonsági rés támadt, és a kliens ezt kihasználva behatolt a rendszerbe, akkor ezzel a szuperfelhasználó jogaival léphetett be és bármit megtehetett a rendszeren. Az alapbeállítás ebben az esetben a www-data felhasználóként futtatja a webszervert, amely felhasználó nem férhet hozzá minden fájlhoz, könyvtárhoz, csak amihez joga van.

ServerAdmin you@your.address

Itt a webszerver adminisztrátorának e-mail címét kell megadni. Amennyiben valamilyen hiba történik, a szerver értesíti őt, illetve a hibaoldalakon ezt az e-mail címet tünteti fel, hogy a felhasználók jelezhessék a hibát.

ServerRoot /etc/apache

A szerver beállításait tartalmazó könyvtár helye.

 BindAddress *

A szerver az erről a címről jövő klienseket szolgálja ki. Ebben az esetben bármilyen címről jövőt kiszolgál.

LoadModule php3 /usr/lib/apache/1.3/php3.so

A LoadModule -lal a szerverhez készített modulokat töltethetjük be. Ezeket futás közben dinamikusan tölti be az Apache és csak akkor, amikor arra szükség van. A CGI, PHP3 futtatáshoz szükséges modulokat itt fel kell tüntetni, különben nem tudja a szerver futtatni azokat.

 ExtendedStatus on

Ezt a mod_status.so modul használatakor értelmezi a szerver. Ennek a segítségével lehetséges a webszerver könyvtárai hozzáféréseit beállítani az acces.conf fájlban. Például így:

<Location /server-status>
SetHandler server-status
order deny,allow
deny from all
allow from .foo.com
</Location>

Ebben a részben a deny -vel tiltjuk a bejövő hívásokat a szerver /server-status könyvtárára és csak a .foo.com domain nevet tartalmazó klienseknek engedjük, hogy lássák ezt a könyvtárat. Ez nagyon hasznos tud lenni abban az esetben, amikor nem akarjuk, hogy az arra nem jogosultak hozzáférjenek könyvtárakhoz.

ErrorLog /var/log/apache/error.log

A webszerver hibalista melyik fájlba kerüljön.

LogLevel warn

Itt lehet meghatározni, hogy mi kerüljön bele az ErrorLog-al meghatározott fájlba. A következő direktívák lehetnek ezek:

szint **Leírás** Emerg Vészleírás, a rendszer használhatatlan Alert Figyelmeztetés Crit Kritikus állapot Error Hibás állapot Warn Figyelmeztető állapot Notice Normális, de jelző állapot Info Tájékoztató jellegû Debug Hibakereső szintûHa nincs beállítva, akkor alapértelmezettként a crit-et használja. A leginformatívabb jellegû a debug sz int, ez akkor fontos, ha a szerver mûködésében hibát keres a szerver karbantartója.

LogFormat "%h %l %u %t \"%r\" %>s %b" common

A keletkező log formátumának leírása, a % utáni betûk meghatározott dolgokat jelentenek, például:

%h  a kliens host-ja
%u  felhasználó
%b  átküldött byte

A LogFormat után áll a hivatkozás neve. Ez természetes bármi lehet, de az általánosan használtak a common, azaz általános és a custom, azaz egyedileg választott.

CustomLog /var/log/apache/access.log common

Ezzel a direktívával lehet beállítani azt, hogy a lekérdezések logjai hová kerüljenek, illetve milyen formátumban. A formátumnak a LogFormat-ban megadott nevek közül kell lenni, különben hibát ad vissza a szerver.

PidFile /var/run/apache.pid

Ezzel azt lehet meghatározni, hogy a szerver által használt processzek azonosítóját hol tárolja a szerve r. Ez leállításnál fontos, mert ennek segítségével akár egyesével is leállíthatóak a szerverek.

LockFile /var/run/apache.lock

Itt az úgynevezett lock fájlt lehet beállítani. Ez amiatt fontos, mert a szervernek tudnia kell, hogy már elindult egy példányban és nem kell még egyszer elindítani, illetve innen tudja meg azt is, ha nincs elindítva.

 ServerName new.host.name

Itt lehet megadni a webszerver nevét. Ez azt is jelenti, hogy az erre a névre érkező kéréseket a szerver kisz olgálja. Virtuális szerverek használatakor az alapértelmezett szerver neve kerül ide.

UseCanonicalName on

Itt azt lehet beállitani, hogy a szerver használja a teljes nevet és portot, vagy sem. Ez CGI hívásokkor lehet fontos, hiszen ha a szerver kap egy hívást a http://www/splas -ra, akkor ha be van kapcsolva ez a direktíva, akkor a ServerName-ben meghatározott névre transzformálja át a lekérést. Amennyiben ez a direktíva ki van kapcsolva, úgy nem történik meg a transzformáció. Amennyiben a CGI-ben meg van határozva, melyik szervernévvel hajlandó együttmûködni, akkor ezt érdemes bekapcsolni, hiszen a www szervernév nem egyenlő a www.sajatdomain.com-al.

Timeout 300

A kliens és szerver kapcsolatának kifutási ideje. Ezzel lehet beállítani azt, hogy a kliens és a szerver között mennyi az a maximum idő, amíg a lekérésre kiküldött válasznak meg kell érkeznie. Ezt az értéket másodpercben kell megadni, az alapértelmezett az 5 perc (300 másodperc). A DoS (Denied of Services) támadások pont ezt az értéket használják ki, mert a lehető legtöbb kapcsolatot építik ki a szerverrel és adatot nem küldenek ki rá, hanem megvárják a Timeout végét, és újra felépítik a kapcsolatot. Ezek a támadások nem állítják le a szervert, csak a teljes kapacitását lefoglalják, ezalatt nem tud a szerver más klienseket kiszolgálni, hiszen minden kapcsolata a támadó felé irányul. Ez ellen van megoldás: lásd lejebb.

KeepAlive On
MaxKeepAliveRequests 100

Maximum kliensenkénti kapcsolatszám.

KeepAliveTimeout 15

Kapcsolantonkénti kifutási idő.

MinSpareServers 5

Legkevesebb várakozó szerverszám.

MaxSpareServers 10

Legtöbb várakozó szerverszám.

StartServers 5

Induláskor ennyi szerver indul el.

MaxClients 150

Szerverenkénti kliensszám.

MaxRequestsPerChild 30

Mennyi kapcsolatonként induljon újra a szerver.

Listen 80

Itt lehet beállítani, hogy melyik IP-n, milyen port-on válaszoljon a szerver a kliensnek. Például:

Listen 192.168.0.1:80
Listen 192.168.100.2:8000

Ebben az esetben a 192.168.0.1 en a 80-as porton válaszol, a 192.168.100.2-es IP-n a 8000 porton. Amennyiben a következő van beállítva:

Listen 80
Listen 8000

akkor a 80-as és a 8000-es porton egyaránt válaszol.

Könyvtárak hozzáférése acces.conf. Az alapértelmezett amit az apache tartalmaz:

<Directory /var/www>
Options Indexes FollowSymLinks

Fenti beállítás azt jelenti, hogy amennyiben nincsen kezdő oldal, úgy kilistázza a könyvtárat. A könyvtárban lévő szimbolikus linkeket feloldja, tehát ahová a link mutat, azt olvassa ki.

Az Options értékei lehetnek:

Indexes Ha nincsen a könyvtárban kezdő oldal, akkor automatikusan legenerálja a könyvtárlistát Includes A szerveroldali beillesztés engedélyezése IncludesNOEXEC Ugyanaz mint az Includes, csak nem engedélyezi az #exec és az #include parancsokat a CGI-ben FollowSymlinks A szimbolikus linkeket követi, az így létrehozott fájlokat,könyvtárakat megjelenití SymLinksIfOwnerMatch Csak akkor követi a symlinket (szimbolikus linket), ha annak a jogosultságai megfelelőek. Amennyiben van akönyvtárra, úgy ez a parancs érvényét veszti ExecCgi CGI futtatást tesz lehetővé MultiViews MultiViews funkció All Engedélyezi az összes direktívátMultiViews könyvtárankénti opció, amely mind a <Directory>, <Location> vagy <Files> szekcióban található, melyek access.conf-ban vannak. Options All esetén a MultiViews nincs engedélyezve, azt külön kell engedélyeztetni. Például, ha a szerver kap egy lekérést a /some/dir/foo- ra és a /some/dir könyvtáron van MultiViews opció és nincsen /some/dir/foo könyvtár, akkor a MultiViews a beállításnak megfelelő foo.* fájlokból választ. Amennyiben az angol nyelv van beállítva, úgy alapértelmezettként a foo.en fájlt küldi ki, de ha a kliens más nyelven akarja olvasi az adott fájlt, és ez a nyelv valóban adott, és a szerveren is megtalálható, úgy ezt a fájlt kapja meg a kliens.

Az Options- ba be lehet állítani azt, hogy egy alkönyvtár örökli a szülő könyvtár beállításait, de ezeken lehet módosítani; mind hozzáadni, mind elvenni a +/-szal, például:

<Directory /web/docs>
Options Indexes FollowSymLinks
</Directory>
<Directory /web/docs/spec>
Options +Includes -Indexes
</Directory>

A szülő könyvtárhoz képest szeretnénk megváltoztatni a spec könyvtár tulajdonságait, az automatikus indexgenerálás helyett szerveroldali beillesztés, viszont megmarad a symlink követés.


Tiltjuk a könyvtárban található .htaccess fájl használatát, amivel esetleg felülbírálhatnánk a következőekben beállítottakat.

```order allow,deny

Felsoroljuk az engedélyezett, valamint tiltott domaineket, hostokat, amelyek ezt a könyvárat nem érhetik el.

```allow from all

Engedélyezi, hogy honnan lehet megtekinteni az adott könyvtárat. Most mindenhonnan megnézhető. Tiltás nincsen. Amennyiben nincsen felsorolva a könyvtárra megadott hozzáférés, az irányadó elv a következő:ha nincsen tiltás, engedélyezés a könyvtárra, úgy mindenhonnan látható. Amennyiben fel van sorolva honnan engedélyezett a könyvtár láthatósága és nincsen a tiltás leírva, úgy minden tiltva van, kivéve, ami engedélyezve. Amennyiben fel van sorolva a tiltás, úgy minden más engedélyezve van, ami nincs tiltva.Tehát:

```order allow,deny
```allow from host.domain.tld

Ebben az esetben ez ugyanazt jelenti, mintha ez lett volna leírva:

```order allow,deny
```deny from all
```allow from host.domain.tld

A fenti példa mindenhonnan tilt, kivéve a host.domain.tld nevû gépet. Ennek ellenkezője:

```order allow,deny
```deny from host.domain.tld
```allow from all

Ez a beállítás mindenkinek megengedi a láthatást, kivéve a host.domain.tld gépről jövőknek. Miért is nagyon hasznos ez az engedélyezés, illetve tiltás? Mert így korlátozni tudjuk azoknak a számát, akik hozzáférhetnek bizonyos kényes adatokhoz. A gép/domain akár egy teljes tld tiltása pedig sok esetben azért következik be, mert a domain tulajdonosa kéri a szerver karbantartóját, hogy a domainját tiltsa, mert a felhasználói nem a megfelelő időben (pl: munkaidő, iskolaidő) férnek hozzá a kívánt adatokhoz, és ezzel valamilyen módon ő károsul. Esetleg az adott domainről/host-ról betörési kísérletet próbáltak meg, és a támadási felület a webszerver volt. A telnet Magyarország Kft. 1998. évben egy unixos webszervert tett ki félévre, hogy a találékony webszerver feltörők prédája legyen. A fél év alatt közel félmillió komolyabb támadás érte a szervert, de senkinek sem sikerült a webszervert leállítani, hibás mûködésre bírni. A feltételezések szerint a használt webszerver alapja egy apache webszerver volt, amelyet betörésvédelemmel egészítették ki..

```</Directory>

A könyvtárra vonatozó beállítások lezárása.

```<Directory /usr/lib/cgi-bin>
```AllowOverride None
```Options ExecCGI FollowSymLinks

Itt a futtatási bittel rendelkező fájlokat CGI-ként futattja, és követi a szimbolikus linkeket.

```</Directory>

A könyvtárra vonatozó beállítások lezárása.

```<Location /cgi-bin/phf*>
```deny from all
```ErrorDocument 403 http://phf.apache.org/phf_abuse_log.cgi

Tiltva van a könyvtár olvasása, valamint a hibaoldalt a megadott helyről olvassa be.

A Directory direktívában látott order allow,deny ebben a direktívában is használható, ám míg a Directory-nál a szerveren megtalálható könyvtár elérésének tulajdonságait állítottuk be, itt a hálozaton látható elérési útvonalat állíthatjuk be. A virtuális szerverek esetén máris láthatóvá válik a különbség, ennek példája a virtuális szerverek beállításánál található meg. 

```</Location>

A webszerver elérési útvonalára vonatozó beállítások lezárása.

```<DirectoryMatch ^/home/.*/public_html>
```Options SymLinksIfOwnerMatch Indexes
```AllowOverride None
```</DirectoryMatch>

Az srm.conf beállítása, az alapértelmezett beállítás:

```DocumentRoot /var/www

A webszerver alapértelmezett könyvtára.

```UserDir /home/*/public_html

A felhasználók által létrehozott oldalakat innen veszi, tehát a szervernév/~usernév könyvtárat innen keresi.

```DirectoryIndex index.html

Az alapértelmezett index fájlokat itt lehet felsorolni.

```FancyIndexing on
```AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip

Ikont rendel a tömörített állományokhoz (listázás esetén ezek az ikonok jelennek meg), ebben az esetben a tömörítési mód szerint határozza meg az ikonokat.

```AddIconByType (TXT,/icons/text.gif) text/*

A fájl típúsa szerint határozza meg az ikont.

```AddIcon /icons/binary.gif .bin .exe

Az adott kiterjesztéshez hozzárendel egy ikont.

```DefaultIcon /icons/unknown.gif

Alapértelmezett ikon.

```ReadmeName README
```HeaderName HEADER
```IndexIgnore .??* *~ *# HEADER* README* RCS CVS

Tiltja az index fájlt, illetve a listázást a felsorolt végződésû fájlok esetén.

```AccessFileName .htaccess

A hozzáférést módosító fájl neve.

```DefaultType text/plain

Alapértelmezett fájl típus MIME kódja.

```AddEncoding x-compress Z

Kódolás típust rendel a .Y kiterjesztésû fájlhoz MIME kód szerint.

```AddLanguage en .en

Az .en végû fájl nyelv specifikációját írja le.

```LanguagePriority en fr de

A nyelvek rangsorolása.

```Alias /icons/ /usr/share/apache/icons/

A szervernév /icons/ könytár valódi helye.

```ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/

Hasonló, mint feljebb, azzal a különbséggel, hogy itt futtatható fájlok találhatóak.

```BrowserMatch "Mozilla/2" nokeepalive

Böngészőnkénti szerverbeállítás.

Ha virtuális szervert szeretnénk használni, akkor előtte a következőket kell tudni:

Egy IP címre szeretnénk őket tenni vagy külön IP címre. Az utóbbi azért hasznos, mert ha a későbbiekben egy másik gépre helyeződik át a virtuális szerver és feleslegessé válik az IP cím, akkor egyszerûen az IP cím törlése után nem lesz elérhető a szerver, így újraindítás nélkül megszüntethető a virtuális szerver. Amennyiben több virtuális szervert szeretnénk, akkor érdemes egy IP címre rakni, és amikor a virtuális szerver megszûnik, akkor a konfigurációs fájlból törölni a rá vonatkozó részt, majd újraindítani a szervert. Tudni kell továbbá azt is, milyen portokat akarunk használni, csak a 80-as portot, vagy esetleg más portot is, mint például a 88-at. Amennyiben eldöntöttük, mit szeretnénk, be is állíthatjuk egyszerûen (IP alapú virtuális szerverekre vonatkozik.):

A httpd.conf-ba a következő kerül:

```<VirtualHost www.smallco.com>
```ServerAdmin webmaster@mail.smallco.com
```DocumentRoot /groups/smallco/www
```ServerName www.smallco.com
```ErrorLog /groups/smallco/logs/error_log
```TransferLog /groups/smallco/logs/access_log
```</VirtualHost>

```ServerAdmin webmaster@mail.baygroup.org
```DocumentRoot /groups/baygroup/www
```ServerName www.baygroup.org
```ErrorLog /groups/baygroup/logs/error_log
```TransferLog /groups/baygroup/logs/access_log
```</VirtualHost>

A VirtualHost <96> ban megadott nevet a szerver feloldja, és az arra érkező kérésekre válaszol.

Név alapú virtuális szerver:

```NameVirtualHost 111.22.33.44

```ServerName www.domain.tld
```DocumentRoot /www/domain
```</VirtualHost>

```ServerName www.otherdomain.tld
```DocumentRoot /www/otherdomain
```</VirtualHost>

Ebben az esetben az a különbség az IP alapú virtuális szerver és eközött, hogy a nevet ott feloldja a szerver és azok különböző IP címeken lehetnek, míg itt egy IP címen található mind a két virtuális szerver. Természetesen IP alapúra is lehetett volna állítani a szervert, de előfordulhat az, hogy több interface-szel is rendelkezik a szerver és különböző interface-ekre más-más virtuális szerver van felkonfigurálva.

Az IP címek helyett természetes beírhatjuk a webszerver nevét is! Mégis hogyan lehetséges ez ? Olymódon, hogy a VirtualHost-ban feloldja a beírt hostnevet az apache ezáltal megkapva az adott hivatkozás IP címét. Ez azért lehet fontos, mert amennyiben a szerver átkerül más IP címre, úgy csak a névszerver – illetve az IP címmel rendelkező interface átállítása után a webszerver – tud tovább üzemelni anélkül, hogy nagyobb változtatásra kerülne sor.

Az access.conf leírásakor említés tettem a <Location> és a <Directory> direktíva hasonlóságáról illetve különbségéről. Mielőtt az ígért példára rátérnénk, vegyük alapul a fentebb beállított virtuális szervereket a következő beállítással:

```NameVirtualHost 111.22.33.44

```ServerName www.domain.tld
```DocumentRoot /www/domain
```</VirtualHost>

```ServerName www.otherdomain.tld
```DocumentRoot /www/domain
```</VirtualHost>

Ezek után az access.conf-ba a következőt szeretnénk beállítani, hogy mindkét domain bizonyos könyvtárához csak a megadott gépekről férjenek hozzá.

```<Directory /www/domain/tiltva>
```Options Indexes
```AllowOverwrite None
```order allow,deny
```deny from all
```allow from innen.szabad.tld
```</Directory>

Ha viszont azt szeretnénk, hogy csak az egyik domain esetén ne látszódjon a könyvtár:

```<Location www.otherdomain.tld/tiltva>
```order allow,deny
```deny from all
```</Location>

gy a <Location> direktívával úgy adható meg a hozzáférés ahogyan a kliensek látják. Természetesen mind a két direktívának vannak előnyei és hátrányai, a webszerver készítői azért hozták ezeket létre, hogy azt használja a webszerver adminisztrátora, ami az adott célnak megfelelő, és a legjobban értelmezhető.

E két direktíva mellett a <Files> is megemlíthető, ami már fájlokra csökkenti a hozzáférést. Ez a direktíva teljes mértékben ugyanazon parancsokkal használható, mint a Directory és a Location.

Port alapú virtuális szerver:

```Listen 80
```Listen 8000

```ServerName www.domain.tld
```DocumentRoot /www/domain
```</VirtualHost>

```ServerName www.otherdomain.tld
```DocumentRoot /www/otherdomain
```</VirtualHost>

Ebben az esetben ha a 80 portot nézi meg valaki, akkor ott csak a www.domain.tld válaszolhat.Viszont a 8000 porton csak a másik domainnévvel nézheti meg az oldalakat.

Ezeket a virtuális szervereket lehet ötvözni. Az egyik legjobb példa erre az, amikor ugyanazt a dokumentumot két külön névvel lehet elérni, illetve a weboldalak adminisztrációja másik porton található, aminek a neve is más méghozzá admin.domain.tld. A mostani példához felhasználom az access.confban található <Directory> szekciót is.

httpd.conf-ban szereplő beállítás:

```Listen 80
```Listen 8000

```<VirtualHost 111.22.33.44:80>
```ServerName www.domain.tld
```DocumentRoot /www/domain
```</VirtualHost>

```ServerName www.domain2.tld
```DocumentRoot /www/domain
```</VirtualHost>


```ServerName admin.domain.tld
```DocumentRoot /www/domain/admin
```</VirtualHost>

Az access.conf-bban lévő beállítás:

```<Directory /www/domain/admin>
```Options Indexes
```AllowOverwrite None
```order allow,deny
```deny from all
```allow from innen.szabad.tld
```</Directory>

Ez csak az egyik lehetséges megoldás.

Felhasználók saját önálló webjeinek megjelenítése:

A webszerveren lévő felhasználók rendelkezhetnek saját webrésszel, amit a webszerver megjeleníthet. ltalában ilyen esetben a webszerver nem is lát el más funkciót, tehát nem szoktak beállítani virtuális szervereket. Azt, hogy a felhasználók a saját home-jaikon belül milyen könyvtárnévvel helyezhetik el a webjüket az srm.conf-ban a következőt kell beállítani:

```UserDir /home/*/public_html

Ezek után a felhasználók webjei a következő módon nézhetőek meg:

www.domain.tld/~felhasználónév/, a felhasználó neve az a szerveren lévő felhasználónak a neve kell, hogy legyen. Ahhoz, hogy valami is látszódjék a felhasználó oldalán, létre kell hoznia egy public\_html könyvtárat, és abban elhelyezni a megjelenítendő weblapokat. Az acces.conf alapbeállításai között szerepel az, hogy a felhasználói könyvtárakat lehet listáztatni, illetve csak olyan symlinkeket követ, aminek a tulajdonosa a könyvtár tulajdonosa. Miért fontos ez az utóbbi kitétel? Mert igensok webszerverre jutottak úgy be , hogy kihasználták a symlinkekben rejlő lehetőséget. Azaz a felhasználói neveket, jelszavakat tároló fájlra symlinket hoztak létre, amit azután weben keresztül leszedtek, így hozzájutva más felhasználók jelszavaihoz. Későbbiekben kódolták a jelszavakat, de ez is viszonylag gyorsan törhetővé vált. A megoldás az úgynevezett shadow jelszavak használata, valamint a nagyon nehezen törhető kódolás lett. A shadow jelszavak az nem más, mint egy külön fájl, amit csak a szuperfelhasználó, azaz a szerver adminisztrátora olvashat és írhat. A belépést ellenőrző program is ilyen felhasználóként fut, és így ő olvasni tudja ezt a jelszót, de más nem. A nehezen törhető kódolás használata azt jelenti , hogy valamelyik elterjettebb 56, 64 bites kódoló rendszert használják.Ezek a jelszavak, amelyek már nem maximum 8 karakter hosszúak lehetnek, hanem akár 128 karakter is. A legelterjettebb a shadow jelszó és az MD45 kódolás használata, az MD45 megtévesztő névválasztás, ugyanis nem 45bites(ahogy a nevéből adódna), hanem 52bites kódolást használ, és ehhez a DES kódolást vették alapul. Ezen biztonsági intézkedések ellenére igen hasznos az Apache azon funkciója, amivel csak az olyan symlinkeket jeleníti meg, aminek a tulajdonosa a megjelenítendő könyvtár tulajdonosa. Hiszen nemcsak a jelszófájl lehet fontos egy szerveren, hanem minden más adat, amit a felhasználók elől elzárva tartanak.

CGI futtatása, korlátozása:

A CGI-k szerveroldalon futó programok, amikkel igen sok dolgot meg lehet csinálni. A CGI-k használata nagy körültekintést igényelnek, hiszen a szerveren futnak, és akár a szerver leállítására, megbénítására is képes, ha nem figyel oda az operátor. Miből adódhatnak a veszélyek? A szerver oldalon futtatva sok processzoridőt vesznek el a webszervertől, háttértárolók hozzáférését lelassítja. De ennek ellenére, miért is használnak CGI-t? Mert nem a kliens oldalon történik meg az adatok feldolgozása, és mert ezek által akár korlátozható a kliensek hozzáférése. Hátrányai: sok processzor időt használnak, egy rosszul megírt CGI akár romba is dönthet egy rendszert. Ez utóbbi miatt korlátozzák a CGI-k futtatását. Csak bizonyos könyvtárakban engedélyezik, a felhasználók weboldalain például alapértelmezett esetben nem is lehet használni CGI-ket. A korlátozás nem minden esetben elegendő, mert egy “jól” megírt CGI-ben könnyen el lehet helyezni, olyan opciókat, amikkel a webszervereken “garázdálkodni” lehet. Tehát nem csak korlátozni kell tudni a CGI-k futtatását, hanem a megírt CGI-ket ellenőrizni is kell. Ez utóbbi hiánya okozza azt, hogy egyes webszervereket könnyebben “feltörnek”. A CGI-k közül talán a legérdekesebb a PHP3, ami a szerveroldalon fut, de a weboldalak HTML kódjában található.

4. Részletes ismertetése egy alrendszernek

Mit is tud ez a programozási nyelv? Mik az előnyei?

A PHP3 minden olyat tud, amit egy PERL program: aritmetikai, matematikai, fájlkezelő, adatbáziskezelő funkciói vannak. A legjobban elterjedt használata az adatbáziskapcsolatok felépítése, adatbázisok lekérdezése, a kapott adatok rendezése,a kliensektől kapott adatok adatbázisba helyezése. Lássunk egy példát magyarázattal:

```<HTML>
```<HEAD><TITLE>táblázat kíratása</TITLE>
```</HEAD><BODY>
```<TABLE BORDER=1>

eddig tart a HTML rész ezután már a PHP3 rész következik

```<?dl('mysql.so');$conn = mysql_connect("localhost", "www", "");
```  if ( !$conn ) {
```   echo "Nem lehet megnyitni az adabázist.\n";
`````````exit;
```  }

adatbázisszerverrel való kapcsolat felépíttése

```proc = mysql_select_db("gepek",$conn);

az adott adabázis megnyitása

```proc = mysql_query("select * from aru order by kateg, pref",conn);

a kiválasztott adatbázisból való SQL lekérdezés

```pnumb = mysql_NumRows($proc);

a lekérdezés által visszaadott tömb sorainak száma

```for ($i=0;$i<$pnumb;$i++) {
```kat = mysql_Result($proc,i, kateg);
```nev = mysql_Result($proc,i, arunev);
```ar  = mysql_Result($proc,i, aruar);

a generált tömbből kiválasztja a számunkra fontos adatot

```echo("<TR><TD>".$kat."</TD><TD>".$nev."</TD><TD>".$ar."</TD></TR>\n");
```}

a for ciklus vége

```mysql_freeresult($proc);felszabadítjuk az erőforrásokatmysql_close($conn);

vége a PHP3 résznek

```  </TABLE>
```</BODY>
```</HTML>

és vége a HTML résznek is, és a fájlnak is

Itt jól kivehető, amint a HTML nyelvben a <? ?> karakterek között megtalálható a PHP3 kód. A szerver a <? ?> közötti jeleket értelmezi és a szerveroldalon futtatja. A httpd.conf-ban a következő beállításnak szerepelnie kell, hogy a szerveroldalon fusson:

```LoadModule php3 /usr/lib/apache/1.3/php3.so

A mime.type fájlban:

```application/x-httpd-php3 .phtml .php3

ez azt jelenti, hogy a .phtml és a php3 kiterjesztésû fájlokhoz az application/x-httpd-php3 MIME típust rendeli. A szervernek az srm.conf-ban a következőket kell beállítani , hogy a szerver oldalon valóban le is fusson:

```AddHandler server-parsed .html .shtml

Ezzel a szerveroldalon értelmezi a html, shtml kiterjesztésû fájlokat. Amennyiben PHP3 kódot talál, úgy azt lefuttatja, és annak eredményét jeleníti meg.

PHP3 hibái, előnyei, fejlődési irányok

A hibák leírásával kezdeném mivel a hibák a lehető legszembetûnőbbek a PH3-ban programozók számára.

Az egyik legnagyobb hiba az, amikor egy ciklikus lekérdezés értékeit tömbben tárolja, ám az új lekérés az adattömböt nem generálja újra, hanem hozzáfûződik az előzőhöz, ezzel feleslegesen nagy erőforrás igénye lehet a programnak, sőt akár túl nagy memória használat következtében le is állhat a program (a PHP3 <96>nak is van egy alapbeállítása, illetve a beállításokat tároló fájl, amiben az alapértelmezett memória mennyiség 8megabájt memória). Az egyik megoldás a ciklus végén való tömb nullázás, vagy a tömb elejére való visszatérés. Az utóbbi természetesen magában hordozza azt a veszélyt, hogy ha nem egyenlőszámú lekérdezések történnek, akkor a leghosszabb lekérdezés tömbjének adatai bennmaradnak a memóriában, ezzel akár téves adatok kerülhetnek a programba. Ennek a hibának a kijavítása természetesen folyamatban van, a következő stabil verzió már a fejlesztők ígérete szerint észre fogja venni (akárcsak a Java rendszerben), melyik az a tömb, változó, amire nincs szükség és felszabadítja ezeket a részeket, ezzel is elősegítve az erőforrás gazdálkodást. A PHP3 nyelv előnyei közé tartozik az , hogy több fajta adatbázis szerverhez tud kapcsolódni (Dbase, gdbm, MySQL, msql, PostrgreSQL, Oracle, Adabas, Informix, InterBase, Microsoft SQL Server, Sybase, Hyperwave, Forms Data Format (formázott adat formátum)). Ezenkívûl ODBC driver használatával bármilyen adatbázishoz amihez van ODBC driver. Az adatbázis kapcsolatokon kívül képes PDF fájlok létrehozására, SNMP protokolon keresztül kommunikálni, ismeri az XML kiterjesztést, tud tömöríteni, titkosítani, base64 szabály szerint fájlokat tárolni, levelet küldeni, string típusú változókkal mûveleteket végezni és ezenkívül még igen sok mindenre amit itt nem soroltam fel. Amint a felsorolásból is látszik, igen sok mindenre képes a PHP3 nyelv. Modulos felépítéséből következik, hogy az új funkciókat nem kell magába a PHP3 magjába beleépíteni, hanem modulba rakva használatba lehet venni, és a következő stabil verzióban akár már a hivatalos PHP3-ban is szerepelhet (amennyiben megnyeri a PHP3 fejlesztők tetszését)

A PHP3 nyelvnek a továbbfejlesztett változata a PHP4 nyelv, ez ugyan a PHP3 alapjain nyugszik, de teljesen újra van írva az értelmező része, ezzel elérték azt, hogy az adatbázis kapcsolatok felépítése gyorsabb, egy egyszerû adatbázis lekérdezés, ami régebben 10-11 másodperc is lehetett (adatmennyiségtől függően), lecsökkent 3-4 másodpercre. Egy bonyolultabb lekérdezés ideje akár egy nagyságrenddel is gyorsabb lehet, programok futtatása akár több nagyságrenddel is gyorsabb lehet. A béta verziója ennek a programnak 1999. júliusában látott napvilágot. Másik nagy újítás az, hogy már nemcsak az adatbázisokkal való kapcsolatokért felelős funkciók, függvények kerültek külön modulokba, hanem más matematikai, aritmetikai, fájlkezelő rutinok, funkciók, függvények is. m ezek behívása automatikusan történik meg, de az adatbázis kapcsolatokért felelős modulokat továbbra is a kódban megadva kell meghívni. Mint észrevehető, pillanatnyilag párhuzamos vonalon folyik a fejlesztés, hiszen a PHP3 programnyelvet még finomítják, de már napvilágot látott a PHP4. Mi értelme van akkor mégis annak, hogy idő előtt megjelenítették a PHP4 nyelvet? Ennek többek között az az oka, hogy béta állapotban van, és a vállalkozókedvû programozók, rendszergazdák akár élesben is kipróbáljhatják ezt a rendszert, ezzel is elősegítik a programnyelv hibáinak kijavítását, és a nyelv fejlődését. A PHP3, PHP4 ingyenes, ez azt jelenti, hogy nem áll semmilyen nagyvállalat a programozók mögött igy a fejlesztésre nincsenek akkora erőforrások, mint másutt. Viszont éppen ez az előnye is, hiszen ezzel éppen a felhasználókkal közösen készül el a nyelv és így a lehető leghatékonyabb nyelvvé fejlődhet. Már most igen nagy az érdeklődés a nagyobb látogatottságú oldalak adminisztrátorai részéről, hiszen egy hatékony adatbázis kezelő programozási nyelvet kapnak.

1. Rendszer létrehozása
Például a következő rendszert lehetne létrehozni ezekkel az eszközökkel: egy adott webszerver kereső szerverét ami adatbázis motorral dolgozik. Ez gyorsabban dolgozna, mint egy fájl alapú keresés, hiszen az adattáblákat lehet indexeltetni, logikai összeköttetéseket lehet létrehozni, amit fájlszintû kereséssel sokkal lassabban lehet megoldani. Létre lehet hozni elektronikus kereskedelmet, mert az adtabázisban lehet tárolni az árukat, árumennyiséget stb. Természetesen az utóbbihoz szükség lenne titkosított adatátvitelre is a kényesen kezelendő ügyféladatok miatt.

(név,cím,bankkártya típusa, bankkártya szám, és más titkosan kezelendő adat). Az Apache webszerver egy ssl modul segítségével képes arra, hogy nyíltkulcsú titkosítást használva, kódolva küldje, fogadja az adatokat. A titkosított protokollal már nem a 80-as porton kommunikál a szerver és a kliens, hanem egy külön szabványos porton. Ennek a titkosításnak a jelzésére szolgál a https:// előtag. Apache rendsszer mûködik az extra.hu, apronet.com, netposta.net, internetto.hu, index.hu, hogy csak a legismertebb weboldalakat említsem.

 **Szerver** **szám** **százalék** Apache 2917 61.91% Microsoft-IIS 778 16.51% Netscape-Enterprise 224 4.75% Novell-HTTP-Server 145 3.08% NCSA 121 2.57% RoxenChallenger 77 1.63% SAIC-HTTP 58 1.23% CERN 43 0.91%**1998 szeptemberi magyarországi webszerverek száma és típusa**

** **Ebből a táblázatból is látszik, milyen nagyszámban használják Magyarországon az Apache webszer vert. Ami talán a legjobban vonzza a webszerverek rendszergazdáit az, hogy ingyenesen használható az Apache.

7. A rendszer értékelése
Az Apache webszerverrel létrehozott webhely, amennyiben jól be van konfigurálva, úgy egy igen flexibilis, hatékony webszerver lehet, ami támogatja az új technológiákat, fejlesztési irányvonalakat.

9. A rendszer fejlesztése

A rendszer fejlesztése több irányú. Említésre méltó a HTTPS fejlesztése, ami egyszerre 2 szálon fut, mivel az amerikai és az európai országok titkosítási exportra vonatkozó szabályok miatt. (52bites és az ennél nagyobb nyiltkulcsú kodolás exportjaûára vonatkozó szabályok) Ezenkívül a TEX, illetve a LaTEX

HTML-en belüli használatára is történik fejlesztés. A TEX egy HTML-hez nagyon hasonlító leírónyelv, amellyel akár matematikai egyenleteket, függvényeket lehet megjeleníteni. Ez is egy szerveroldali alkalmazás, lenne ahol a TEX nyelven leírt kódot GIF formátumú képpé alakítja át. Mint már előzőekben említettem a PHP3 nyelv is fejlődik, a PHP4-et is lehet nemsokára használni. Ezenkívûl más programnyelveket is modulosan hozzá lehet majd adni az Apache-hoz. Pillanatnyilag ezek a fejlődési utak, de feltehetőleg a technika fejlődése igényelni fogja újabb HTTP verziót, illetve újabb szerveroldali funkciókat, főleg a multimédia területén, amiket feltehetőleg eleinte külön szerverek, későbbiekben talán maga a webszerver fog kiszolgálni. Természetesen a fejlődésnek ez a pillanatnyi megítélése, hiszen ha megjelenik egy újabb technológia, ami a webszerverekhez valami módon kapcsolódik, biztosan belekerül az Apache fejlesztők listájába.

Felhasznált irodalom:

1. Apache user documents, FAQ, HOWTO ami megtalálható:http://www.apache.org/
2. PHP3 FAQ, HOWTO, user documents ami megtalálható: http://www.php.net/
3. RFC1866 HTML 2.0
4. RFC2068 HTTP 1.1
5. RFC2069 An Extension to HTTP : Digest Access Authentication
6. RFC2070 Internationalization of the HTML
7. RFC2109 HTTP State Management Mechanism
8. RFC2110 MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)
9. RFC2227 Simple Hit-Metering and Usage-Limiting for HTTP
10. Kónya László: Számítógéphálózatok (ISBN 963 577 192 4)
11. Tanenbaum A.S: Számítógép <96> hálózatok (ISBN 963 585 162 6)
12. Füstös János: World Wide Web (ISBN 963 855 640 4)
13. Hargitai Péter <96> Kaszanyiczki László: Internet haladóknak (ISBN 963 577 165 7)<
14. Bártfalvi Barnabás: Hogyan használjam ? (ISBN 963 035 218 4)
15. Nyékyné G. Judit (szerk.)et.al.:JAVA 1.1útikalauz programozóknak (ISBN 963 463 147 9)

Az ábrák és adatok a webszerverek számáról a Netcraft honlapjáról valóak, amely a http://www.netcraft.com/ webcímen érhető el.