Analýza implementace projektu FreeNetIS včetně implementace doplňkových funkcí

České vysoké učení technické v Praze Fakulta elektrotechnická

Diplomová práce

Analýza implementace projektu FreeNetIS včetně implementace doplňkových funkcí Bc. Lubomír Buben

Vedoucí práce: Ing. Josef Semrád

Studijní program: Elektrotechnika a informatika, strukturovaný, navazující magisterský Obor: Informatika a výpočetní technika, počítačové sítě a internet Duben 2010

II

III

IV

Poděkování Chtěl bych poděkovat všem, kteří se podíleli na této práci a kteří mi při práci pomáhali a podporovali mě. Děkuji panu Ing. Josefu Semrádovi, vedoucímu této práce a stejně tak i panu Ing. Tomáši Dulíkovi, oběma za mnoho hodin strávených konzultacemi. Dále děkuji za trpělivost a pomoc Jiřímu Svitákovi, Michalu Klimentovi a Romanu Ševčíkovi jakožto spoluautorům informačního systému FreeNetIS.

V

VI

Prohlášení Prohlašuji, že jsem svou diplomovou 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 dne 10.5. 2010

…………………………………………

VII

VIII

Abstract This thesis deals in first part with analysis of open source project FreeNetIS, the information system for community networks. It is used especially for management of users, finances and devices in computer networks. The analysis is done using UML language. In the second part there is design and description of implementation of additional modules and functions for FreeNetIS. These modules are web page redirection, generation of configuration files, network supervision, backup of configuration of network devices and interconnection with GSM gateway for sending SMS messages

Abstrakt Tato práce se zabývá v první části analýzou open source projektu FreeNetIS, informačního systému pro komunitní sítě. Slouží zejména ke správě uživatelů, financí a zařízení v počítačových sítích. K analýze jsou využity nástroje jazyka UML. V druhé části je návrh a popis implementace rozšiřujících modulů a funkcí pro FreeNetIS. Jedná se o moduly pro přesměrování webového provozu, generování konfiguračních souborů, dohled sítě, zálohování konfigurace síťových prvků a propojení s GSM gateway pro posílání SMS zpráv.

IX

X

Obsah Seznam obrázků

XI

1 Úvod

1

1.1 Úvod do FreeNetISu

1

1.2 Vývoj FreeNetISu

1

1.2.1 PHP framework

2

1.2.2 Kohana framework

2

1.2.3 MVC

4

1.3 Záměr a struktura práce

5

2 Analýza současného stavu

7

2.1 Obecná analýza systému

7

2.2 Diagramy užití

8

2.3 Struktura databáze

9

2.4 Diagramy tříd

10

2.5 Hierarchie adresářů

11

3 Návrh rozšiřujících modulů

13

3.1 Sběr informací pro rozšiřující funkce

13

3.2 Přesměrování webového provozu

15

3.3 Generování konfiguračních souborů

16

3.3.1 Zónové soubory DNS

16

3.3.2 Konfigurační soubory DHCP

16

3.3.3 Zabezpečení MAC restrikcemi

17

3.4 Monitorování sítě

21

3.5 Zálohování síťové konfigurace

22

3.5.1 Zálohování Linuxu

22

3.5.2 Zálohování RouterOS

23

3.6 Posílání SMS zpráv

24

3.7 Vrstva pro komunikaci s externími systémy

24

XI

4 Implementace rozšiřujících modulů

25

4.1 Modul pro přesměrování webového provozu

25

4.1.1 Přístupová práva phpGACL

25

4.1.2 Mechanismus přesměrování

26

4.2 Kontrolér pro generování konfiguračních souborů

28

4.2.1 Generování zónových souborů DNS

29

4.2.2 Generování zpětných DNS zónových souborů

29

4.2.3 Generování dopředných DNS zónových souborů

31

4.2.4 Kontrolér pro správu oblastí

32

4.2.5 Generování konfiguračních souborů DHCP

32

4.2.6 Generování MAC restrikcí

34

4.3 Kontrolér pro monitorování sítě

35

4.4 Kontrolér pro zálohování sítě

37

4.5 Kontrolér pro SMS komunikaci

39

4.6 REST

40

5 Další vývoj FreeNetISu

43

5.1 Vylepšení nově přidaných funkcí

43

5.1.1 Vylepšení funkce přesměrování

43

5.1.2 Vylepšení funkce generování konfiguračních souborů

44

5.1.3 Vylepšení funkce monitorování sítě

45

5.1.4 Vylepšení funkce zálohování sítě

45

5.1.5 Nové funkce a další vývoj

46

5.2 Budoucnost informačního systému FreeNetIS 6 Závěr

46 48

6.1 Shrnutí diplomové práce

48

7 Seznam literatury

50

A UML diagramy

53

B Uživatelská příručka

57

B.1 Instalace systému FreeNetIS

57 XII

B.2 Používání modulu přesměrování

58

B.3 Generování konfiguračních souborů

59

C Dodatek k PHP frameworku Kohana

61

D Obsah přiloženého CD

62

XIII

Seznam obrázků 1.1 Porovnání rychlostí jednotlivých frameworků

3

1.2 Paměťová náročnost jednotlivých frameworků

4

1.3 Diagram závislostí v softwarové architektuře MVC

5

2.1 Use case diagram uživatelských rolí a přístupových práv

8

2.2 Diagram užití pro modul „Finance“

9

2.3 Návrh struktury databáze pro moduly „Uživatel“ a „Finance“

10

2.4 Zjednodušený diagram tříd FreeNetISu

11

3.1 Komunikační schéma modulu pro přesměrování webového provozu

15

3.2 Modelování sítě v nástroji Nagios Map

18

3.3 Měření vytížení CPU nástrojem Cacti

19

3.4 Korekce grafu v delším časovém období pomocí pluginu

19

3.5 Plugin Weathermap v monitorovacím nástroji Cacti

20

3.6 Nástroj SmokePing pro měření latence a packetloss

21

3.7 Export a import konfigurací v RouterOS

23

4.1 Přesměrování IP adresy v informačním systému FreeNetIS

27

4.2 Uživatelské rozhraní konkrétní oblasti ve FreeNetISu

32

4.3 Stromové menu v nástroji Smokeping

35

4.4 Přidávání nové zálohy ve FreeNetISu

38

4.5 Aplikace b-SMS Plus s importovaným adresářem z FreeNetISu

40

5.1 Percentuální zastoupení programovacích jazyků ve FreeNetISu

47

6.1 Počet řádků kódu projektu FreeNetIS

48

A.1 Struktura databáze modulu „Síť“

53

A.2 Struktura databáze pro nově vzniklé funkce a moduly

54

A.3 Diagram užití pro práce a brigády

55

A.4 Diagram užití pro modul „Přesměrování“

55

XIV

A.5 Diagram tříd systému FreeNetIS

56

B.1 Seznam přesměrovaných záznamů včetně filtrování

59

XV

XVI

KAPITOLA 1. ÚVOD

1 Úvod V první kapitole se seznámíme s informačním systémem FreeNetIS. Jsou zde také vymezeny cíle a obsah této práce.

1.1 Úvod do FreeNetISu FreeNetIS je systém pro správu uživatelů, financí a síťových zařízení v rozsáhlých počítačových sítích. Je vyvíjen pod licencí GNU/GPL a využívání je tak možné bezplatně pro kohokoliv, nicméně je primárně určený pro neziskové organizace, zejména komunitní bezdrátové sítě. Pokud má někdo zájem FreeNetIS využívat, může si ho volně stáhnout z SVN SourceForge [1] a podle návodu jednoduše nainstalovat. Návod k instalaci naleznete v příloze B.1 Instalace systému FreeNetIS. Cílem systému FreeNetIS je urychlení administrativy a správa uživatelských účtů pro správce těchto sítí a zjednodušení správy jejich zařízení i chodu celé sítě [2]. Systém je schopný spravovat podvojné účetnictví, a přestože se nejedná o účetní software, tak předčí ve správě jednotlivých účtů například i základní verzi Pohoda software, který má omezení na správu nejvýše 999 účtů. V modulu Síť je zahrnuta správa zařízení připojených do sítě včetně síťové konfigurace. Jedná se především o evidenci podsítí a jejich IP adres, rozhraní zařízení včetně případného použití VLANů či zapojení portů na switchích nebo routerech. Systém disponuje českou i anglickou jazykovou verzí a umožňuje případně poměrně jednoduché rozšíření a přeložení do dalších jazyků.

1.2 Vývoj FreeNetISu Vývoj FreeNetISu započal na Univerzitě Tomáše Bati ve Zlíně a od roku 2008 pokračuje v síti UnArt Slavičín [3]. O vývoj systému se staralo vždy několik vývojářů zároveň, na přelomu roku 2009 a 2010 jsou to 4 programátoři. Repozitář SVN na SourceForge [1] by měl zajišťovat bezproblémovou spolupráci všech programátorů, nicméně ne vždy se toto daří. Ještě lepší podmínky pro současnou práci vývojářů by měly zajišťovat jednotlivé větve (branches) na SVN repozitáři (betaversion, testing, stable atd.). Od léta 2010 se budou vždy veřejně vydávat pouze stabilní verze pro případné zájemce a vývojové verze budou dostupné

1

KAPITOLA 1. ÚVOD pouze programátorům. Tím se zamezí stahování nestabilních verzí systému případnými zájemci o užívání.

1.2.1 PHP framework Framework je softwarový nástroj, který nám pomáhá při programování, vývoji a organizaci jiných softwarových projektů. Snad pro každý programovací jazyk existuje i příslušný framework, který se stará o rutinní záležitosti jako je práce s databází, stránkování, formuáře atd. Jsou to například Ruby on Rails pro jazyk Ruby, jQuery pro JavaScript nebo třeba jUnit či Spring pro programovací jazyk Java. Pro programátora sice vzniká na začátku potřeba naučit se syntaxi daného frameworku, nicméně u větších projektů se používání takovýchto nástrojů vyplatí. Pro programovací jazyk PHP sice neexistuje žádné oficiální řešení, nicméně máme na výběr z velkého množství opensource frameworků. Mezi nejznámější patří Zend Framework, CakePHP, CodeIgniter, PRADO, Kohana, Symfony a dokonce i český framework Nette. Tyto frameworky byly testovány v rámci diplomových prací [4] a [5] a další informace o srovnávání jednotlivých frameworků můžete nalézt například na webu [6].

1.2.2 Kohana framework Pro vývoj byl již od počátku vybrán framework Kohana [7]. Výběrem nejvhodnějšího PHP frameworku se zabývaly před začátkem vývoje diplomové práce Ing. Petra Daňka [4] a Ing. Marka Rozehnala [5] na Fakultě aplikované informatiky na Univerzitě Tomáše Bati ve Zlíně. Framewok Kohana byl v těchto pracech srovnán s frameworky FUSE, PRADO, Qcodo, Zend, Akelos, CakePHP, CodeInteger a Jelix. Výsledky těchto testů jsou na obrázku 1, kde je porovnání rychlostí jednotlivých frameworků, a na obrázku 2, kde si můžeme prohlédnout paměťovou náročnost testovaných frameworků.

2

KAPITOLA 1. ÚVOD

Obrázek 1: Porovnání rychlostí jednotlivých frameworků [4], [5] Kohana je malý a rychlý framework určen čistě pro PHP5 a je velmi podobný CodeIntegeru, avšak je vyvíjen komunitou, nikoliv firmou. Podporuje MySQL, PostgreSQL nebo i PDOSqlite a práci s databází velmi usnadňuje ORM knihovna, která nám umožňuje přistupovat přímo k datům v databázi a patří tak k hlavním výhodám tohoto frameworku.

3

KAPITOLA 1. ÚVOD

Obrázek 2: Paměťová náročnost jednotlivých frameworků [4], [5]

1.2.3 MVC Velmi důležité je, že framework Kohana se drží návrhového vzoru Model (model) – View (pohled) – Controller (řadič), zkráceně tedy MVC. Tato softwarová architektura rozděluje výslednou aplikací na 3 nezávislé komponenty – datový model aplikace, uživatelské rozhraní a řídicí logiku. Tyto části se mezi sebou ovlivňují jen minimálně a celý projekt je tak mnohem více přehledný a udržovatelný. •

Model (model) je doménově specifická reprezentace informací, s nimiž aplikace pracuje. Obstarává tedy práci s databází.

4

KAPITOLA 1. ÚVOD •

View (pohled) převádí data získaná z modelu do podoby vhodné k interaktivní prezentaci uživateli.

•

Controller (řadič) reaguje na události (typicky pocházející od uživatele) a zajišťuje změny v modelu nebo v pohledu. [8]

Jednoduše je celý proces a diagram závislostí znázorněn na obrázku 3. Uživatel provede akci v uživatelském rozhraní a komponenta view předá o této události zprávu řadiči, který na základě toho může přistoupit k modelu a případně ho aktualizovat či provést jakoukoliv jinou akci. Jakmile model obsahuje aktuální data, komponenta view je může opět použít pro zobrazení uživateli. V tomto případě je model zcela nezávislý na pohledu zatímco pohled získává data přímo od modelu. Přestože s použitím návrhového vzoru pozorovatel lze komponentu view automaticky informovat o změnách v modelu, v případě FreeNetISu tomu tak není.

