Webové rozhraní pro administraci DNS serveru. Pavel Vachek

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů

Bakalářská práce

Webové rozhraní pro administraci DNS serveru Pavel Vachek

Vedoucí práce: Ing. Miroslav Bureš, Ph.D.

Studijní program: Softwarové technologie a management, Bakalářský Obor: Web a multimedia 27. května 2010

iv

v

Poděkování Touto cestou bych rád poděkoval celé rodině za velkou morální podporu při studiu, a také panu Ing. Miroslavu Burešovi za mnoho výborných rad a také za čas strávený na mé práci.

vi

vii

Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 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ů (autorský zákon).

V Praze 24. 5. 2010

.............................................................

viii

Abstract This thesis explains the basic principles of operation of the DNS system, possible attacks on it and maps the most commonly used DNS servers. The main part of the thesis is a creation of a simple administrative interface to one of the most widely used DNS servers - PowerDNS. The modern development methodology was used in its development. Everything is written in a young, dynamic programming language Ruby, which is focused on simplicity of writing the web applications and on productivity. Several chapters are also devoted to this language and its most popular framework Ruby on Rails, explaining its basic functionality and philosophy.

Abstrakt Tato práce vysvětluje základní principy fungování DNS systému, možné útoky na něj a mapuje nejpoužívanější DNS servery. Stěžejní část práce je vytvoření jednoduchého administračního rozhraní k jednomu z nejpoužívanějších DNS serverů jménem PowerDNS. Při vývoji jsou použity moderní metodiky vývoje. Vše je napásno v mladém, dynamickém programovacím jazyku Ruby, který je zaměřen na jednoduchost psaní webových aplikaci a na produktivitu. Tomto jazyku a jeho nejpopulárnějším frameworku Ruby on Rails je také věnováno několik kapitol, kde vysvětluji základní filozifii a fungování.

ix

x

Obsah 1 Úvod

1

2 Teoretický úvod 2.1 Co je to DNS? . . . . . . . . . . . . . . . . . . . . . 2.1.1 Jak funguje DNS? . . . . . . . . . . . . . . . 2.1.1.1 Konkrétí případ . . . . . . . . . . . 2.1.1.2 Autoritativní server . . . . . . . . . 2.1.1.3 Rekurzivní server . . . . . . . . . . . 2.1.2 Typy záznamů . . . . . . . . . . . . . . . . . 2.2 Útoky na DNS servery . . . . . . . . . . . . . . . . . 2.2.1 DNS Cache Poisoning . . . . . . . . . . . . . 2.2.1.1 Obecně . . . . . . . . . . . . . . . . 2.2.1.2 Útok podle pana Dana Kaminského 2.2.2 DNSSEC . . . . . . . . . . . . . . . . . . . . 2.3 Nejpoužívanější DNS servery . . . . . . . . . . . . . 2.3.1 BIND . . . . . . . . . . . . . . . . . . . . . . 2.3.2 PowerDNS . . . . . . . . . . . . . . . . . . . 2.3.3 djbdns . . . . . . . . . . . . . . . . . . . . . . 2.3.4 MyDNS . . . . . . . . . . . . . . . . . . . . . 2.3.5 NSD . . . . . . . . . . . . . . . . . . . . . . . 2.4 PowerDNS . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 Funkce a návrh PDNS . . . . . . . . . . . . . 2.5 Ruby-on-Rails . . . . . . . . . . . . . . . . . . . . . . 2.5.1 Co je to Ruby-on-Rails? . . . . . . . . . . . . 2.5.2 Kde a kdy ROR vzniklo? . . . . . . . . . . . 2.5.3 Balíčkovací systém RubyGems . . . . . . . . 2.6 MVC architektura . . . . . . . . . . . . . . . . . . . 2.6.1 Model . . . . . . . . . . . . . . . . . . . . . . 2.6.2 Controler . . . . . . . . . . . . . . . . . . . . 2.6.3 View . . . . . . . . . . . . . . . . . . . . . . . 2.7 Agilní vývoj . . . . . . . . . . . . . . . . . . . . . . . 2.7.1 Co jsou agilní metodiky vývoje software ? . . 2.7.2 Proč agilně ? . . . . . . . . . . . . . . . . . . 2.7.3 TDD . . . . . . . . . . . . . . . . . . . . . . . 2.7.3.1 Problémy TDD . . . . . . . . . . . .

xi

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 3 3 4 5 5 5 6 6 6 7 7 7 8 8 8 8 8 8 9 9 9 10 10 11 11 11 11 12 12 12 13 13

xii

OBSAH

2.7.4 2.7.5

BDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Continuous Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Analýza a návrh řešení 15 3.1 Existující řešení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2 Znovu a lépe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.3 Použité technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4 Realizace 4.1 Grafický návrh . . . . . . . . . . . . . . . . . . . . . 4.1.1 Zvolené barvy aplikace . . . . . . . . . . . . . 4.1.2 Zdroje použitých obrázků . . . . . . . . . . . 4.1.3 Ukázka grafickách návrhů . . . . . . . . . . . 4.1.3.1 První grafický návrh . . . . . . . . . 4.1.3.2 Konečný grafický návrh . . . . . . . 4.2 Kódování . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Kompatibilita s prohlížeči . . . . . . . . . . . 4.2.2 Dodržení standardů . . . . . . . . . . . . . . 4.2.3 Použité aplikace . . . . . . . . . . . . . . . . 4.2.4 Tisk . . . . . . . . . . . . . . . . . . . . . . . 4.3 Implementované funkce . . . . . . . . . . . . . . . . . 4.3.0.1 Rozdělení uživatelských rolí a práv . 4.3.0.2 Vlastní šablonovací systém pro DNS 4.4 Aplikační server . . . . . . . . . . . . . . . . . . . . . 4.5 Databázová vrstva . . . . . . . . . . . . . . . . . . . 4.6 Verzovací systém . . . . . . . . . . . . . . . . . . . . 4.6.1 Popis GITu . . . . . . . . . . . . . . . . . . . 5 Testování 5.1 Úvod do testování . . . . . . . . . 5.2 Uživatelské Testování aplikace . . . 5.2.1 Kvalitativní . . . . . . . . . 5.2.2 Kvantitativní . . . . . . . . 5.3 Kognitivní průchod . . . . . . . . . 5.4 Testování použitelnosti . . . . . . . 5.4.1 Ukázka testvacího scénáře . 5.4.2 Instrukce pro testera . . . . 5.5 Výsledky testů a provedené změny 5.6 Testování aplikace v Ruby-on-Rails 5.6.1 Unit testing . . . . . . . . . 5.6.2 Functional Tests . . . . . . 5.6.3 Integration Testing . . . . . 5.6.4 Continuous Integration . . . 5.7 Vyhodnocení výsledků testování . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

17 17 17 17 17 17 17 19 19 20 20 20 20 20 21 21 21 22 23

. . . . . . . . . . . . . . .

25 25 25 25 25 25 26 26 27 27 28 28 28 30 30 30

OBSAH

xiii

6 Závěr 31 6.1 Další možné plány vývoje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Literatura

33

7 Seznam použitých zkratek

35

8 Instalační a uživatelská příručka 8.1 Úvod . . . . . . . . . . . . . . . 8.1.1 Instalace . . . . . . . . . 8.1.2 Závislosti aplikace . . . 8.1.3 Spuštění serveru . . . .

37 37 37 37 38

9 Obsah přiloženého CD

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

39

10 Přílohy 41 10.1 Unit, functional a integrations tests . . . . . . . . . . . . . . . . . . . . . . . . 41 10.2 Continuous integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

xiv

OBSAH

Seznam obrázků 2.1 2.2

Grafické znázornění rozdělení domén . . . . . . . . . . . . . . . . . . . . . . . Grafické znázornění útoku (zdroj:[7]) . . . . . . . . . . . . . . . . . . . . . . .

3.1

Screenshot z úvodní stránky aplikace PowerAdmin . . . . . . . . . . . . . . . 16

4.1 4.2 4.3 4.4

První grafický návrh aplikace . . . . . . . . . . . Výsledná grafická verze aplikace . . . . . . . . . . Výsledná grafická verze aplikace i s ikonama . . . Aplikační server Webrick - zpracování požadavku

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

18 18 19 21

5.1 5.2 5.3 5.4

