VYSOKÁ ŠKOLA POLYTECHNICKÁ JIHLAVA Katedra elektrotechniky a informatiky Obor: Aplikovaná informatika
M o d u l p ro s p r á v u d o m é n p ro p ro g r a m ISPConfig bakalářská práce
Autor: Martin Škarabela Vedoucí práce: Mgr. Antonín Přibyl Jihlava 2012
Abstrakt Tato bakalářská práce se zabývá návrhem a implementací modulu registrace domén do hostingového ovládacího panelu ISPConfig. V modulu bude možné registrovat české, evropské a nadnárodní domény a zaregistrovat k nim příslušné kontakty. Dále bude možné prodloužit platnost domény a registrovat nového plátce. U českých domén bude možné provést transfer nebo změnit některé její vlastnosti. Modul bude napsán za pomocí jazyků HTML, PHP a přístup k databázi bude řešen jazykem MySQL.
Klíčová slova Hostingový ovládací panel, doména, doménový kontakt, DNS, webový server, HTML, PHP, MySQL
Abstract This bachelor thesis deals with design and implementation of the domain registration module for hosting control panel ISPConfig. In this module will be possible registration of Czech, European and international domains and registration of their appropriate contacts. It will also be possible to renew the domain and register a new payer. It will be possible to transfer Czech domains or update some of its properties. The module will be written using HTML, PHP languages and database access will be solved by MySQL language.
Keywords Hosting control panel, domain, domain contact, DNS, website, HTML, PHP, MySQL
Poděkování Rád bych zde poděkoval mému vedoucímu práce panu Mgr. Antonínu Přibylovi za poskytnuté odborné informace a podporu při zpracovávání této bakalářské práce.
Prohlašuji, že předložená bakalářská práce je původní a zpracoval/a jsem ji samostatně. Prohlašuji, že citace použitých pramenů je úplná, že jsem v práci neporušil/a autorská práva (ve smyslu zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů, v platném znění, dále též „AZ“). Souhlasím s umístěním bakalářské práce v knihovně VŠPJ a s jejím užitím k výuce nebo k vlastní vnitřní potřebě VŠPJ . Byl/a jsem seznámen/a s tím, že na mou bakalářskou práci se plně vztahuje AZ, zejména § 60 (školní dílo). Beru na vědomí, že VŠPJ má právo na uzavření licenční smlouvy o užití mé bakalářské práce a prohlašuji, že s o u h l a s í m s případným užitím mé bakalářské práce (prodej, zapůjčení apod.). Jsem si vědom/a toho, že užít své bakalářské práce či poskytnout licenci k jejímu využití mohu jen se souhlasem VŠPJ, která má právo ode mne požadovat přiměřený příspěvek na úhradu nákladů, vynaložených vysokou školou na vytvoření díla (až do jejich skutečné výše), z výdělku dosaženého v souvislosti s užitím díla či poskytnutím licence. V Jihlavě dne 24. 12. 2011 ...................................................... Podpis
Seznam zkratek ....................................................................................................... 38
9
Seznam použité literatury ....................................................................................... 39
10 Seznam obrázků ...................................................................................................... 41 11 Seznam tabulek ....................................................................................................... 42 12 Přílohy..................................................................................................................... 43 12.1
Obsah přiloženého CD ................................................................................. 43
12.2
Přístup k běžící aplikaci................................................................................ 43
1 Úvod Tato bakalářská práce se zabývá návrhem a implementací modulu do již existující webové aplikace řešící správu hostingových služeb. Vzhledem k faktu, že vývoji webových aplikací jsem se začal věnovat už od střední školy, domnívám se tedy, že v tomto oboru jsem díky vykonaným pracím, především na odborné praxi, nabyl četných zkušeností. Proto jsem se rozhodl uplatnit nabyté dovednosti při tvorbě bakalářské práce. Skutečnost, že podrobněji nahlédnu do fungování registrace a překladu doménových jmen moji volbu utvrdily. Cílem této práce je naimplementovat do aplikace ISPConfig modul řešící správu domén a to především českých, evropských a nadnárodních (com, org, net, info, biz, name). Správa domén bude řešena za pomocí aplikačního rozhraní Master API pro jazyk PHP od firmy General Registry s.r.o., díky kterému bude možné uvést webové stránky pod danou doménou ihned do provozu. V modulu bude možné každému uživateli registrovat kontakt pro domény, bude možné domény registrovat a prodloužit jejich platnost. U českých domén pak bude možné editovat jejich vlastnosti nebo provést jejich transfer. Při zřízení domény by se měla pro ni automaticky vytvořit DNS zóna na serveru vybraném skrze rozhraní ISPConfigu a volitelně by se potom měla zřídit webová stránka. Do aplikace bude zabudován kreditní systém, který bude kombinován s kreditním systémem Domain Masteru, čím by se měl vytvořit přehled o stavu kreditu jednotlivých uživatelů aplikace ISPConfig. V naimplementovaném modulu by se měl použít stejný způsob přístupových práv k manipulaci s doménou, jako se používá v samotné aplikaci. Daný systém přístupových práv by měl být dodržen i při registraci domény, čímž se dosáhne stejných možností manipulace s doménou osobami, které k tomu mají oprávnění i skrze aplikaci Domain Master spravovanou firmou General Registry s.r.o. Vzhled formulářů a tabulek by měl být vytvořen za pomoci značkovacího jazyka HTML. Funkcionalita modulu bude řešena skriptovacím jazykem PHP běžícím na straně serveru. Komunikace s databázovým prostorem bude nakonec řešena skrze jazyk MySQL.
8
2 Úvod do problematiky a vymezení cílů Provoz webové aplikace na internetu si vyžaduje mít založený server s nainstalovanou službou jakou je například Apache, který umožní naslouchat http požadavkům na portu 80. K takovému serveru se pak dá přistupovat pomocí veřejné IP adresy, přes kterou je server vidět. IP adresa je 32 bitové číslo, které se používá k identifikaci zařízení v síti. Adresa je rozdělena na čtyři 8 bitové části oddělené tečkou. Vzhledem k tomu, že člověk neumí udržet v paměti takovéto číslo, je třeba takovémuto číslo přiřadit textovou adresu, která je už pro člověka zapamatovatelná. Z toho vyplývají další problémy, které je pro provoz nutné vyřešit. Za prvé je třeba někde přeložit tuto webovou adresu na adresu IP. K tomu slouží DNS (Domain Name System). Za druhé je třeba, aby webová adresa našeho serveru byla unikátní, z toho plyne, že tuto adresu musím mít zaregistrovanou u registrátora, který spravuje druhou úroveň systému DNS.
2.1 DNS DNS je hierarchický decentralizovaný systém jmenných serverů sloužící k překladu doménových jmen na IP adresy a naopak. Hierarchická struktura systému DNS je stejná jako struktura doménového jména. [6] Každá koncová stanice v síti má ve své konfiguraci nastavenou adresu lokálního DNS serveru. Při dotazu na IP adresu dané domény se pak lokální DNS server na tuto doménu zeptá kořenového serveru. Kořenových serverů je celkem 13, jelikož kořenové servery jsou všeobecně známé, tak jejich adresy obsahuje každý lokální DNS server. Kořenový server danou adresu nezná, tak pošle lokálnímu DNS serveru seznam autoritativních serverů pro danou TLD. Jak je patrné z obrázku na straně 10, tak lokální DNS server opakuje dotaz k příslušným autoritativním serverům, na které ho odkazují nadřazené jmenné servery, tak dlouho, dokud nedostane v odpovědi IP adresu požadovaného doménového jména. Nakonec lokální DNS server pošle výsledek dotazu koncové stanici.
9
Obrázek 1: Proces překladu webové adresy na adresu IP
2.2 Proces registrace domén Samotná registrace domény není činnost, která jde provést jedním příkazem. Pro to, aby člověk byl schopný registrovat doménu, musí být zaregistrovány kontakty na osoby, kterých se tato registrace týká. V databázi se u domény, pak uchovává vlastník domény, plátce domény a technický správce. Vlastník domény (registrant) je osoba, která doménu zaregistrovala a má oprávnění s touto doménou nakládat. Údaje o této osobě se vedou v tzv. databázi WHOIS, o které se zmíním níže. Plátce domény je osoba, která za danou doménu platí. Tato informace se ale nemusí vyskytovat u všech záznamů domén. Zda tento údaj bude u konkrétního záznamu domény, pak záleží, přes kterého registrátora je doména zaregistrovaná. Některé firmy identitu svých zákazníků nezveřejňují.
10
Technický správce je osoba, která má na starosti provoz webových stránek pod danou doménou. Většinou jde o stejný typ kontaktu jako je vlastník domény, takže je možné, že vlastník může být zároveň i správce. U českých domén je třeba mít dále zaregistrovaný tzv. nsset, což je takový typ záznamu, který uchovává záznamy odkazující na autoritativní name servery spravující danou doménu. Zde je povinné nastavit minimálně dva jmenné servery. Uchovává se zde taktéž technický správce, což je ten samý kontakt, jak byl uveden výše.
2.2.1 Registr WHOIS WHOIS je v UNIXových systémech protokol, kterým se přistupuje k informacím o doménách z centrálního registru. Pozdější potřeba zobrazit tyto informace v ostatních operačních systémech vedla k založení webových WHOIS klientů. Pomocí WHOIS lze zjistit jakékoli informace o doméně nebo nssetu. Dále se zde uchovávají informace o kontaktech, u některých je pak možné nastavit, zda jsou veřejné nebo ne. Existence centrálního registru se dá zdůvodnit nejen zpřehledněním stavu registrace domén, ale i celkovým zvýšením bezpečnosti a důvěryhodnosti internetu. Z tohoto důvodu nelze uvádět při registraci jakéhokoli kontaktu falešné nebo zavádějící informace, pod hrozbou zrušení registrace dané domény. [2] V České Republice spravuje tento registr sdružení CZ.NIC.
2.3 Stanovení cílů Z výše nastíněné problematiky vyplývá, že výsledná aplikace by měla umět spravovat server, na kterém běží webové stránky, dále by měla umět spravovat DNS záznamy pro dané webové sídlo a nakonec by měla umět řešit veškerou funkcionalitu potřebnou pro správu doménových jmen u daného registrátora. Mimo těchto požadavků by měla takováto aplikace splňovat i mnoho dalších požadavků jako například správu firewallu, FTP atd., aby byla konkurenceschopná i dalším hostingovým ovládacím panelům. 2.3.1 Důvod vlastního řešení Na internetu existuje mnoho webových aplikací řešící správu domén a zároveň komplexní správu webového serveru. Problémem je fakt, že tyto aplikace jsou vytvořeny pro potřeby podnikání konkrétních registrátorských firem, tím pádem nejsou 11
dále distribuovatelné. Toto tvrzení zároveň utvrzuje fakt, že systém DNS je rozsáhlý strukturovaný strom na sebe odkazujících name serverů, které provozují tyto firmy. Vytvořit aplikaci spravující domény nezávisle na registrátorské firmě a bez jakéhokoli přístupu k name serverům ve vyšších patrech DNS hierarchie je prakticky nemožné. Z toho plyne skutečnost, že zatím neexistuje žádný hostingový ovládací panel, který řeší registraci domén a je zároveň dostupný pro jakéhokoli provozovatele hostingových služeb. 2.3.2 Volba vhodného ovládacího panelu Vzhledem k tomu, že implementace úplně nového ovládacího panelu splňujícího výše uvedené požadavky, je velice rozsáhlá a náročná činnost zabírající dlouhý časový úsek, jeví se jako nejefektivnější řešení implementace modulu správy doménových jmen do již hotového ovládacího panelu. Z toho vyplívá první problém a tím je volba vhodného ovládacího panelu, který by byl snadno rozšiřitelný. Na internetu již pár takových řešení existuje:
Plesk – komerční ovládací panel vyvinutý v Rusku, běžící na všech důležitých operačních systémech. Aplikace umožňuje spravovat z jediného prostředí více serverů a nezávisle na těchto serverech spravovat domény. Umožňuje vytvořit zákaznické účty s přidělenými právy. [9]
cPanel – proprietární ovládací panel fungující na operačních systémech Linux, BSD a Windows. Obsahuje příkazovou řádku a API přístup k automatizaci standardních systémových administračních procesů. [1]
ISPConfig – open source nástroj pro správu serveru fungující na systémech Linux. Jedná se o jedno z kvalitnějších řešení schopné do určité míry nahradit výše zmíněné ovládací panely. [10]
Z výše popsaných řešení se jako nejvhodnější jeví ISPConfig, protože tak odpadá nutnost vynaložení finančních nákladů za jeho užívání a je pod licencí BSD, která umožňuje jeho modifikaci. 2.3.3 Volba API pro registraci domén Jelikož aplikace má řešit správu domén je třeba zvolit vhodné API pro implementaci. API by mělo dostatečně řešit registraci, prodloužení domény, nesmí chybět i funkce 12
pro registraci potřebných kontaktů či Nssetu. Dále by API mělo obsahovat kreditní systém, díky kterému by operace jako registrace domény nebo její prodloužení měly být ihned úspěšně provedeny. Těmto požadavkům dostatečně vyhovuje Master API od firmy General Registry s.r.o. Toto API disponuje taktéž testovacím rozhraním, díky tomu není třeba během vývoje mít zaplacený kredit, aby bylo možné registraci či prodloužení domén testovat.
13
3 Popis struktury ve vztahu k vytyčeným cílům 3.1 Prostudování struktury a procesů aplikace ISPConfig Před započetím samotné implementace je vhodné prostudovat co se děje uvnitř aplikace, kterou chci rozšiřovat. Je třeba zjistit, jak je aplikace napsaná a jakou strukturu programování budu dodržovat. Musím znát hlavní strukturu databáze, v tomto případě tabulky, které v sobě mají data o registrovaných uživatelích aplikace a tabulky spojené se správou webového serveru. Aplikaci je taktéž vhodné prostudovat běžným užíváním neboli zkoušením funkcí podstatných z hlediska cílů mé práce. Je nutné pochopit samotný proces vytvoření a správy webových sídel, který se pouhým čtením zdrojového kódu nesnadno stává srozumitelným. Jednou z nejdůležitějších věcí je pochopit samotný systém uživatelských práv, protože tento systém bude aplikován do nového modulu správy domén. Níže uvedený diagram zobrazuje jednotlivé typy uživatelů, a jejich hierarchické zařazení v hostingovém ovládacím panelu ISPConfig.
Obrázek 2: Hierarchická struktura jednotlivých typů uživatelů
Jak je z výše uvedeného obrázku patrné v aplikaci ISPConfig existují tři typy uživatelů:
Admin – je správcem celého hostingového ovládacího panelu. Admin má přístup ke všemu, co je skrze tuto aplikaci nastaveno nebo vytvořeno.
Distributor (reseller) – může vytvářet nové uživatele (klienty), vytvářet nebo spravovat DNS zóny nebo webové sídla podřízených klientů.
14
Klient (běžný uživatel) – má omezená práva, může spravovat jenom to, co sám vytvoří.
3.2 Implementace 3.2.1 Úprava existujících modulů pro potřeby registrace domén V této fázi práce je třeba připravit samotnou aplikaci na existenci nového modulu. Zejména jde o možnost spravovat uživatelům kredit, mít přehled o jeho stavu nebo nastavit uživatelům TLD, které mohou spravovat. V neposlední řadě zde musí být možnost jak nastavit přihlašovací údaje k Domain Masteru, pomocí kterých se bude možné spojit s Master API serverem. 3.2.2 Vytvoření modulu správy domén Druhou fází implementace je samotná realizace cílů této práce. Nejdříve bude vytvořen nový modul a následně se do něj budu snažit co nejvíce a nejefektivněji zakomponovat funkce, které nabízí Master API. Určitě je třeba naimplementovat mimo samotnou registraci domén, také funkce, které jsou nezbytné pro její realizaci, zejména registraci doménového kontaktu a registraci NSsetu. Dále by zde neměly chybět funkce jako prodloužení, změna nebo transfer domény.
15
4 Analýza a návrh implementace V této části práce bych se chtěl zabývat kódovou a datovou strukturou aplikace ISPConfig. Především jaké jsou zde užité programovací jazyky, a jak je pro svou práci budu moci využít. U datové struktury bych chtěl rozebrat důležité databázové tabulky a způsob, jak tuto strukturu modifikovat pro potřeby modulu správy domén.
4.1 Užité programovací jazyky ISPConfig je aplikace napsaná v PHP, která z drtivé většiny pracuje na technologii AJAX, tím pádem zde odpadá možnost navigace v historii stránek. Z toho také plyne použití programovacích jazyků, o kterém se dále zmíním. 4.1.1 Užití PHP Jako skriptovací jazyk na straně serveru je zde použit PHP ve verzi 5. Pátá verze jazyka PHP se považuje jako přelomová hlavně díky nové možnosti, kterou v tomto jazyce bylo možno použít a tou byl objektově orientovaný přístup. Aplikace objektového modelování samozřejmě využívá, díky tomu je přehledná a snadno rozšiřitelná. Třídy
potřebné
pro
běh
aplikace
ISPConfig
jsou
umístěné
ve
složce
„/usr/local/ispconfig/interface/lib/classes“ (pozn.: toto umístění je platné pro linuxovou distribuci CentOS ve verzi 5.6, podstatná část této cesty k umístění souborů začíná až od složky ispconfig, dále budu užívat tuto úplnou cestu k souborům), kde hodlám taktéž nové třídy spojené se správou domén ukládat. V následující tabulce bych chtěl popsat hlavní třídy aplikace a jejich význam pro potřeby mé práce. Tabulka 1: Seznam důležitých tříd objektů Název třídy
Soubor
Popis
app
../app.inc.php
Jedná se o hlavní objekt, který v sobě drží informace o stavu běhu aplikace. Přes tento objekt přistupuji ke všem ostatním objektům majícím vliv na běh aplikace. Soubor třídy je jako jediný o složku navrch v adresářové struktuře.
16
auth
auth.inc.php
Tato třída má na starosti autentizaci. Jsou zde metody pro rozpoznání druhu uživatele a taktéž metoda pro řízení přístupu k modulům.
db
db_mysql.inc.php
Třída pro styk s bází dat. Aplikace sice
db_firebird.inc.php
využívá jen MySQL, ale kód je psán, tak že menší změnou v konfiguračním souboru lze používat databázi typu Firebird. Nicméně soubor s třídou pro práci s Firebirdem nemá pokryty
všechny
metody,
které
jsou
v souboru s MySQL, takže přechod mezi těmito databázemi není snadný. Každopádně je
třeba
s Firebirdem
počítat,
a
proto
k databázi přistupovat skrze metody této třídy. tform
tform.inc.php
Třída
sloužící
k propojení
formuláře
s příslušnou databázovou tabulkou. Vzhledem k tomu, že ne všechny akce související se správou domén mají svou databázovou tabulku, tak tuto třídu využívám hlavně především kvůli tomu, že má v sobě metodu pro validaci vstupních proměnných. tform_actions
tform_actions.inc.php
Tato třída v sobě obsahuje akce, které mohou u formuláře nastat, jako například „onShow“, „onSubmit“, „onInsert“, „onUpdate“ atd.
listform
listform.inc.php
Jedná se o třídu, která má na starosti zobrazení dat z databázové tabulky.
listform_actions
listform_actions.inc.php
Obdobně jako u třídy „tform_actions“, tato třída má na starosti akce typu „onLoad“ nebo „onShow“.
4.1.2 Jazyk pro styk s bází dat Primárním relačním databázovým jazykem je v této aplikaci MySQL. Jak již bylo zmíněno, aplikace by měla umět komunikovat i s databázovým systémem Firebird. 17
Vzhledem k tomu, že syntaxe jazyka MySQL je v některých případech odlišná syntaxi jazyka databázového systému Firebird, tak jsem se snažil sestavovat SQL dotazy pokud možno takové, aby byly použitelné na obou systémech. 4.1.3 Užití dalších programovacích jazyků Pro aplikaci ISPConfig zde hrají nemalou roli i další jazyky, které zde zmiňuji jen okrajově, jelikož do mé práce zasahovaly minimálně. Kaskádové styly, zkráceně CSS, je kolekce metod pro grafickou úpravu webových stránek. [8] Pomocí CSS stylů jsem zmenšil šířku o deset pixelů u záložek modulů v záhlaví aplikace, z důvodu přidání modulu správy domén. Bez této změny by tyto záložky byly rozhozeny na dvou řádcích a aplikace by působila nevzhledně. Jako skriptovací jazyk na straně klienta je zde použit Javascript. Vzhledem k faktu, že celá aplikace je AJAXového charakteru, tak skrze tento jazyk volám pouze funkce načítající obsah stránek a funkci pro odeslání formuláře. Při mazání domén s prošlou platností, zde používám funkci „confirm“ přes, kterou se ujišťuji, zda má být doména opravdu odstraněna z databázové tabulky. Nakonec je zde použit i jazyk XML určený pro serializaci dat. O jeho užití se zmíním později v popisu kreditního systému.
4.2 Adresářová struktura ISPConfig Jak již bylo naznačeno aplikace ISPConfig se dělí na moduly. Každý modul má svoji adresářovou reprezentaci ve složce „/usr/local/ispconfig/interface/web“, kde se nachází taktéž i zdrojový kód modulu. Každá složka pak má strukturu, kterou popisuje následující tabulka. Tabulka 2: Popis adresářové struktury modulu Adresář
Popis
/
V této kořenové složce modulu se nacházejí všechny hlavní soubory, tzn. soubory provádějící hlavní skripty jako například zobrazení tabulky domén nebo zaregistrování domény.
/templates
V tomto adresáři se nachází soubory typu *.htm takzvané šablony.
18
Šablony popisují vzhled a rozložení obsahu stránky. O šablonách se zmíním níže. Tento adresář obsahuje soubory s příponou *.list.php, které se
/list
používají jako definiční pro třídu „listform_actions“. Tyto soubory popisují, které sloupce z databázové tabulky budou zobrazeny ve výsledné tabulce. V této složce se nachází soubory pro konfiguraci hlavního menu
/lib
modulu. /lib/lang
Zde jsou umístěny soubory jazykových mutací.
/form
Zde se nachází soubory s příponou *.tform.php používající se jako definiční soubory pro třídu „tform_actions“. Tady se definují vstupní pole a jejich validátory, které se budou zapisovat do databázové tabulky.
4.2.1 Šablony Šablony jsou, jak jsem již uvedl, soubory pro určení rozmístění elementů na stránce. Jsou psány jazykem HTML, který je v této aplikaci doplněn o takzvané řídící značky. Mezi nejhlavnější řídící značky tu patří například „tmpl_if“, což je značka zastupující funkci větvení. Další důležitou značkou je zde „tmpl_var“, která slouží pro vypisování proměnných. Využití této značky spočívá hlavně především u jazykových mutací. Nástin užití těchto značek můžete vidět v následujícím útržku kódu.
Překlad takovéto šablony má v PHP na starosti třída „tpl“ za pomoci své metody „parse()“. Jak je z předchozí ukázky kódu zřejmé, proměnné jsou zde užity jak v podmínkách, tak pro výpis různých hodnot. Proměnné musí být před samotným překladem nastaveny v třídě „tpl“, to se provádí metodou „setVar($name, $value)“. 4.2.2 Jazykové mutace V aplikaci ISPConfig je zabudována podpora cizích jazyků. Každý modul má speciálně určený adresář pro jazykové soubory, jeho umístění popisuje Tabulka 2. Jazykové soubory, které se zde nachází, musí mít sice příponu *.lng, ale jedná se o soubory obsahující PHP kód. Každý soubor má ve svém názvu prefix o délce dvou znaků obsahující ISO zkratku jazyka, který soubor obsahuje. Každý soubor je tvořen asociativním polem, jehož indexy jsou zároveň slova, které se mají přeložit a hodnotou každého prvku pole je samotný překlad. O překlad slov se stará svými metodami „lng($text)“ a „load_language_file($filename)“ hlavní objekt „app“. Níže můžete vidět ukázku kódu jazykového souboru. 20
4.3 Popis Master API Master API je aplikační rozhraní pro registraci a správu domén, pomocí tohoto rozhraní je možné jedním HTTP požadavkem například zaregistrovat doménu. Příkazy a odpovědi jsou zde řešeny zasíláním zpráv ve formátu YAML, což se v PHP kódu projevuje jednoduchým a přehledným použitím asociativních polí. [3] Příklad takového příkazu můžete vidět v níže uvedené ukázce zdrojového kódu. $result = $spojeni->sendCommand("register cz nsset", array( "id"
), "report-level" => $nsset["report"] )); Za pomoci příkazů, jako je výše uvedený, se komunikuje se serverem Domain Master firmy General Registry s.r.o. Zda jsou tyto příkazy úspěšně provedeny, se pak zjišťuje funkcí „isSuccess()“. Dle typu příkazu pak server může vrátit podobné asociativní pole jako je ve výše uvedeném kódu. V celém Master API je zabudován kreditní systém, tak je možné zpoplatněné funkce, jako registrace domény provést s okamžitou platností. Z toho plyne fakt, že přes právě zaregistrovanou doménu se už můžu dostat k požadovaným webovým stránkám. Díky tomu můžu ve výsledné aplikaci rychle spravovat domény a případně reagovat na vzniklé události. Master API existuje ve dvou verzích produkční a testovací. Produkční Master API slouží pro správu domén naostro. Zatímco testovací prostředí slouží pro hrubé testování právě vyvíjených aplikací využívajících Master API.
21
4.4 Datová struktura Pro vytvoření funkčního modulu správy domén bude třeba taktéž zasáhnout do datové struktury aplikace ISPConfig. V této části rozeberu databázové tabulky, které budu přidávat a tabulky, které budu rozšiřovat o další sloupce. 4.4.1 Úprava stávajících tabulek Z hlediska registrace domén je třeba umožnit uživatelům, jako jsou administrátoři nebo reselleři (česky distributoři), spravovat výčet povolených domén (přesněji výčet povolených TLD) a kredit podřízeným uživatelům. Tyto dvě atributy jsou zakomponované v tabulce „client“, protože se v této tabulce už uchovávají limity daného uživatele. Tyto atributy jsou nenulového charakteru z důvodu nutnosti přesně určit, zda uživatel má dostatek kreditu k registraci domény a zda vůbec může doménu s danou TLD registrovat. Dále je třeba udržovat přihlašovací údaje plátce k systému Domain Master, aby bylo vůbec možné domény spravovat. Tyto údaje jsou přidány do tabulky „sys_user“, protože oproti tabulce „client“ tato tabulka v sobě uchovává také záznamy administrátorů. Z toho plyne, že všichni uživatelé, pokud nemají vlastní účet u firmy General Registry s.r.o., jsou přihlašování skrze účet administrátora, tím pádem daný administrátor je v záznamu domény veden jako plátce. V tabulce „sys_user“ jsou taktéž doplněny atributy, které drží identifikátory kontaktů pro registraci domén. Všechny uvedené atributy v tomto odstavci mohou být nulové, jelikož ne každý potřebuje v této aplikaci spravovat domény nebo nepotřebuje být veden u zaregistrovaných domén jako plátce. Na následujícím obrázku vidíte výčet všech modifikovaných tabulek a všechny atributy, které do nich byly přidány.
22
Obrázek 3: Nové sloupce v původních tabulkách
4.4.2 Návrh nových tabulek Pro registraci české domény je třeba mít zaregistrovaný NSset. Jelikož v Master API neexistuje, žádná funkce, která by vracela zaregistrované NSsety, je třeba tyto NSsety a jejich informace ukládat do tabulky. V této tabulce se drží atributy jako názvy name serverů, jméno NSsetu a id DNS serveru, na kterém se bude pro doménu s tímto NSsetem vytvářet DNS zóna. Jelikož se jedná zde o důležité atributy, jsou všechny nenulového charakteru. V Master API sice existuje funkce pro výpis zaregistrovaných domén, pro potřeby modulu správy domén to, ale nestačí. V tabulce, která uchovává záznamy zaregistrovaných domén, jsou hlavními atributy „userid“ díky, kterému můžu zjistit kdo všechno má oprávnění záznam vidět a „expire_date“, které je použito při operaci prodloužení domény. Atributy „dm_login“ a „expire_date“ mohu být nulové, jelikož nemají zásadní vliv a nevadí, když budou zapsány později. Poslední přidanou tabulkou je „dm_cenik“, který je použit pro kontrolu, zda daný uživatel má dostatečný kredit pro požadovanou operaci. Tabulka obsahuje atributy „popis“, „cena“ a „cena_dph“, které nemohou být nulové. Tabulka slouží jako prevence příliš častých neúspěšných dotazů, které by mohly zapříčinit zablokování přístupu přes daný účet u Domain Masteru. [4] Začlenění nových tabulek do databázového systému můžete vidět na následujícím obrázku.
23
Obrázek 4: E-R diagram nově vytvořených tabulek
24
5 Popis implementace V následujících řádcích popisuji způsob implementace modulu správy domén. Podrobně se snažím popsat jak kreditní systém, tak i vytvoření nového modulu v aplikaci a zpracování jednotlivých funkcí řešící správu domén.
5.1 Kreditní systém Aby byly jednotlivé funkce související se správou domén rychlé, je třeba mít v aplikaci zavedený kreditní systém. Jelikož ne každý uživatel používající aplikaci ISPConfig má zaveden u General Registry s.r.o. účet, tak jsem rozdělil kreditní systém na vnější a vnitřní. Vnitřní kreditní systém umožňuje administrátorovi nebo distributorům spravovat stav kreditu podřízeným uživatelům. Vnějším kreditním systémem se zde rozumí kreditní systém zavedený v aplikaci Domain Master, ke kterému přistupuji pomocí aplikačního programovacího rozhraní Master API. 5.1.1 Vnitřní kreditní systém a jeho správa Vnitřní kreditní systém byl vytvořen, za účelem spravování stavu kreditu u uživatelů, kteří nemají vlastní účet v Domain Masteru. Uživatelům, kteří mají tento účet samozřejmě stav kreditu lze upravovat, tito uživatelé mají pak dvojí kredit: vnitřní a vnější, čili ten, který mají na svém Domain Master účtu. Způsob jak se těmto uživatelům s dvojím kreditem odečítá kredit při platbě, vysvětlím níže. Ve vnitřním kreditním systému se kredit uchovává v databázové tabulce „client“ ve sloupci „kredit“ v záznamu příslušného uživatele. Spravovat vnitřní kredit lze dvěma způsoby: skrze příslušné pole v záložce „Limity“ při editaci uživatele nebo importem XML souboru. XML import může provádět jak administrátor, tak distributor s tím rozdílem, že distributor může tento import provést jen uživatelům, kteří jsou pod ním v systémové hierarchii. Pokud distributor zadá do importu soubor s informacemi o kreditu cizích uživatelů nebo dokonce svého kreditu, jsou tato data jednoduše ignorována a aktualizuje se kredit jen podřazeným uživatelům. Kredit se při importu každému uživateli přičítá k jeho zůstatku. Formát vstupního XML souboru používaného při importu můžete vidět v následujícím útržku kódu.
25
<username>test_client 1200 <username>test_client_2 1000 <username>test_reseller 8000 Ještě zde dodávám, že když distributor edituje podřízenému uživateli kredit, tak tento přidaný kredit se odečte od kreditu distributora. Tento odečet se provádí jak u editace skrze „Limity“ uživatele, tak i u XML importu. 5.1.2 Vnější kreditní systém Jak jsem již naznačil, vnějším kreditním systémem se zde myslí kreditní systém, který je zabudován v aplikaci Domain Master. Použití tohoto systému je úzce spojeno s použitím aplikačního programovacího rozhraní Master API a změny stavu kreditu jsou zde řešeny automaticky voláním funkcí Master API, které provádějí zpoplatněné operace jako je například registrace domény. K serveru Domain Master se skrze Master API připojuji svým uživatelským jménem a heslem, které jsou uloženy v databázové tabulce „sys_user“ ve sloupcích „dm_username“ a „dm_password“. Zda daný uživatel používá vnější kreditní systém skrze vlastní přihlašovací údaje, lze pak zjistit v této tabulce, tak že uživatel má ve svém záznamu v tabulce taktéž vyplněny tyto údaje. Nakonec zde ještě zmíním, že heslo je v databázi uloženo „nezahešované“, jelikož neexistuje žádná možnost přihlásit se k tomuto účtu pomocí „heše“ hesla.
26
5.1.3 Procesy kreditního systému při platbě Při veškerých platbách je nutno vědět skrze který Domain Master účet se bude platit a zda se to nějak promítne ve vnitřním kreditním systému. Řešení tohoto problému lépe vysvětluje Obrázek 5. Úplně první akce, která se provádí je načtení přihlašovacích údajů příslušného Domain Master účtu. To se provede pomocí funkce „connect()“, která automaticky vybere Domain Master účet daného uživatele, anebo jeho nadřazeného uživatele a potřebné informace o účtu uloží do proměnných v třídě objektu, která tuto platbu vykonává. Uložené informace se hned využijí v prvním větvení a to při otázce, zda načtený Domain Master účet je můj vlastní nebo ne. Pokud je tento účet můj vlastní, tak zde plyne další otázka, zda jsem běžný uživatel, nebo jsem administrátor. To zjistím pomocí hodnoty uložené v následujícím poli: $_SESSION["s"]["user"]["typ"]. Pokud jsem běžný uživatel, tak zde vyvstává poslední otázka, a tou je, jestli mi zbyl ve vnitřním kreditním systému kredit dostatečně velký na zaplacení následující operace. Pokud ano, tak pomocí funkce „connect_parent()“ se načtou přihlašovací údaje k Domain Master účtu nadřazeného uživatele (rodiče) a aktualizují se informace o použitém účtu v třídě objektu. Nakonec zde zmíním význam bloku „Proveď operaci“ na následujícím obrázku. Tímto blokem se rozumí jakákoli placená operace, například: registrace domény nebo prodloužení domény.
27
Obrázek 5: Vývojový diagram popisující platbu
5.2 Vytvoření nových tříd objektů Při implementaci modulu správy domén byly vytvořeny třídy objektů řešící určitou část operací. Tyto třídy se nacházejí mezi původními třídami objektů, v již dříve zmíněné složce „/usr/local/ispconfig/interface/lib/classes“. Celkem byly naimplementovány tři třídy objektů: 28
registruj_domenu – nachází se v souboru registruj_domenu.inc.php. Tato třída má na starosti operace nad doménou, jmenovitě to jsou: registrace domény, prodloužení platnosti domény, registraci NSsetu pro českou doménu, změna české domény a transfer české domény. Jelikož je tato třída jako jediná, která má v sobě placené operace nad doménami, je v ní naimplementován výše zmíněný algoritmus platby.
registruj_kontakt – nachází se v souboru registruj_kontakt.inc.php. V této třídě se řeší registrace kontaktu pro daný typ domény. Lze v ní registrovat kontakt pro českou doménu (cz), pro evropskou doménu (eu) a pro nadnárodní doménu (com, org, net, info, biz, name).
registruj_platce – je umístěna v souboru registruj_platce.inc.php. Tato třída řeší registraci nového plátce domény.
Všechny výše zmíněné třídy objektů mají v sobě naimplementovanou metodu pro navázání spojení s Master API serverem, na který jsou odesílány požadavky na provedení funkcí, jež tyto třídy řeší.
5.3 Modul domén Zde popíšu všechny kroky tvorby nového modulu a následně rozeberu všechny funkce správy domén. Prvním krokem pro tvorbu nového modulu je vytvoření potřebné adresářové struktury jak popisuje Tabulka 2. Adresář modulu se tedy nazývá „domains“, jelikož v aplikaci název „domain“ je už obsazen jiným modulem, který ale neřeší potřebnou správu domén. Následně se vytvoří ve složce „/lib“ soubor module.conf.php, v kterém je popsáno hlavní menu modulu a úvodní stránka modulu. Dále se do adresáře „/lib/lang“ vytvoří hlavní soubory potřebných jazykových mutací. Název hlavního souboru se skládá z ISO zkratky jazyka a přípony, například: en.lng nebo cz.lng. V těchto souborech se nachází především překlad hlavního menu modulu. Posledním nutným krokem je editace konfiguračního souboru config.inc.local.php. Do následujících proměnných: $conf["modules_available"] $conf["interface_modules_enabled"]
29
se nakonec přidá řetězec ",domains", díky tomu se dosáhne toho, že každý nově vytvořený uživatel už vidí nový modul v aplikaci. Stejný řetězec je třeba přidat každému již existujícímu uživateli, zejména administrátorům do tabulky „sys_user“ do sloupce „modules“. Díky tomu nový modul vidí i stávající uživatelé. 5.3.1 Seznam zaregistrovaných domén Za účelem přehledu právě zaregistrovaných domén, byl jako úvodní stránka modulu vytvořen seznam, který tyto domény zobrazuje. Hlavní soubor, ve kterém je hlavní kód tohoto seznamu má název „domains_list.php“ a nachází se v kořenovém adresáři modulu. Tento seznam můžete vidět na následujícím obrázku.
Obrázek 6: Snímek seznamu zaregistrovaných domén
Tento seznam je potřeba, jak pro přístup k dané české doméně aby ji bylo možné upravit, tak i pro přístup k doméně za účelem načtení formuláře prodloužení její platnosti. Aby nemusel být vytvořen dvakrát soubor s téměř totožným kódem, byl vytvořen jenom jeden soubor, který otevírám pomocí následujících URL adres:
30
"domains/domains_list.php?action=update", "domains/domains_list.php?action=renew". Která operace bude vykonána nad doménou po kliknutí na ní, určuje následující útržek kódu. switch ($_GET["action"]) { case "update": $app->tpl->setVar("action_path", "domena_update"); $_SESSION["s"]["domains_list"]["action_path"] = "domena_update"; break; case "renew": $app->tpl->setVar("action_path", "domena_renew"); $_SESSION["s"]["domains_list"]["action_path"] = "domena_renew"; break; default: if (isset($_SESSION["s"]["domains_list"]["action_path"])) { $app->tpl->setVar( "action_path", $_SESSION["s"]["domains_list"]["action_path"] ); } else { $app->tpl->setVar("action_path", "domena_update"); } }
Jak je vidět z předchozí ukázky kódu, po výběru operace nad doménou se nastaví proměnná šablony, která určuje název volaného souboru, který vykonává danou operaci. Dále je nastavena session, která zajistí, že při přepínání stránek seznamu domén bude pořád nastaven název požadovaného souboru (pro změnu domény nebo pro její prodloužení). 5.3.2 Registrace kontaktu a Nssetu Ještě před samotnou registrací domény musí mít všechny osoby, které mají něco společného s doménou (registrant, admin), zaregistrovaný kontakt pro daný typ domény (česká, evropská, nadnárodní). V této práci jsem se snažil jednotlivé kroky nutné pro správu domén zautomatizovat. Tím pádem bylo přidáno do formuláře tvorby 31
nového uživatele zaškrtávací políčko, které indikuje, zda se má aplikace pokusit automaticky zaregistrovat potřebné kontakty pro správu domén. Z toho vyplynula potřeba označit některé položky formuláře při tvorbě nového uživatele jako povinné a některým položkám přidat dodatečně potřebné validátory. V samotném modulu správy domén je taktéž vytvořen formulář pro zadání zaregistrovaných kontaktů pro případ, že uživatel už zaregistrovaný kontakt má. Pokud uživatel kontakty zadány nemá, objevuje se u příslušných kontaktů tlačítko odkazující na formulář pro tvorbu nového kontaktu. Pro potřeby registrace českých domén je třeba mít zaregistrovaný NSset, což je takový typ záznamu, který v sobě má uloženy kontakty administrátorů, adresy jmenných serverů a jejich glue adresy (IP adresy). V modulu správy domén byl proto vytvořen formulář pro registraci nového NSsetu, který ihned po úspěšné registraci uloží název NSsetu, doménové adresy jmenných serverů a identifikační číslo jmenného serveru do tabulky „nsset“. Tyto zaregistrované NSsety jsou přístupné při registraci české domény přes rolovací menu. 5.3.3 Registrace domény Modul správy domén používá jediný formulář pro registraci všech typů domén (české, evropské a nadnárodní), díky tomu je modul přehlednější. V tomto formuláři se vyskytují vstupní pole jako název domény, TLD, perioda (počet let registrace domény), klient (uživatel, který u domény bude veden jako registrant). Další vstupní pole se zobrazují v závislosti na typu domény. Pole NSset se zobrazuje jen u českých domén, zatímco adresy obou jmenných serverů a identifikační číslo jmenného serveru se zobrazují u evropských a nadnárodních domén. Jelikož je TLD umístěno v rolovacím menu, které při každé změně vyvolá znovu načtení formuláře, tak se výše uvedená vstupní pole zobrazují u správných typů domén. Při potvrzení formuláře se výše zmíněná vstupní pole odešlou na Master API server a pokud registrace proběhne úspěšně, tak
je doména uložena
do tabulky
„domain_registered“ a pro tuto doménu je na DNS serveru vytvořena nová zóna. Díky tomuto automatickému vytvoření DNS zóny odpadá nutnost tuto zónu ručně vytvářet po registraci domény. Ve formuláři registrace domén se taktéž vyskytuje zaškrtávací pole umožňující automatické vytvoření webových stránek pro právě zaregistrovanou doménu. Pokud je 32
toto políčko zaškrtnuté a registrace domény proběhla úspěšně, objeví se nový formulář umožňující nastavení hlavní konfigurace nově vytvořených webových stránek. Díky tomuto formuláři je možné ihned po registraci mít běžící webové stránky, které jsou viditelné v internetu. 5.3.4 Prodloužení a transfer domény Prodloužení platnosti domény je jednou z dalších funkcí správy domén. Master API potřebuje znát tři hodnoty: název domény, perioda a datum vypršení platnosti. Jelikož k formuláři prodloužení domény je přistupováno skrze seznam domén, pole názvu domény je předem vyplněné a neměnné. Datum vypršení platnosti je uchováváno ve vstupním poli typu hidden a je automaticky získáno z tabulky „domain_registered“. Uživateli tak stačí zadat pouze periodu (počet let), na kterou chce doménu prodloužit. Po úspěšném prodloužení platnosti domény je v příslušném záznamu v tabulce „domain_registered“ vymazán sloupeček „expire_date“, tento sloupeček je později automaticky vyplněn novým datem vypršení platnosti domény. Transfer domény je taková činnost, kdy dojde ke změně registrátora domény (neboli firmy pod kterou je doména zaregistrovaná). Z důvodu, že Master API umí provést transfer jen české domény, je v modulu správy domén transfer omezen jen na tyto české domény. V samotném formuláři pro transfer domény jsou pak vstupní pole jako název domény a rolovací menu, které určí, pod jakým uživatelem bude doména v aplikaci ISPConfig vedena. Posledním vstupním polem je auth-info kód, což je klíč k dané doméně a je důvěrným tajemstvím mezi vlastníkem a stávajícím registrátorem. [5] Při úspěšně
provedeném
transferu
domény se
tato
doména
vloží
do
tabulek
„domain_registered“ a „domain“ což je původní tabulka aplikace ISPConfig. 5.3.5 Změna domény Mezi funkcemi, které umožňuje Master API se také nachází změna české domény. Díky tomu lze u českých domén změnit keyset nebo NSset. Změny českých domén mohou provádět jen uživatelé, kteří mají svůj kontakt v záznamu domény, autorizace se provádí pomocí hesla příslušného kontaktu. Ve formuláři změny české domény se tak vyskytují rolovací menu se seznamem NSsetů, dále textové vstupní pole pro případ, že zaregistrovaný NSset není v databázi aplikace ISPConfig a nakonec vstupní pole
33
pro heslo příslušného kontaktu. Kontakt, který momentálně provádí změnu domény, je uložen ve skrytém poli. Snažil jsem se držet přístupová práva u změny domény, tak aby k této funkci byla stejná přístupová práva jako k ostatním funkcím v celé aplikaci ISPConfig. To znamená, aby mohli změnit doménu jak uživatelé, kteří ji zaregistrovali, tak jejich nadřazení distributoři nebo administrátoři. Příslušné kontakty musím tak posílat v poli administrátorů už při registraci domény, tím pádem po úspěšné registraci mohou s doménou zacházet všichni, kdo mají v této aplikaci na to právo. Pokud při změně domény dojde ke změně NSsetu, je třeba upravit všechny záznamy DNS, aby doména zůstala stále funkční. Zejména se jedná o záznamy s adresami jmenných serverů.
34
6 Výsledky testování Při vývoji nebo i při úpravě jakékoli aplikace je nutné ji průběžně testovat, zda je funkční a zda se v ní nevyskytují chyby. Při vývoji modulu správy domén do hostingového ovládacího panelu ISPConfig jsem tak samozřejmě postupoval. Nový modul jsem vyvíjel na virtuálním stroji s nainstalovaným operačním systémem CentOS 5.6. a všemi potřebnými službami, jako webový server, DNS server, MySQL databáze atd. Vzhledem k tomu, že registrace domény nebo prodloužení její platnosti jsou placené funkce, tak testování nového modulu probíhalo na testovacím Master API serveru, ke kterému mi byl zaveden přístup. Na testovacím Domain Master účtu, který mi byl zřízen, jsem měl nastaven kredit na 100 000 Kč, takže v testování aplikace jsem měl téměř neomezené možnosti. Testovací Master API sice běží s neaktuální databází zaregistrovaných domén, ale pro potřeby prvotního testování funkcí to stačí. Nicméně při testování některých funkcí využívajících Master API docházelo k chybám ze strany Master API serveru, jmenovitě u pokusu zaregistrovat nadnárodní kontakt a u pokusu zaregistrovat plátce. Tyto chyby nešly odstranit jinak než testováním na produkčním Master API serveru. Aplikace i s nově naimplementovaným modulem nyní běží (v době odevzdání bakalářské práce) na serveru s veřejnou IP adresou. Na tomto serveru byla otestována řada možných způsobů automatického získání IP adresy serveru, která je potřeba při registraci NSsetu nebo domény. Úplnému prověření by mělo dojít až ostrým nasazením, kdy se teprve může zjistit zda DNS servery v internetu směrují správně na právě zaregistrovanou doménu.
35
7 Závěr Cílem této bakalářské práce bylo vytvořit modul správy českých, evropských a některých nadnárodních domén do hostingového ovládacího panelu ISPConfig, který se používá pro konfiguraci webových serverů. Tento modul by umožňoval jak jejich registraci, tak jejich prodloužení nebo změnu. Tyto cíle se mi i přes občasné problémy nakonec podařilo z větší části splnit. Aplikace je dle mého názoru nyní schopná nasazení. Hlavní činnost aplikace, která se týká registrace domény, byla zde doplněna o automatické vytvoření DNS zóny a možnost automatického vytvoření webových stránek pro danou doménu. Díky tomu je možné pod nově zaregistrovanou doménou mít už běžící webové stránky. Aktuálnost DNS záznamů v zóně jsem se taktéž snažil držet i po případné změně NSsetu české domény. Modul se tak v rámci svých možností snaží usnadnit uživatelům práci. Při implementaci tohoto modulu se mi podařilo provést pár úkonů, které nebyly vyloženě nutné pro správnou funkci celé aplikace. Jejich naprogramováním si myslím, že se mi povedlo udržet celkovou aplikaci na slušné úrovni. Například modul správy domén jsem vytvořil ve dvou jazykových mutacích: anglické a české. Česká jazyková mutace byla vytvořena z důvodu, že se jedná o modul spravující především české domény. Anglická verze byla vytvořena především proto, že je to primární jazyk aplikace ISPConfig a skrze tuto jazykovou mutaci lze doplňovat chybějící překlady i v jiných jazykových mutacích. Také jsem do přehledových tabulek uživatelů aplikace přidal informaci o stavu jejich kreditu. Především významným krokem zde bylo doplnění možnosti filtrovat kredit v určitém rozsahu, což předchozí aplikace neumožňovala. Stav kreditu se uživatelům zobrazuje po přihlášení na nástěnce. Nakonec jsem i přidal možnost automatického registrování kontaktu pro doménu při tvorbě účtu nového uživatele, což může mírně urychlit uživatelům aplikace práci. I přes všechny úspěšně splněné cíle, se v této práci objevuje pár nedostatků, kterým určitě stojí za to věnovat pozornost. Modul správy domén jsem vyvíjel v ISPConfig verze 3.0.3, nyní ale je už vydána verze 3.0.4.1 s podporou virtuálních serverů. Při implementaci tohoto modulu jsem zasahoval i do původních zdrojových kódů samotné aplikace. Z toho plyne, že modul není snadno přenositelný mezi verzemi této aplikace. Myslím si, že rozšířit tento modul o podporu virtuálních serverů není špatný 36
nápad. Modul správy domén je nyní ve stavu, že umí pracovat pouze s IP adresami verze 4. Vzhledem k tomu, že adresy pod tímto protokolem vstoupily do fáze vyčerpání, začíná na scénu pomalu nastupovat protokol IP verze 6. [7] Právě proto si myslím, že i zde by se měla tomuto protokolu věnovat pozornost formou doplnění do tohoto modulu.
37
8 Seznam zkratek
AJAX – Asynchronous Javascript And XML – webová technologie umožňující změnit obsah stránky bez nutnosti jejího znovunačtení.
API – Application Programming Interface – rozhraní určené pro programování aplikací.
BSD – Berkeley Software Distribution – licence svobodného software.
CSS – Cascade Style Sheet
DNS – Domain Name System
HTML – HyperText Markup Language – značkovací jazyk určený k psaní webových stránek.
HTTP – HyperText Transfer Protocol – internetový protokol pro přenos hypertextových dat.
IP – Internet Protocol
ISO – International Organization for Standardization
NSset – Name Server Set – záznam uchovávající sadu jmenných serverů a jejich informací.
PHP – PHP: Hypertext Preprocessor
TLD – Top Level Domain – doména nejvyššího řádu.
URL – Uniform Resource Locator – jednotný lokátor zdrojů informací.
XML – eXtensible Markup Language – jazyk pro serializaci dat.
YAML – YAML Ain’t Markup Language - jazyk pro serializaci dat.
38
9 Seznam použité literatury [1] CPanel. In Wikipedia : the free encyclopedia [online . St. Petersburg (Florida) : Wikipedia Foundation, 3 December 2004, last modified on 5 December 2011 [cit. 201112-06 . Dostupné z WWW: . [2] CZ.NIC [online]. 2011-10-01 [cit. 2011-12-01]. Pravidla registrace doménových jmen v ccTLD .cz. Dostupné z WWW: . [3] Domain Master [online]. [2008?] [cit. 2011-12-17]. Master API. Dostupné z WWW: . [4] Domain Master [online]. [2008?] [cit. 2011-12-17 . Penaltový systém. Dostupné z WWW: . [5] Domain Master [online]. [2008?] [cit. 2011-12-27 . Transfer cz domény. Dostupné z WWW: . [6] Domain Name System. In Wikipedia : the free encyclopedia [online]. St. Petersburg (Florida) : Wikipedia Foundation, 15. 6. 2004, last modified on 18. 7. 2011 [cit. 201112-06 . Dostupné z WWW: . [7 FILIP, Ondřej. .blog [online]. 2011-02-01 [cit. 2011-12-18 . Fáze vyčerpání už začala. Dostupné z WWW: . [8 JANOVSKÝ, Dušan. Jak psát web [online]. 1998 [cit. 2011-12-16]. CSS styly úvod. Dostupné z WWW: . ISSN 18010458. [9] KOPECKÝ, Lubor. ITBIZ [online]. 2010-08-23 [cit. 2011-12-06]. Co je Plesk. Dostupné z WWW: . ISSN 1802-1581. [10] POLZER, Jan. Maxiorel.cz [online]. 2010-08-16 [cit. 2011-12-25]. ISPConfig: open source alternativa k nástrojům cPanel nebo Plesk. Dostupné z WWW:
39
. ISSN 1802-470X.
40
10 Seznam obrázků Obrázek 1: Proces překladu webové adresy na adresu IP .............................................. 10 Obrázek 2: Hierarchická struktura jednotlivých typů uživatelů ..................................... 14 Obrázek 3: Nové sloupce v původních tabulkách .......................................................... 23 Obrázek 4: E-R diagram nově vytvořených tabulek ....................................................... 24 Obrázek 5: Vývojový diagram popisující platbu ............................................................ 28 Obrázek 6: Snímek seznamu zaregistrovaných domén .................................................. 30
41
11 Seznam tabulek Tabulka 1: Seznam důležitých tříd objektů .................................................................... 16 Tabulka 2: Popis adresářové struktury modulu .............................................................. 18
42
12 Přílohy 12.1 Obsah přiloženého CD Na přiloženém CD se nachází kompletní zdrojový kód této práce, dva instalační soubory a soubor readme.txt obsahující stručný postup instalace. Pro úspěšné nainstalování modulu správy domén do aplikace ISPConfig 3.0.3.3, tak stačí spustit oba instalační soubory a řídit se instrukcemi napsaných v souboru readme.txt. Součástí tohoto CD je taktéž instalační balíček hostingového ovládacího panelu ISPConfig ve verzi 3.0.3.3.
12.2 Přístup k běžící aplikaci Tato aplikace je v době odevzdání bakalářské práce taktéž dostupná na internetu pod adresou http://195.113.207.172:8080. Přihlašovací údaje jsou na přiloženém CD.