Obrázek 3: Diagram závislostí v softwarové architektuře MVC [9]

1.3 Záměr a struktura práce Hlavním cílem této práce je zanalyzovat současný stav informačního systému FreeNetIS a implementovat rozšiřující funkce do systému, pro zvýšení jeho efektivity a funkcionality. V této práci zjišťuji jeho připravenost a použitelnost v nejrůznějších komunitních sítích. K tomu se využívá mimo jiné i grafický jazyk UML. Zhodnocení současného stavu je obsaženo v kapitole 2 Analýza současného stavu. V následující části můžete nalézt návrh rozšiřujících modulů pro informační systém FreeNetIS, zatímco v kapitole 4 Implementace 5

KAPITOLA 1. ÚVOD rozšiřujících modulů už se zabývám samotným řešením. Návrh databáze stejně jako propojení nových funkcí se současným systémem byl konzultován s ostatními vývojáři systému. V závěrečném oddílu práce jsou rozebrány možnosti budoucího rozvoje a případného dalšího použití systému FreeNetIS. Výstupem implementační části je několik kontrolérů (řadičů) vytvořených v programovacím jazyce PHP pro framework Kohana. Tyto kontroléry buď rozšiřují funkcionalitu samotného systému nebo upravují strukturu systému pro širší použitelnost v komunitních sítích. Pro tyto řadiče byly vytvořeny odpovídající pohledy a stejně tak modely podle předchozího návrhu databáze. Nejdůležitějším kontrolérem je modul pro přesměrování webového provozu, který nahrazuje dřívější mechanismus přesměrování v systému FreeNetIS, který měl pouze velmi omezené nastavení. Nový kontrolér se stará o předávání urgentních zpráv uživatelům v síti a nabízí administrátorům širokou nabídku nejrůznějších nastavení. Další kontrolér se stará například o generování konfiguračních souborů pro DHCP server, generování zónových dopředných i zpětných souborů pro DNS či generování bezpečnostních souborů pro MAC restrikce. Informace pro generování jsou čerpány ze současných databází FreeNetISu a dále z obecného nastavení administrátorem v příslušných pohledech. Méně rozsáhlé jsou pak kontroléry pro spolupráci s GSM bránou kvůli posílání SMS zpráv na mobilní telefony uživatelů, kontrolér pro monitorování sítě pomocí nástroje Smokeping anebo také kontrolér pro správu autonomních oblastí v sítích, jejich správců a přidělených podsítí.

6

KAPITOLA 2. ANALÝZA SOUČASNÉHO STAVU

2 Analýza současného stavu V této kapitole najdete shrnutí analýzy současného stavu FreeNetISu pomocí nástrojů UML. Na

základě

zhodnocení

této

analýzy

budou

dále

implementovány

nové

funkce

do informačního systému. UML diagramy nechybí ani u návrhu nových funkcí a modulů.

2.1 Obecná analýza systému Původní specifikace pro systém FreeNetIS vznikly v práci Ing. Tomáše Dulíka [10], kde jsou vytyčeny cíle, vlastnosti i funkce celého systému. Systém má co nejvíce zjednodušit správu (bez)drátových sítí s orientací na uživatele. Primárně je projekt určen pro neziskové organizace (freenety), kterým by měl být ušit na míru. Mezi základních osm vlastností systému patří zejména registrace nových uživatelů včetně samoregistrace, správa plateb členských příspěvků, zasílání zpráv uživatelům pomocí přesměrování webu, monitoring, správa uživatelských účtů a další. Na první pohled může být trochu matoucí terminologie uživatelů. Člověk, který se zaregistruje do FreeNetISu a následně je připojen do komunitní sítě, se nazývá člen, zatímco uživatelem se rozumí každý, kdo fyzicky využívá síť a tedy připojení k Internetu. V praxi je členem většinou domácnost, která může mít libovolné množství uživatelů, přičemž vždy právě jeden uživatel je hlavní. Struktura uživatelů a členů je více zřetelná na diagramu tříd na obrázku 26 v dodatku A této práce. V práci prvotní specifikace [10] je také nastíněno rozdělení přístupových práv k jednotlivým částem systému podle uživatelských rolí. Rozdělení základních uživatelských rolí podle přístupových práv je na use case diagramu (obrázek 4, kapitola 2.2 Diagramy užití). Mezi další role v systému patří člen-technik, který může tvořit a měnit záznamy o technologiích ve vlastnictví sdružení, účetní s plnými právy pro účetní záznamy a správní rada, která má plná práva pro veškeré operace v systému. Různé stupně přístupových práv jsou dosaženy díky phpGACLu [11], který je podrobněji rozebrán v kapitole 4.1.1 Přístupová práva phpGACL.

7

KAPITOLA 2. ANALÝZA SOUČASNÉHO STAVU

2.2 Diagramy užití V první řadě si představíme diagramy užití (resp. use case diagramy), které podávají první představu o systému směrem k zákazníkovi, kterým je v našem případě komunitní síť. Tyto diagramy neřeší platformu, programovací jazyk ani samotnou implementaci, ale naopak zachycují vnější pohled na modelovaný systém. Pomocí use case diagramů zjišťujeme, které procesy má systém podporovat a jací uživatelé je budou používat. První diagram použití byl už zmíněn v předchozí kapitole ve spojitosti s typy uživatelů a jejich přístupovými právy, který je zobrazen na obrázku 4.

Obrázek 4: Use case diagram uživatelských rolí a přístupových práv. Stěžejní část celého systému spočívá v evidenci plateb a měli bychom tedy mít dobrou představu o tom, jací uživatelé budou k této části systému přistupovat a jaké budou moci provádět operace. Diagram použití pro modul „Finance“ si můžete prohlédnout na obrázku 5. V diagramu není zobrazen administrátor systému a správní rada, protože tito uživatelé disponují plnými právy pro přístup ke všem informacím a funkcím systému FreeNetIS. V analýze jsem se dále zabýval částí systému pro správu prací a brigád a dále nového modulu

8

KAPITOLA 2. ANALÝZA SOUČASNÉHO STAVU pro přesměrování webového provozu. Diagramy užití pro tyto části najdete v příloze A – UML diagramy.

Obrázek 5: Diagram užití pro modul Finance.

2.3 Struktura databáze Nyní už máme jasnou představu o obecné struktuře systému, jeho hranicích a interakcí systému s uživateli. Dalším krokem je návrh databáze, který byl proveden už před začátkem vývoje samotného systému v diplomových pracích [4] a [5]. Celé schéma databáze v současné době obsahuje 23 tabulek pro phpGACL a téměř 60 dalších tabulek pro strukturu systému, od počátečního návrhu tedy přibylo několik tabulek. Návrh databáze pro části členů a uživatelů, účtů, bankovních převodů a evidence prací je zobrazen na obrázku 6, přestože je to jen část z celé databáze. Druhou část návrhu databáze, která pokrývá modul Síť (zařízení, IP adresy, podsítě, rozhraní, segmenty, porty a VLANy) a třetí, poslední část zobrazuje strukturu databáze nových tabulek a jejich propojení. Oba diagramy si můžete prohlédnout na obrázkách 22 a 23 v příloze A – UML diagramy.

9

KAPITOLA 2. ANALÝZA SOUČASNÉHO STAVU

Obrázek 6: Návrh struktury databáze pro moduly Uživatel a Finance [4].

2.4 Diagramy tříd V poslední řadě jsou v analýze představeny diagramy tříd, které popisují strukturu systému jeho třídami, atributy a vztahy mezi nimi. Tyto diagramy mají z dříve zmíněných nejblíže k samotné implementaci kódu. Zjednodušený diagram tříd (resp. class diagram) je popsán v této kapitole, kompletní diagram naleznete v příloze A této práce.

10

KAPITOLA 2. ANALÝZA SOUČASNÉHO STAVU Obecně každé třídě odpovídá alespoň jeden kontrolér a měl by pro ni existovat i fyzický ekvivalent v reálném světě. Na následujícím diagramu (obrázek 7) jsou zobrazeny atributy a funkce pro třídy Oblast, Subnet (podsíť) a IP adresa. Každá podsíť je popsána svým jménem, síťovou adresou a maskou a dále obsahuje i proměnnou s identifikátorem oblasti, do které patří. Podsíť nemusí buď patřit k žádné oblasti anebo je přiřazena právě k jedné oblasti. Oblast má svůj název a správce oblasti, který má plná přístupová práva k informacím o oblasti. Může přidávat nové podsítě a generovat telefonní seznam pro danou oblast, resp. uživatele spadající do přidělených podsítí. Dále podsíť obsahuje libovolné množství IP adres, které disponují základními operacemi (zobrazit, editovat, smazat a přidat) a dále můžou být IP adresy monitorovány nebo přesměrovány.

Obrázek 7: Zjednodušený diagram tříd FreeNetISu.

2.5 Hierarchie adresářů V poslední části analýzy bych chtěl popsat strukturu adresářů a souborů systému FreeNetis. Ta je určena především frameworkem Kohana. Zjednodušená adresářová hierarchie vypadá přibližně následovně: – application – cache – config – controllers – helpers – hooks – i18n

11

KAPITOLA 2. ANALÝZA SOUČASNÉHO STAVU – libraries – logs – models – views – media – modules – system Prakticky největší část projektu se nachází v adresářích controllers, models a views, které odpovídají MVC architektuře zmíněné v kapitole 1.2.3 MVC. Za zmínku stojí dále adresář i18n, který obsahuje kompletní překlad celého systému z angličtiny do češtiny (systém je primárně psán v anglickém jazyce). V adresáři helpers se nacházejí pomocné funkce, které se v systému využívají častěji, ať už vlastní nebo z třetích stran. Nakonec v adresáři media jsou uložené obrázky a další soubory včetně šablon pro CSS (Cascading Style Sheet) a dále například skripty pro odesílání SMS zpráv ze systému.

12

KAPITOLA 3. NÁVRH ROZŠIŘUJÍCÍCH MODULŮ

3 Návrh rozšiřujících modulů V této kapitole je popsáno, jakým způsobem byly navrhovány a připravovány rozšiřující kontroléry a moduly pro FreeNetIS a k čemu by měly sloužit.

3.1 Sběr informací pro rozšiřující funkce Po analýze informačního systému máme přehled o současných funkcích i o struktuře celého projektu. FreeNetIS je nasazen v ostrém provozu pouze v jediném sdružení (UnArt Slavičín) a v dalších sítích se reálné nasazení teprve připravuje. Sám se pohybuji několik let v prostředí komunitní sítě o.s. HKFree, odkud jsem také čerpal informace pro chybějící funkce FreeNetISu. V síti HKFree je několik desítek správců sítě a nejen od nich jsem sbíral připomínky a podněty k novým modulům už jen z důvodu, že by zde mohl být FreeNetIS také potenciálně nasazen. V HKFree chybí totiž kvalitní informační systém a jeho absence je čím dál více patrná. Nicméně tyto požadavky musely být dále sladěny s principy současných vývojářů systému FreeNetIS, což nebylo vždy jednoduché. Analýza posloužila hlavně pro výběr nových funkcí a modulů implementovaných do systému FreeNetIS v této práci. Po rozboru je totiž patrné, že základní části systému jsou poměrně propracované, ani v návrhu databáze nebyly nalezeny žádné nedostatky. Nicméně nasazení FreeNetISu v dalších sítích brání především dvě věci. Systém stále ještě není dostatečně modulární a flexibilní, pro většinu sítí je totiž až přehnaně komplexní a vypnutí určitých modulů by bylo přínosem. A v druhé řadě chybí nějaká přidaná hodnota k základním funkcím. Zvláště druhý nedostatek jsem se snažil odstranit přidáním doplňujících funkcí, které velmi citelně chybí v síti o.s. HKFree a neexistuje žádná alternativa, která by nabízela podobné funkce bez propojení s informačním systémem. V prvním kroku jsem se snažil zdokonalit komunikaci v síti pomocí zpráv na přesměrovaných webových stránkách a dále zasíláním SMS zpráv přímo ze systému včetně vytváření telefonního seznamu. Generování konfiguračních souborů bylo zvoleno pro zjednodušení rutinních prací, které správci často zanedbávají a čas strávený u těchto záležitostí pro ně nemá žádný velký význam. Mezi základními vytyčenými vlastnostmi systému je i monitorování sítě, nicméně tato oblast je prozatím ve FreeNetISu zcela netknutá, proto jsem se zaměřil i na tuto problematiku. 13

KAPITOLA 3. NÁVRH ROZŠIŘUJÍCÍCH MODULŮ