Unit test - testování validace správného doménového jména . . . Unit test - testování validace nesprávného doménového jména . . Integrační test - Ověření vytvoření domény a zobrazení formuláře Integrační test - inicializace (HTTP Auth přihlášení) . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

29 29 29 30

8.1

Start aplikačního serveru Webrick . . . . . . . . . . . . . . . . . . . . . . . . . 38

10.1 10.2 10.3 10.4 10.5 10.6 10.7 10.8

RoR - Unit tests - úspěšný průchod . . . . . . . . . . . . . . . . . . . RoR - Functional tests - úspěšný průchod . . . . . . . . . . . . . . . RoR - Integration testing - úspěšný průchod . . . . . . . . . . . . . . RoR - Functional tests - selhaný test . . . . . . . . . . . . . . . . . . Continuous integration - průběh sestavování testů . . . . . . . . . . . Continuous integration - testování selhalo (chybná verze Rails) . . . Continuous integration - build neprošel testy . . . . . . . . . . . . . . Continuous integration - build prošel testy + výpis posledních buildů

xv

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

4 7

41 42 42 42 43 43 44 45

xvi

SEZNAM OBRÁZKŮ

Seznam tabulek 2.1

Příklad zónového souboru domény "domain.tld" . . . . . . . . . . . . . . . . .

xvii

5

xviii

SEZNAM TABULEK

Kapitola 1

Úvod Fungování DNS systému v dnešní době všichni vnímáme jako něco naprosto samozřejmého, respektivě si spíše myslím, že málokdo vůbec ví, že něco takového vůbec existuje, natož pak jak tento systém funguje. A to právě díky tomuto systému se nám tak lehce surfuje na celosvětové síti zvané internet. Tato práce vysvětluje základní principy fungování DNS systému, možné útoky na něj a mapuje nejpoužívanější DNS servery. Stěžejní částí mé práce je vytvoření jednoduchého administračního rozhraní k jednomu z nejpoužívanějších DNS serverů jménem PowerDNS. Jako motivace této byla má vlastní zkušenost z absence kvalitního, lehce použitelného a snadno ovladatelného rozhraní. Při vývoji jsou použity moderní metodiky vývoje. Vše je napsáno v mladém, dynamickém programovacím jazyce Ruby, který je zaměřen právě na jednoduchost psaní webových aplikaci a na produktivitu. Tomto jazyku a jeho nejpopulárnějším frameworku Ruby on Rails je také věnováno několik kapitol, kde vysvětluji základní filozifii a fungování. Pevně věřím, že se mi povedlo splnit stanovený cíl a výsledkem je snadno instalovatelná, přehledná a lehce použítelná webová aplikace.

1

2

KAPITOLA 1. ÚVOD

Kapitola 2

Teoretický úvod Rozhodl jsem se implementovat jednoduché, ale přitom funkcemi neomezené webové rozhraní k administraci PowerDNS serveru. Co je to DNS, PowerDNS, jaké jsou nové a moderní metodiky vývoje především webových aplikací a v jaké programovcím jazyce jsem se rozhodl program napsat Vám vysvětlím v následujících kapitolách. Jako první bych ale rád vysvětlil, co bude výsledkem mé práce. PowerDNS je funkční a velice dobře napsaný DNS server. Jediné co mu dle mého názoru chybí je přehledné administrační rozhraní, podotýkám ze myslím webové administrační rozhraní. Aplikaci jsem se rozhodl napsat v poměrně mladém, moderním jazyce Ruby a jeho nejpopulárnějším frameworku Ruby-on-Rails. Nejsem sice nijak extra zdatný programátor, né všichni přeci musíme být, ale toto pro mě byla výzva. Už jen proto, že bych rád trochu hlouběji pronikl do Ruby potažmo do Ruby-on-Rails (dále už jen RoR). V RoR se klade velký důraz na testování, proto se také v kapitole 5 i v dalších zabývám problematikou testování aplikace a ukazuji zde použití na mé práci.

2.1

Co je to DNS?

Je to zkratka z anglických slov Domain Name System, což v překladu znamená „systém doménových jmem“. Je to hierarchický systém doménových jmen, realizovaný pomocí DNS serverů a také stejnojmenným protokolem. Hlavním úkolem systému DNS jsou převody doménových jmen na IP a také zpátky (reverzní záznamy). Protokol DNS používá podle RFC1035 porty TCP/53 a UDP/53.

2.1.1

Jak funguje DNS?

Prostor doménových jmen tvoří strom. Každý uzel tohoto stromu pak obsahuje informace o jeho další části (toto vše má vždy přiřazeno od své rodiče, tedy od nadřízené domény). Kořenem stromu je kořenová doména, zapisuje se pouze jako tečka. O úroveň níže jsou domény nejvyšší úrovně (TLD), které jsou rozděleny do skupin podle tématu. Jsou buďto národní/státní domény, například cz pro Českou republiku, sk pro Slovenskou republiku, atd. Dále jsou pak podle typu použití, například com pro komerční použití, org pro neziskové organizace, edu pro vzdělávací organizace, atd.

3

4

KAPITOLA 2. TEORETICKÝ ÚVOD

Obrázek 2.1: Grafické znázornění rozdělení domén

Celý doménový strom je rozdělen do několika zón o které pak starají jeho správci, kteří o zónách poskytují autoritativní informace. Toto je veliká výhoda DNS systému. Díky tomuto rozdělení je možné určitou část domény svěřit někomu dalšímu, který se o dané subdomény (zóny) bude starat. 2.1.1.1

Konkrétí případ

Jako výborný konkrétní příklad zde mohu uvést, nám všem jistě velice známou, doménu ČVUT, tedy cvut.cz. Vlastník domény je ČVUT a její hlavní DNS (ze SOA záznamu) je nameserver: ns.cvut.cz. Doména je dále rozdělena na mnoho subdomén, jako příklad zde uvedu tři subdomény: sh.cvut.cz klub Silicon Hill (o její další subdomény se stará NS ns.sh.cvut.cz) fel.cvut.cz Elektrotechnická fakulta (o její další subdomény se stará NS ns1.fel.cvut.cz) fs.cvut.cz Fakulta architektury (o její další subdomény se stará NS fw.fa.cvut.cz) Z tohoto příkladu by tedy mělo být hned jasné, že vhodné rozdělení domény může vést nejen k dobré orientaci, kde se právě nacházíme, ale také to ulehčuje práci správcům, kteří o jednotlivé záznamy domén starají.

2.1. CO JE TO DNS?

@

www www subdomain 1

IN IN IN IN IN IN IN IN IN

SOA NS NS MX MX A AAAA CNAME PTR

5

ns1.domain.tld. root.domain.tld. (200605140 1h 5m 1w 1d) ns1.domain.tld ns2.domain.tld 10 mailserver.domain.tld 20 mailserver2.domain.tld 10.0.0.1 2001:718:1c01:1:02e3:7eff:fc33:acb3 www www.domain.tld

Tabulka 2.1: Příklad zónového souboru domény "domain.tld" 2.1.1.2

Autoritativní server

Autoritativní server odpovídá na dotazy ohledně domén, o které se stará a pro které je tedy autoritativní. Neodpovídá na žádné jiné. Autoritativní server vždy bere nejnovější informace z databáze, není zde tedy možné server jakkoliv obelstít nebo zmást (viz kapitola o podvržení odpovědí). 2.1.1.3

Rekurzivní server

Tento server odpovídá na všechny ostatní dotazy. Tzn. na dotazy na domény pro které není autoritativní. Sám nemá žádné informace a k odpovědím vždy využívá dalších autoritativních serverů, kterých se dotazuje.

2.1.2

Typy záznamů

Zde uvádím seznam nejčastěji použývaných DNS typů záznamů, všechny jsou implementovány do mojí práce. A (IPv4 address record) definuje IPv4 adresu pro dané doménové jméno (převod domény na IP adresu) AAAA (IPv6 address record) definuje IPv6 adresu pro dané doménové jméno CNAME (canonical name record) definuje alias pro již definované doménové jméno MX (mail exchange record) definuje poštovní server a jeho prioritu pro danou doménu NS (name server record) definuje DNS server pro danou doménu PTR (pointer record) speciální typ záznamu, definuje záznam pro reverzní zónu (převod z IP adresy na doménu) SOA (start of authority record) definuje primární DNS server, emailovou adresu správce, sériové číslo a další časové údaje pro danou doménu

6


