UNIX / Linux rendszeradminisztráció
III. előadás
Mai program: ✗
✗
✗
Hálózati fájlrendszer ✗ Fájlrenszerek általában ✗ NFS koncepció ✗ NFS kliens ✗ NFS szerver DNS és BIND ✗ Előzmények, kialakulás ✗ Felépítése, működése ✗ A BIND üzemeltetése ✗ Magyarországi szabályozás (.hu TLD-re) ✗ Speciális alkalmazási lehetőségek Webszerver (Apache) ✗ Több-process szerverek ✗ Teljesítmény vs. biztonság ✗ Konfiguráció és virtuális hosztok ✗ Alkalmazások HTTP fölött
Hálózati fájlrendszer ●
●
●
Unix fájlrendszerek egyetlen jegyzék struktúrába “szerelhetők” be. Ötlet: az egyik gép egy jegyzékét egy vagy több másik gépen mint fájlrendszert használjuk. Haszna: homedirectory, program directory-k, diskless rendszerek
NFS kliens ●
● ●
●
Sun RPC rendszeren működik, portmapper kell hozzá. Minden NFS szolgáltatás RPC-n működik. A mount utasítással a rendszergazda mount-olhatja (-t nfs kapcsolóval) Az fstab-ba beírható, akár user opcióval is. 193.6.5.54:/home
/home
nfs
soft,bg,nosuid,nodev 0
0
NFS kommunikáció ● ● ●
●
Eredetileg: UDP, változó portokon Ma van lehetőség TCP-re is Gondot jelent a zárolási mechanizmusok megvalósítása. Pl flock() nem támogatott. Nem titkosított.
NFS szerver ● ●
Szintén RPC szolgáltatásként fut. Egyetlen konfiguráció az /etc/exports fájl –
Szabályozza, melyik jegyzéket, mely állomásokról, milyen opciókkal lehet mount-olni
/home/share /home
ekrazit(ro,no_root_squash) *(rw,root_squash)
Mai program: ✔
✗
✗
Hálózati fájlrendszer ✔ Fájlrenszerek általában ✔ NFS koncepció ✔ NFS kliens ✔ NFS szerver DNS és BIND ✗ Előzmények, kialakulás ✗ Felépítése, működése ✗ A BIND üzemeltetése ✗ Magyarországi szabályozás (.hu TLD-re) ✗ Speciális alkalmazási lehetőségek Webszerver (Apache) ✗ Több-process szerverek ✗ Teljesítmény vs. biztonság ✗ Konfiguráció és virtuális hosztok ✗ Alkalmazások HTTP fölött
Név és címfeloldás története ●
● ●
●
ARPANET ('70-es évek): néhány száz hoszt, HOSTS.TXT fájl a névfeloldó Közopnti karbantaró: SRI-NIC A TCP/IP bevezetésével robbanás- szerűen növekszik a hosztok száma Problémák: – – –
●
Forgalom és terhelés: karbantartás és terjesztés Névütközések: egyetlen névtér Konzisztencia: gyorsabban változik, mint terjed
Igény a fejlesztésre...
A DNS születése ●
●
Paul Mockapetris feladata egy új rendszer kidolgozása. A DNS specifikációja (1984-től kezdve): – – – –
RFC 882, 883: első specifikáció RFC 1034, 1035: mai szabvány RFC 1535, 1536, 1537: a DNS biztonsági, implementációs és adminisztrációs problémáit világítják meg. További RFC-k, ujabb funkciók, forrásrekord típusok, stb. (extensible standard)
A DNS szerepe ma ●
●
● ●
●
Az Internet egyeduralkodó név- és címfeloldó rendszere Bármilyen interneten használható (itt van konkurenciája pl. NIS, LDAP) “A legfontosabb háttérszolgáltatás” Igen sok szolgáltatás veszi igénybe, felhasználó közvetlenül ritkán Elosztott, redundáns kiszolgálású adatbázis.
Implementációja ● ●
JEEVES volt az első névszerver Mockapetris írta. BIND, a ma legelterjedtebb névszerver (Berkeley Internet Name Domain) – – – –
●
Eredetileg Kevin Dunlap írta a 4.3BSD-hez Ma Paul Vixie a maintainere Fejlesztését az ISC felügyeli. Portolták a legtöbb OS-re
Számos névszerver implementáció létezik.
Mai program: ✔
✔
✗
Hálózati fájlrendszer ✔ Fájlrenszerek általában ✔ NFS koncepció ✔ NFS kliens ✔ NFS szerver DNS és BIND ✔ Előzmények, kialakulás ✗ Felépítése, működése ✗ A BIND üzemeltetése ✗ Magyarországi szabályozás (.hu TLD-re) ✗ Speciális alkalmazási lehetőségek Webszerver (Apache) ✗ Több-process szerverek ✗ Teljesítmény vs. biztonság ✗ Konfiguráció és virtuális hosztok ✗ Alkalmazások HTTP fölött
A Domain Névtér ● ● ●
●
● ●
Objektum típusa: csomópont (node) A csomópont, névvel ellátott attributum halmaz. Az attributumok típussal és értékkel rendelkező entitások. A forrásrekord (Resource Record) egy atributumot ír le. Hierarchikus felépítésű, van gyökere Domainnek a névtér tetszőleges alfáját nevezzük.
A Domain Névtér ● ● ● ●
●
Szülő-gyermek kapcsolatok láncai. Gyökerét a “.” nevű csomópont szimbolizálja. Magassága korlátozott, nem lehet több 127-nél! Minden domain a gyökérben található névvel azonosítható. A testvér (azonos szülővel rendelkező) csomópontok neveinek egyedinek kell lenni!
Domain nevek ●
●
●
●
Minden csomópontnak van neve. Nem több mind 63 karakter. (spec. karakterek kizárva, ma már lehet UTF) Domain nevét a gyökercsomópontjának nevétől kezdve a hierarchiában fölfelé haladva értelmezzül. Elválasztó karakter a “.”. A csomóponttól a gyölkérig vezető teljes útvonal egyérteműen azonosítja a domaint. Abszolút domain név: FQDN Relatív domain neveket is lehet megadni.
Példa “.”
de
hu
org
uni-miskolc
index
szkp
hwvg
hwbn
zeus
iit
odin
gold
www
www
arrkis
com
Domain színtek ●
A domain szintje a gyökértől való távolsága – – –
A gyökér gyermekei a elsőszintű domainek (TLD – top level domain) A TLD-k gyermekei a másodszintű domainek (SLD – second level domain) Stb.
Forrásrekordok (RR) ● ●
A csomópontok attributumait tartalmazzák. Hálózattípus szerint osztályokba soroljuk: – – – –
internet osztály, minden TCP/IP hálózat Chaosnet, nagyon régi Hesiod, MIT Ultrix világa Lehetne több is...
Az Internet domain névtere ●
Kötött TLD-k: – – – – – – – –
●
●
.com – kereskedelmi célú szervezetek (sgi.com) .edu – USA oktatási intézmények (berkeley.edu) .gov – USA kormányhivatalok (nasa.gov) .mil – USA hadsereg intézményei (navy.mil) .net – Hálózatüzemeltetők (internic.net) .org – nem kereskedelmi szervezetek (isc.org) .int – nemzetközi szervezetek (nato.int) ISO 3166 szabványos 2 karakteres országkódok.
Alsóbb szintű domainek kiadásáról a fölötte lévő domain tulajdonosa rendelkezik. Az országok TLD-i az adott ország tulajdonában állnak.
Domain delegálás ●
●
●
Delegálás: azon intézkedés melyet követően a delegált domain kezelése egy szervezet hatáskörébe kerül. A delegált domain alatti domainek létrehozása, esetleg delegálása a kezelő szervezet joga és felelőssége. Pl. – – –
.hu – delegálva van Magyarországnak uni-miskolc.hu – delegálva van a Miskolci Egyetemnek (SzKP) iit.uni-miskolc.hu – delegálva van az Ált. Inf. Tsz.-nek.
Névszerverek ●
●
●
A DNS üzemeltetését, adatainak tárolását, kérések megválaszolását, névszerverek látják el. A névszerver teljes infomációval rendelkezik a domain névtér egy részéről. Ezt hívjuk zónának (zone). A zóna a névszerver fennhatósága alatt áll (authority). Egy névszerver fennhatósága alatt több zóna is lehet.
Zónák ●
●
●
●
A zóna egy domain azon infomációinak összessége, melyet az adott domainben nem delegáltak. Egy zónának több névszervere lehet, melyek fennhatósága alatt áll. Zóna delegálás útján kerül egy vagy több névszerver fennhatósága alá. A delegálás a szülő zónában adható meg, egy domainhez névszerver hozzárendelésével.
Névszerver típusok ●
A specifikáció két típusát különbözteti meg a névszervereknek: –
–
●
●
master: elsődleges névszerver, a zóna adatok karbantartásának helye. Minden zónához csak 1 ilyen tartozhat. slave: másodlagos névszerver, lemásolja a zónaadatokat (zone-transfer) az elsődleges névszerverről és abból dolgozik. Tetszőleges számú tartozhat egy zónához.
A zóna szempontjából egyenértékűek. Mindkét típus fennhatósága a zónának. Nem feltétel, hogy a fennhatóságot viselő névszerverek a zónába tartozzanak.
Adattár – data backend ●
A névszerver hátterében minden zónához tarozik egy adattár, ami tartalmazza a zóna adatait. Lehet: – – – – –
●
File DBMS LDAP CVS repository Stb.
Másodlagos névszervereknél nem szükséges a perzisztens tárolás.
Névfeloldók ● ●
A DNS kliensei. Általában könyvtári függvények. Feladatuk: – – –
●
Kérések továbbítása a névszerverhet Válaszok értelmezése Információk visszaadása a kérdező alkalmazásnak
Önálló keresést a DNS-ben a feloldó általában nem végez.
Rezolúció - feloldás ● ●
●
A kérésre adandó válasz előállításának folyamata. Névszerverek végzik, mivel a feloldók korlázotott képeségei erre nem alkalmasak. Az algoritmus egyszerű fa-bejárás a gyökértől kezdve, azon az ágon amely közelebb visz a keresett név zónájának fennhatóságához (authoritative name server).
Gyökér névszerverek ●
●
●
●
Azon névszerverek melyek zónája a gyökér csomópontban kezdődik. Bejegyzései többnyire csak delegálások, így csak a TLD-k tartoznak a fennhatósága alá. Jelenleg 13 db működik a világ különböző pontjain. [A-K].ROOT-SERVERS.NET Az F szerver összesen 25 node-os klaszter, terhelésmegosztással.
Feloldó algoritmusok ●
●
Rekurzív: a feloldást végző névszerver rendre lekérdezéseket küld, előbb a gyökér névszervernek, majd a következő zóna fennhatóságoknak egészen a keresés céljáig. A válasz ilyenkor hiteles (authoritative). ábra Iteratív: minden megkérdezett névszerver csak a saját adataiból dolgozik és a lehető legjobb választ adja, ami a keresést előre viszi. A válasz nem biztos, hogy hiteles, ilyenkor (non-authoritative). ábra
Címfeloldás (reverse DNS) ●
●
●
A címek nevekre történő leképzése is a DNS feladata. Erre az in-addr.arpa. Domaint használja, mely alatt 4 szinten 0..255 csomopont hierarchiája van. A leveleketn PTR rekord lehet, ami a címhez társított névre mutat. A közbenső csomópontokban csak delegálás van. Pl. 193.6.5.78 címhez tartozó nevet a 78.6.5.193.in-addr.arpa. csomópont PTR rekordja tartalmaza.
Cache-elés ●
●
●
●
A lekérdezés gyorsítását segíti az eredmények ideiglenes tárolása. A névszerver minden válaszrekordot (RR) eltárol, és ujabb lekérdezéskor előbb a gyorsítótárban keres. (non-authoritative) A gyorsítótárban nem lehetnek élhetnek a végtelenségig. Minden RR-nek van TTL értéke. (time-to-live) Van negative-caching is.
Forrásrekordok felépítése ●
Minden RR 4 db mezőből áll, a mezőket whitespace választja el: [
] [] [] – name: a csomópont neve – ttl: az RR ttl értéke – class: az RR osztálya (IN, CH, HS, stb) – type: az RR típusa – data: az RR adatai
●
A következőkben az IN osztály főbb RR típusait tekintjük át.
Főbb RR típusok ●
SOA – fennhatóság kezdete, adatai – – –
Zóna master névszerverének neve Zónafelelős e-mail címe Replikációs adatok ● ● ● ● ●
Serial – verziószám; szig.mon.növ. !!! Refresh – a másolat frissítése percben Retry – sikertelen xfer utánni várakozás Expire – zónaadatok lejáratai ideje TTL – negatív cache TTL
Főbb RR típusok ●
● ●
●
NS – névszerver rekord, adata a névhez tartozó névszerver neve vagy címe. A – címrekord, a névhez rendel címet. MX – a domain MTA-it adja meg. Precedencia és név vagy cím adatokat tartalmaz. CNAME – a név egy alias, ami az adatmezőben lévő másik domain névre mutat.
Főbb RR típusok ●
● ● ● ●
HINFO – hoszt információ, két sztringet tartalmaz, az hw ill. Sw -ről. TXT – szabad szövegmező AAAA – a névhez IPv6 címet rendel A6 – a névhez IPv6 címet rendel. PTR – revDNS pointer rekord, domain nevet társít az in-addr.arpa címhez.
Mai program: ✔
✔
✗
Hálózati fájlrendszer ✔ Fájlrenszerek általában ✔ NFS koncepció ✔ NFS kliens ✔ NFS szerver DNS és BIND ✔ Előzmények, kialakulás ✔ Felépítése, működése ✗ A BIND üzemeltetése ✗ Magyarországi szabályozás (.hu TLD-re) ✗ Speciális alkalmazási lehetőségek Webszerver (Apache) ✗ Több-process szerverek ✗ Teljesítmény vs. biztonság ✗ Konfiguráció és virtuális hosztok ✗ Alkalmazások HTTP fölött
A BIND üzemeltetése ● ●
Letöltés, fordítás, telepítés a szokásos. Konfigurációja egyszerű, két fajta fájlból áll – –
●
●
named.conf: szerver konfiguráció Zóna fájlok: zónainformációk
Az üzemeltetés mottója: “If you put junk in it, you will get junk from it!” Minden fájl szövegfájl.
Szerver konfiguráció ●
Konfigurációs fájl parancsok: –
–
Acl name { [!] IP|IP_pref|aclname|list ; }; Options { [ directory path; ] [ named-xfer path; ] [ notify yes_no; ] [ recursion yes_no; ] [ forwarders { ip; [ip;[...]] }; ] [ allow-query { acl }; ] [ allow-transfer { acl }; ]
Szerver konfiguráció –
–
Zone “domain” [ (in|hs|ch) ] { type master|slave|stub; [ masters { ip; [ip;[...]] }; ] [ file path; ] [ allow-update { acl }; ] [ allow-query { acl }; ] [ allow-transfer { acl }; ] }; Zone “.” [ (in|hs|ch) ] { type hint; [ file path; ] };
Zóna fájl ●
Zóna fájl: – – –
Forrásrekordok Kommentárok (; kezdettel a sor végéig) Makrók: ● ● ●
@ - origó a zóna kezdete $TTL – forrásrekordok alapértelmezett ttl értéke $ORIGIN – origó átállítása
Ellenőrző eszközök ●
Névszerverek működésének ellenőrzésére rendelkezésre álló eszközök: – – –
●
Nslookup: parancssori kliens (elavult) Host: egyszerű kliens Dig: mindent “tudó” DNS böngésző
Domain regisztrációkor hasznos még a whois ami a RIPE adatbázist kérdezi le.
Mai program: ✔
✔
✗
Hálózati fájlrendszer ✔ Fájlrenszerek általában ✔ NFS koncepció ✔ NFS kliens ✔ NFS szerver DNS és BIND ✔ Előzmények, kialakulás ✔ Felépítése, működése ✔ A BIND üzemeltetése ✗ Magyarországi szabályozás (.hu TLD-re) ✗ Speciális alkalmazási lehetőségek Webszerver (Apache) ✗ Több-process szerverek ✗ Teljesítmény vs. biztonság ✗ Konfiguráció és virtuális hosztok ✗ Alkalmazások HTTP fölött
Magyar DNS szabályok ●
●
●
●
A .hu TLD alá domain neveket kiosztani a Magyar állam joga. Jogait az ISZT kht gyakorolja, a technikai üzemeltetést a NIIFI végzi. Regisztrációt Franchiese keretében regisztrátor cégek (ISZT tagok) végezhetnek. Tőlük igényelhető. Árakra vonatkozó irányelveket az ISZT, tarifákat a regisztrátor szab meg.
Magyar DNS szabályok ●
Regisztráció menete: – – –
Domain név ellenőrzése, hogy szabad-e Üzembe kell állítani min. 2 db névszervert (különböző halózatokon) mint zóna hatóságot Technikai ellenőrzés http://www.domain.hu/domain/regcheck/
–
Regisztrációs kérelem benyújtása, annak díjának megfizetése és üzemeltetési szerződés aláírása. A regisztráció kétféle lehet: ● ●
Prioritásos: jogi személyhez, talalmányhoz, stb. Nem prioritásos: 2 hetes nyilvános meghirdetés
Magyar DNS szabályok ●
Ide vonatkozó jogszabályok: – – –
●
Ptk. ISZT domain üzemeltetési szabályzat Regisztrátorral kötött szerződés
Információk: –
ISZT Kht : http://iszt.hu http://nic.hu
Mai program: ✔
✔
✗
Hálózati fájlrendszer ✔ Fájlrenszerek általában ✔ NFS koncepció ✔ NFS kliens ✔ NFS szerver DNS és BIND ✔ Előzmények, kialakulás ✔ Felépítése, működése ✔ A BIND üzemeltetése ✔ Magyarországi szabályozás (.hu TLD-re) ✗ Speciális alkalmazási lehetőségek Webszerver (Apache) ✗ Több-process szerverek ✗ Teljesítmény vs. biztonság ✗ Konfiguráció és virtuális hosztok ✗ Alkalmazások HTTP fölött
Speciális alkalmazások ●
A DNS-be TXT RR-ként tetszőleges információk felvihetők –
●
●
Címtár szolgáltatás
Spam terjesztők elleni védekezésként létrehoztak feketelistákat. Ezek publikálásának egyik módja a DNS. Terhelésmegosztás –
Dinamikusan generált RR-ekkel.
Mai program: ✔
✔
✗
Hálózati fájlrendszer ✔ Fájlrenszerek általában ✔ NFS koncepció ✔ NFS kliens ✔ NFS szerver DNS és BIND ✔ Előzmények, kialakulás ✔ Felépítése, működése ✔ A BIND üzemeltetése ✔ Magyarországi szabályozás (.hu TLD-re) ✔ Speciális alkalmazási lehetőségek Webszerver (Apache) ✗ Több-process szerverek ✗ Teljesítmény vs. biztonság ✗ Konfiguráció és virtuális hosztok ✗ Alkalmazások HTTP fölött
Az Apache webszerver ● ●
● ● ●
Az Internet legelterjedtebb webszervere. OSS, fejlesztője az ASF – Apache Software Foundation. Projekt neve: httpd Használatos verziók: 1.3.x és 2.x Jellemzői: – – – –
Jól skálázható Bővíthető Jól portolható Könnyen kezelhető
HTTP/1.0 kommunikáció ●
● ● ● ●
Kliens tcp kapcsolatot kezdeményez a szerverrel (syn, ack, syn+ack) Kliens HTTP request -et küld a szervernek Szerver feldolgozza a kérést Szerver HTTP response választ kült a kliensnek Szerver tcp-reset csomaggal bontja a kapcsolatot.
Több-processz szerverek ●
Alap kliens/szerver modell szerint egy szerver egyszerre egyetlen klienst szolgál ki. –
●
Előnye: egyszerű megvalósítás
Igény több kliens “párhuzamos” kiszolgálására: –
Worker processz modell (ábra) ●
● ●
–
A szülő fogadja a kapcsolatot, de továbbadja egy gyermek processznek (worker) A szülő kész fogadni a következő kapcsolatot A gyermek kommunikál a klienssel és kiszolgálja a kéréseit, majd megszünik.
Hátrány: fork() időigényes
Spare Server koncepció ●
●
●
●
Van mindig készenlétben korlátozott számú tétlen gyermek processz (SpareServer). A szülő csak a gyermek processzek megfelelő számáról gondoskodik. A Spare szerverek mindegyike kapcsolatra vár. Az OS ilyenkor a legrégebben várakozónak diszponálja az új kapcsolatot. Ettől a spare-ből worker lesz. A worker kiszolgálja a kliens és megszűnik.
Server reuse ●
●
További teljesítmény növelés érhető el, ha a worker nem szűnik meg a processz, hanem Spare szerverré alakul. Így kevesebb processzt kell létrehozni ugyanannyi kérés kiszolgálásához.
Keepalive - HTTP/1.1 ●
● ●
●
A HTTP/1.1 szabvány lehetőséget ad arra, hogy ne a HTTP response után a TCP kapcsolat megmaradjon és azon a kliens ujabb HTTP request-et küldjön. Ez a keepalive tulajdonság. A kliens a TCP kapcsolat első HTTP request-jében jelzi ha ilyet kér. A HTTP response után bármelyik fél bonthatja a kapcsolatot.
Mai program: ✔
✔
✔
Hálózati fájlrendszer ✔ Fájlrenszerek általában ✔ NFS koncepció ✔ NFS kliens ✔ NFS szerver DNS és BIND ✔ Előzmények, kialakulás ✔ Felépítése, működése ✔ A BIND üzemeltetése ✔ Magyarországi szabályozás (.hu TLD-re) ✔ Speciális alkalmazási lehetőségek Webszerver (Apache) ✔ Több-process szerverek ✗ Teljesítmény vs. biztonság ✗ Konfiguráció és virtuális hosztok ✗ Alkalmazások HTTP fölött
Teljesítmény vs. biztonság ●
●
A worker processz modell, a server reuse és a keepalive mind más-más biztonsági problémákat vetnek fel. Worker: –
Probléma: ●
–
Minden kapcsolat égy új processz -> végtelen ciklusban egy kliens DoS-t okozhat a processztábla betöltésével.
Megoldás: ●
●
Azonos címről érkező kapcsolatok számának maximálása (DDoS-t nem oldja meg) Worker processzek számának globális maximálása
Teljesítmény vs. biztonság ●
Server reuse: –
Probléma: ●
–
Gyakori programozói hiba a “memory leakage”, aminek oka nem biztos, hogy a szoftverben van, lehet a függvénykönyvtárakban is.
Megoldás: ●
Worker processzek bizonyos request szám utánni megszüntetése. A szülő pedig minél egyszerűbb, hogy csökkentse a hiba lehetőségét.
Teljesítmény vs. biztonság ●
Keepalive: –
Probléma: ●
●
–
Rosszindulatú kliens nyitva tarthatja a TCP kapcsolatokat tétlenül -> DoS, DDoS Rosszindulatú kliens igen nagy időbeli sűrűsséggel küldhet request-eket.
Megoldás: ● ●
Kapcsolat timeout Egy kapcsolatra jutó request-et korlátozása
Mai program: ✔
✔
✔
Hálózati fájlrendszer ✔ Fájlrenszerek általában ✔ NFS koncepció ✔ NFS kliens ✔ NFS szerver DNS és BIND ✔ Előzmények, kialakulás ✔ Felépítése, működése ✔ A BIND üzemeltetése ✔ Magyarországi szabályozás (.hu TLD-re) ✔ Speciális alkalmazási lehetőségek Webszerver (Apache) ✔ Több-process szerverek ✔ Teljesítmény vs. biztonság ✗ Konfiguráció és virtuális hosztok ✗ Alkalmazások HTTP fölött
Apache konfiguráció ●
Konfigurációs fájlok: – – –
●
●
httpd.conf – fő konfig fájl srm.conf – erőforrások beállítása access.conf – hozzáférés szabályozás
Ma már csak a httpd.conf használatos a virtuális hosztok elterjedése miatt. A konfigurációnak 3 szakasza van: – – –
Szerver processzek konfigurációja Globális vagy default szerver erőforrás és hozzáférés konfigurációja Virtuális hosztok konfigurációja
Processz kezelés beállításai ● ● ● ● ● ●
Szerver típus: folyamatos, igény szerinti Munkajegyzékek, állapotfájlok Limitek, keepalive, spare szerverek Interfészek, portok Dinamikus (DSO) modulok betöltése Privilégium szeparáció felhasználó neve és csoportja
Defaul szerver konfiguráció ● ● ● ● ● ● ● ● ● ●
Szerver név, adminisztrátor Dokumentumok gyökere Jegyzék és URL szintű hozzáférés szabályozás Modulokhoz kötődő beállítások Felhasználói hozzáférés szabályozás fájlneve Index fájlnevek Fájltípusok kezelői Hibaüzenetek lapjai Naplózás beállításai Proxy beállítások
Virtuális hosztok ●
●
●
Egy webszerver nemcsak egy webhely kiszogálására alkalmas. Ugyanazon címre mutathat több domain név is. Ilyenkor virtuális hosztokat hozunk létre, melyeket ugyanaz a szerver szolgál ki, ugyanazon a címen, csak más néven megszólítva. Igen elterjedt technika. (több webhely mint szerver hoszt)
Egy példa ServerName msdn.iit.uni-miskolc.hu ServerAdmin [email protected] ServerAlias msdn ServerAlias msdn.iit DocumentRoot /home/staff/wagner/public_html/msdn/ Options FollowSymLinks AllowOverride None Order allow,deny Allow from all ErrorLog /var/log/apache/msdn.iit-errorlog CustomLog /var/log/apache/msdn.iit-accesslog common
Mai program: ✔
✔
✔
Hálózati fájlrendszer ✔ Fájlrenszerek általában ✔ NFS koncepció ✔ NFS kliens ✔ NFS szerver DNS és BIND ✔ Előzmények, kialakulás ✔ Felépítése, működése ✔ A BIND üzemeltetése ✔ Magyarországi szabályozás (.hu TLD-re) ✔ Speciális alkalmazási lehetőségek Webszerver (Apache) ✔ Több-process szerverek ✔ Teljesítmény vs. biztonság ✔ Konfiguráció és virtuális hosztok ✗ Alkalmazások HTTP fölött
Alkalmazások HTTP fölött ●
A webszerver nem csak html lapok kiszolgálására alkalmas: –
–
Egyes URL-ekhez köthető program, ami az arra az URLre érkező kérést kezeli és választ generál ra dinamikusan (CGI). Igy komplex alkalmazások is megvalósíthatók. Vannak erre specializálódott fejlesztőeszközök pl. PHP. Az ilyet webalkalmazásnak hívjuk. A HTTP-be beágyazható más protokoll is. Pl. SOAP, ami távoli szoftver objektumok elérését teszi lehetővé programok számára. Ezt hívjuk webszolgáltatásnak (WS WebService).