3.2 Přesměrování webového provozu V síti se stovkami či dokonce několika tisíci uživateli je komunikace velmi důležitá. Největší komunitní sítě v České republice (například PilsFree z Plzně nebo KLFree z Kladna) se pohybují dokonce již na hranici 10 tisíc uživatelů. Základní komunikace přes maily v takto rozlehlých sítích však často selhává kvůli nefunkčním či přeplněným emailovým schránkám nebo kvůli prostému nezájmu uživatelů. Informování přes mobilní telefon není vždy vhodné a často pro malé sítě ani prakticky možné. Vyvinula se tedy potřeba informovat členy těchto sítí přímo přes webové rozhraní jejich internetových prohlížečů. Stěžejními úpravami byla tedy integrace takového mechanismu přímo do FreeNetISu – jedná se o modul pro přesměrování webového provozu. Jak takový systém pracuje? Celý mechanismus je obecně znázorněn na obrázku 8. Nejdříve se správce sítě přihlásí do systému (v našem případě FreeNetIS) a přihlášení je ověřeno buď s lokální databází anebo častěji oproti LDAP (Lightweight Directory Access Protocol) serveru. Po přihlášení správce zadá IP adresu, důvod přesměrování a případně i trvání a nakonec i volitelnou zprávu, která se zobrazí uživateli. Tato data se uloží do lokální databáze, se kterou se pravidelně synchronizuje centrální router Internet Gateway (IGW). Právě IGW může díky pravidlům IPTABLES zakázat přístup IP adresy do Internetu a místo toho podstrčit uživateli cílový web s připraveným sdělením. Uživatel po přečtení zprávy může kliknout na odkaz, přičemž se smaže záznam na lokální databázi a při příští synchronizaci s IGW se obnoví přístup do Internetu. Databáze nemusí být lokálně umístěná spolu s webovým serverem, ale v případě informačního systému tomu tak zpravidla bývá.

14

KAPITOLA 3. NÁVRH ROZŠIŘUJÍCÍCH MODULŮ

Obrázek 8: Komunikační schéma modulu pro přesměrování webového provozu.

3.3 Generování konfiguračních souborů Vesměs ve všech komunitních sítích musí správci provádět spoustu rutinní práce stále dokola. Jedná se například o správu DNS (Domain Name systém) záznamů zpětných i dopředných, aktualizace nejrůznějších konfiguračních souborů, zabezpečení připojení pro uživatele na kabelových LAN (Local Area Network) sítích i pro bezdrátově připojené členy. Společným rysem všech těchto konfiguračních souborů je, že obsahují redundantní informace, což vždy znamená duplicitní a tedy neefektivní práci. Neexistuje žádný volně dostupný software, který by uměl rozdistribuovat tyto informace do všech potřebných souborů a služeb. Na Internetu jsem našel pouze nástroj pro generování DNS zónových souborů, ale to nám tolik práce neušetří, protože další využití už s tímto nástrojem nenajdeme. Proto jsem se rozhodl

15

KAPITOLA 3. NÁVRH ROZŠIŘUJÍCÍCH MODULŮ zaintegrovat do FreeNetISu funkci generování konfiguračních souborů ze současných databází.

3.3.1 Zónové soubory DNS Zónové záznamy DNS jsou v sítích velmi důležité a přesto často podceňované. Častokrát narazíme na neaktuální záznam a v komunitních sítích je dokonce běžné, že většina záznamů chybí úplně. Přitom pro troubleshooting (zjišťování problému na síti) může být takový záznam i kriticky důležitý. Špatný stav DNS souborů je způsobený hlavně tím, že administrátoři zadají jednou údaje o uživateli do svého informačního systému a nechtějí znovu stejné informace vypisovat do dopředného DNS záznamu a následně i do zpětného. Přitom pro rekonstrukci těchto souborů nepotřebujeme nic víc, než IP adresu a doménové jméno, které lze snadno odvodit z uživatelského jména a přípojného místa v síti – tzv. cloudu nebo-li oblasti.

3.3.2 Konfigurační soubory DHCP Další důležitou službu, bez které se dnes prakticky už většinou vůbec neobejdeme, je přidělování IP adres a nastavení sítě pro koncovou stanici ze serveru automaticky, tedy DHCP (Dynamic Host Configuration Protocol). Oproti již zmíněným informacím potřebujeme navíc pouze fyzickou adresu nebo-li MAC (Media Access Control) adresu koncového zařízení, kterou už ale současná databáze FreeNetISu také obsahuje. Na LAN sítích, kde jsou připojené desítky počítačů je aktualizace konfiguračního souboru DHCP serveru velmi náročná. Navíc tato informace není definitivní a s každým nákupem nového počítače musí správci tyto záznamy znovu a znovu aktualizovat.

3.3.3 Zabezpečení MAC restrikcemi Velmi důležitou otázkou na síti je zabezpečení. Jednou z možností je tzv. MAC restrikce, nebo-li využití fyzické adresy a její svázání s IP adresou. Mohlo by se stát, že si neplatící (neaktivní) uživatel změní IP adresu na svém zařízení na cizí, která patří jinému avšak platícímu uživateli. Tím pádem mu bude fungovat Internet, přestože by k němu měl mít přístup zakázaný. To je sice obvykle hrubé porušení pravidel všech takových komunitních sítí,

16

KAPITOLA 3. NÁVRH ROZŠIŘUJÍCÍCH MODULŮ ale odhalení tohoto podvodu je poměrně náročné. Prakticky je to možné pouze na routeru za použití skriptů spolu s ARP (Address Resolution Protocol) tabulkou a ručním porovnáváním starších a aktuálních dvojic IP adresa – MAC adresa. MAC restrikce je velice dobrá prevence před těmito typy útoků. Nejúčinnější je tato ochrana, pokud je nasazena na nejbližším aktivním prvku směrem k uživateli. Na LAN sítích to bývá zpravidla switch. Bohužel managed switche, které takové zabezpečení umí, jsou oproti obyčejným mnohonásobně dražší. Proto v levnějších a méně kvalitních sítích lze MAC restrikce uplatnit až na routerech. Sice se tímto kvalita zabezpečení mírně degraduje, protože ji lze obejít odposlechem na síti a změnou jak IP adresy tak i fyzické adresy na síťové kartě, ale přesto většinu útočníků odradí. Pokud se správci rozhodnou MAC restrikci použít v praxi, je velmi důležité udržovat svázané dvojice aktuální. V opačném případě by byla ochrana buď děravá a neefektivní, anebo by aktivní platící uživatelé neměli přístup do Internetu. Ruční správa takového zabezpečení připadá tedy v úvahu pouze na malých sítích s maximálně několika desítkami stanic.

3.4 Monitorování sítě V každé síti musí fungovat nějaký monitoring, jinak bychom vůbec neměli představu, jak hodně je síť vytížená, zda funguje vše jak má, a jak brzy budeme muset infrastrukturu obměnit novým hardwarem. Nástrojů pro monitoring a grafování sítě je k dispozici poměrně hodně. Namátkou můžu jmenovat například dříve oblíbený HotSaNIC, který se ovšem později přestal dále vyvíjet, nebo flexibilní MRTG (The Multi Router Traffic Grapher), který podobně jako HotSaNIC pomocí protokolu SNMP (Simple Network Management Protocol) sbírá data ze zařízení a následně vykresluje grafy. MRTG se nespecializuje pouze na sledování provozu na síti, ale umí měřit spoustu dalších parametrů od zatížení procesoru a zaplněnosti pevného disku až po teploty, rychlosti větru atd.

17

KAPITOLA 3. NÁVRH ROZŠIŘUJÍCÍCH MODULŮ

Obrázek 9: Modelování sítě v nástroji Nagios Map [12]. Kvalitní open source systém pro monitorování sítí a služeb je Nagios [13], který nabízí poměrně komplexní služby. Výhodou je velké množství rozšiřujících pluginů od nejrůznějších vývojářů, protože Nagios je vyvíjen pod licencí GPL. Umí monitorovat služby jako POP3, HTTP, SMTP, ICMP a další. Oproti ostatním nástrojům bych ještě vyzdvihl funkci modelování sítě, kterou pak lze procházet. Na druhou stranu je konfigurace mnohem komplikovanější než u ostatních monitorovacích nástrojů a systém má větší hardwarové nároky. Nagios například umožňuje zasílat výstražné zprávy administrátorům na e-mail, ICQ komunikátor nebo mobilní telefon při zjištěném problému na síti.

18

KAPITOLA 3. NÁVRH ROZŠIŘUJÍCÍCH MODULŮ

Obrázek 10: Měření vytížení CPU nástrojem Cacti. Velmi populární je v poslední době také nástroj Cacti [14], který využívá RRDTool stejně jako dříve HotSaNIC. Cacti je mnohem rychlejší a přehlednější než jeho předchůdce. V obrázku 10 si můžete prohlédnout, jak například může vypadat graf pro měření vytíženosti routeru či serveru. V základní verzi dochází k podstatnému zkreslení grafů. Záleží totiž na hustotě vzorkování a vytváření grafů a při větších časových obdobích se uvažují průměry, což není úplně korektní. Při častém vzorkování potřebuje Cacti větší výpočetní výkon zatímco při nižší hustotě vzorkování se na grafech ztratí „špičky“ provozu, které mají velkou informační hodnotu pro správce sítí. Nepřesnost grafů v delším časovém horizontu se dá napravit až s použitím zásuvného modulu pro zobrazování maximálních dosažených hodnot v grafu. Takový graf můžete vidět na obrázku 11.

Obrázek 11: Korekce grafu v delším časovém období pomocí pluginu. 19

KAPITOLA 3. NÁVRH ROZŠIŘUJÍCÍCH MODULŮ Stejně jako pro Nagios [13] tak i pro Cacti existuje poměrně velké množství rožšiřujících modulů. Za zmínku stojí rozhodně plugin Weathermap [15], který umožňuje vizualizaci mapy sítě spolu s přehledným vytížením jednotlivých částí infrastruktury přímo v grafickém rozhraní Cacti (obrázek 12). Nástroj Weathermap lze ovšem provozovat i samostatně bez nasazení Cacti, protože umí pracovat přímo s RRDTool i MRTG.

Obrázek 12: Plugin Weathermap v monitorovacím nástroji Cacti. Jednoznačně nejoblíbenějším nástrojem pro měření latence a packetloss (ztrátovost paketů) na síti je SmokePing [16]. Stejně jako většina ostatních monitorovacích programů i SmokePing využívá RRDTool backend pro vykreslování grafů. Oproti většině ostatních nástrojů pro monitoring latence SmokePing neudává pouze průměrné hodnoty, ale pomocí různých stupňů šedé zobrazuje i minimální a maximální naměřené hodnoty. Dalším měřeným údajem je i procentuálně zobrazovaná ztrátovost paketů, jak je vidět na obrázku 13.

20

KAPITOLA 3. NÁVRH ROZŠIŘUJÍCÍCH MODULŮ

Obrázek 13: Nástroj SmokePing pro měření latence a packetloss. Administrátoři sítě by měli být informováni jak o spolehlivosti sítě, kterou nejlépe vystihuje latence a packetloss, tak i o kvalitě a propustnosti sítě, znázorněné na grafech provozu. Nejčastějším řešením je tedy buď nasazení Nagiosu, který pokrývá nároky většiny uživatelů, anebo paralelní provozování SmokePingu a nějakého nástroje pro grafování, jako je MRTG nebo Cacti. V síti, kde chceme monitorovat desítky nebo dokonce i stovky uzlů, je ruční správa takových souborů poměrně zdlouhavá. V modulu monitorování sítě v informačním systému FreeNetIS jsem se rozhodl pro integraci generátoru konfiguračního souboru nástroje SmokePing.

3.5 Zálohování síťové konfigurace Díky kvalitnímu monitoringu počítačových sítí administrátoři dokáží rychle zjistit, zda vše funguje v pořádku, nebo jestli se vyskytl v síti problém. Hardwarová závada nějakého zařízení bývá nejčastější příčinou výpadku. Podstatnou část opravy závady zabere nová konfigurace náhradního zařízení. Při špatné dokumentaci sítě je často velmi náročné nebo téměř nemožné ihned vše uvést do pořádku. Pro takové případy slouží zálohování síťové konfigurace. Nicméně i záloha konfigurace musí být aktuální. V komunitních bezdrátových sítích v České republice dominují 2 architektury. Linuxové systémy se běžně používají na PC routerech, případně na CF kartách spolu s levnějším hardware jako jsou desky Alix nebo RouterBOARD. Linuxu velmi dobře v posedních letech konkuruje čistě proprietární systém 21

KAPITOLA 3. NÁVRH ROZŠIŘUJÍCÍCH MODULŮ RouterOS pro RouterBOARD od firmy Mikrotik. RouterOS je uzavřený systém s grafickým rozhraním vyvíjený přímo výrobcem RouterBOARDů.

3.5.1 Zálohování Linuxu Zdaleka nejpopulárnější zálohovací open source nástroj nejen pro Linuxové systémy je Bacula. Je to sada programů, která umožňuje spravovat zálohování, obnovu a verifikaci dat přes síť a to na počítačích různých druhů, podporuje Linux, UNIX i Windows. Bacula automaticky vytváří zálohy a ukládá je do SQL databází. To zjednodušuje celou situaci administrátorovi při obnovování systému nebo jen části jeho konfigurace. V otázce zabezpečení je Bacula velmi důsledná, umožňuje kryptování na síti přes TLS (Transport Layer Security), autentizaci MD5 (Message-Digest algorithm 5), kontrolu integrity souborů přes MD5/SHA (Secure Hash Algorithm) i šifrování uložených dat přes PKI (Public Key Infrastructure). Nastavení klienta pro Bacula je přímo triviální záležitostí, pouze musí admininistrátoři dbát na správné zaheslování přístupu k serveru. Pravidelné zálohování se pak nastavuje pomocí plánovače cron na straně serveru.