Glue záznam, neboli tzn. slepovací záznam je speciální použití A záznamu, který nám určuje IP adresu jmenného serveru, který se o danou doménu stará. Je to jediná vyjímka, kdy ma nadřazený DNS server jakékoliv údaje o serveru podřízeném.

2.2

Útoky na DNS servery

Existuje mnoho typů útoků na DNS. Mezi nejznámější je právě typ útoku DNS Cache Poisoning.

2.2.1 2.2.1.1

DNS Cache Poisoning Obecně

DNS Cache Poisoning funguje na principu podvržení odpovědí DNS serveru. DNS server se zeptá na informace o dané doméně a dostane falešné informace. Tím je možné například podstrčit jinou IP adresu a dostat tak uživatele na falešný web. Takovéto weby někdo vytváří většinou za účelem neoprávněně získat přihlašovací údaje, například do internetového bankovnictví, nebo údaje o platební kartě. Je několik způsobů, kterými zde DNS povrdhnout, spoléhá se na tyto vlastonosti protokolu DNS. • dotazování do DNS je opatřeno tzv. Transaction ID, což je 2-bitové číslo, je tedy pouze konečný počet kombinací, a to přibližně 65 tisíc • stará a neupdatované servery používají pro všechny dotazy stejný zdrojový port, proto se tedy doporučuje updatovat vždy na nejnovější stabilní verzi • pro dotazování se používá UDP protokol, který je bezstavový a je tedy velice lehké podvrhnout zdrojovou IP adresu Na útočníkovi je nyní, aby uhodl Transaction ID, a nebo všechny možné varianty vyzkoušel (metoda hrubou silou), ale musí je poslat velmi rychle za sebou, aby odpověd přišla ještě v časovém limitu, který je pro odpověd stanoven. A dále také musí odpověd od útočníka přijít dříve, než od pravého autoritativního DNS serveru. Tento útok je velice problematický, a to především z časového hlediska. Musí se totiž čekat, dokud dotazujícímu serveru nevyprší záznam ve vyrovnávací paměti a poté se bude muset zeptat autoritativního serveru. Všechny záznamy jsou uloženy ve vyrovnávací paměti po dobu, která je uvedena v TTL daného záznamu. Šance tohoto útoku na úspěch jsou tedy velice malé, je to 1 ku 65 tisícům. A to je jen pro tipnutí Transaction ID, pak ještě je potřeba tipnout čas a trefit se do správného časového okna, celkově jde tedy říct, že tato metoda není moc reálná, čí přinejmenším je velice nepravděpodobná.

2.3. NEJPOUŽÍVANĚJŠÍ DNS SERVERY

7

Obrázek 2.2: Grafické znázornění útoku (zdroj:[7])

2.2.1.2

Útok podle pana Dana Kaminského

Pan Dan Kaminsky odhalil, že je možné najít způsob, kdy není potřeba čekat na to, až se server zeptá na "čerstvá" data, a tedy až mu vyprší data uložená ve vyrovnávací paměti. Útočník se při tomto typu útoku neptá na konkrétní IP adresu webového serveru. Ptá se na úplně libovolný, například i náhodně vygenerovaný, neexistující záznam a podvrhne IP adresu pomocí sekce AUTHORITATIVE a ADDITIONAL pomocí GLUE záznamu (viz. 2.1.2). Existuje pouze jedno řešení, které DNS server před touto metodou ochrání a je to technologie DNSSEC (vice v kapitole 2.2.2)

2.2.2

DNSSEC

Jedná se o rozšíření DNS, které slouží ke zvýšení bezpečnosti. Díky DNSSECU si můžete být jisti, že veškerá data jsou poskytnuta tím správným serverem a že se Vás nikdo nesnaží napadnout. Kontroluje se, zda nebyla napadnutá integrita dat při přenosu, můžete si tak být jisti důvěrnosti údajů od DNS serveru.

2.3

Nejpoužívanější DNS servery

Zde uvádím seznam těch nejpoužívanějších DNS serverů. Nebudu se zde s nimi zabývat nijak podrobně, jen je lehce představím a uvedu o nich základní informace.

8

2.3.1


BIND

BIND (viz [1]) je jeden z nejstarších DNS servrerů. Jeho jméno je zkratka „Berkeley Internet Name Domain“, to proto, že byl původně vytvořen studenty z University of California at Berkeley. Je to multiplatformní server, ale jeho typické použití je právě na operačních systémech UNIX a LINUX. Je vydáván pod licencí BSD (viz [2]) a jeho aktuální stabilní verze je 9.7.

2.3.2

PowerDNS

Tomto serveru se budu více věnovat až v kapitole 2.4.

2.3.3

djbdns

Djbdns (viz [3]), vznikl jako reakce pana Daniela J. Bernsteina (proto jméno djbdns) jako reakce na DNS server BIND. Vadily mu totiž jeho časté problémy s bezpečností. V roce 2004 byl djbdns druhý nejvíce populární DNS server. Je vydán pod licencí Public domain (viz [11]) a v současné době stále patří mezi nejbezpečnější DNS servery.

2.3.4

MyDNS

Je to DNS server, který běží na operačním systému UNIX. A je navržen pro servírování dotazů přímo z SQL databáze. Podporuje MySQL a nebo také PostgreSQL. Server neobsahuje rekurzivní server. Je navržen především pro organizace s velkým počtem zón, kde je potřeba dostávat vždy nejaktuálnější data z SQL serveru (pro velmi časté změny). Bohužel tento server již není ne vývoji a je tak velice zastarán a je náchylný k novějším útokům. Uvádím ho zde jen proto, že byl ve své době velice populární.

2.3.5

NSD

Zkratka NSD znamená Name Server Daemon. Je to jeden z řady DNS serverů, který je vydán jako Open Source. Stejně jako předešlý server neobsahuje rekurzivní server, tzn. že odpovídá pouze na dotazy pro domény, pro které je autoritativní. Používá stejné záznamy zón jako BIND. Server je stále ve vývoji, jeho aktuální stabilní verze je 3.2.5.

2.4

PowerDNS

PowerDNS (viz [9]) démon je velice všestranný jmenný server, který podporuje velké množštví backendů. Backendy mohou být jak prosté zónové soubory, tak i rozsáhle dynamické systémy. PowerDNS nabízí velmi dobrý výkon a má dobré rozlišovací schopnosti. Díky tomu, že byly při programování PowerDNS použity velmi inteligentní postupy a techniky nabízí velmi dobré rozlišovací schopnosti domén. Například jeden z nejdůležitějších a nejvýstižnějších příkladů toho co PowerDNS umí je, že podporuje relační databáze, kde můžete data uchovávat, pak také podporuje (geograficky oddělený) loadbalancing a failover algoritmy. PowerDNS vyvíjí stejnojmenná firma PowerDNS.COM BV.

2.5. RUBY-ON-RAILS

2.4.1

9

Funkce a návrh PDNS

PowerDNS je složen ze dvou částí. První z nich je autoritativní server a druhou je Recursor. Konkurenční jmenné servery často nabízejí tyto dvě věci současně, PowerDNS je však nabízí jako dva oddělené systémy. Není však problém tyto dva systémy spojit a použít je současně. PowerDNS podporuje velkou řadu backendů, zde uvedu seznam těch nejdůležitějších: • bind a bind2 načítání zón z běžných BIND zónových souborů • db2 dotazování z IBM DB2 databázového serveru • geo umožnuje různé odpovědi k různých IP adresám, podle stanovených pravidel o jejich zeměpisném umístění • gmysql podporuje MySQL relační databázi • gpsql podporuje PostgreSQL relační databázi • goracle podporuje Oracle databázi • gsqlite podrpouje SQLite databázi (verze 2 a verze 3) • ldat umožnuje dotazovat se z hiearchického adresáře LDAP • odbc umožnuje dotazovat se jakékoliv databáze, která podporuje ODBC • dále pak: pipe, random, xdb, opendbx PowerDNS byl navržen tak, aby se lehce instaloval, lehce konfiguroval a byl schopný obhospodařovat velké množětví dotazů pro velké množšství domén a jejich záznamům. Další velice důležitý cíl PowerDNS je bezpečnost. Systém je velice dobře navržený a je velice malý (něco okolo 10 000 řádků), proto je tedy možné kód lehce zkoumat. PowerDNS také nabízí velké množštví statistik, které mohou pomoci při škálování a nebo odhalování problému.

