-1-
ÓBUDAI EGYETEM Neumann János Informatikai kar Alba Regia Egyetemi Központ
SZAKDOLGOZAT
OE-NIK 2010.
Hallgató neve:
Berencsi Gergő Zsolt
Törzskönyvi száma:
T 000123/FI38878/S-N
-2-
-3-
I. Tartalomjegyzék
-4-
II. Tartalmi összefoglaló
-5-
III. A megoldandó probléma megfogalmazása
A feladat annak megoldása, hogy az időnként a szolgáltatótól más-más IP-címet kapó szerver gépek, ugyanazon a domain címen legyenek elérhetőek. Ezen belül megoldandó az aldomainek regisztrációja, azok dinamikus frissítése az aktuális IP címre és a felhasználói jogosultságok kezelése. A dolgozat bemutatja a felhasznált technológiákat, a tervezési megfontolásokat, az adatbázis felépítését, a programot és a felhasználói, illetve programozói dokumentációt.
-6-
IV. A probléma elemzése, specifikáció kidolgozása 1.
A DNS azaz a Domain Name System (Domain Név Rendszer) működése.
A DNS egy hierarchikus, osztott elnevezési rendszer, számítógépek, szolgáltatások, illetve bármilyen más hálózatra kötött erőforrás számára amelyet 1983-ban Paul Mockapetris alakított ki[1]. A rendszer lényege, hogy ne kelljen a felhasználónak megjegyeznie, és állandóan beírnia a kapcsolódási szándékából következő cél szerver IP címét (pl.: 195.228.74.124), hanem egyszerűen egy névvel hivatkozni tudjon az adott rendszerre. Ezt valósítja meg a DNS oly módon, hogy az erre kijelölt DNS névfordító gépek feloldják a domaint a náluk meglévő IP címmé és így kiszolgálhatóvá teszik a kérést. Ez alapján például a w5.hu gépnévhez a 94.125.248.21 IP cím tartozik (1.1 ábra).
(1.1 ábra Névfeloldás)
A DNS feloldáshoz nem szükséges egy központi fordító állomást állandóan üzemeltetni. A név feloldáshoz először a fő névkiszolgálókhoz fordulnak a gépek (amennyiben a saját névkiszolgálója nem tartalmazza a szükséges bejegyzést). Ezek szolgáltatják az országos domain neveket (pl.: .hu .org .info) és tartalmazzák a további névfordítókat. Így tulajdonképpen egy fa struktúrát alakítanak ki, amely ágain haladva könnyen feloldhatóak a címek. Lássunk erre egy példát. Valamely számítógép keresi a [1] Forrás: http://hu.wikipedia.org/wiki/Domain_Name_System
-7houston.debilinux.hu címét. Először a .hu feloldásáért felelős gépet keresi meg, majd ezután fordul a debilinux.hu fordításáért felelős géphez, majd így fordított sorrendben végighaladva eljut addig a gépig amely szolgáltatni fogja neki a houston.debilinux.hu IP címét. A névfeloldáshoz a bejegyzéseket a névszerverek úgynevezett zónákban tárolják. A zónák tartalmaznak egy FORWARD és egy REVERSE nevű részt. A forward részben vannak azok a bejegyzések, amelyek a domain-t IP címmé alakítják, míg a reverse rész az adott IP címhez szolgáltat domain nevet.
2.
2.1.
A DNS zónák felépítése.
A zóna bejegyzés:
A DNS zóna definiálásakor (amely a névszerver kofigurációjában történik) meg kell adni a zóna típusát (master vagy slave amelynél a slave a masterről frissíti az információit), a filet amely tartalmazza a zóna tulajdonságait és bejegyzéseit, illetve egy bejegyzést arról, hogy honnan elérhető az adott zónafájl (any esetén bárhonnan). A reverse zóna neve adott. Ezt meghatározza a tartomány neve, amely formátuma az IP cím nem változó részei fordított sorrendben pontal elválasztva, majd az „in-addr.arpa” felirat. Pl.: Ha egy lokális zónát definiálunk a 192.168.0.0/24 -es hálózatra akkor a reverse zóna neve 0.168.192.in-addr.arpa. A konfigurációban így néz ki egy zóna bejegyzés:
-8zone ”tesco” { type master; file /etc/bind/tesco; allow-transfer {any;}; };
zone ”0.168.192.in-addr.arpa”{ type master; file ”/etc/bind/tescorev”; }; Ez a minimális követelmény egy zóna bejegyzésére.Ezekután nézzünk egy példát a zónafájlok felépítésére is.
-92.2.
A forward zóna:
(1.2 ábra A forward zóna) A forward zóna (1.2 ábra) egy TTL (Time To Live) értékkel kezdődik, amely meghatározza, hogy mennyi ideig érvényes a belőle kinyert információ. Ez után következik egy SOA rekord. Ebben kell definiálni a zóna alapvető tulajdonságait. A „@” jel a zóna nevére illeszkedik, így nem kell mindig kiírni azt. A „localhost.” az elsődleges névszervert határozza meg, a „root.localhost” pedig egy e-mail cím, amely a „@” elválasztó helyett pontot alkalmaz. Ezek után következik 5db szám, melyekből az elsővel szokás jelölni az utolsó módosítás dátumát. Alapesetben ez csak egy növelendő szám, amely alapján ellenőrzik a slave-ek, hogy történt-e módosítás a zónában, de ha a dátumot írjuk bele az információval szolgálhat a későbbiekben. A második szám a Refresh. Ez határozza meg, hogy mennyi időnként ellenőrizzék a slavek, hogy történt-e módosítás. A retry határozza meg, hogy ha nem elérhető a névszerver, akkor ennyi időnként próbálkozzanak újra. Az utolsó előtti expire szám azt adja meg, hogy mennyi ideig szolgáltathatják a zónát a slavek ha az elsődleges névszerver nem elérhető. A Negative Cache TTL adja meg mennyi ideig cache-elhessen egy bejegyzést. A számok minden esetben másodpercben értendők.
- 10 A következő rekord (@ IN NS localhost.) a névszerver rekord. Ez határozza meg, hogy milyen címen érhető el a névszerver. Jelen esetben localhost tehát a saját névszerverét használja. Megadható több ilyen rekord is, ilyen esetben terhelés-megosztással működik a feloldás. Az ezt követő (@ IN A 192.168.0.1) rekord egy „A” típusú rekord, amely IP címet képes rendelni egy adott domain névhez. A domain név itt a zóna neve a „@” miatt. A felépítés tehát láthatóan a következő: <domainnév> IN A
. A következő egy CNAME típusú rekord (geery IN CNAME @). Ennek a típusnak a lényege hogy domaint képes rendelni egy másik domainhez, tehát a feloldás során egy másik domain nevet kapunk vissza. Ez akkor lehet hasznos, ha például van egy domain nevünk ami automatikusan frissül (mert például a mi névszerverünk frissíti) és van egy amit bérlünk. Ha a béreltet egy CNAME rekorddal a mi domain-ünkre állíttatunk nem kell mindig átirattatni az IP címet amire mutat. Az utolsó bejegyzésbe található „AAAA” rekord szinte teljes mértékben megegyezik az „A” rekorddal, csak annyi a különbség, hogy ezt használhatjuk Ipv6-os címek fordítására. Még létezik egy fontos rekord típus, az „MX” rekord. Ez az e-mail forgalom lebonyolításáért felelős, mert mint például itt is a „tesco” domaint a névszerver 192.168.0.1-re oldja fel, de így ha levélről van szó (pl.: geery@tesco) akkor ebben a bejegyzésben található címet fogja fordítani. Több ilyen rekorddal biztosítható, hogy ne vesszenek el a levelek, mert ha például egy másik átveszi akkor onnantól ő próbálja továbbítani az elsődlegesnek. Az MX rekordok súlyozhatóak. Mindig a kisebb súlyú értékkel próbálkozik először.
- 11 2.3.
A reverse zóna:
(1.3 ábra A reverse zóna) A reverse zóna (1.3 ábra) egy ugyan olyan „SOA” rekorddal kezdődik mint a forward és a működése is ugyanaz. Egy dologban tér el, mégpedig abban, hogy itt kell definiálni az úgynevezett PTR rekordokat. Ezek határozzák meg, hogy adott IP-t milyen domainnévre oldjon fel a névszerver. Mivel a definícióban a 192.168.0 már meg van adva, itt elegendő a „2 IN PTR asus-geery.” bejegyzés. Ha 192.168-ig lett volna csak, abban az esetben 2.0-t kellene megadni, tehát itt is fordított sorrendben.
3.
A DNS problémája
A DNS rendszer működése felvet bizonyos problémákat. Az egyik ilyen nagyobb közülük az internet szolgáltatók megoldásaiban rejlik. Némelyik szolgáltató (főleg a DSL-ekre jellemző) 24 óránként bontja az internet kapcsolatot és másik IP címet oszt ki az ügyfélnek. Amennyiben az ügyfél valamilyen (pl.: VNC) szolgáltatást üzemeltet, ez az IP változás problémákat vet fel. A DNS látszólag megoldás erre, de viszont fontos dolog hogy a domain nevek frissüljenek az adott IP-re a lehető leggyorsabban. Amennyiben ez nem történik meg minél hamarabb, a VNC kliens a domain névvel sem tudja megtalálni az adott gépen futó szolgáltatást. Így a szolgáltatás elérhetőségi szempontból nagyon gyenge lesz. Erre a problémára kellene valamiféle gyors, megbízható, dinamikus megoldást találni.
- 12 -
V. Lehetséges megközelítési módok
1.
Igénylő rendszer kialakítása a frissítéshez
Az igénylő rendszer egy olyan rendszer, amelyben a felhasználók egy adott helyen jelzik IP cím változási problémájukat, majd a másik oldalon ezt egy adminisztrátor fogadja. Az adminisztrátor ezek után átállítja a kérés alapján a megfelelő domaint a megfelelő helyre.
1.1.
A rendszer előnyei:
A rendszer előnye, hogy az adminisztrátor ellenőrizhet minden kérést és így nem terhelik a rendszert a felhasználó által rosszul megadott kérések.
1.2.
A rendszer hátrányai:
Az egyik nagyon nagy hátránya ennek a megközelítésnek a sebesség. A kérésnek ugyanis idő kell ahhoz, hogy eljusson az őt kiszolgáló személyhez, így nem történhet meg azonnal a módosítás. A másik probléma, hogy ezzel emberi tényezőt viszünk a rendszerbe, ami felmerülhet később mint hibaforrás (pl.: valamit elír az adminisztrátor), továbbá nagyon magas költséggel is jár.
- 13 2.
Dinamikus DNS kiszolgáló szerver fejlesztése
A dinamikus DNS kiszolgáló szerver egy olyan szolgáltatást nyújt, amelyben a felhasználók a saját domainjeiket, saját maguk kezelhetik. Ilyen rendszerek több helyen léteznek már és használhatók is, ám vagy fizetősek, vagy korlátozottak. Egy saját dinamikus DNS kiszolgáló fejlesztése tehát hosszú távon jó befektetés lehet.
2.1.
A rendszer előnyei:
A rendszer előnye, hogy adott változtatás azonnal életbe lép, így nincs szolgáltatás kiesés. A másik nagy előny, hogy a felhasználók a szerveken futó (már létező és több helyről ingyen letölthető) IP frissítő kliens programokkal automatikusan frissíthetik a szervereik IP címét. További előny még, hogy egy jól megírt kiszolgáló képes jogosultságokkal korlátozni a felhasználókat, hogy csak a hozzájuk tartozó domainekhez férjenek hozzá.
2.2.
A rendszer hátrányai:
A fejlesztés költséges lehet, és a rendszert karbantartani is kell. Otthoni kisgépes környezeben nem hatékony, érdemes szerverre telepíteni.
- 14 -
VI. Módszer kiválasztása, a választás indoklása
A módszer kiválasztásánál összevetettem az előnyöket illetve hátrányokat és arra a következtetésre jutottam, hogy a saját DynDNS rendszer a legjobb választás. Ennek az oka, hogy minimális hátránnyal rendelkezik a statikus átírással szemben, a létező bérléssel szemben pedig annyiban jobb, hogy a fejlesztési költséget egyszer kell megfizetni, amely idővel megtérül.
- 15 -
VII.
1.
A program részletes specifikációja
A programmal szemben támasztott követelmények:
•
Felhasználó szintű azonosítás jelszóval védve ◦ Felhasználónév ◦ Jelszó (tárolás kódolva) ◦ Teljes név ◦ E-mail cím ◦ Regisztráció dátuma ◦ Admin jogosultság adása védett módon (felhasználói felületről ne lehessen) ◦ Megjegyzés
•
Fő domainek tárolása, melyekhez aldomainek regisztrálhatók ◦ Domain neve ◦ Létrehozó tárolása ◦ Létrehozás dátumának tárolása ◦ Megjegyzés ◦ Lehessen pulikussá tenni domaint, amihez bárki felvehet aldomaint
- 16 -
•
Aldomainek tárolása ◦ Melyik fődomainhez tartozik ◦ Mi az amihez hozzárendelünk ◦ Mit rendelünk hozzá ◦ Milyen típusú az adott hozzárendelés (A,AAAA,MX,CNAME) ◦ Létrehozó tárolása ◦ Létrehozás dátuma ◦ Megjegyzés
•
Lehetőség legyen adott domainhez adott usernek jogot adni ◦ Domain amihez a jogosultság tartozik ◦ Felhasználó aki kapja a jogosultságot ◦ Jogosultság létrehozójának tárolása ◦ Jogosultság keletkezésének dátuma ◦ Megjegyzés
•
Adminisztrációs felület ahol az adminok karbantarthatják az egyes táblákat ◦ Felhasználók karbantartása (hozzáadás,törlés,módosítás) ◦ Domainek karbantartása (hozzáadás,törlés,módosítás) ◦ Aldomainek karbantartása (hozzáadás,törlés,módosítás) ◦ Jogosultságok karbantartása (hozzáadás,törlés,módosítás)
- 17 -
•
Egyéb elvárt funkciók ◦ Adminisztrációs felületen törlés esetén ha vannak kapcsolódó rekordok más táblákban, csak figyelmeztetés után lehessen törölni (ilyenkor a kapcsolódó rekordok is törlődnek) ◦ Adott felhasználó csak azokhoz a domainekhez férhessen hozzá amelyekhez van jogosultsága, vagy pulikusak ◦ Adott felhasználó korlátlan számú aldomaint vehessen fel ◦ A felhasználó módosíthassa a saját jelszavát (ezen kívül semmi mást) ◦ Az adminisztrátor ne férhessen hozzá más jelszavához, csak módosítani tudja azt ◦ A felhasználó a már létező felépítésű IP frissítő kliensel aktualizálni tudja az IP címét
- 18 -
VIII.
1.
1.1.
A tervezés során végzett munkafázisok
Megvalósítási mód kiválasztása
Operációs rendszer választása:
Első dolog a megvalósítás kiválasztása során a futtatási környezet kiválasztása. Két lehetőség jött szóba operációs rendszer szinten, hogy Windows vagy Linux környezet alól üzemeltessem-e a szerver oldali programot. Megbízhatósági megfontolásból a Linuxos környezetet választottam, illetve azon okból is mert a Linux disztribúció ingyenes amely csökkenti az üzembe helyezés költségeit. Ha meg kellene vásárolnom az operációs rendszert és még hozzá az adatbáziskezelőt is, a költségek nagyon magasak lennének.
1.2.
Adatbázis kiválasztása:
Linux operációs rendszer alatt több stabilan működő adatbázis kiszolgáló működik. Ilyenek például a PostgreSQL, a MySQL és még az OracleSQL is feltelepíthető bizonyos Linux disztribúciókra. Az adatbázis kiválasztásánál fontos tényező, hogy a bonyolultságnak megfelelő adatbázist válasszunk. Mivel az adatbázisban nincs szükségünk különleges képességekre ezért talán a legjobb a választás a MySQL. „A MySQL egy többfelhasználós, többszálú, SQL-alapú relációs adatbázis-kezelő szerver, amely az egyik legelterjedtebb azon oknál fogva, hogy a teljesen nyílt forráskódú LAMP (Linux-Apache-MySQL-PHP) összeállítás részeként költséghatékony és egyszerűen beállítható megoldást ad a dinamikus webhelyek szolgáltatására.[2]” [2] Forrás: http://hu.wikipedia.org/wiki/MySQL
- 19 1.3.
Futtatói környezet kiválasztása:
A futtatói környezet kiválasztása volt talán az egyik legegyszerűbb feladat. Az adatbázis kiválasztását követően egyértelmű, hogy a MySQL az Apache webkiszolgálóval, és a PHP programnyelvvel képes a leghatékonyabban együtt dolgozni. „Az Apache HTTP Server (röviden Apache) nyílt forráskódú webkiszolgáló alkalmazás, szabad szoftver, mely kulcsfontosságú szerepet játszott a World Wide Web elterjedésében. A projekt célja olyan webszerver program létrehozása, karbantartása, és fejlesztése, amely megfelel a gyorsan változó Internet követelményeinek, biztonságos, üzleti, vállalati felhasználásra is megfelelő és szabadon használható.[3]” Tehát az Apache webszerver egy jó választás a megvalósításra. A PHP (Hypertext Preprocessor) Rasmus Lerdorf által 1994-ben megalkotott nyílt forráskódú, számítógépes szkriptnyelv, legfőbb felhasználási területe a dinamikus weboldalak készítése és ingyenesen telepíthető a legtöbb operációs rendszerre.[4]
2.
Adatbázis szerkezet felépítése
A következő fázis az adatbázis felépítése volt. Ezen folyamatot először megpróbáltam teljesen a specifikáció alapján elkészíteni, de ki kellett egészíteni később a programozás logikájából következő mezőkkel. Az adatbázis táblák tehát a következőképpen alakultak:
[3] Forrás: http://hu.wikipedia.org/wiki/Apache_HTTP_Server [4] Forrás: http://hu.wikipedia.org/wiki/PHP
- 20 -
(x.y ábra) Az ábrán látható (x.y ábra), hogy összesen négy táblát tartalmaz az adatbázis. A bal oldalon találhatóak az idegen kulcsot nem tartalmazó táblák, míg a jobb oldalon az ezekből kialakult jogosultság összerendelő, és aldomain összerendelő táblák. A user tábla tartalmazza a felhasználók adatait, mint például e-mail címüket, teljes nevüket. Itt az elsődleges kulcs maga a felhasználó neve, amely így "unique" tehát egy felhasználónév csak egyszer szerepelhet. A domain tábla tartalmazza a fő domaineket, melyeket egyértelműen meghatároz a nevük, így ez lett az elsődleges kulcs. Tartalmazza még a tábla a létrehozó nevét, a létrehozás idejét, megjegyzést, és egy "public" nevű mezőt, amely meghatározza hogy az adott domainhez bárki hozhat-e létre aldomaint. A következő tábla a "grants". Ez a tábla tartalmazza hogy adott felhasználó melyik nem
- 21 publikus domainhez férhet hozzá. Ehhez szükség van két idegen kulcsra, a felhasználóra akinek a jogosultságot adjuk, és a domain neve amihez hozzáférhet. Ezen felül tárolódik, hogy ki adta a jogosultságot a felhasználónak, mikor adta, és esetlegesen megjegyzést lehet megadni, hogy miért kapta a felhasználó a jogosultságot. Ebben a táblában az elsődleges kulcs megosztva a felhasználó neve és a domain. A negyedik tábla a "subdomain". Ez a tábla tartalmazza az összes létrehozott aldomaint. Szintén két idegen kulcsa van, a domain neve amelyhez az aldomain tartozik, illetve a user aki létrehozta. Ennél a táblánál egy domainhez, azonos típusú rekord, csak egy néven hozható létre, így ez a három lett összetetten az elsődleges kulcs. A tábla tartalmazza még hogy milyen IP címre vagy domainre mutat az adott rekord, illetve a létrehozás időpontját és a megjegyzés mezőt.
- 22 -
IX. A megvalósítás leírása, elemzése.
1.
1.1.
Felhasználói dokumentáció
Belépés a rendszerbe
A felhasználó a weboldalra lépve az x.y ábrán látható felülettel találkozik. Amennyiben már van hozzáférése a rendszerhez, a felhasználó nevének és jelszavának beírásával, valamint a Belépés gombra kattintással tudja azonosítani magát.
1.2.
Regisztráció
Amennyiben a felhasználó még nem rendelkezik az azonosításhoz szülséges adatokkal, ez esetben regisztrálnia kell magát a rendszerben. A regisztráció gombra kattintva az x.y ábrával találkozik. Itt adhatja meg a kívánt felhasználói nevét, illetve az érvényes e-mail címét. Sikertelen a regisztráció ha az e-mail cím vagy a felhasználó név már használatban van. Sikeres regisztráció esetén egy e-mailes értesítést kap a regisztráció megerősítéséről. Az e-mail tartalmaz egy linket mellyel véglegesíthető a regisztráció. Ha ez is megtörtént az oldalon a "Sikeres megerosites! Most mar belephetsz! A jelszavadat a megadott címre elküldtük!" felirat jelenik meg, és egy "Vissza a bejelentkezéshez" link. Az e-mailben kapott jelszóval, és a kiválasztott felhasználó névvel.
1.3.
A kezdő felület
Az x.y ábrán látható kezdő felület jelenik meg sikeres bejelentkezés esetén. A főoldalon olvashatóak az éppen aktuális hírek, esetleg tervezett leállási dátumok, vagy bármely
- 23 olyan információ melyet az adminisztrátor megoszt. A felső sorban található egy menü. Ezzel lehet a kívánt oldalra navigálni.
1.4.
Domainek
A domainek gombra kattintva az alábbi x.y. ábra jelenik meg. Itt kiválasztható, hogy mely domainek elérhetők a számunkra. Amennyiben nem jelenik meg egy domain sem, abban az esetben az adott rendszeren nincsenek publikus domainek és nincs jogosultságunk egyetlen domainhez sem. A megfelelő domain kiválasztásával az x.y.ábra jelenik meg. Egy táblázat tartalmazza az összes általunk létrehozott aldomaint. Az alsó részen lehetőségünk van regisztrálni aldomaineket a megfelelő mezők kitöltésével. Például ha az adott domainen például a valami.hu-n szeretnénk létrehozni egy valaki.valami.hu rekordot amely a mi ip címünkre mutat amely mondjuk a 123.45.67.89, abban az esetben a "MIT:" feliratú mezőbe írjuk a "valaki" szót, ezután válasszuk az A rekord típust, majd a "MIRE:" mezőbe írjuk be az IP címünket. Ezekután a létrehoz gombra kattintva létrejön a megadott rekord. Amennyiben egy aldomainre már nincs szükségünk, egyszerűen eltávolíthatjuk a sor végén lévő "Törlés" gombal.
1.5.
Beállítások
A Beállítások oldalon két lehetőségünk van. Az egyik a jelszó módosítása, amely első bejelentkezés után ajánlott, a másik pedig az e-mail címünk módosítása.
1.5.1.
Jelszó módosítása
A jelszó módosításához meg kell adnunk a régi jelszavunkat. Ezzel védjük a felhasználót, hogy esetlegesen másik személy módosítani tudja a jelszavát. Ezek után kétszer meg kell adnunk az új jelszót. A két jelszónak meg kell egyeznie, és legalább 6 karakteres kell hogy legyen. Amennyiben minden rendben zajlott a rendszer tudatja
- 24 velünk a jelszó frissítés sikerességét. 1.5.2.
E-mail cím módosítása
................ 1.6.
Kijelentkezés gomb
A kijelentkezés gomb segítségével megszüntethetjük az adott munkamenetet. Ez olyan esetekben lehet hasznos, hogy ha például publikus helyről jelentkeztünk be és az utánunk következő esetlegesen hozzáfér a felhasználónkkal a rendszerhez.
1.7.
IP cím frissítése
Az IP cím frissítés elvégezhető bármelyik internetről letöltött programmal, de az "ezipupdate" nevű script ajánlott amelyet a "http://ez-ipupdate.com/" lehet letölteni.