3.5.2 Zálohování RouterOS Firma Mikrotik, která vyrábí desky RouterBOARD a potřebné příslušenství se stará zároveň o vývoj nativní operačního systému RouterOS. V podstatě se jedná o grafické uživatelské rozhraní pro jednoduché nastavení systému. Detailnější nastavení může být provedeno přes konzoli (telnet nebo SSH). Přes grafické rozhraní lze celkem jednoduše vygenerovat a uložit konfigurační soubor nebo stejně tak jinou konfiguraci importovat (viz obrázek 14). Oproti zálohování například v Bacula zde neexistuje možnost automatického zálohování, což bývá v sítích kámen úrazu. Na tento problém jsem se proto zaměřil při implementace nadstavbových funkcí FreeNetISu.

22

KAPITOLA 3. NÁVRH ROZŠIŘUJÍCÍCH MODULŮ

Obrázek 14: Export a import konfigurací v RouterOS.

3.6 Posílání SMS zpráv Informování uživatelů přes přesměrovaný web má své výhody ale i nevýhody a stejně tak tomu je i s komunikací přes textové zprávy SMS. Pro malé sítě je to pravděpodobně velký luxus, který si nemohou dovolit. Ať už je to vlastnictví vlastní GSM gateway nebo outsourcování adekvátní firmě. U středně velkých a rozlehlých sítích je to však dobrá alternativa pro spojení s uživateli sítě. Ze všech možností je právě posílání SMS zpráv nejrychlejším způsobem, jak sdělit stručně důležité informace. Informační systém obsahuje veškeré údaje potřebné pro zprovoznění této komunikace. Implementací funkce pro zasílání SMS zpráv přes externí GSM gateway a vytváření telefonních adresářů pro rychlý přístup správců ke všem telefonním číslům je popsán dále v kapitole 4.5 Kontrolér pro SMS komunikaci.

3.7 Vrstva pro komunikaci s externími systémy Jak už bylo řečeno dříve, většina komunitních sítí má v dnešní době vlastní více či méně funkční informační systémy. Vzhledem k nedostatku lidských zdrojů v těchto sítích nevznikají velké komplexní systémy, ale spíše menší projekty a aplikace, které využívají data z informačního systému, pro vlastní potřeby. Nejčastějším případem je využití uživatelského 23

KAPITOLA 3. NÁVRH ROZŠIŘUJÍCÍCH MODULŮ jména a hesla pro přihlášení do jiných aplikací. Dalším příkladem může být import použitých IP adres pro generování schématu využití adresního prostoru apod. Nejjednodušší formou spolupráce s informačním systémem je bezesporu přístup přímo do databáze. Taková varianta je ale nejvíce nebezpečná kvůli možnému zneužití a bohužel i nejrozšířenější díky své jednoduchosti. V případě FreeNetISu bychom se chtěli takto laickému přístupu vyhnout. Chceme sice nabídnout možnou kooperaci i s jinými systémy, ale ne za cenu bezpečnostní trhliny. Druhou možností je vytvoření samostatné vrstvy pro komunikaci s externími aplikacemi. Pravděpodobně nejznámějším protokolem je SOAP (Simple Object Access Protocol). Slouží pro výměnu zpráv založených na jazyce XML (eXtensible Markup Language). Formát SOAP tvoří základní vrstvu komunikace mezi webovými službami a poskytuje prostředí pro tvorbu složitější komunikace. Největší slabinou je ale přílišná složitost a velký zápis komunikace. V našem případě by řešení pomocí SOAPu bylo přehnaně komplikované. Mnohem vhodnější je pro naše použití architektura REST (Representational State Transfer) navržená pro distribuované prostředí mezi klienty a servery – ovšem opravdu se jedná „pouze“ o architekturu, nikoliv o protokol. REST je na rozdíl od SOAPu orientován datově (nikoliv procedurálně). Webové služby definují vzdálené procedury a protokol pro jejich volání, REST určuje, jak se přistupuje k datům [17]. Rozhraní REST používá čtyři základní metody CRUD (Create Retrieve Update Delete) pro přístup ke zdrojům (resources), kterými mohou být samotná data nebo stavy aplikace. Metodám CRUD po řadě odpovídají standardní http metody POST, GET, PUT a DELETE. Architektura REST poskytuje oproti jiným alternativám výhody, jakými jsou jednoduchost a nenáročnost a spolu s bezestavovostí vychází vstříc moderním metodám vývoje webových distribuovaných aplikací [18]. Proto i pro FreeNetIS jsem se rozhodl právě pro REST jakožto vrstvu, která poskytuje zdroje (data) externím spolupracujícím systémům a aplikacím.

24

KAPITOLA 4. IMPLEMENTACE ROZŠIŘUJÍCÍCH MODULŮ

4 Implementace rozšiřujících modulů V této kapitole je vysvětlen postup při řešení problémů zmíněných v kapitole 3. Důraz je kladen na samotnou implementaci modulů do informačního systému FreeNetIS v prostředí framworku Kohana.

4.1 Modul pro přesměrování webového provozu V kapitole 3.2 Přesměrování webového provozu byl nastíněn proces, kterým by mělo docházet ke komunikaci s uživateli důraznějším způsobem než pouhým zasíláním informačních e-mailů. Celý tento mechanismus byl zaintegrován do FreeNetISu pouze s drobnými odchylkami. Správce oblasti nebo administrátor se přihlásí do systému a přihlášení se ověřuje proti lokální databázi. Tady stojí za pozornost systém přístupových práv implementovaný pomocí knihoven phpGACL (Generic Access Control Lists).

4.1.1 Přístupová práva phpGACL Knihovny phpGACL poskytují sadu funkcí pro řízení přístupu uživatelů k libovolným objektům (webové stránky, databáze atd.). Projekt je vyvíjen pod licencí GPL a tedy je volně dostupný ke stažení na webu sourceforge.net [1]. Systém přístupových práv pomocí phpGACL je poměrně složitý, nicméně nabízí velmi široké možnosti a flexibilitu při nastavování uživatelských práv. Přístupová práva jsou obyčejně řízena dvěma základními tabulkami. ACO (Access Control Objects) jsou objekty, ke kterým chceme přistupovat (různé webové stránky, moduly či funkce ve FreeNetISu). Tabulka ARO (Access Request Objects) zahrnuje uživatele, kteří přistupují ke zmíněným objektům. Díky takové struktuře můžeme jednoduše vidět, kdo má přístup k jakým objektům a stránkám a můžeme spravovat jednotlivé přístupy pro individuální uživatele. Nevýhodou je pak velmi náročná správa u rozsáhlejších tabulek přístupových práv. Ucelený souhrn nebo vizualizace práv je téměř nemožná u projektů, které mají třeba i stovky nebo tisíce záznamů v ACO a ARO tabulkách.

25

KAPITOLA 4. IMPLEMENTACE ROZŠIŘUJÍCÍCH MODULŮ PhpGACL tuto základní architekturu rozšiřuje o ARO strom, který definuje skupiny ARO objektů (ARO Groups). Počet pravidel se pak radikálně snižuje. Navíc zde existuje volitelná tabulka AXO (Access eXtension Object), díky které můžeme přidat do přístupových práv 3. rozměr. V informačním systému FreeNetIS nám dovoluje taková struktura definovat přístupová práva pro uživatele (ARO), kteří přistupují k objektům (ACO) a můžou je zobrazovat, editovat nebo mazat (AXO).

4.1.2 Mechanismus přesměrování Po přihlášení může správce sítě, pokud má dostatečná přístupová práva, vstoupit do modulu pro přesměrování webového provozu. Kromě unikátní IP adresy lze přesměrovat také rozsah IP adres (od – do), dále podsíť IP adres definovaný maskou podsítě a nebo také konkrétního uživatele, resp. všechny jeho IP adresy. Konkrétně varianta přesměrování subnetu využívá informací v současné databázi FreeNetISu, a tak má správce na výběr přímo z existujících podsítí. U přesměrování uživatele je nutné znát jeho identifikační číslo (ID). Trvání přesměrování může být na dobu neurčitou, do konce měsíce, do konce dne nebo na konkrétní počet hodin s tím, že uživatel může, ale i nemusí mít možnost vpustit se sám do Internetu. Kontrola platnosti těchto intervalů se provádí pomocí crontabu přímo na serveru. Každý měsíc, resp. den se spustí speciální webová stránka, která se stará o smazání příslušných záznamů z databáze. Navíc každou hodinu ještě dochází k dekrementaci počtu zbývajících hodin přesměrování. Záznam v crontabu vypadá přibližně následovně: 0 0 1 * * /usr/bin/wget -O - -q http://freenetis.hkfree.org/cron_monthly.php 0 0 * * * /usr/bin/wget -O - -q http://freenetis .hkfree.org/cron_daily.php 0 * * * * /usr/bin/wget -O - -q http://freenetis .hkfree.org/cron_hourly.php Přesměrování se provádí na určitý cílový web (zavirovaný počítač, rozesílání spamu, porušení pravidel sítě atd.). Každý má svoji předvyplněnou (globální) zprávu. O tento mechanismus globálních zpráv se stará samostatný kontrolér a zpráv může být v systému libovolné množství. Pro jeden cílový web ale může být v daném okamžiku aktivní pouze jediná globální zpráva. Kromě těchto hlavních zpráv, které jsou společné pro celou síť, může správce přiložit k přesměrování ještě vlastní zprávu, která je aktuální například pouze pro konkrétní případ přesměrování. 26

KAPITOLA 4. IMPLEMENTACE ROZŠIŘUJÍCÍCH MODULŮ Dalším nastavením je zasílání e-mailů správcům sítě po vypršení či ukončení přesměrování. Správce má tedy přehled, zda uživatel přesměrovaný web s informacemi četl či jenom vypršel časový limit. Zároveň se ve výpisovém e-mailu zobrazí i komentář, ve kterém si správce mohl poznamenat nějakou poznámku pouze pro sebe (například podrobnosti, proč nechal IP adresu přesměrovat). Posledním nastavením je uzamčení přesměrování. To slouží k zabezpečení záznamu pouze pro správce, který přesměrování vytvořil nebo mu v editaci nastavil příznak zámku. Nikdo jiný tak nemůže zjistit osobní zprávu od správce či jiné podrobnosti, ani nemůže nijak toto přesměrování upravovat.

Obrázek 15: Přesměrování IP adresy v informačním systému FreeNetIS. Na straně serveru s informačním systémem FreeNetIS máme tedy vždy aktuální databázi přesměrovaných IP adres, se kterou se pravidelně synchronizuje centrální router (Internet Gateway). Na něm se crontabem spouští například každých 5 minut perlovský skript, který se stará o aktualizaci tabulek iptables. Právě pomocí iptables s doplněnými údaji z databáze FreeNetISu (IP adresy) dochází k přesměrování na centrálním IGW routeru. Celý příkaz iptables vypadá přibližně následovně: iptables -A FREENETIS -s $ip -p tcp -m tcp --dport 80 -j DNAT –to-destination $dest 27

KAPITOLA 4. IMPLEMENTACE ROZŠIŘUJÍCÍCH MODULŮ Podle požadavků správců z praxe ještě takovýto systém přesměrování není dokonalý. Velmi důležité a prozatím chybějící nastavení je opakování přesměrování. Tzn. pokud je uživatel například opakovaně přesměrovaný do konce dne, tak při prvním spuštění webového prohlížeče se mu každý den zobrazí přesměrovaný web až do zrušení správcem. Většina uživatelů totiž byla schopná web odkliknout bez valné pozornosti, ale při opakovaném zobrazení zprávy již uživatelé věnovali pozornost obsahu. Druhou chybějící funkcí je formulář pro zpětný feedback od uživatele. Častokrát totiž správce nepotřebuje uživateli pouze něco sdělit, ale očekává i nějakou zpětnou odezvu. Nejjednodušší taková komunikace může být zajištěna formulářem pro odeslání zprávy přímo na přesměrovaném webu FreeNetISu. Uživateli tak odpadá starost se sháněním telefonního čísla nebo e-mailové adresy správce. Navíc někteří uživatelé ani nemají vlastní e-mailovou schránku pro komunikaci a za telefon nechtějí utrácet. Obě tyto funkce už jsou ve vývojové verzi a brzy budou nasazeny do ostrého provozu FreeNetISu.

4.2 Kontrolér pro generování konfiguračních souborů Pro generování konfiguračních souborů v informačním systému FreeNetIS byl vytvořen kontrolér config_files.php, který byl začleněn do modulu Síť. Skládá se z 5 komponent – generování DHCP konfiguračních souborů, dopředných a zpětných DNS zónových souborů, bezpečnostních MAC restrikcí a poslední komponenta se týká nastavení. V nastavení může administrátor systému určit globální parametry pro všechny výše zmíněné generátory. Jedná se o centrální DNS servery, name servery, exchange server, čas vypršení DHCP lease a další časové konstanty pro DNS servery. Pokud chce správce sítě vygenerovat konkrétní soubor, může sice tyto přednastavené hodnoty změnit, ve většině případů ovšem vůbec není potřeba se tím zdržovat a stačí jednoduše vygenerovat výsledný soubor pomocí několika málo kliknutí.