2.5 2.5.1

Ruby-on-Rails Co je to Ruby-on-Rails?

Ruby on Rails je framework, který je určen pro vývoj webových aplikací. Většinou používajících relační databázi. RoR používá návrhový vzor Model-view-controller 2.6. Vše se odvyjí od jazyka Ruby, ve kterém je framework napsán. Jde v něm vše velice snadno napsat, např. definovat vlastní šablonu (view), Ajax, atd. Ruby on Rails znamená v překladu Ruby na kolejích. Mezi základní myšlenky a filozofii frameworku patří:

10


• Konvence má přednost před konfigurací (programátor konfiguruje pouze ty části aplikace, které se liší od běžného nastavení). Vytvoří-li tedy např. model Plane, aplikace bude data automaticky hledat v tabulce plane. Pokud byste chtěli, aby se informace načítali z jiné tabulky, museli byste si to aakonfigurovat. • automaticky se v něm mapují URL na vnitřní řídící prvky aplikace / routování • abstrahuje se přístup k datům v databázi pomocí mapování záznamů přímo na objekty (ORM) • dále RoR obsahují rozsáhlé knihovny pro snadné generování HTML, pro práci s Ajaxem, formátování dat a další • žádná konfigurace není v XML, hojně se zato používá YAML • DRY (Don’t Repeat Yourself), RoR se snaží definovat vždy jednu věc na jednom místě, abychom ji neopisovali vícekrát

2.5.2

Kde a kdy ROR vzniklo?

Ruby-on-Rails vzniklo v roce 2004. Napsal ho dánský programátor David Heinemeier Hansson. Dostal tehdá zakázku od firmy 37signals na vytvoření nástroje pro projektové řízení. Zjistil, že ze všech dostupných frameworků neodpovídá žádný jeho představě. Začal tedy psát Basecamp a postupně z něj tento framework extrahoval. Jedna z nejdůležitějších vlastností Ruby-on-Rails je právě to, že vznikli z praxe, nikoliv nějak uměle. Někdy od roku 2005/2006 došlo asi k největšímu návalu zájmu o RoR.

2.5.3

Balíčkovací systém RubyGems

Programovací jazyk Ruby má svůj vlastní balíčkovací systém, který obsahuje velké množštví již hotových řešení, které jsou dostupné jako knihovny. Jeho ovládání je velice jednoduché. Ovládá se z textového režimu a zde uvádím základní příkazy, pro instalaci, hledání a smazání balíčků. Výpis nainstalovaných gemů/balíčků: gem list Vypis dostupných gemů/balíčků: gem list --remote Instalace gemů/balíčků: gem install <jmeno_balicku> Je možné také přidat další repozitáře, odokud se balíčky mohou instalovat. To se provádí příkazem:

2.6. MVC ARCHITEKTURA

11

gem sources -a http://gemcutter.org Vypsání aktuálně používaných repozitářů: gem sources

2.6 2.6.1

MVC architektura Model

Model se stará o získávání dat. Tvoří rozhraní mezi databází a kontrolérem. V modelu se také definují vztahy mezi ostatními modely. V Rails se vždy pracuje s databází objektově, tzn díky ORM, ActiveRecord, je používání databáze velice jednoduché. Navíc nejste tolik zavislí na typu databáze, což je veliká výhoda. Pro Vaše testování můžete například používat pouze SQLite, které se rychleji nainstaluje a pro produkční prostředí používat například MySQL. Model se také stará o kontrolu vstupních údajů a jejich validaci.

2.6.2

Controler

Kontrolér řeší logiku celé aplikace. Je to třída s metodami, které řídí celou funkcionalitu aplikace. Řídí se v něm posloupnost, kterou se zobrazují stránky a definuje se zde výměna dat mezi nimi. Není zde vůbec žádné SQL. V kontroléru můžeme přesměrovávat, různě kombinovat akce, měnit pohledy, šablony/layouty, zařídit přihlašování atd. Kontrolér je svázán také s mapou (routes). V mapě se definují jednotlivé kontroléry pro dané akce.

2.6.3

View

View, neboli pohled, je část, která se stará o vlastní generování HTML. Rails mají jako výchozí šablonovací systém použit ERB renderer 2.6.3. Je to renderovací systém, který je velice podobný například PHP. Soubory šablon s ERB mají koncovku .erb např. index.html.erb. Je zde možné použít mimo IFů, FOREACHů a dalších použít i pomocné metody, takzvané helpers, které nám usnadňují generování html. RoR podporují také mnoho dalších šablonovacích systémů, jako jeden z nejpoužívanějších uvedu HAML 2.6.3.

<%= print_date %>

<%= current_user.address %>

<%= current_user.email %>

<%= current_user.bio %>

12


#profile .left.column #date= print_date #address= current_user.address .right.column #email= current_user.email #bio= current_user.bio

2.7 2.7.1

Agilní vývoj Co jsou agilní metodiky vývoje software ?

Na konci devadesátých let minulého století se poprvé začaly objevovat agilní metodiky vývoje. Byla to reakce na to, že většina softwarových firem nesprávně odhadla projekt, očekávané vydání se stále posouvaly, narůstal rozpočet, atd. V roce 2001 byly v tzv. „Manifestu agilního vývoje softwaru“ (viz [4]) sepsány hlavní rysy těchto metodik. Zde uvádím jejich částečný výpis: • důraz na průběžnou komunikaci mezi vývojovým týmem a zákazníkem • důraz na tvorbu kvalitního kódu a funkcí, které mají přímou obchodní hodnotu pro zákazníka • týmovou spolupráci a samoorganizaci týmů • co nejčastější předávání hotové práce • vítání změn jako příležitosti být lepší • důraz na výslednou hodnotu pro zákazníka před dokumenty a papírováním Každá metodika klade na jednotlivé rysy jiný důraz. Například metodika nazvaná „extrémní programování“ uvádí některé věci doopravdy až do extrémů. Například jediná její dokumentace je vlastní kód softwaru! Tato metodika klade tedy velký důraz na čitelnost a jednoduchost kódu. Také téměř denně dochází k odesílání nové funkcionality zákazníkovi, který se k ní může vyjadřovat a tak spolupracovat na vývoji.

2.7.2

Proč agilně ?

Hlavní očekávání, pokud se rozhodnete vyvýjet software agilně, bude nejspíše v tom, že se Vám již nestane, že Vás projekt vyjde na 2x více peněz, než se čekalo. Také by se nemělo stát, že bude trvat několikanásobně déle, a už vůbec by se nemělo stát, že po několikaletém vývoji, kdy odevzdáváte výsledek zákazníkovi uslyšíte něco jako: „No pěkné, ale není to úplně podle našich představ.“ . A nezbyde nic jiného, než začít téměř od začátku. Nic takového by se Vám nemělo stát při správném používání agilních metodik vývoje softwaru.

2.7. AGILNÍ VÝVOJ

2.7.3

13

TDD

Co je to to TDD? Je to zkratka z anglických slov Test-driven development, což v překladu znamená testy řízený vývoj nebo také programování řízené testy. Je to speciální technika vývoje aplikací, kde se vždy nejdříve napíší testy, kterými musí daná aplikace projít, a až poté se píše vlastní aplikace. Vývojový cyklus podle TDD: 1) Vytvořit test - Vytvoření testu je vždy prvním krokem k tvorbě nové funkcionality. V této fázi se většinou vývojař ještě jednou přesně ujistí, zda dobře rozumí zadané funkcionalitě. 2) Spustit testy a ujistit se, že všechny neprojdou - Po spuštění všech testů bez naprogramované funkcionality nesmí žádný z testů projít. Pokud prošel, je špatně napsán. 3) Napsat vlastní kód - V tomto kroku je důležité napsat kód, který úspěšně projde testy, nemusí být však nejhezčí či nejrychlejší, či obecně nejlepší, musí jen projít testy. 4) Kód automatickými testy prochází - Očekávaný stav, zde je prostor pro další úpravy/profilování kódu s tím, že se musí předešlé kroky opakovat. 2.7.3.1

Problémy TDD

Objevuje se zde klasický problém. Kdo testuje testy? Testy sice testují aplikace, ale kdo testuje testy? Zde je tedy velmi důležité psát testy co nejlépe, tak, aby pokryly v ideálním případě všechny možné stavy aplikace a otestovali tak tedy celou funkcionalitu. Někdy však může být psaní testů velice obtížné, protože daná funkcionalita může například komunikovat s externím zařízením a nebo stahovat data z nějakých webových služeb.