28

KAPITOLA 4. IMPLEMENTACE ROZŠIŘUJÍCÍCH MODULŮ

4.2.1 Generování zónových souborů DNS DNS zónový soubor obsahuje zdrojové záznamy a struktura souboru je popsána v RFC 1035. Nejčastěji se používá server BIND a záznamy se v něm skládají z doménového jména, životnosti, která určuje dobu platnosti záznamu, ze třídy určující rodinu protokolů (nejčastěji IN pro Internet), typu (A, PTR, CNAME atd.) a dalších parametrů. Generování zónových souborů DNS je rozdělené na dopředné a zpětné (resp. reverzní) záznamy. U zpětných záznamů se pracuje s IP prefixy podsítí, protože běžně zpětný soubor pokrývá právě jednu podsíť o rozsahu /24 (tedy 24 bitů v adrese přísluší adrese sítě a 8 bitů je variabilních pro adresy hostů v protokolu IPv4), zatímco u dopředných záznamů se pracuje se souborem těchto podsítí. Resp. každá oblast ve freenetu zpravidla má právě jeden takový dopředný zónový soubor, který obsahuje všechny použité podsítě v oblasti.

4.2.2 Generování zpětných DNS zónových souborů Speciálním typem zdrojového záznamu pro zpětné záznamy je pointer (PTR). Tento typ obsahuje jméno hosta (typicky počítač) po pravé straně přidělené adrese po levé straně. Základní informace pro vygenerování zpětného záznamu je IP prefix. Ve FreeNetISu existuje v databázi tabulka se seznamem podsítí, které mají však různou velikost. Nejčastěji jsou to podsítě o velikosti 24 (/24) až 29 (/29) bitů. Z těchto podsítí je vytvořen seznam IP prefixů, ve kterých uvažujeme pouze první 3 oktety adresy. Například z podsítě 10.20.30.0/26 do seznamu importujeme pouze část 10.20.30, tím docílíme toho, že seznam obsahuje pouze podsítě o velikosti 24 bitů (/24) a navíc se mažou duplicitní záznamy. Tedy v našem případě by podsíť 10.20.30.64/26 nevytvořila další položku v seznamu IP prefixů, ale byla by zahrnuta v již vytvořeném záznamu 10.20.30. Aby byly názvy podsítí korektní, měly by obsahovat 4 oktety a velikost masky, tedy pro náš případ by byl záznam 10.20.30.0/24, nicméně poslední oktet i masku lze již z principu vynechat, protože všechny záznamy IP prefixů mají stejnou velikost. Z takto vytvořeného seznamu si správce sítě vybere odpovídající IP prefix pro jeho oblast. V pokročilém nastavení generování zpětných DNS zónových souborů jsou ostatní hodnoty implicitně vyplněny z globálního nastavení od administrátora systému. Správce sítě může

29

KAPITOLA 4. IMPLEMENTACE ROZŠIŘUJÍCÍCH MODULŮ v případě potřeby editovat potřebné parametry pro vlastní potřeby, ale ve většině případů je to téměř zbytečné. Jedná se například o refresh time, tedy dobu v sekundách mezi aktualizacemi sekundárních a slave DNS serverů, nebo TTL (Time To Live), což je počet sekund, kdy je doménové jméno uloženo v paměti cache před expirací a tedy následnou aktualizací od autoritativního DNS serveru. V kontroléru config_files.php se o generování zpětného DNS souboru starají funkce dns_reverse( ) a generate_dns_reverse( ). První se stará o tvorbu seznamu IP prefixů, vyplnění formuláře a validaci vložených dat, zatímco druhá vytváří samotný obsah souboru. V generate_dns_reverse( ) se čas v sekundách převádí na lépe čitelný údaj převodem na hodiny, dny a týdny. Následně se z databáze přečtou všechny existující IP adresy spadající do dotyčného prefixu a ke každé adrese se přiřadí jméno uživatele, kterému je adresa přidělena. Výsledný zónový soubor může vypadat například následovně: 37.107.10.in-addr.arpa IN SOA ns.hkfree.org. root.pmv.hkfree.org. ( 2010031401 ; serial 10800 ; refresh (3 hours) 3600 ; retry (1 hour) 604800 ; expire (1 week) 86400 ; minimum (1 day) ) NS ns2.hkfree.org. NS ns.hkfree.org. $ORIGIN 37.107.10.in-addr.arpa. $TTL 43200 ; 12 hours 1 PTR kocourkov.hkfree.org. 50 PTR sappe.kocourkov.hkfree.org. 51 PTR sappe-ap.kocourkov.hkfree.org. 52 PTR jakubickova.kocourkov.hkfree.org. 53 PTR sichrovska.kocourkov.hkfree.org. Výše bylo vysvětleno téměř vše z obsahu zpětného DNS souboru, ale chtěl bych ještě zdůraznit proměnnou serial. Tato hodna musí být s každou změnou v DNS souboru inkrementována (platí i pro dopředné záznamy). Obvykle se do parametru serial vyplňuje aktuální datum ve tvaru YYYYMMDDXX, kde Y označuje rok, M měsíc, D den a X se používá pro inkrementaci v rámci jednoho dne. Při první změně toho dne bude hodnota XX rovna 00, ale při každé další změně ve stejný den se musí hodnota zvýšit o 1. Pokud je hodnota serial nižší než v předchozích verzích, změny se na serveru neprojeví.

30

KAPITOLA 4. IMPLEMENTACE ROZŠIŘUJÍCÍCH MODULŮ

4.2.3 Generování dopředných DNS zónových souborů Nejčastějšími typy zdrojových záznamů v dopředných DNS zónových souborech jsou typy A, AAAA a CNAME. Typ A (Address Record) přiřazuje IPv4 adresu danému jménu a používá se tak v naprosté většině případů. Typ AAAA (Ipv6 Address Record) provádí totéž co typ A, ale jménu přiděluje adresu Ipv6. Typ CNAME (Canonical Name Record) nepřiřazuje IP adrese žádné nové jméno ale pouze vytváří alias pro již existující doménové jméno. Jak už bylo řečeno v podkapitole 4.2.1, generátor dopředných DNS zónových souborů nepracuje s jednotlivými podsítěmi, nýbrž se souborem takových podsítí, které náleží jedné oblasti (cloudu). Přestože naprostá většina freenetů v České republice se dělí na autonomní oblasti, tato organizační struktura ve FreeNetISu prozatím úplně chyběla. Pro každou takovou oblast potřebujeme úplný seznam použitých podsítí. Proto byl vytvořen kontrolér clouds.php, ten je však rozebrán dále v podkapitole 4.2.4 Kontrolér pro správu oblastí. Seznam oblastí je pro generování dopředných DNS souborů stěžejní předpoklad. Pokročilé nastavení se nijak neliší od zpětných DNS souborů a bylo již popsáno v podkapitole 4.2.2 Generování zpětných DNS zónových souborů. Více informací pro generování výsledného souboru nepotřebujeme, vše již existuje v současných databázích FreeNetISu. Analogicky ke zpětným DNS souborům se zde používá funkce dns_forward( ) pro vyplňování formuláře, validaci dat a export souboru ke stažení uživateli. Důležitější je ale funkce generate_dns_forward( ), ve které se získávají data z databáze (IP adresy, uživatelská jména, podsítě atd.) a vytváří se finální soubor, který vypadá orientačně následovně: kocourkov.hkfree.org. IN SOA charon.hkfree.org. pmv.root.hkfree.org. ( 2010033100 ; serial 28800 ; refresh (8 hours) 7200 ; retry (2 hours) 604800 ; expire (1 week) 86400 ; minimum (1 day) ) NS ns.hkfree.org. NS ns2.hkfree.org. MX 10 relay.hkfree.org. admin

A A A

10.107.37.1 10.107.37.95 10.107.37.129 31

KAPITOLA 4. IMPLEMENTACE ROZŠIŘUJÍCÍCH MODULŮ pepa karel

A A

10.107.37.130 10.107.37.151

4.2.4 Kontrolér pro správu oblastí Správa oblastí (nebo-li cloudů) slouží v informačním systému FreeNetIS jako organizační struktura. Byla vytvořena kvůli potřebě uceleného seznamu pro dopředné DNS zónové soubory, nicméně využití může být v budoucnu mnohem širší. Každá oblast má svoje ID, jméno a právě jednoho správce oblasti. Dále může mít libovolný počet zástupců oblasti. Nejdůležitější je ovšem přidělení podsítí. Buď může administrátor přidělit do oblasti již existující podsítě, které nejsou přiřazeny k žádné oblasti, anebo může vytvořit podsítě nové. Výpis podsítí přidělených k určité oblasti ve FreeNetISu je zobrazen na obrázku 16. Když máme u oblasti přidělené podsítě, jednoduše můžeme pomocí toho vygenerovat dopředný DNS záznam, jak bylo popsáno v kapitole 4.2.3.

Obrázek 16: Uživatelské rozhraní konkrétní oblasti ve FreeNetISu.

4.2.5 Generování konfiguračních souborů DHCP DHCP (Dynamic Host Control Protocol) slouží pro automatické přidělování síťové konfigurace koncovému zařízení (počítač, domácí router, mobil atd.). U bezdrátových sítí ve struktuře AP – klient nastává většinou problém. Velká část hardwarových klientů totiž 32

KAPITOLA 4. IMPLEMENTACE ROZŠIŘUJÍCÍCH MODULŮ nemá správně implementovaný mód bridge a na 2. (spojové) vrstvě komunikuje s AP vlastní fyzickou (MAC) adresou namísto fyzické adresy skutečného koncového zařízení. Takový bridge tedy není skutečně transparentní. V důsledku toho při DHCP requestu dorazí na router (AP) žádost o IP adresu od neznámé fyzické adresy (hardwarového klienta). V dnešní době převažuje již ale připojení po metalickém či optickém kabelu na LAN sítích v domech. S routerem, který slouží jako DHCP server, tedy skutečně komunikují přímo koncová zařízení (většinou počítače). Pro konfigurační soubor DHCP serveru potřebujeme především dvojice fyzické a IP adresy koncové stanice, dále bránu (gateway) a DNS servery (primární a sekundární). To vše je již obsaženo v současných databázích FreeNetISu. Pro kompletní soubor tedy pouze vybereme seznam podsítí, na kterých chceme DHCP službu spustit (v rámci jednoho serveru). Jako doplňkové informace ještě potřebujeme znát lease time a maximal lease time, což jsou časy, po které klient smí používat přidělenou IP adresu. Obě hodnoty vyplňuje administrátor systému v obecném nastavení generování konfiguračních souborů a jednotliví správci si můžou tyto hodnoty podle potřeby upravit. V PHP funkci dhcp( ) dochází k validaci formuláře a exportu souboru dhcpd.conf pro uživatele ke stažení, zatímco funkce generate_dhcp( ) se stará o tvorbu samotného souboru a využívá podpůrnou funkci dhcp_subnet( $subnet_id ), která vypočítává z IP adresy sítě a masky broadcastovou adresu a vytváří bloky group, které se skládají z uživatelského jména, fyzické adresy a IP adresy. Výsledný DHCP konfigurační soubor vypadá přibližně následovně. boot-unknown-clients false; one-lease-per-client true; default-lease-time 2400; max-lease-time 7200; option domain-name-servers 10.107.4.100, 10.107.4.129, 10.107.3.1; option domain-name "hkfree.org"; authoritative; subnet 10.107.37.0 netmask 255.255.255.128 { option routers 10.107.37.1; option broadcast-address 10.107.37.127; group { host pepa2-1 { hardware ethernet 00:00:00:00:11:23; fixed-address 10.107.37.95; } 33

KAPITOLA 4. IMPLEMENTACE ROZŠIŘUJÍCÍCH MODULŮ host pepa-2 { hardware ethernet 12:34:56:78:9a:bc; fixed-address 10.107.37.101; } } }

4.2.6 Generování MAC restrikcí Jak již bylo vysvětleno v kapitole 3.3.3 Zabezpečení MAC restrikcemi, MAC restrikce slouží pro zabezpečení počítačových sítích. Na Linuxových PC routerech je pro tento účel nejvhodnějším nástrojem IPTABLES. Pomocí něho se povolí pro každou fyzickou adresu jen konkrétní IP adresa a všechny ostatní se zakážou. Všechna taková pravidla se pak společně uloží do bash skriptu a spustí se na routeru pro aktualizaci. Aby nevznikala duplicita pravidel, je potřeba staré záznamy vyřadit pomocí příkazu iptables -F FORWARD, případně lze vytvořit vlastní chain. Pomocí chainů lze optimalizovat složitější firewall s mnoha pravidly, pokud jsou na routeru využívány iptables i k jiným účelům než pro MAC restrikce vygenerované FreeNetISem. Mezi defaultní chainy patří PREROUTING, POSTROUTING, FORWARD, INPUT a OUTPUT. Funkce mac_restriction( ) ve FreeNetISu pouze pro zvolenou podsíť sváže podle šablony dvojice fyzických a IP adres a předá funkci generate_mac_restriction( ), která výsledný skript vygeneruje pomocí dat z existujících databází. Výsledný vygenerovaný skript s MAC restrikcemi si můžete prohlédnout. #!/bin/sh iptables -F FORWARD #pepa iptables -I FORWARD -m mac --mac-source 00:00:00:00:11:22 -j REJECT iptables -I FORWARD -s 10.107.37.103 -m mac --mac-source 00:00:00:00:11:22 -j ACCEPT #pepa2 iptables -I FORWARD -m mac --mac-source 00:00:00:00:11:23 -j REJECT iptables -I FORWARD -s 10.107.37.95 -m mac --mac-source 00:00:00:00:11:23 -j ACCEPT #pepa iptables -I FORWARD -m mac --mac-source 12:34:56:78:9a:bc -j REJECT iptables -I FORWARD -s 10.107.37.101 -m mac --mac-source 12:34:56:78:9a:bc -j ACCEPT

34

KAPITOLA 4. IMPLEMENTACE ROZŠIŘUJÍCÍCH MODULŮ

4.3 Kontrolér pro monitorování sítě Možnosti monitorování sítě a její důležitost byla již vysvětlena v kapitole 3.4 Monitorování sítě. I kontrolér monigoring.php byl zařazen ve FreeNetISu do modulu Síť. Rozhodl jsem se zabudovat do systému funkci, která by vytvářela konfigurační soubor pro monitorovací nástroj Smokeping. Soubor smokeping.cfg, který je pro monitorování latence a dostupnosti klíčový, se skládá z obecného nastavení a seznamu kontrolovaných hostů. V obecném nastavení můžeme nastavit časové intervaly jak pro získávání dat tak i pro jejich zobrazování v grafech nebo třeba velikosti posílaných paketů. Zde většinou není potřeba nic měnit a zatím to současná verze FreeNetISu ani neumožňuje. Mnohem důležitější je druhá část, která obsahuje prakticky seznam hlídaných adres v podobě stromové struktury. V ní můžeme nalézt dva typy záznamů – koncové stanice, které chceme monitorovat a uzly, které obsahují jak samotné stanice tak i další poduzly. Od toho se odvíjí i uživatelské rozhraní kontroléru monitoring.php ve FreeNetISu. Nejprve můžeme přidat „položku menu Smokepingu“ (tedy uzel), která obsahuje parametry Menu, Title a Parent. Menu označuje název položky v levém sloupci nabídky Smokepingu, kterou si můžete prohlédnout na obrázku 17. Title je nadpis v seznamu grafů, resp. nadpis samotného grafu a Parent určuje rodiče nově vytvořené položky menu. Pokud je stromová struktura prázdná, parametr Parent musí ukazovat na tzv. root nebo-li kořen. V opačném případě můžeme jako Parent vybrat jakýkoliv dříve vytvořený uzel nebo opět root.

Obrázek 17: Stromové menu v nástroji Smokeping. Druhou možností je přidání „záznamu Smokepingu“, který oproti uzlu ještě obsahuje IP adresu a parametr Parent nesmí obsahovat root položku, ale pouze jakýkoliv existující uzel. Důležité je však následné zpracování takového záznamu ve FreeNetISu, protože v nástroji 35

KAPITOLA 4. IMPLEMENTACE ROZŠIŘUJÍCÍCH MODULŮ Smokeping většinou nechceme sledovat pouze cílové stanice uvnitř vlastní sítě ale i hosty mimo naši síť. Pokud chceme sledovat nějakého hosta, který je určený doménovým jménem, či IP adresu, která se nenachází uvnitř sítě a není tedy obsažena v databázi FreeNetISu, uloží se tento cíl (ať už IP adresa nebo doménové jméno) do tabulky outter_addresses a v tabulce smokepings bude ve sloupci outter_address_id ukazatel na tento cíl. Pokud chceme naopak sledovat adresu uvnitř vlastní sítě, tak se v tabulce smokepings do sloupce outter_address_id uloží hodnota null a namísto toho bude na adresu odkazovat hodnota ve sloupci ip_address_id (samotná adresa je pak uložena v tabulce ip_addresses). Je pouze na uživateli, zda vyplní adresu ručně anebo v kontroléru ip_addresses.php klikne u dotyčné adresy na tlačítko „sledovat“. Stromová struktura ve výsledném souboru smokeping.cfg je definována pomocí konkrétního počtu znaků „+” před záznamem uzlu či sledované stanice a dále pořadím všech záznamů. Výsledný vygenerovaný soubor může vypadat například takto: + HKFree menu = HKFree title = HKFree +++ DNS menu = DNS1 title = DNS1 host = 10.107.4.100 + Internet menu = Internet title = Internet ++ FEL CVUT menu = FEL ČVUT title = FEL ČVUT host = fel.cvut.cz ++ Seznam.cz menu = Seznam.cz title = Seznam.cz host = www.seznam.cz

36

KAPITOLA 4. IMPLEMENTACE ROZŠIŘUJÍCÍCH MODULŮ

4.4 Kontrolér pro zálohování sítě Pravidelné zálohování PC routeru s operačním systémem Linux lze celkem dobře vyřešit díky nástroji Bacula, jak již bylo zmíněno dříve v kapitole 3.5.1 Zálohování Linuxu. Mým cílem tedy bylo do FreeNetISu zabudovat funkci, pro pravidelné zálohování RouterBOARDů od Mikrotiku s operačním systémem RouterOS. Za tímto účelem byl vytvořen kontrolér backup.php a integrován byl do modulu Síť. V uživatelském rozhraní lze v menu Zálohování RouterBOARDů vytvořit novou zálohu, jak si můžete prohlédnout na obrázku 18. Uživatel potřebuje znát pouze IP adresu RouterBOARDu, přihlašovací jméno a heslo a záznam si může pro přehlednost libovolně pojmenovat. Po vytvoření je možné takto uloženou zálohu kdykoliv upravit, zobrazit nebo smazat. Po kliknutí na odkaz Vytvořit zálohu u příslušného záznamu se spustí pomocí PHP příkazu system ( ) bash skript „backup.sh $ip_address $username $password”, který se připojí ke konkrétnímu RouterBOARDu určenému přidanými parametry, a který vypadá následovně. #!/bin/bash { sleep 1s printf "$2+ct\x0d\x00" sleep 1s printf "$3\x0d\x00" sleep 1s printf "export\x0d\x00" printf "quit\x0d\x00" } | nc -t -w 10 $1 23 | head -n -3 | tail -n +22 | sed 's/\x0d//g' | sed 's/\x0d//g' > /var/www/sites/freenetis/freenetis/kohana/media/download/mikrotik.backup V praxi se provede v zobrazeném skriptu přihlášení k RouterBOARDu, příkazem export se vygeneruje současná konfigurace, odfiltrují se nedůležité znaky a uloží se do dočasného souboru mikrotik.backup. Takový soubor je pak předán následně v PHP funkci create_backup( ) uživateli ke stažení. Pro pravidelné zálohování by bylo nutné mít více kopií souboru, případně ukládat staženou konfiguraci do databáze, což by byla pravděpodobně lepší varianta. Bash skript, který se o celé zálohování stará, lze jednoduše pouštět v crontabu v libovolném časovém intervalu.

37

KAPITOLA 4. IMPLEMENTACE ROZŠIŘUJÍCÍCH MODULŮ Bohužel současné řešení má nevýhodu v univerzálnosti. Zálohování systému RouterOS je funkční pro firmware verze 3.x a 4.x, ovšem na některých RouterBOARDech se provozuje stále ještě zastaralý firmware verze 2.x a v posledním měsíci firma Mikrotik vypustila betaverzi nového firmware 5.0beta1. Takto časté aktualizace firmware (a následně i BIOSu) komplikují naše snahy o automatické zálohování.

Obrázek 18: Přidávání nové zálohy ve FreeNetISu.

4.5 Kontrolér pro SMS komunikaci Přestože informační systém FreeNetIS má předpoklady pro používání ke komunikaci pomocí zasílání SMS zpráv, tato funkce nebyla nikdy funkční. U každého uživatele může být však uvedeno kontaktní telefonní číslo, a proto se nabízí jeho širší využití než pouhá evidence v databázi. Pro správce by vznikla jednoduchá a přehledná alternativa pro komunikaci s uživateli. Pro spolupráci s SMS systémem od firmy MATERNA Communications a.s. [17], který je provozován například v Královéhradecké komunitní sítí HKFree.org, byl vytvořen jednoduchý kontrolér pro zasílání SMS zpráv. Kontrolér sms.php se stará o validaci telefonního čísla a dosazení parametrů do bash skiptu sendsms.sh. V něm se pouze správně přiřadí parametry do perlovského skriptu smsbackend.py a spustí se. Skript smsbackend.py se vzdáleně připojí k serveru Materny, ověří uživatele a odešle SMS zprávu s pomocí GSM gateway. Tento skript poskytuje přímo firma Materna ke svým poskytovaným službám. Obsah

38

KAPITOLA 4. IMPLEMENTACE ROZŠIŘUJÍCÍCH MODULŮ skriptu sendsms.sh vypadá následovně a do parametrů se po řadě přiřadí uživatelské jméno, heslo, telefonní číslo a obsah textové zprávy. #!/bin/bash /var/www/sites/freenetis/freenetis/kohana/media/download/smsbackend.py -a https://aweg3.maternacz.com/ -l $1:$2 -d $3 "$4" > /dev/null Alternativně můžou správci sítě využívat software b-SMS Plus pro operační systém Windows a zasílat tak pohodlně SMS zprávy přímo ze svého počítače. Program b-SMS Plus podporuje telefonní adresář a jeho export i import. K importu telefonních čísel z FreeNetISu byla do kontroléru sms.php přidána funkce address_book_subnet pro vygenerování telefonního seznamu uživatelů z dané podsítě a address_book_cloud pro generování z oblastí. Výsledný soubor contacts.conf má formát jazyka XML a je čitelný aplikací b-SMS Plus. Následuje krátká ukázka obsahu XML souboru contacts.conf a aplikaci s importovaným telefonním seznamem z FreeNetISu si můžete prohlédnout dále na obrázku 19. Buben Lubomír <MobileTelephoneNumber>737769742

39

KAPITOLA 4. IMPLEMENTACE ROZŠIŘUJÍCÍCH MODULŮ

Obrázek 19: Aplikace b-SMS Plus s importovaným adresářem z FreeNetISu.

4.6 REST Důvody ke zvolení architektury REST pro vytvoření vrstvy pro komunikaci s externími aplikacemi byly již probrány v kapitole 3.7. Místo programování REST serveru jsem však využil již hotové řešení z frameworku Zend, který je volně dostupný na webu projektu [13]. Vytvoření serveru i klienta pomocí nástroje Zend je velmi jednoduché. Ke zdrojům na straně serveru se přistupuje přes URI (Uniform Resource Identifier). Paradoxně nám ale takový přístup znemožňuje framework Kohana. V Kohaně se upravuje URL pro vlastní syntax, kde se v adrese určí použitý kontrolér, metoda i případné parametry ve formátu: http://freenetis.org/cs/controller/method/param1/param2 Zatímco pro REST se vyžaduje URL řetězec určující metodu a parametry v jiném formátu: http://freenetis.org/cs/rest_server?method=user&user_id=1&test=hay

40

KAPITOLA 4. IMPLEMENTACE ROZŠIŘUJÍCÍCH MODULŮ Kvůli nespolupráci frameworků Kohana a Zend je lepší umístit REST server mimo adresář s kontroléry, například do adresáře /media/rest. Bohužel tím přijdeme o možnost přistupovat k databázi přes komponentu Model. Pro vytvoření REST serveru stačí nastavit cestu k Zend_Rest_Server a definovat potřebné metody. V metodách zpracujeme zdroje (v našem případě data z databáze) a ve formátu XML je zaobalíme do objektu. Nakonec vytvoříme instanci serveru a vystavíme funkce na serveru, které chceme zvenčí zpřístupnit, pomocí funkce addFunction. Následuje ukázkový REST server s modelovou metodou getUser. set_include_path('/usr/share/php/libzend-framework-php'); require_once 'Zend/Rest/Server.php'; function getUser($user_id){ $sql = mysql_query("SELECT * FROM `users` WHERE id=$user_id"); $result=@mysql_fetch_array($sql); $name = $result["name"]." ".$result["surname"]; $phone = $result["phone"]; $xml =' <user> '.$name.' '.$phone.' '; $resource = simplexml_load_string($xml); return $resource; } $server = new Zend_Rest_Server(); $server->addFunction('getUser'); $server->handle(); Na straně klienta musíme analogicky nastavit cestu k Zend_Rest_Client, připojit klienta k serveru a u vybrané metody předat potřebné parametry. Výsledkem získáme XML objekt, který můžeme libovolně zpracovat. set_include_path('/usr/share/php/libzend-framework-php'); require_once 'Zend/Rest/Client.php'; $client = new Zend_Rest_Client('http://freenetis.org/kohana/media/rest/rest.php'); 41