2.7.4

BDD

BDD, tedy Behavior-Driven Development, tedy vývoji řízenený popisem chování. Je to v podstatě stejné jako TDD, s tím rozdílem, že jsou zde celé "story", tedy celá daná funkcionalita, kterou musí aplikace projít. Například ve webové aukční aplikaci napíšeme test s názvem "příhoz do aukce" a který otestuje všechny potřebné úkony potřebné k tomuto úkolu.

2.7.5

Continuous Integration

Continuous Integration, tedy Průběžná integrace je souhrn vývojařských nástrojů a metod, které společně slouží k urychlení vývoje software a spolupráce celého jeho týmu. Pomocí Continuous Integration Serveru (viz [6]), který je napsán v jazyce Ruby, lze velmi snadno najít nedostatky a chyby v aplikaci v různých fázích vývoje. Celý systém je navržen tak, aby hned poté, co vývojař nahraje aktuální verzi projektu do verzovacího sytému, se stáhne aktuální verze na integrity server, kde se sestaví aktuální build a spustí se nad něj testy, které jsou pro aplikaci napsány. TDD nebo ostatní podobné metody jsou velice kompilkované a především u větších projektů je zde veliká časová náročnost. Právě pro urychlení a zautomatizování testován je CI server navržen. Continuous Integration je také jednou z částí extrémního programování. I já jsem se rozhodl že integrační server použiji. Více o něm v kapitole 5.6.4.

14


Kapitola 3

Analýza a návrh řešení 3.1

Existující řešení

Webové administrační rozhraní k PowerDNS serveru již nějaká existují. Například asi nejznámější je právě PowerAdmin ([10] obr. 3.1), dále pak pdns-admin ([8]) a existují ještě další rozhraní. Ale všechny tyto i ostatní se vyznačují tím, že nejsou moc intuitivní, těžkopádně se ovládají a instalace je zbytečně složitá. Všechny existující rozhraní se tedy vyznačují především: • jsou napsány ve skriptovacím jazyce PHP • webové rozhraní je velice nepřehledné • graficky jsou špatně zpracované • většinou mají zakomponovanou i nějakou funkcionalitu navíc (například správa uživatelů, atd.), ale bohužel tím se komplikuje jeho nasazení a instalace

3.2

Znovu a lépe

Rozhodl jsem se inspirovat již hotovými aplikacemi, ale vyvarovat se stejných chyb. To znamená, že především použitelnost nesmí byt na úkor funkcionality, ale to samé platí také i obráceně. Chtěl jsem vyvinout aplikaci, která bude mít vše na správném místě. Nebudete v ní bloudit a hledat, kde by jen ta daná funkcionalita mohla být schována. Doufám, že jsem také nijak neomezil její funkcionalitu oproti konkurenci. Ale nebudu tvrdit, že je to ta nejlepší ze všech aplikací na správu DNS. Mohu pouze doufat, že kdybych ji dotáhl do takové úrovně, kterou bych rád, konkurence schopná by byla. Více o plánech a dalším možném rozvoji aplikace je v kapitole 6.1.

15

16

KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ

Obrázek 3.1: Screenshot z úvodní stránky aplikace PowerAdmin

3.3

Použité technologie

Celou aplikaci jsem se rozhodl napsat v jazyce Ruby a jeho framworku Rails (Ruby on Rails). Více o RoR v kapitole 2.5. V aplikaci je použita databáze SQLite verze 3, která lze lehce napojit na backend PowerDNS serveru. Je možné také použít i jinou databázi, musí ji však podporovat aplikace a také zároveň PowerDNS server (seznam backendů, které aplikace podporuje naleznete na 2.4.1). Dále jsem používal verzovací systém GIT, více o něm v 4.6. Použil jsem také dvě, již hotové knihovny z balíčkovacího systému RubyGems (více v kapitole 2.5.3), a to knihovny Crack a FastCSV. Knihovna Crack slouží k parzování JSONu a XML. Tu jsem využil pro import z XML. Dále jsem použil knihovnu FastCSV k exportu dat do formátu CSV. Využíval jsem také Continuous Integration Serveru (vice v 2.7.5), který jsem měl nainstalován lokálně na svém počítači.

Kapitola 4

Realizace 4.1 4.1.1

Grafický návrh Zvolené barvy aplikace

Aplikaci jsem navrhl, až na ikony, celou černobílou. Myslím si, že není potřeba zde mít jakékoliv grafické (a to především zkrášlující) prvky. Ty jsou potřeba na prezentační weby, nikoliv na funkční aplikace, alespoň tedy dle mého názoru. Živější nežli černobílé barvy jsou použity právě na ikonách, které velmi pomohou orinataci v aplikaci (více o barvách také v 5.5)

4.1.2

Zdroje použitých obrázků