KAPITOLA 4. IMPLEMENTACE ROZŠIŘUJÍCÍCH MODULŮ $result = $client->getUser(1)->get(); echo $result->name."
"; echo $result->phone."
"; Vystavení dalších funkcí, které z FreeNetIS databáze získávají data nebo je tam naopak zapisují, je jen rutinní záležitost. Velmi jednoduše tak byla vytvořen podklad pro vrstvu sloužící ke komunikaci s externími systémy s využitím frameworku Zend a propojení se současnými aplikacemi při nasazení v nových sítích by již neměly nastat vážnější komplikace – samozřejmostí je implementace REST klienta do těchto aplikací.

42

KAPITOLA 5. DALŠÍ VÝVOJ FREENETISU

5 Další vývoj FreeNetISu V této kapitole je nastíněn možný budoucí rozvoj systému FreeNetIS. U nově přidaných modulů a funkcí existuje velké množství dalších možností a vylepšení, které jsou však již nad rámec této diplomové práce.

5.1 Vylepšení nově přidaných funkcí Vzhledem k širokému záběru nových funkcí se zde nabízí celá řada možných úprav pro zlepšení funkčnosti informačního systému FreeNetIS. Každá nová funkce je sama o sobě funkční, ale byly vytvořeny hlavně jako nastínění, jakým směrem se může dále FreeNetIS ubírat a kde jsou stále jeho velké rezervy. Jsou to hlavně nadstavbové funkce, kterými může FreeNetIS zaujmout různá občanská sdružení, aby začala tento systém používat. Správu financí i uživatelů má prakticky už každá síť více či méně funkční, takže existence modulů Finance či Uživatelé ve FreeNetISu neznamená žádnou přidanou hodnotu, přestože kvalitou i provedením zřejmě převyšují současné na koleni dělané informační systémy většiny freenetů. Ale nadstavbové funkce, které umí pracovat s již dříve zadanými daty, aby ulehčily práci správcům sítě, už důvod k používání FreeNetISu znamenají.

5.1.1 Vylepšení funkce přesměrování Modul pro přesměrování ve FreeNetISu je poměrně komplexní nástroj, nicméně je zde mnoho námětů pro vylepšení. Jeden z nejdůležitějších nových poznatků, po zavedení této funkcionality do praxe, se týká opakovaného přesměrování. Může se totiž stát, že uživatel na přesměrovaném webu zprávu zruší, aniž by jí věnoval větší pozornost a veškeré úsilí správce přijde pak nazmar. Proto by správce měl mít možnost zadat přesměrování na každý den (resp. týden nebo měsíc) a ze seznamu přesměrovaných záznamů by dotyčné přesměrování odstranil, jakmile by cílový uživatel adekvátně zareagoval na zprávu. Dále by určitě stálo za úvahu přesměrování i jiných portů, než portu 80. Například přes protokol https na portu 443 lze současný systém bez problému obejít. Za úvahu by stála i možnost zakázat všechny porty (bez přesměrování), dokud by se uživatel nacházel

43

KAPITOLA 5. DALŠÍ VÝVOJ FREENETISU na seznamu přesměrovaných záznamů. Případně jako výjimku povolit porty 25 pro SMTP (Simple Mail Transfer Protocol) resp. 465 pro SMTPS (šifrovaná verze protokolu SMTP). V poslední řadě by jistě bylo vhodné umístit na přesměrovaný web formulář, pro odeslání zprávy správci sítě či oblasti (ať již přes e-mail nebo sms gateway). Uživatel by tak mohl jednoduše zareagovat na důvod přesměrování či přiloženou zprávu bez zbytečných prodlev nebo hledání kontaktů. Tyto tři zmíněné úpravy by pravděpodobně dovedly modul pro přesměrování (již nejen) webového provozu téměř k dokonalosti a FreeNetIS by se mohl pyšnit touto unikátní funkcí, kterou nenabízí žádný podobný informační systém.

5.1.2 Vylepšení funkce generování konfiguračních souborů Nejpalčivější problém u konfiguračních souborů je ten, že se správce musí do FreeNetISu zalogovat, nechat vygenerovat nový konfigurační soubor, uložit, přehrát na server a zrestartovat službu, případně v případě DNS zónových souborů nahrát přes SVN klienta do repozitáře. Přestože je to jen zlomek času oproti dřívější strávené práci s úpravami těchto souborů, stále je to rutina, které bychom se rádi zbavili. Určitě největším pokrokem by byla implementace mechanismu, pro automatické nahrávání pravidelně vygenerovaných konfiguračních souborů (např. jednou denně) přímo na dotyčný router nebo server, kde by byl restart služby zajištěn pomocí příkazu v crontabu. Dalším zajímavým nápadem by bylo vygenerování dokumentace sítě pomocí informací z databází FreeNetISu. K tomu už by byl ale potřeba i nějaký grafický editor, který by dokázal znázornit alespoň ikonu switche, routeru, hardwarového AP a případně i dalších aktivních prvků. Ke každému by pak doplnil nejdůležitější informace jako je IP adresa, VLAN (Virtual LAN) a rozhraní (nebo-li interface). Správce by tak získal kompletní dokumentaci své části sítě a v případě problémů by mohl nahlédnout i do okolních oblastí. Současný kontrolér pro generování konfiguračních souborů podporuje pouze Linux. Až blízká budoucnost ukáže, zda se proprietární operační systém RouterOS od Mikrotiku rozšíří na routerech natolik, aby stálo za úvahu doprogramovat kompatibilitu i pro tento systém. Zatím se však v praxi ukazuje, že RouterOS má vážné trhliny jak v routovacím protokolu OSPF tak i na správě bezdrátových karet a výrazně se to projevuje na nestabilitě zařízení.

44

KAPITOLA 5. DALŠÍ VÝVOJ FREENETISU Desky RouterBOARD se pak s tímto systémem v módu router chovají značně nedeterministicky, což je velmi nežádoucí stav nejen v počítačových sítích.

5.1.3 Vylepšení funkce monitorování sítě Monitorování sítě je velmi široký pojem a sledování dostupnosti a latence pomocí nástroje Smokeping je jen malá část z komplexního monitoringu. Vygenerování databázových tabulek pro Cacti by jistě ulehčilo v důsledku mnoho práce, nicméně špatná dokumentace samotné databáze projektu Cacti bude znamenat problematickou implementaci takové funkce do FreeNetISu. Kromě sledování provozu na síti bychom tím ale docílili i hlídání vytíženosti aktivních prvků, teploty v serverovnách nebo využití paměti v routerech. Další možností by bylo sledování vybraných IP adres souhrnně na jediné stránce, což by byla alternativa programu Pinger pod operačním systémem Windows. Zobrazovaly by se případně jen nefunkční adresy. Takovou funkci by však bylo vhodné propojit se systémem zasílání varovných SMS zpráv na mobilní telefon nebo upozorňování správců pomocí e-mailu. Správce by tedy byl vždy informován, pokud by se vyskytl problém na nějaké službě nebo přístupovém bodu. Je ovšem otázkou, zda takovou funkci integrovat přímo do FreeNetISu, když například nástroj Nagios zasílání varovných sms nebo mailů hravě zvládá. Jistě lepším ale podstatně komplikovanějším řešením by bylo generování databází a konfiguračních souborů pro samotný open source Nagios, který lze volně využívat.

5.1.4 Vylepšení funkce zálohování sítě V zálohování síťové konfigurace má FreeNetIS asi největší rezervy. I když není nutné přímo konfiguraci na routerech a switchích pravidelně ukládat. Druhou možností je rekonstrukce nastavení aktivních prvků z obsahu databáze. Pro linuxové routery by to už se současným obsahem rozsáhlé FreeNetIS databáze nebyl zase takový problém. Problematické jsou různorodé distribuce operačního systému Linux, mezi kterými jsou drobné syntaktické odchylky. Při generování síťové konfigurace by tedy musela být nabídka výsedných formátů souborů poměrně rozmanitá.

45

KAPITOLA 5. DALŠÍ VÝVOJ FREENETISU Co se týká operačního systému routerOS, nejlepším řešením se zdá být pravidelné zálohování a ukládání do databáze FreeNetISu a případné možnosti jednoduchého uploadu. Bohužel tento úkol znepříjemňuje častá aktualizace verzí operačního systému od Mikrotiku. Za poslední tři roky se totiž přešlo od verze 2.x až k verzi 5.x, přičemž způsoby logování a výpisů při přihlášení přímo ze serveru se liší a nelze použít stejný mechanismus pro všechny verze.

5.1.5 Nové funkce a další vývoj Většinu potenciálních uživatelů o informační systém FreeNetIS bezesporu odrazuje vidina mnoha hodin práce, kdy budou muset správci naplnit databáze systému relevantními daty. Pro ulehčení tohoto kroku by se vyplatil modul pro konverzi dat z cizích databází, zejména pak jména, příjmení a identifikační čísla uživatelů. Další možností automatického naplnění tabulek je použití jednoduchého skriptu, který by na linuxových routerech vytvořil z ARP tabulek dvojice IP adresy a fyzické adresy. Import těchto dat do databáze FreeNetISu by byla jen rutinní operace nějakou pomocnou funkcí vytvořenou k tomuto účelu.

5.2 Budoucnost informačního systému FreeNetIS Informační systém FreeNetIS má poměrně pevné základy. Struktura databáze je pečlivě navržena a dá se na tom dobře stavět v budoucnu. Podstatně horší situace je s použitým PHP frameworkem Kohana. Použitá verze už není podporovaná a nová není plně kompatibilní. Přepsání do nové verze Kohany nebo do jiného PHP frameworku je natolik náročný proces, že v blízké budoucnosti na to nebudou prostředky a dále se tedy bude systém vyvíjet bohužel v zastaralé verzi, která nepodporuje mnoho moderních webových nástrojů. Jak velká část projektu je naprogramována v jazyce PHP se monitoruje v projektu Ohloh [18] a ukázkový graf si můžete prohlédnout na obrázku 20. Podle analýzy pokrývá PHP kód 80 % projektu, což je ale jen relativní údaj. Teprve ve spojení s objemem kódu, který činí v dubnu 2010 téměř 600 tisíc řádků kódu PHP, má tento údaj smysl. Počet řádků kódu (bez rozdílu použitého programovacího jazyka) z analýzy projektu Ohloh najdete na obrázku 21.

46

KAPITOLA 5. DALŠÍ VÝVOJ FREENETISU

Obrázek 20: Percentuální zastoupení programovacích jazyků ve FreeNetISu [18]. Přepsání téměř 485 tisíc řádků PHP kódu do nového frameworku tedy zatím pro vývojáře FreeNetISu není prakticky možné. Prozatím by se měl věnovat čas zpříjemnění a zpřehlednění uživatelského rozhraní. Obzvláště s modulem Síť se pracuje velmi těžkopádně a začínající uživatel systému nejednou jistě ztratí trpělivost u nekonečných varovných hlášek při vyplňování formulářů. Po úpravách uživatelského rozhraní by určitě měl směřovat vývoj k nadstavbovým funkcím již zmíněným v této kapitole, protože samotná správa uživatelů i financí je už poměrně kompletní. Dále by bylo vhodné zaměřit se na kompatibilitu se strukturou většiny komunitních sítí v České republice, protože pokud budou připravené variabilní role uživatelů a jejich přístupová práva, nebrání ostatním sdružením již nic v používání informačního systému FreeNetIS.

47

KAPITOLA 6. ZÁVĚR

6 Závěr V závěru tohoto dokumentu naleznete zhodnocení a přínos celé diplomové práce. Jsou zde uvedeny úspěchy i neúspěchy a popsány jsou i důvody a komplikace, proč k těmto neúspěchům došlo.

6.1 Shrnutí práce Výsledek diplomové práce umožňuje používat systém FreeNetIS efektivněji a usnadňuje administrátorům správu počítačových sítí a jejich služeb. Jak velká část FreeNetISu doznala změn, je dostatečně vidět na obrázku 21. Od září do prosince 2009, kdy vznikla většina nově vytvořených modelů a kontrolérů, se zvýšil počet řádků kódu ze 400 na téměř 590 tisíc. Ve stejnou dobu sice pracovali na projektu ještě další 2 programátoři, nicméně jejich úpravy byly převážně kosmetického charakteru (oprava instalačního postupu, oprava modulu financí atd.).

Obrázek 21: Počet řádků kódu projektu FreeNetIS [18]. Myslím, že zejména modul pro přesměrování webového provozu se vydařil. Vyplňuje chybějící mezeru v komunikaci s problematickými uživateli a přidává novou alternativu v komunikaci. Používání je poměrně flexibilní a bezproblémové a i pro laiky velmi jednoduché. Jako další možnost přibyla i komunikace pomocí SMS zpráv, která je ovšem 48

KAPITOLA 6. ZÁVĚR závislá na poskytovateli služeb (v našem případě MATERNA Communications). Nicméně napojení na skript jiného poskytovatele nebo vlastní GSM brány je jen kosmetickou záležitostí. Modul generování konfiguračních souborů beze zbytku naplnil zadání práce a k dokonalosti zbývá už jen automatické nahrávání souborů na routery a restart služby pro bezúdržbový chod. Naopak finální modul zálohování konfigurace síťových provků nefunguje zcela podle očekávání. Obzvláště různé typy firmwarů a problematické chování operačního systému RouterOS způsobilo komplikace natolik vážné, že jsem se musel smířit se zálohováním pouze určitých verzí systému. Po detailnější analýze se navíc zálohování linuxových routerů jevilo jako neefektivní a lepším řešením by byla generace síťové konfigurace přímo z databáze FreeNetISu. Poměrně obtížné bylo dohodnutí všech návrhů nových funkcí spolu s ostatními vývojáři FreeNetISu. Návrhy databází ne vždy vyhovovaly všem programátorům a stejně tak i na grafické uživatelské rozhraní se lišily naše názory. Největší vliv na to měly různorodé charaktery komunitních sítí, ve kterých se pohybujeme. Každý freenet v České republice je více či méně originál a zaujaté pohledy z různých sdružení se jen těžko dokázaly srovnat s odlišným modelem. Nicméně po osobní schůzce všech vývojářů v Brně se podařilo pod vedením Ing. Tomáše Dulíka požadavky sladit tak, aby výsledek byl co možná nejpřijatelnější všemi stranami. Myslím, že tato práce byla nakonec nemalým přínosem pro FreeNetIS a věřím, že nasazení tohoto informačního systému v dalších komunitních sítích na sebe nenechá dlouho čekat. Případné pluginy či spolupracující aplikace s nadstavbovými funkcemi mají teď volnou cestu díky komunikační vrstvě REST, která je za pomocí frameworku Zend velmi jednoduchá na používání.

49

KAPITOLA 7. SEZNAM LITERATURY

7 Seznam literatury [1] SourceForge SVN FreeNetIS http://sourceforge.net/search/?type_of_search=soft&words=freenetis [2] Dokumentační stránka systému FreeNetIS http://wiki.freenetis.org/index.php/Hlavn%C3%AD_strana [3] UnArt Slavičín http://www.unart.cz/ [4] Diplomová práce Informační systém pro správu a evidenci uživatelů rozsáhlých sítí, Bc. Petr Daněk, 2008 [5] Diplomová práce Informační systém pro správu rozsáhlých sítí, Bc. Marek Rozehnal, 2008 [6] Výběr webového PHP frameworku http://stribny.name/zapisnik/?clanky/vyber-php-frameworku [7] Kohana User Guide http://docs.kohanaphp.com/index.php [8] Otevřená encyklopedie Wikipedia, 2010. http://en.wikipedia.org/ [9] Asp.net & Sql server blog http://indiandotnet.files.wordpress.com [10] Specifikace systému FreeNetIS aneb Informační systém pro freenet-y, 2007 http://wiki.freenetis.org/index.php/P%C5%AFvodn%C3%AD_specifikace

50

KAPITOLA 7. SEZNAM LITERATURY [11] PhpGACL http://phpgacl.sourceforge.net/ [12] Nagios Map http://lj.deformica.com [13] Nagios http://www.nagios.org/ [14] Cacti http://www.cacti.net/ [15] Network Weathermap http://www.network-weathermap.com/ [16] Smokeping http://oss.oetiker.ch/smokeping/ [17] University of California, Irvine – REST http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm [18] Informační server zdroják.cz http://zdrojak.root.cz/clanky/rest-architektura-pro-webove-api/ [17] MATERNA communications, a.s. http://www.maternacz.com/ [18] Analýza kódu systému FreeNetIS v projektu Ohloh https://www.ohloh.net/p/freenetis/analyses/latest [19] Informační server v oblasti IT http://zdrojak.root.cz/

51

KAPITOLA 7. SEZNAM LITERATURY [20] Zend framework http://framework.zend.com/ [22] IBM – RESTful Web Services https://www.ibm.com/developerworks/webservices/library/ws-restful/ [23] REST tutorial http://rest.elkstein.org/ [24] Introduction to writing a REST server in PHP http://fliquidstudios.com/2009/01/13/introduction-to-writing-a-rest-server-in-php/ [25] RESTful Web Services Cookbook, O'Reilly, Yahoo Press, 2010

52

DODATEK A. UML DIAGRAMY

A UML diagramy

Obrázek 22: Struktura databáze modulu Síť [4].

53

DODATEK A. UML DIAGRAMY

Obrázek 23: Struktura databáze pro nově vzniklé funkce a moduly.

54

DODATEK A. UML DIAGRAMY

Obrázek 24: Diagram užití pro práce a brigády.

Obrázek 25: Diagram užití pro modul Přesměrování. 55

DODATEK A. UML DIAGRAMY

Obrázek 26: Diagram tříd systému FreeNetIS.

56

DODATEK B. UŽIVATELSKÁ PŘÍRUČKA

B Uživatelská příručka B.1 Instalace systému FreeNetIS Nejdříve je nutné splnit všechny předpoklady pro instalaci systému FreeNetIS. Těmi jsou instalace PHP, Apache, MySQL server, SVN klienta a nějakého MySQL klienta (například phpmyadmin). Na operačním systému Linux s distribucí Debian nebo Ubuntu lze jednoduše stáhnout balíčky pomocí příkazu apt-get install. Následně se musí správně nastavit kódování jazyka na české UTF-8 příkazem dpkg-reconfigure locales. Na web serveru Apache je nutné povolit modul mod_rewrite a ve virtual hostu povolit možnost přenastavování konfigurace Apache pomocí .htaccess souboru (AllowOverride All). Výsledný virtual host by měl vypadat přibližně následovně. ServerAdmin [email protected] ServerName freenetis.example.org DocumentRoot /var/www/freenetis Options Indexes FollowSymLinks MultiViews AllowOverride All Order allow,deny allow from all

Nyní máme připravený systém na samotnou instalaci systému FreeNetIS. Pomocí SVN klienta se připojíme k sourceforge.net [1], kde se celý projekt nachází a stáhneme uloženou verzi projektu spolu se všemi aktualizacemi. cd /var/www/freenetis svn checkout https://freenetis.svn.sourceforge.net/svnroot/freenetis/freenetis/trunk/kohana svn update Na serveru MySQL musíme následně vytvořit nového uživatele freenetis a pro něj s plnými právy novou databázi. Dále je nutné v souboru kohana/application/config/config.php nastavit vlastní doménu a protokol (http nebo https) a přihlašovací údaje k MySQL databázi v souboru 57

DODATEK B. UŽIVATELSKÁ PŘÍRUČKA kohana/application/config/database.php. Po upravení názvu souboru kohana/.htaccess.dist a jeho obsahu (cesta k nainstalovanému FreeNetISu) je FreeNetIS nainstalovaný a připravený k použití.

B.2 Používání modulu přesměrování Při vstupu do menu Přesměrování se zobrazí všechny přesměrované záznamy. Vyhledávat mezi jednotlivými záznamy můžete pomocí filtrování IP adresy, správce, trvání přesměrování a cíle přesměrování. Výsledek z filtrovaného výběru můžete případně hromadně smazat. Zobrazené záznamy je možné řadit vzestupně či sestupně podle sloupce kliknutím na jeho nadpis. Každý záznam je možné zobrazit, upravit nebo smazat. Při zobrazení záznamu jsou vidět veškeré detaily, včetně zprávy, komentáře nebo příznaku zámku. Pokud je v systému přesměrování s příznakem zámku, může s ním manipulovat (prohlížet, editovat a mazat) pouze vlastník zámku anebo administrátor systému. Důležitá je možnost přidat záznam přesměrování. Na výběr je přesměrování jednotlivé IP adresy, přesměrování rozsahu IP adres (je potřeba vyplnit počáteční a koncovou IP adresu), přesměrování podsítě (na výběr jsou existující podsítě v systému) a přesměrování uživatele (resp. všech jeho IP adres) podle jeho uživatelského UID. Výběr délky trvání a cílové zprávy jsou povinné položky při vyplňování formuláře. Osobní zpráva, komentář, informační email a zámek jsou volitelné možnosti. Každý cílový web má vlastní zprávu, které může uživatel s dostatečnými právy spravovat v administraci přesměrování. Zde může být libovolné množství zpráv, ale pro každý cíl může být právě jedna zpráva aktivní. U každé zprávy má uživatel na výběr zobrazení, editaci, smazání a aktivaci zprávy. Při přidávání nové zprávy je nutné vyplnit její název, obsah a cíl, pro který se bude zpráva zobrazovat. Po přidání je ještě nutné zprávu zaktivovat ručním kliknutím na odkaz. Při každé změně v modulu přesměrování se ukládá uživatel, který změnu provedl, činnost (nové přesměrování, editace a smazání záznamu), cílová IP adresa a čas, kdy úprava proběhla. I zde má uživatel možnost filtrování podle IP adresy, uživatele a činnosti, která byla provedena.

58

DODATEK B. UŽIVATELSKÁ PŘÍRUČKA

Obrázek 27: Seznam přesměrovaných záznamů včetně filtrování.

B.3 Generování konfiguračních souborů Nejdříve je vhodné zkontrolovat a případně upravit defaultní hodnoty pro generování konfiguračních souborů, k tomu má přístupová práva administrátor systému a správní rada. Pokud správce při generování DHCP konfiguračního souboru používá například jiné DNS servery, než jsou doporučované servery ve freenetu, může hodnotu upravit pro vlastní potřeby, nebude však uložena pro další používání. Dále vybere podsítě, pro které chce provozovat službu DHCP (na výběr jsou pouze existující podsítě ve FreeNetISu) a nakonec klikne pouze na tlačítko Generovat. Pro správné vygenerování souboru dhcpd.conf musí být zvolena minimálně jedna podsíť, která musí mít alespoň jednu IP adresu označenou jako brána. U generování zpětných a dopředných DNS zónových souborů budou správci pravděpodobně nejčastěji editovat hodnoty refresh time, retry time a další pro určení, jak dlouho mají být překlady podle DNS platné. Následně vybere správce IP prefix pro zpětný záznam resp. oblast pro dopředný záznam. Při generování se správně doplní i důležitý parametr serial, který byl vysvětlen již dříve, a proto po vygenerování nejsou potřebné žádné ruční úpravy a výsledný soubor se může nahrát přímo na DNS server.

59

DODATEK B. UŽIVATELSKÁ PŘÍRUČKA Nejjednodušší generátor má bezpečnostní firewall MAC restrikcí, u kterého se pouze zvolí podsíť a vygeneruje se bash skript. Po přehrání skriptu na router je nejprve nutné přidělit mu práva pro spouštění (chmod 775 mac_restriction.sh) a teprve pak je možné skript spustit. Bezpečnostní pravidla jsou zavedeny okamžitě po spuštění. U modulu pro dohled sítě se při nové instalaci systému FreeNetIS musí nejprve vytvořit hierarchie stromového menu Smokepingu pomocí funkce Přidat položku menu smokepingu. Teprve po vytvoření hrubé struktury můžou správci přidávat do příslušných větví sledované IP adresy. Parametry Menu a Title u přidávání nových záznamů jsou téměř identické. Pouze parametr Menu se zobrazí v levém panelu Smokepingu ve stromovém menu a název Title nad grafem při samotném zobrazení. Když jsou sledované záznamy přidány do seznamu, stačí kliknout na odkaz Generovat konfigurační soubor smokepingu, nahrát ho na server a zrestartovat službu smokepingu následujícím příkazem. root@andre:~# /etc/init.d/smokeping restart * Shutting down latency logger daemon smokeping * Starting latency logger daemon smokeping

60

[ OK ] [ OK ]

DODATEK C. DODATEK K PHP FRAMEWORKU KOHANA

C Dodatek k PHP frameworku Kohana Framework Kohana byl podrobněji popsán v kapitole 1.2.2 Kohana framework. Je poměrně jednoduchý, přímočarý a přehledný. Bohužel se však později ukázalo, že výběr Kohany pro projekt FreeNetIS nebyla nejlepší volba. Verze Kohany (2.x), na které se postavil vývoj FreeNetISu, se totiž přestala dále v komunitě podporovat a nová verze (3.x) je velmi odlišná a hlavně nekompatibilní s předchozí verzí. Předělání celého programového kódu do nové syntaxe by tak bylo velmi náročné a prozatím se pokračuje ve vývoji na staré verzi. Navíc nemůžu souhlasit s konstatováním, že dokumentace je přehledná a dostatečná, jak píše Bc. Petr Daněk ve své diplomové práci [3]. Oproti jiným frameworkům je dokumentace velmi špatná a neúplná a vzhledem k ukončení vývoje verze 2.x se zřejmě už nikdy nedočkáme doplnění této dokumentace.

61

DODATEK D. OBSAH PŘILOŽENÉHO CD

D Obsah přiloženého CD •

EXE – FreeNetIS.zip – archiv kompletní aplikace FreeNetIS

•

HTML – abstractcz.html – rozšířený abstrakt v češtině – abstractaj.html – rozšířený abstrakt v angličtině – abstract.html – krátký abstrakt – index.html – webové stránky diplomové práce

•

SRC – *.* - zdrojové soubory informačního systému FreeNetIS

•

TEXT – DP.pdf – text diplomové práce v pdf – DP.odt – text diplomové práce ve formátu Open Office Document

•

index.html – výchozí stránka projektu

•

readme.txt – popis struktury přiloženého CD

•

install.txt – postup instalace systému FreeNetIS

62