Obrázky a ikony jsem hledal na osvědčeném vyhledávači www.iconfinder.com. Zde se nachází velké množstí ikon, které jsou šířeny většinou pod licencí "Creative Commons", což znamená, že je mohu bez problémů ve své práci použít. Použil jsem sadu ikon jménem "Fugue Icons" od autora Yusuke Kamiyamane (http://www.iconfinder.com/search/?q=iconset:fugue)

4.1.3 4.1.3.1

Ukázka grafickách návrhů První grafický návrh

Na obrázku 4.1 je screenshot úplně první vývojové verze aplikace. Byla ještě celá v českém jazyce. V této verzi ještě nebyla naprogramována funkcionalita pro import a export záznamů domén. Nebyly zde žádné grafické prvky (ikony) pro zpřehlednění funkcionality.

4.1.3.2

Konečný grafický návrh

Na obrázku 4.2 a 4.3 je již finální grafická podoba aplikace. Je zde uvedená grafická verze bez ikon a dále s ikonama, které rozhraní vylepší a díky nim se lépe orientuje.

17

18

KAPITOLA 4. REALIZACE

Obrázek 4.1: První grafický návrh aplikace

Obrázek 4.2: Výsledná grafická verze aplikace

4.2. KÓDOVÁNÍ

19

Obrázek 4.3: Výsledná grafická verze aplikace i s ikonama

4.2

Kódování

Jak dále píši v 4.2.3 kódování celé aplikace probíhalo v editoru TextMate. Je to vynikající program, a pro editaci CSS a HTML a je výborně použitelný. Současně s ním jsem používal v prohlížeči Firefox rozšíření FireBug, díky kterému je možné editovat CSS přímo v prohlížeči a to urychluje celé kódovnání. V prohlížeči Google Chrome je podobné rozšíření, v českém jazyce se jmenuje "Nástroje pro vývojaře", které je přímo intergrované do prohlížeče, které jsem také využil.

4.2.1

Kompatibilita s prohlížeči

Celou aplikaci jsem se rozhodl otestovat v následujících nejpoužívanějších prohlížečích. Zkoumal jsem, zda je ve všech prohlížečích v ideálním případě úplně stejné zobrazení, a nebo alespoň hodně podobné. Všechny prohlížeče, mimo Internet Explorer (MSIE), jsem testoval na svém operačním systému Mac OS X (10.6.3 Snow Leopard). Prohlížeče Internet Explorer jsem testoval pomocí webové aplikace BrowserShots (http://browsershots.org), která umí otestovat zobrazování až ve 42 verzích prohlížečů na čtyřech různých operačních systémech. Mozilla Firefox (verze 3.6) - vše funguje bez problémů Safari (verze 4.0) - vše funguje bez problémů Chrome (verze 5.0) - vše funguje bez problémů

20


MSIE (verze 6 a nišší) - layout je lehce rozhozen, jinak vše funguje bez problémů MSIE (verze 7 a výšší) - vše funguje bez problémů

4.2.2

Dodržení standardů

Webové rozhraní je napsáno podle standardů, doctype XHTML 1.0 Transitional. V kódování UTF-8. A je zkontrolováno validátorem od W3C na adrese http://validator.w3.org/ a vítězoslavně hlásí: "This document was successfully checked as XHTML 1.0 Transitional!".

4.2.3

Použité aplikace

Pro veškerou editaci jsem používal program TextMate (viz [13]). K dispozici je časově omezená (30 denní) verze, a nebo je možnost si aplikaci koupit. Já jsem si aplikaci koupil, protože ji velice často využívám. Koupil jsem si však studentskou verzi, ta je plnohodnotná, jen se nesmí používat ke komerčním účelům. Vřele Vám tento editor doporučuji. Je rychlý a velice všestranný a má podporu téměř pro všechny programovací jazyky.

4.2.4

Tisk

Pro případný tisk výstupu z aplikace je použit speciální CSS soubor, který je určen právě pro tisk. Rozdíl je v tom, že pro tisk není důležitá ani hlavička aplikace, kde jsou odkazy na další stránky, tak ani patička, kde je uveden autor a odkaz na validátor. U tisku všichni ocení, že nebudou tisknout tedy data, která vůbec nepotřebují.

4.3

Implementované funkce

• přidávání domény (při prvotním přidání nové domény se přidává zároveň její SOA záznam) • editace a mazání domény • přidávání, úprava a mazání záznamů domény • import záznamů pro danou doménu z XML • export záznamů domény do XML a nebo CSV • vyhledávání v názvech domén 4.3.0.1

Rozdělení uživatelských rolí a práv

Bohužel toto jsem již oproti původnímu plánu ve své bakalářské práci neobsáhl. Rozhodl jsem si to nechat pro budoucí vývoj aplikace. Více k kapitole 6.1

4.4. APLIKAČNÍ SERVER

21

Obrázek 4.4: Aplikační server Webrick - zpracování požadavku

4.3.0.2

Vlastní šablonovací systém pro DNS

Bohužel i toto jsem již oproti původnímu plánu ve své bakalářské práci neobsáhl. Rozhodl jsem si to nechat pro budoucí vývoj aplikace. Více k kapitole 6.1

4.4

Aplikační server

V Rails je jako výchozí (a především jako vývojový server) server použit WEBrick. Jeho použití do produkčního prostředí se nedoporučuje. Mě však jak pro vývoj tak pro produkci bohatě stačil, a to především proto, že aplikaci obslujuju prakticky sám. Pokud by zde bylo nějaké masivnější použití určitě bych od WEBricku upustil, a použil bych například Unicorn, jehož hlavní předností je například to, že "nezamrzná" při novém deployi aplikace, ale plynule požadavky přepne na novou verzi. Jak je vidět na obrázku 4.4, tak výstup WEBricku je velice stručný a pro vývoj přímo ideální. Je zde vidět na jakou URL přišel požadavek. Jaké měl parametry. Dále je zde přehledně vypsán přehled všech SQL dotazů, které byly pro vygenerování stránky použity. Jsou zde vidět jednotlivé časy generování, což může mnohdy velmi rychle odhalit, kde je aplikace pomalá a kde je potřeba aplikaci upravit.

4.5

Databázová vrstva

Jako úložiště dat je zde použita SQLite databáze. Ale není problém aplikaci napojit na jakoukoliv databázi, kterou backend PowerDNS podporuje (víc o PowerDNS a jeho backendech na 2.4) Celkem se používájí pouze 2 tabulky (třetí je pro běh aplikace zcela irelevantní). Jedná se tedy pouze o tabulky jménem domains a records. Zde uvádím pro lepší představu SQL, které vytvoří základní databázovou strukturu. create table domains ( id name master last_check type notified_serial account

INTEGER PRIMARY KEY, VARCHAR(255) NOT NULL, VARCHAR(128) DEFAULT NULL, INTEGER DEFAULT NULL, VARCHAR(6) NOT NULL, INTEGER DEFAULT NULL, VARCHAR(40) DEFAULT NULL

22


); CREATE UNIQUE INDEX name_index ON domains(name); CREATE TABLE records ( id INTEGER PRIMARY KEY, domain_id INTEGER DEFAULT NULL, name VARCHAR(255) DEFAULT NULL, type VARCHAR(6) DEFAULT NULL, content VARCHAR(255) DEFAULT NULL, ttl INTEGER DEFAULT NULL, prio INTEGER DEFAULT NULL, change_date INTEGER DEFAULT NULL ); CREATE INDEX rec_name_index ON records(name); CREATE INDEX nametype_index ON records(name,type); CREATE INDEX domain_id ON records(domain_id); create table supermasters ( ip VARCHAR(25) NOT NULL, nameserver VARCHAR(255) NOT NULL, account VARCHAR(40) DEFAULT NULL );

4.6

Verzovací systém

Jelikož mám dobré zkušenosti s GITem a jeho používání je též v RoR komunitě velice populární, rozhodl jsem se ho také použít pro moji bakalářskou práci. Hosting mého repozitáře jsem svěřil veřejnému poskytovateli GitHub [5], který hostuje velké množštví opensource projektů a to nejej v Ruby. Nabízí tarify, které jsou zdarma, ale to je podmíněno tím, že je Vás repozitář veřejně dostupný. Dále pak nabízí placené tarify, které jsou odstupňované podle počtu repozitářů, obsazeného prostoru. Celý můj projekt naleznete na adrese http://github.com/vachekcz/pdnsadmin. Součástí hostingu GITu je také veřejná wiki ke každému repozitáři. Pro můj projekt je na adrese http://wiki.github.com/vachekcz/pdnsadmin/. To bych také rád doplnil, ale zatím to zůstává pouze jako přání. Více se uskuteční, až po vydání projektu jako OpenSource. Zde ještě uvedu cesty ke zdrojovým kódům ve verzovacím systému. SSH přístup ke zdrojovým kódům (pro čtení i zápis): [email protected]:vachekcz/pdnsadmin.git HTTPS přístup ke zdrojovým kódům (pouze čtení): https://[email protected]/vachekcz/pdnsadmin.git

4.6. VERZOVACÍ SYSTÉM

GIT přístup ke zdrojovým kódům (pouze čtení): git://github.com/vachekcz/pdnsadmin.git

4.6.1

Popis GITu

Zde bych rád uvedl příklady používání GITu. Globální nastavení: git config --global user.name "Pavel Vachek" git config --global user.email [email protected] Prvotní inicializace repozitáře: mkdir pdnsadmin cd pdnsadmin git init git add * git commit -m ’first commit’ git remote add origin [email protected]:vachekcz/pdnsadmin.git git push origin master Pokud již máte repozitář vytvořený, pak: cd existujici_git_repozitar git remote add origin [email protected]:vachekcz/pdnsadmin.git git push origin master

23

24


Kapitola 5

Testování Mým cílem, není napsat jen aplikaci, která správně ovládá PowerDNS server, ale především uživatelsky přívětivou a lehce použitelnou aplikaci. Abych tohoto dosáhl, je jistě nevyhnutelné, abych celou aplikaci otestoval. Pro otestování správné funkcionality slouží právě výše popsané techniky (viz. 2.7.3, 2.7.4, atd.). Bohužel však tyto techniky nedovedou otestovat použitelnost aplikace. K tomu je potřeba zapojit nějakého reálného uživatele a celou aplikaci s ním projít a prozkoumat jak se uživatel chová. Jestli danou funkcionalitu vždy rychle najde, jestli nejsou nějaké prvky aplikace zbytečně moc veliké, nebo naopak malé, schované, atd.

5.1

Úvod do testování

Testování se mnohdy rozděluje do těchto dvou skupin a to kvalitativní a kvantitativní testování.

5.2 5.2.1

Uživatelské Testování aplikace Kvalitativní

Tento způsob testování je velice náročný na provedení, ale uvádí se, že odhalí až 90% problémů. Obvykle se provádí na 6-8 účastnících a je velice časté v komerční praxi.

5.2.2

Kvantitativní

Kvantitativní je provádí většinou na 20ti a více učastnících. Používá se především pro různé druhy statistického ověření. Klasickým příkladem toho může být například anketa vyvěšená na webu. Takovéto testování jsem na své práci neprováděl.

5.3

Kognitivní průchod

Aplikaci jsem nejprve procházel sám, a to metodou kognitivního průchodu všemi funkcemi aplikace. Po několikanásobném projití, které jsem udělal vždy po nějaké změně, se mě zdála aplikace již odladěná a tak jsem se pustil do dalšího bodu testování.

25

26

KAPITOLA 5. TESTOVÁNÍ

Při testování jsem se snažil vkládat nestandardní adresy, jména, atd. abych otestoval, jak se aplikace chová, pokud ji zadám i něco jiného, než co očekává. Zde jsem narazil na nejvíce mezer ne vývoji. Několikrát jsem znovu přepisoval kontrolu vstupů a testoval, zda již vše vyhovuje.

5.4

Testování použitelnosti

U testování použitelnosti jsem postupoval podle těchto doporučených bodů: • vymyslet, co přesně budeme testovat • vytvořit seznam testovacích úkolů • jaká je naše cílová skupina uživatelů (naprostý laik, laik, pokročilý, expert) • sehnat lidi a domluvit si terminy na testování • napsání scénáře • pilotní otestování scéraře • opravení případných chyb ve scénáři • ostré testování scénáře Testování použitelnosti bývá většinou velice efektivní a má širokou škálu použití. Doporučuje se testovat nejen finální verzi (pokud tedy bude testování úspěšné a po testování se již nebudou dělat další úpravy), ale doporučuje se testovat již od prvního prototypu. U mé práce však stačilo otestování až finální verze. Není zdaleka tak rozsáhlá ani složitá, aby potřebovala testovat více. Pro testování jsem si vybral pět uživatelů. Všichni ve věku v rozmezi 19 - 35 lety. Až na dva naprosté laiky to byli uživatelé zkušení (tato aplikace není v žádném případě určena naprostým laiků, a tak tedy nevadí, pokud naprostý laik neprojde úspěšně testovacím scénářem).

5.4.1

Ukázka testvacího scénáře

Zde bych rád ukázal, jak vypadal testovací scénář: 1. Do vašeho prohlížeče napište adresu http://localhost:3000. 2. Do systému máte následující přístupy: uživatelské jméno: dnsadmin a heslo: heslo123, přihlašte se tedy prosím. 3. Jako první zjistěte, jeslti je v systému doména jménem kafka.cz (zde jsem sledoval, jestli uživatel hned objevil možnost vyhledávání, a nebo jestli seznam domén prochází postupně)

5.5. VÝSLEDKY TESTŮ A PROVEDENÉ ZMĚNY

27

4. Pokud není, vytvořte ji s výchozíma hodnotama. (zde jsem sledoval, zda jsou výchozí hodnoty jasné, a není nějaký pochyb, že je potřeba mimo jména domény ještě něco vyplňovat) 5. Doménu kafka.cz vyexportujte a to do všech dostupných formátů. (v tomto bodě jsem sledoval, dal uživatel hned přejde do detailu domény a nebo si všimne sloupečku "Export to" a export provede přímo z výpisu domén) 6. Vytvořte doménu jménem franta.cz. (toto je pouze mezikrok, s doménou bude uživatel ještě později pracovat) 7. Vytvořte doménu jménem karel.cz. (toto je pouze mezikrok, s doménou bude uživatel ještě později pracovat) 8. Doméně karel.cz přidejte (pokud již existuje tak změnte) záznam pro poštu (MX) na hodnotu mail.seznam.cz. (zde jsem čekal první problém, při přidávání dalšího záznamu jsem si nebyl jist, zda všichni dobře pochopí, že kolonku doménu mají nechat beze změn) 9. Doméně www.franta.cz přidejte nový ipv6 (AAAA) záznam "2001:db8::1428:57ab". (zde jsem testoval, zda uživateli dojde, že musí kolonku doména přepsat, resp. musí dopsat ještě "www")

5.4.2

Instrukce pro testera

Uživateli, který bude aplikaci testovat, je potřeba vysvětlit následující základní myšlenky, aby správně pochopil testování. • je potřeba uživateli vysvětlit význam testování (snáze tak pochopí jak s náma spolupracovat a pojme správně celé testování) • vysvětlení pojmu "myšlení nahlas" (to spočívá v tom, že uživatel musí stále mluvit, musí stále hlásit proč na dané tlačítko klikl, proč tedka nic nedělá, atd. ) • důležité je mít na paměti, že netestujeme uživatele, ale aplikaci!

5.5

Výsledky testů a provedené změny

Z výsledků testování jsem poznal, že aplikace je téměř hotová. Žádné velké chyby jsem již neodhalil. Zjistil jsem, jelikož jsem testoval na dvou verzích, jedna byla bez ikon a jedna již s ikonama, že verze s ikonama je mnohem více intuitivní, rozhodl jsem se tedy do konečné verze ikony použít. Ikony, podle mě velice pomáhají uživateli v rychlém pátrání, co který prvek asi znamená. Funguje zde velice dobře následující: • zelená barva - vytváření, přidávaní

28


• orandžová barva - změna, editace • červená barva - "nebezpečí", mazání, pozor Proto je tedy vhodné používat například při úspěšném vytváření hlášku zelenou. Naopak, pokud se něco nezdaří, zcela jistě by se mela použít barva červená. Tyto barvy zjednodušší používání a velice pomohou intuitivnímu ovládání. Proto jsem se taky rozhodl, až na ikony, udělat celou aplikaci téměř černobílou (více o barvách aplikace 4.1.1)

5.6

Testování aplikace v Ruby-on-Rails

Testování aplikace je velice důležité. Představte si, že změníte nějakou část aplikace, přidáte funkcionalitu nebo jakkoliv upravujete aplikaci a po každé takovéto změně musíte celou aplikaci projít a znovu celou otestovat. Tento krok je lepší co nejvíce a co nejdůkladněji zautomatizovat. K tomu jsou v Ruby-on-Rails 3 základní typy testů. Testuje se například v modelu (více v 2.6.1), v kontroleru (více v 2.6.2). Zde jsou tedy 3 základní typy testů (více o testování najdete na [12]) • Unit Testing • Functional Tests • Integration Testing

5.6.1

Unit testing

Unit testy a nebo také testy modelu slouží k otestování, zda model správně validuje vstupní data. Zde uvedu příklad z aplikace. Na obrázku ze zdrojového kódu 5.1 je vidět testovací kód, který testuje seznam domén, které mohou projí validací modelu. Naopak, na obrázku 5.2 se testuje seznam domén, které validací projít nesmějí.

5.6.2

Functional Tests

Co by se mělo ve funkčních testech testovat: • Byl webový požadavek úspěšný? • Byli jsme přesměrováni na správnou stránku? • Byli jsme úspěšně přihlášeni? • Byl objekt vložen do správné šablony? • Byla zobrazena správná hláška uživateli?

5.6. TESTOVÁNÍ APLIKACE V RUBY-ON-RAILS

Obrázek 5.1: Unit test - testování validace správného doménového jména

Obrázek 5.2: Unit test - testování validace nesprávného doménového jména

Obrázek 5.3: Integrační test - Ověření vytvoření domény a zobrazení formuláře

29

30


Obrázek 5.4: Integrační test - inicializace (HTTP Auth přihlášení)

5.6.3

Integration Testing

Na obrázku 5.4 a 5.3 můžeme vidět zdrojový kód testů, kterým se říká integrační testy. Na první obrázku (5.4) je prvotní inicializace, která se spouští pro každý integrační test, ve kterém je pouze přihlášení do aplikace pomocí HTTP Auth. Uživatelské jméno a heslo se načítá z konfiguračních souborů aplikace. Na obrázku 5.3 je napsán již celý scénář integračního testu. Jako první se zde testuje, zda se vůbec úspěšně zobrazí požadovaná stránka s formulářem pro novou doménu. Poté se pomocí metody POST odešlou testovací data na zadanou adresu. Dále se testuje, zda se na úvodní stránce domén zobrazí text, který nám říká, že se doména přidala v pořádku. Těchto integračních testů je dobré napsat co možná nejvíce, ověřují celý postup, který nedefinujeme a dalo by se tedy říct, že se jedná o nejdůkladnější metodu.

5.6.4

Continuous Integration

V příloze 10.2 ukazuji, jak vypadají výstupy z CI (viz [6])„ které jsem pro svoji bakalářskou práci použil. Jsou zde zobrazeny úspěšné i neúspěšné průchody testy. Je zde také zobrazeno, jak vypadá celé rozhraní.

5.7

Vyhodnocení výsledků testování

Co se zhodncení celého testování týče, mohu říci jediné. Testuje, testuje a testuje! Při testování téměř vždy narazíte na nějaké nedostatky aplikace, mohou to být od základních věcí jako je například špatná validace vstupů, až po zjištění, že aplikace není dobře rozdělena, jednotlivé funkce uživatelé nemohou najít, no zkrátka aplikace není dobře odladěná. Stejně tak i já, jsem při testování narazil na hodně nedostatků. Uživatelé při testování na tyto nedostatky ukázali, a já je tedy mohl opravit. Závěrem bych chtěl říci, že nejvíce problémů mě udělala právě špatně vybraná cílová skupina. Je vždy nutné si uvědomit, pro koho je aplikace určena a jestli je i takové složení testovací skupiny lidí.

Kapitola 6

Závěr Výstupem má práce je aplikace, která umožnuje kompletní správu databáze PowerDNS serveru. Je zde možné domény přidávat a kompletně je administrovat po stránce DNS. Aplikace je uživatelsky přívětivá, velice jednoduchá a lehce nainstalovatelná. Při jejím vývoji jsem se snažil klást velký důraz na správnou funkčnost aplikace a na její lehkou použitelnost. Aplikaci jsem naprogramoval v jednom z nejmodernějších programovacích jazyků a to Ruby a jeho frameworku Ruby on Rails. Snažil jsem se také dodržovat moderní programovací techniky pro vývoj softwaru, a to především TDD, tedy programování řízené testy. Dále jsem úspěšně celou aplikaci doladil pomocí uživatelského testování. Výsledná aplikace by tedy mela být stabilní a dobře ovladatelná.

6.1

Další možné plány vývoje

Jak jsem se již zmínil v kapitole 4.3.0.1 implementaci uživatelských rolí a jejich práv jsem odložil, a tak je možné aplikaci dále v tomto směru rozvíjet. Problém může nastat s databází, protože tato aplikace je navržena přímo na konkrétní, již danou, strukturu databáze, do které nemohu zasahovat, což by trochu komplikovalo tyto práva zavést. Není to však neřešitelný problém, stačí mít další databázi, ve které by byla příslušná data uložena. Další možností je zachovat stávající databázi a pro nová data ji pouze rozšiřovat. Jako další krok k vylepšení, navrhuji tvorbu šablon, případně celých vzorových domén, podle kterých by se přidávaly nové. Zde by byl také prostor pro definování například všech českých i celosvětových hostingů. Také by se mohly implementovat jen částečné šablony, pro například migraci domény na Google Apps (Google Mail), kde je potřeba změnit 7 MX záznamů a manuálně je to velice zdlouhavé.

31

32

KAPITOLA 6. ZÁVĚR

Literatura [1] BIND. http://www.isc.org/software/bind, stav z 11. 4. 2010. [2] The BSD License. http://www.opensource.org/licenses/bsd-license.php, stav z 11. 4. 2010. [3] djbdns: Domain Name System tools. http://cr.yp.to/djbdns.html, stav z 11. 4. 2010. [4] Manifesto for agile software development. http://agilemanifesto.org, stav z 11. 4. 2010. [5] GitHub. http://www.github.com/, stav z 11. 4. 2010. [6] Integrity - continuous integration server. http://www.integrityapp.com, stav z 11. 4. 2010. [7] CZ NIC: O DNSSEC. http://http://www.nic.cz/dnssec/, stav z 11. 4. 2010. [8] pdns-admin. http://freshmeat.net/projects/pdns-admin/, stav z 11. 4. 2010. [9] PowerDNS. http://www.powerdns.com/content/home-powerdns.aspx, stav z 11. 4. 2010. [10] PowerAdmin. https://www.poweradmin.org/trac/, stav z 11. 4. 2010. [11] The Public domain License. http://en.wikipedia.org/wiki/Public_domain, stav z 11. 4. 2010. [12] Ruby on Rails - Testing guide. http://guides.rubyonrails.org/testing.html, stav z 11. 4. 2010. [13] TextMate — The Missing Editor for Mac OS X. http://macromates.com/, stav z 11. 4. 2010.

33

34

LITERATURA

Kapitola 7

Seznam použitých zkratek DNS Domain Name System / Systém doménových jmen NS Name Server / Jmenný server TLD Top-Level Domain / Doména nejvyšší úrovně RoR Ruby-on-Rails XHTML (Extensible HyperText Markup Language) / značkovací jazyk určený pro tvorbu hypertextových dokumentu TTL Time to Live / Doba života ORM Object-relational mapping / Mapování na objekty CI Continuous Integration / Kontinuální(průběžná) integrace CSV Comma-separated values / Hodnoty oddělené čárkami JSON JavaScript Object Notation / JavaScriptový objektový zápis XML Extensible Markup Language / Rozšiřitelný značkovací jazyk

35

36

KAPITOLA 7. SEZNAM POUŽITÝCH ZKRATEK

Kapitola 8

Instalační a uživatelská příručka 8.1

Úvod

Celá komunita okolo Ruby, Ruby-on-Rails používá téměř výhradně Mac OS X, tak proto zde také uvádím instalaci v tomto operačním systému. Samozřejme to neznamená, že by aplikace nemohla běžet i jinde, ale instalace právě na OS X je nejjednodušší.

8.1.1

Instalace

Aplikace je naprogramována v Ruby verze 1.8.7 a v frameworku Ruby-on-Rails verze 2.3.5. V době, kdy jsem psal tuto práci vyšla nová řada RoR a to dlouho očekávaná verze 3, která přináší spousty vylepšení, bohužel do tuto verzi aplikace nepodporuje. Pokud používáte MacPorts (opensource projekt, který je navržen pro snadnou instalaci a používání UNIX like aplikací na MAC OS X) k základní instalaci stačí zadat příkaz: sudo port install ruby Tento příkaz nainstaluje jazyk Ruby do systému. Poté přejdete do adresáře s aplikací a spustíte následující příkaz, který již doinstaluje všechny ostatní balíčky z balíčkovacího systému RubyGem. gem install rails --include-dependencies

8.1.2

Závislosti aplikace

Pro správnou funkčnost je potřeba doinstalovat několik nestandardních doplňků ve formě GEMů (více v 2.5.3). Zde tedy uvádím jejich seznam a také postup, jak je nainstalovat do Vašeho systému. Jedná se o následující GEMy: fastercsv a crack. Jejich instalaci provedete následovně: sudo gem install fastercsv sudo gem install crack

37

38

KAPITOLA 8. INSTALAČNÍ A UŽIVATELSKÁ PŘÍRUČKA

Obrázek 8.1: Start aplikačního serveru Webrick

8.1.3

Spuštění serveru

Na obrázku 8.1 je zobrazen start aplikačního serveru Webrick, který běží ve výchozí konfiguraci na portu 3000 a poslouchá na všech IP adresách. Uvádím zde příkaz, kterým se spouští a jeho základní parametry jako je nastavení portu, na kterém má poslouchat a dále v jakém prostředí má běžet. script/server script/server -p <port> script/server -e [test/development/production]

Kapitola 9

Obsah přiloženého CD install.txt src |-- pdnsadmin ‘-- pdnsadmin.zip text |-- pdf | ‘-- bp.pdf ‘-- tex |-- bp.tex ‘-- figures html |-- abstract | ‘-- index.html |-- RabstrCJ | ‘-- index.html ‘-- RabstrCJ ‘-- index.html

- instalační příručka - adresář obsahující zdrojové kódy aplikace

- adresář obsahující vlastní text BP - adresář obsahující vlastní text BP ve formátu PDF - adresář obsahující vlastní text BP ve forámtu LaTeX - adresář obsahující obrázky - adresář obsahující krátkou anotaci - adresář obsahující anotaci v českém jazyce - adresář obsahující anotaci v anglickém jazyce

39

40

KAPITOLA 9. OBSAH PŘILOŽENÉHO CD

Kapitola 10

Přílohy 10.1

Unit, functional a integrations tests

10.2

Continuous integration

Obrázek 10.1: RoR - Unit tests - úspěšný průchod

41

42

KAPITOLA 10. PŘÍLOHY

Obrázek 10.2: RoR - Functional tests - úspěšný průchod

Obrázek 10.3: RoR - Integration testing - úspěšný průchod

Obrázek 10.4: RoR - Functional tests - selhaný test

10.2. CONTINUOUS INTEGRATION

Obrázek 10.5: Continuous integration - průběh sestavování testů

Obrázek 10.6: Continuous integration - testování selhalo (chybná verze Rails)

43

44

KAPITOLA 10. PŘÍLOHY

Obrázek 10.7: Continuous integration - build neprošel testy

10.2. CONTINUOUS INTEGRATION

Obrázek 10.8: Continuous integration - build prošel testy + výpis posledních buildů

45

Webové rozhraní pro administraci DNS serveru. Pavel Vachek

Recommend Documents