XML Správa sít. Bc. Pavel imon. ƒeské vysoké u ení technické v Praze Fakulta elektrotechnická Katedra po íta. Diplomová práce

eské vysoké u£ení technické v Praze Fakulta elektrotechnická Katedra po£íta£·

Diplomová práce

XML Správa sít¥ Bc. Pavel imon

Vedoucí práce:

Ing. Peter Macejko

Studijní program: Elektrotechnika a informatika, strukturovaný, Navazující magisterský

Obor: Výpo£etní technika

1. ledna 2012

iv

v

Pod¥kování Na tomto míst¥ bych cht¥l pod¥kovat vedoucímu práce panu Ing. Peteru Macejkovy za jeho pomoc, rady a p°edev²ím trp¥livost.

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 dne 29.12.2011

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

viii

Abstract This work describes implementation of computer network management application. Communication between individual agents and managers is accomplished by XML based protocol. This protocol complements and extends common SNMP protocol. The management application is implemented as a JSP based web application. By implementing this application the long term project of creating a XML based network management system is accomplished. This work is continuation of this project, that has been started in another Master's Theses.

Abstrakt Tato práce popisuje implementaci managerské aplikace pro správu za°ízení na po£íta£ové síti. Pro komunikaci mezi jednotlivými agenty a managery je pouºíván XML protokol, který vhodným zp·sobem dopl¬uje a zobec¬uje klasický protokol SNMP. Managerská aplikace je implementována jako webová aplikace za pomoci JSP. Provedená implmentace je zavr²ením snahy o vytvo°ení systému správy síóvých za°ízení s vyuºitím moºností XML, jehoº tvorba byla zahájena v jiných diplomových pracech.

ix

x

Obsah 1 Úvod

1

2 SNMP a XML

3

2.1

SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.1.1

Standardy SMI a MIB . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.1.1.1

SMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.1.1.2 2.1.2

2.2

MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

Verze protokolu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.1.2.1

SNMPv1

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

5

2.1.2.2

SNMPv2

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

6

2.1.2.3

SNMPv3

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

6

XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.2.1

XML schéma

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

7

2.2.2

XSL

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

8

2.2.3

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

8

2.2.3.1

Zpracování XML

SAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.2.3.2

DOM

8

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

3 XML protokol pro správu sít¥

9

3.1

Motivace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2

Cíle

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

10

3.3

Informa£ní model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

3.3.1

Oznamovací zprávy . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

3.3.2

Adresace dat

3.4

3.5

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

Mapování MIB do XML

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

9

11 11

3.4.1

Datové typy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

3.4.2

Import MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

3.4.3

P°eklad MIB stromu . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

Komunika£ní model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

3.5.1

DICOVERY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

3.5.2

PUBLICATION

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

13

3.5.3

GET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

3.5.4

SET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

3.5.5

RESPONSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

3.5.6

EVENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

xi

OBSAH

xii

3.5.7

SUBSCRIBE

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

15

3.5.8

DISTRIBUTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

4 Implementované projekty 4.1

4.2

Java manager a brána

17

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

17

4.1.1

Informa£ní model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

4.1.2

Komunika£ní model

4.1.3

Zhodnocení

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

18

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

19

XML-SNMP brána v C++

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

19

4.2.1

SNMP modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

4.2.2

XML modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

4.2.3

Zhodnocení

21

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

5 Výsledky výzkumu

23

5.1

TU Braunsweig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

5.2

POSTECH

23

5.3

Web services for network management

5.4

ínský výzkum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

5.5

XMLN over VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

5.6

Zhodnocení

27

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

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

6 Návrh systému

24

29

6.1

Stav projektu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

6.2

Managerská aplikace

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

29

6.2.1

Programovací jazyk . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

6.2.2

Komunika£ní modul

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

30

6.2.3

Dohledový modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

6.2.4

Uºivatelský modul

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

32

6.2.5

Kongura£ní modul

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

33

7 Realizace

35

7.1

Struktura aplikace

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

35

7.2

Uºivatelský modul

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

36

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

36

7.2.1

JSP Stránky

7.2.2

Servlety . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

7.2.3

Beany

37

7.2.4

Pomocné t°ídy

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

37

7.3

Dohledový modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

7.4

Kongura£ní modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

7.5

Komunika£ní modul

39

7.6

Úpravy XML-SNMP brány

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

40

7.7

Výkonný cyklus aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

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

OBSAH

xiii

8 Testování

43

8.1

Testovací prost°edí

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

8.2

Výsledky test·

43

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

43

8.2.1

DISCOVERY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

8.2.2

GET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

8.2.3

SET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

8.2.4

SUBSCRIBE

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

46

8.2.5

EVENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

8.2.6

Ukládání dat

49

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

9 Záv¥r

51

A Seznam pouºitých zkratek

57

B Instala£ní a uºivatelská p°íru£ka

59

B.1

Kompilace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

B.2

Instalace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

60

B.3

Kongurace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

60

B.4

Pouºívání

B.5

59

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

61

B.4.1

Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

B.4.2

Discover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

B.4.3

Browse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

B.4.4

Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

Testovací XML-SNMP brána

C Obsah p°iloºeného CD

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

63

65

xiv

OBSAH

Seznam obrázk· 2.1

Princip SNMP ([13]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.2

P°íklad MIB stromu ([13]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

3.1

Mapování datových typ· SMIv1 do XML schématu ([23])

3.2

Mapování makra OBJECT TYPE (simpleType) ([23])

4.1

Schéma prototypové brány ([27])

4.2 4.3

Vlákna a fronty SNMP modulu ([20]) . . . . . . . . . . . . . . . . . . . . . . .

20

5.1

Struktura POSTECH agenta ([19]) . . . . . . . . . . . . . . . . . . . . . . . .

24

5.2

Architektura systému ([25])

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

25

5.3

Architektura systému ([15])

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

26

7.1

Schéma aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

8.1

Formulá° operace DICSOVERY . . . . . . . . . . . . . . . . . . . . . . . . . .

44

8.2

Výsledek DISCOVERY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

8.3

Operace GET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

8.4

Výsledek GET

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

45

8.5

Operace SET

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

46

8.6

Výsledek SET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

8.7

Formulá° operace SUBSCRIBE

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

47

8.8

Výsledek SUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

8.9

Dohledová operace

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

48

8.10 P°ijatá zpráva EVENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

. . . . . . . . . . .

12

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

13

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

17

Schéma C++ brány ([20]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

B.1

Stránka Status

B.2

Stránka Discover

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

61

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

62

B.3

Stránka Browse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

xv

xvi

SEZNAM OBRÁZK

Seznam tabulek 7.1

Jednoduchý POST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

7.2

multipart POST

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

41

8.1

Výpis logu XML-SNMP brány . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

xvii

xviii

SEZNAM TABULEK

Kapitola 1

Úvod I kdyº jsou po£íta£ové sít¥ obor tém¥° stejn¥ starý jako po£íta£e samotné, tak o opravdovém rozmachu se dá hovo°it aº s nástupem osobních po£íta£· a internetu na p°elomu osmdesátých a devadesátých let dvacátého století. A kam tento obor od té doby postoupil je tém¥° nepochopitelné. Jak se na jedné stran¥ roz²i°uje po£et do po£íta£ových sítí p°ipojitelných za°ízení - od osobních po£íta£· jsme postoupili k notebook·m, netbook·m, inteligentním telefon·m a tablet·m. Tak na druhé stan¥ roste snaha na r·zné sluºby - televizi, rozhlas, telefonní hovory,... - pohlíºet £ist¥ jako na r·zné druhy datových p°enos·. Není pak d·vod na jejich p°enos budovat speciální jednoú£elové sít¥, ale pouºívat sít¥ univerzální. Ruku v ruce s rostoucí poptávkou jde i poºadavek na kvalitu a dostupnost takových sluºeb. M·ºe být tedy pon¥kud p°ekvapivým zji²t¥ním, ºe základem moderních systém· pro sledování a správu po£íta£ových sítí je tém¥° £tvrt století starý protokol, navíc navrºený jako do£asné °e²ení - Simple Network Management Protocol (SNMP). Ten ale není bez nedostatk·. Od roku 2006 probíhá pod vedením Doc. Ing. Jane£ka a pozd¥ji Ing. Macejka na fakult¥ vývoj nového protokolu, který má zaru£it kompatibilitu s SNMP a ostranit jeho hlavní nedostatky. Tato práce je pokra£ováním tohoto projektu a klade si dva cíle. Za prvé revidovat p°edchozí práce a jejich výstupy, porovnat je s výsledky podobných výzkumných projekt· ve sv¥t¥. A za druhé na základ¥ tohoto porovnání implementovat chyb¥jící £ásti tak, aby byla výsledkem funk£ní dvojice manager - agent. Kapitola 2 se zabývá popistem zálakdních technologií pouºitých v této práci - protokolu SNMP a jazyka XML. V kapitole 3 je popsán protokol navrºený Peterem Macejkem s úpravami z práce Tomá²e Hrocha. Kapitola 4 popí²e výstupy implementa£ních prací Tomá²e Hrocha a Michala Tre²a. Tím bude ukon£eno shrnutí výsledk· p°edchozích projekt·. Porovnání výsledk· p°edchozích prací s výsledky podobn¥ zam¥°ených výzkumných projekt· odsahuje kapitola 5. Analýza poºadavk· na systém a diskuze zp·sobu implementace je v Kapitole 6. V kapitole 7 je pak podrobný popis implementovaného systému a jeho funkcí. Ov¥°ení funk£nosti je popsáno v kapitole 8.

1

2

KAPITOLA 1. ÚVOD

Kapitola 2

SNMP a XML 2.1 SNMP Simple Network Management Protocol je dnes základem správy po£íta£ových sítí. Vznikl v roce 1988 jako vývojová v¥tev protokolu Simple Gateway Monitoring Protocol (SGMP). P·vodn¥ m¥l slouºit jen jako nástroj na správu nizkoúrov¬ových síóvých prvk·. Postupn¥ se ale stal de facto standardem pro celý obor. Základní princip protokolu SNMP je zachycen na obrázku 2.1. SNMP vyuºívá model agent-manager. Kde manager je aplikace, která sleduje a spravuje po°ízené agenty. Agent je aplikace spu²t¥ná na spravovaném za°ízení. Stará se o p°eklad a vykonání p°íkaz· managera. B¥ºná komunikace mezi managerem a agentem pracuje na principu poºadavek-odpov¥¤. Manager za²le agentovi p°íkaz, ten ho vykoná a ode²le odpov¥¤. Pokud ale u agenta nastane n¥jaká vyjíme£ná situace m·ºe managera informovat zasláním zprávy Trap, nebo Inform (popsány dále). Podle standardu m·ºe SNMP vyouºívat r·zné transportní protokoly. V naprosté v¥t²in¥ p°ípad· se ale pouºívá nepotvrzovaný User Datagram Protocol (UDP). Obecn¥ tedy není moºné zaru£it bezchybnou komunikaci. N¥které zprávy nemusí v·bec dorazit k cíli.

2.1.1 Standardy SMI a MIB 2.1.1.1 SMI Pro správné fungování celého systému správy nesta£í jen denovat formát p°ená²ených zpráv. Také je nutné ur£it zp·sob reprezentace dat, jaká data se budou p°ená²et a jaká bude jejich struktura. Za tímto ú£elem byla do standartu za°azena Structure and Identication of Management Information for TCP/IP-based Internet - krátce SMI. Ta popisuje základní datové struktury a datové typy. Základní datovou strukturou je objekt. Ten musí mít jméno, syntaxi a kódování. Jméno (Object identier - OID) slouºí jako jednozna£ná identikace objektu. Syntaxe ur£uje jeho datový typ a nastavení kódování umoº¬uje správnou serializaci p°i p°enosu. Pravidla dále ur£ují, ºe jednotlivé objekty tvo°í hierarchickou stromovou strukturu. Pro sestavování OID v této struktu°e se pouºívá Abstract Syntax Notation One (ASN.1). Ta funguje na principu £íslování potomk· kaºdého uzlu a sestavování t¥chto £ísel do OID od ko°ene. RFC také ur£uje jaká sekvence £ísel (OID) je p°i°azena ko°enu správní databáze.

3

KAPITOLA 2. SNMP A XML

4

Obrázek 2.1: Princip SNMP ([13])

2.1.1.2 MIB

Zkratka MIB znamená Management Information Base. Jedná se o databázi ve které se ukládání objekty vytvo°ené pravidel ur£ených SMI. Jak uº bylo uvedeno v £ásti v¥nované SMI, objekty v MIB tvo°í stromovou strukturu. Za OID nejblíºe ko°enu zodpovídají standartiza£ní organizace. Níºe umíst¥né OID pak spravují jednotliví výrobci. Kaºdá spole£nost si m·ºe vytvo°it svou privátní v¥tev a do ní uloºit specické informace svých za°ízení. V dne²ní dob¥ existuje více neº 100 takových MIB (uvádí se i více neº 200). P°íklad £ásti MIB stromu je na obrázku 2.2. Pro objekty, které nepro²ly procesem ociálního schválení a standartizace je vyhrazena experimentální v¥tev.

Objekty MIB je moºné rozd¥lit na dv¥ kategorie. První jsou skalární objekty. Ty p°edstavují jeden parametr za°ízení - nap°íklad po£et odeslaných TCP segment·. Druhou jsou tabelární objekty vzniklé spojením n¥kolika souvisejících objekt· - nap°íklad tabulka informací o síóvých rozhraních za°ízení.

2.1. SNMP

5

Obrázek 2.2: P°íklad MIB stromu ([13])

2.1.2 Verze protokolu SNMP byl poprvé standartizován v roce 1988. Od té doby vznikly t°i hlavní verze. Nov¥j²í verze vznikaly hlavn¥ za ú£elem zlep²ení bezpe£nostního modelu, p°ípadn¥ dopln¥ní dal²ích funkcí, nebo datových typ·.

2.1.2.1 SNMPv1 První verze protokolu byla popsána ve standardu RFC 1068 [10], pozd¥ji RFC 1157 [21] v roce 1988. Protokol byl navrhován s minimální náro£ností na zdroje agenta. Tento cíl se povedlo úsp¥²ne splnit. P°enos SNMP paketu byl moºný p°es jeden z podporovaných protokol· ni²²ích vrstev - User Datagram Protocol (UDP), Internet Protocol (IP), Novell Internet Packet Exchange (IPX) a dal²í. Byly denovány tyto operace:

Get Request

Dotaz na hodnotu uzlu ur£eného OID. Sm¥r od managera agentovi.


6

Get Next Request

Dotaz na odnotu uzlu následujícího po OID. Sm¥r od managera agen-

tovi.

Set Request

Nastavení hodnoty uzlu identikovaného OID. Sm¥r od managera agentovi.

Get Response

Odpov¥d na p°íkaz GET, nebo SET s hodnotou uzlu. Sm¥r od agenta ma-

nagerovy.

Trap

Asynchronní informace o významné události, nebo chyb¥. Sm¥r of agenta managerovi.

Nejv¥t²í slabinou první verze je velmi jednoduché zabezpe£ení. Kaºdý SNMP paket je podepsán tzv. Community Stringem. Ten slouºil pro ov¥°ení práv p°ístupu k poloºkám MIB. Protoºe Community String není nijak ²ifrován, je jeho zji²t¥ní ze odposlechnuté komunikace velmi snadné. Také není moºné jedním dotazem získat hodnotu více objekt·. Kaºdý musí být zvlá²´ získám vým¥nou zpráv Get a Response. Komunika£ní reºije tedy zabírá nezanedbatelnou £ást komunka£ního kanálu.

2.1.2.2 SNMPv2 Hlavním d·vodem vzniku druhé verze protokolu bylo zlep²ení velmi ²patného zabezpe£ení verze první. Ale proces schvalování standard· RFC 1441-1452 [3] byl velmi sloºitý a nakonec neúsp¥²ný. Výsledkem byly £ty°i vzájemn¥ nekompatibilní verze ozna£ované jako SNMPv2 party-based, SNMPv2u, SNMPv2* a SNMPv2c. Z konkuren£ních standard· se nejlépe uplatnila verze SNMPv2c. Ta p°ebrala nové operace a datové typy druhé verze a zachovala p·vodní systém zabezpe£ení zaloºený na Community Stringu. Nové operace jsou:

Get Bulk

zefektivn¥ní vyuºití kanálu pomocí p°ená²ení v¥t²ího mnoºství dat jednou ope-

rací.

Inform

Stejná funkce jako TRAP, ale manager musí p°íjem zprávy potvrdit.

Response

Potvrzení p°ijetí zprávy INFORM managerem. Zasílá manager agentovi.

2.1.2.3 SNMPv3 Zabezpe£ení protokolu zlep²ila aº verze 3, standartizovaná jako RFC 2271-2275 [3]. Novinkou bylo i umoºn¥ní vzdálené kongurace agenta. Model zabezpe£ení je postaven na dvou základních komponentách - User Security model (USM) a View-based Access Control Model (VACM). USM má na starosti autentikaci a ²ifrování SNMP paket· a VACM spravuje p°ístupová práva k dat·m v MIB. Návrh USM se zam¥°il na tato bezpe£nostní rizika:

Integrita dat P·vod dat

zajistit, ºe p°i p°enosu nejsou data zm¥n¥na t°etí stranou.

zajistit, se aby t°etí strana nemohla vydávat jednoho z ú£astník· komunikace

Utajení dat

zabránit t°etí stran¥ £íst obsah p°edávaných zpráv

Po°adí zpráv

zajistit, aby t°etí strana nemohla zm¥nit po°adí zpráv.

2.2. XML

7

Autentikaci a soukromí zaji²úje systém uºivatel· a tajných klí£·. Autentikace je zaji²t¥na pomocí Hash-based Message Authentication Code - (HMAC-MD5)[18] a (HMACSHA)[18] s soukromí pomocí Data Encryption Standard (DES)[2]. VACM umoº¬uje vytvá°et skupiny uºivatel· a p°i°azovat jim p°ístupová práva. Je moºné omezit jak p°ístup k £ástem MIB, tak ur£it jaké operace m·ºe skupina nad MIB vykonávat. Vzdálená kongurace se provádí pomocí nastavnování (operace SET) hodnot ur£itých poloºek MIB.

2.2 XML Extensible Markup Language (XML) [26] vznikl odvozením ze Standard Generalized Markup Language (SGML)[7]. SGML je velmi univerzální, ale sou£asn¥ komplikovaný zna£ovací jazyk. Díky své univerzálnosti se stal velmi oblíbeným a jeho sloºitost vedla k odvozování jednodu²²ích jazyk·. Takto krom¥ XML vznikl i jiný dnes velmi d·leºitý jazyk - HyperText Markup Language (HTML) [14]. XML vzniká jako jazyk pro vytvá°ení strojov¥ £itelných dokument· p°ená²ených po Internetu. Dal²ími klí£ovými poºadavky byla maximální jednoduchost a univerzálnost. I p°es d·raz na strojové zpracování m¥l být XML dokument pro £lov¥ka £itelný. Pracovní skupina okolo Jona Bosaka tyto poºadavky nejen sestavila, ale i dokázala úsp¥²n¥ vy°e²it. World Wide Web Consortium (W3C) p°ijako XML jako standard v roce 1998. Jako zna£kovací jazyk pouºíva XML zna£ky(tagy) pro vytvá°ení struktury dokumentu. Základním prvkem dokumentu je element tvo°ený párem zna£ek (nap°. ... <\ulice>). Ten m·ºe mít denované atributy a m·ºe obsahovat dal²í elementy. Elementy se nesm¥jí p°ekrývat(element vloºený do jiného musí být uzav°en p°ed svým rodi£em). Dob°e sestavený XML dokument má stromou strukturu s jedním ko°enovým elementem a jeho potomky. Na rozdíl od HTML XML neur£uje význam jednotlivých zna£ek. Na to je moºné pouºít bu¤ star²í Document Type Denition (DTD) [26], nebo nov¥j²í XML schéma(XSD, nebo WXS) [9].

2.2.1 XML schéma Jak uº bylo uvedeno v p°edchozím textu XML schéma je nástroj na denování struktury a obsahu dokumentu. Oproti strar²ímu DTD vyuºívá syntaxe XML. Je ho tedy moºné zpracovávát pomocí stejných nástroj· jako XML dokumenty. Za hlavní zlep²ení je ale povaºován systém denice dat. Ten oproti DTD umoº¬uje kontrolovat datový typ atributu nebo elementu. Specikace XSD denuje 19 primitivních datových typ· [11] a formuluje pravidla pro vytvá°ení dal²ích. T°i základní zp·soby jsou:

•

Omezení mnoºiny hodnot.

•

Sestavení posloupnosti hodnot.

•

Moºnost vybrat hodnoty z n¥kolika datových typ·.

Pomocí t¥chto pravidel bylo ve specikaci denováno dal²ích 25 datových typ· [11]. Dal²í klí£ovou vlastností XSD je vytvá°ení prostor· jmen. Tím se dají velmi snadno °e²it konikty p°i slu£ování dokument·.


8

2.2.2 XSL Protoºe XML neur£uje význam zna£ek, bylo pot°eba najít zp·sob jak m¥nit formát dokumentu. e²ení se nazývá XML Stylesheet language (XSL) [11]. Tvo°í ho t°i £ásti. XSLT [12] - jazyk pro transformování XML dokument·, XPath [22] - jazyk pro prohledávání XML dokument· a slovník pro formátování XML dokument· - XSL Formating Objects [11]. XSLT je nejd·leºit¥j²í £ástí XSL standardu. Umoº¬uje vytvo°it transforma£ní ²ablonu. Ta denuje pravidla podle kterých jeden, nebo více vstupních dokument· transformováno na jiné dokumenty. Trasformace m·ºe obná²et zm¥nu XML schématu, nebo nap°íklad jen odstranit £ást dokumentu. Výstupním formátem nemusí být jen XML. XSTL se b¥ºn¥ pouºívá na p°eklad XML dokument· do HTML nebo XHTML. Dal²í moºností je transformace dokumentu do XML Formatting Objects. Takový výstup pak m·ºe být p°eveden do dal²ích formát·, mezi jinými do PDF, nebo PostScript. Pro prohledávání dokumentu vyuºívá XPath jeho stromové struktury. Pro vyjád°ení cesty ve stromu se pouºívá lomítková notace, podobná zp·sobu adresování v souborovém systému. Takto vyjád°ená cesta nemusí být absolutní, tedy nemusí za£ínat v ko°enu stromu. Výsledek dotazu je dále moºné omezit nap°íklad podle hodnoty atributu. Více informací o XPath se dá nalézt nap°íklad zde [22].

2.2.3 Zpracování XML Do v²eobecného pouºívání se dostaly dva zp·soby strojového zpracování XML dokument·. První, známý pod zkratkou SAX (Simple API for XML), zpracovává dokument proudov¥. Druhý, nazývaný DOM (Document Object Model) zpracovává dokument do struktury objekt· se stejnou hierarchií. Pro oba p°ístupy jsou dostupné imlementace ve v¥t²in¥ hlavních programovacích jazyk·.

2.2.3.1 SAX P°i proudovém zpracování je dokument postupn¥ £ten od za£átku do konce. P°i p°e£tení rozpoznané £ásti dokumentu (za£átek, nebo konec elementu, jeho t¥lo, nebo atribut apod.) je vyvolána událost. Zpracování dokumentu je tedy záleºitostí obsluhy série událostí. Tento p°ítup je velmi rychlý a má malou pam¥óvou náro£nost. Ale u sloºit¥ strukturovaných dokument· m·ºe být implementa£n¥ velmi náro£ný. Pokud je pot°eba k dokumnetu p°istupovat náhodn¥ a ne jen sekven£n¥ není moºné tuto metodu pouºít.

2.2.3.2 DOM Document Object Model je v mnoha sm¥rech opakem SAX. P°i zpracování je celý dokument na£ten do pam¥ti jako stromová struktura objekt·. V této struktu°e p°edstavuje kaºdý objekt jeden element dokumentu. Hlavní výhodou je práv¥ na£tení celého dokumentu do pam¥ti. Úpravy dokumentu se dají provád¥t velmi snadno. P°edev²ím je nad dokumentem moºné provád¥t dotazy jazykem XPath. Na£t¥ní dokumentu do pam¥ti je sou£asn¥ i hlavní nevýhodou. Pam¥óvá náro£nost je oproti SAX v¥t²í. Také vytvá°ení struktury objekt· je (relativn¥) pomalej²í. U malých dokument· nejsou tyto rozdíly p°íli² patrné, ale u v¥t²ích uº mohou být zna£né.

Kapitola 3

XML protokol pro správu sít¥ Jak jiº bylo uvedeno, ve své diplomové práci Peter Macejko navrhl systém pro správu po£íta£ových sítí zaloºený na XML. Cílem této kapitoly je poskytnout stru£né vysv¥tlení motivace vývoje takového protokolu a poskytnout jeho základní popis. Detailní informace je moºné najít v p·vodním textu Petera Macejka [23].

3.1 Motivace SNMP je dnes standardem v problematice správy po£íta£ových sítí. Jsou pro to dva d·leºité d·vody:

•

Implementace SNMP agent· jsou dostupné pro naprostou v¥t²inu síóvých prvk· - od po£íta£· p°es tiskárny po routery.

•

SNMP je roz²í°itelný protokol. Systém MIB umoº¬uje bez komplikací komunikovat s tak rozdílnými za°ízeními jako jsou routery a tiskárny. Sou£asn¥ moºnost denovat vlastní MIB zp°ístupní i specické vlastnosti konkrétního za°ízení, nebo výrobce.

P°esto se nejedná o dokonalé °e²ení. Mnoho nedostatk· pramení z p·vodní specikace protokolu. V dob¥ jeho vzniku byl rozsah a sloºitost sítí na kterých je dnes pouºíván jednodu²e nep°edstavitelný. Za hlavní nedostatky je povaºováno:

•

P°es "Simple"v názvu a malou náro£nost na systémové prost°edky je protokol náro£ný na implementaci.

•

Pomalé získávání v¥t²ích objem· dat z MIB. P°es ur£itá zlep²ení (nap°. operace Get Bulk) je kaºdá poloºka získávána samostatn¥ vým¥nou ºádosti a odpov¥di mezi managerem a agentem. Kaºdá taková operace je zatíºena zpoºd¥ním a ztrátami p°i p°enosu sítí.

•

Neefektivní vyuºívání kapacity kanálu. Roli zde hraje jednoduché kódování paket·, p°ená²ení dlouhého (a stále stejného) prexu OID a tzv. overshoot([23] kapitola 2.2.4) u operace Get Bulk.

9

KAPITOLA 3. XML PROTOKOL PRO SPRÁVU SÍT

10

•

P°enost tabulek je velmi sloºitý. Problémy jsou hlavn¥ p°i p°enosu "d¥ravých"tabulek(viz. [23] kapitola 2.2.4).

•

Uº mnohokrát zmín¥né zabezpe£ení protokolu je nedostate£né. Zde není na vin¥ ani tak specikace protokolu, jako spí²e selhání standartiza£ních snah v této oblasti. Jen mén¥ roz²í°ená verze 3 má praktické zabezpe£ení. Ale i ta je citlivá na slovníkové útoky a útoky hrubou silou. Pouºití transportního protokolu UDP pak nabízí moºnost podvrºení paket· t°etí stranou. Bezpe£nostní funkce SNMPv3 by ale m¥ly tomuto útoku zabránit. Ohroºeny tímto zp·sobem tedy jsou jen star²í verze.

3.2 Cíle Na základ¥ zmín¥ných nedostatk· a studia podobn¥ zam¥°ených publikací stanovil Peter Macejko základní poºadavky na navrhovaný protokol takto:

•

Musí vyuºívat XML dokumenty pro p°enos dat a musí vyuºívat informa£ní model zaloºený na XML schématu.

•

M¥l by být nenáro£ný na implementaci.

•

Musí být pouºitený na existujících za°ízeních.

•

Musí obsahovat mechanizmy pro autentikaci a ²ifrování p°ená²ených dat. Sou£asn¥ ale musí umoº¬ovat i nezabezpe£ený provoz. (Slabina zlep²ování zabezpe£ení SNMP byla v jeho vynucování za kaºdých okolností)

•

informa£ní model musí být roz²í°itelný.

Aby bylo moºné tyto poºadavky splnit bylo nutné vy°e²it n¥kolik díl£ích problém·. Nejprve bylo nutné navrhnout informa£ní model pro popis datových struktur a jejich vztah·. Pro zaji²t¥ní kompatibility s SNMP byl navrºen zp·sob mapování MIB do XML schémat. Dále byl ur£en zp·sob jakým bude probíhat komunikace a zp·sob jejích zabezpe£ení.

3.3 Informa£ní model Ú£elem infroma£ního modelu je mapování vlastností n¥jakého za°ízení do jasn¥ ur£ené struktury. P°i °e²ení této otázky hrálo hlavní roli zaji²t¥ní kompatibility s MIB SNMP. Nabízely se dv¥ moºnosti - zaloºit model na MIB, nebo ignorovat MIB model a budovat model na základ¥ objektového paradigma. P°ímé mapování MIB strom - XML strom je velmi snadné na implementaci a nabízí moºnost automatického p°evodu mezi MIB a XML schématem. Sou£asn¥ ale nep°iná²í ºádné zlep²ení proti MIB a vytvá°í p°ímou závislost XML stromu na MIB. Není tedy moºné upravit XML strom bez úpravy MIB. XML slouºí jen jako p°enosový protokol a není mnoho prostoru na uplatn¥ní jeho vlastností. Protoºe objektové mapování nevyuºívá struktury MIB není moºné p°evod MIB do tohoto infroma£ního modelu provád¥t automaticky. Pro kaºdý MIB objekt se musí ru£n¥ ur£it kam

3.4. MAPOVÁNÍ MIB DO XML

11

je mapován. Z druhé strany stromová struktura XML dokumentu omezuje moºnosti jako mapování provád¥t - v závislostech objekt· obecn¥ mohou být cykly. Po analýze se jako nejvhodn¥j²í ukázala kombinace obou p°ístup·. Model simuluje objektovou d¥di£nost pomocí odvození a roz²í°ení XML schématu. Spravovaný objekt pak tvo°í moduly. T¥ch existuje n¥kolik druh·. Z hlediska této práce je d·leºitá kategorie speciálních modul· - tzv. bran. Jejich úkolem je zajistit kompatibilitu se za°ízeními nepodporujícími XML protokol. Tedy p°eklad XML p°íkaz· do formátu srozumitelného pro dané za°ízení. Brána sou£asn¥ reprezentuje nekompatibilní za°ízení jako své moduly. Pro odvození typ· se pouºívá d¥di£nost. Od abstraktních (nap°. "Interface") se postupuje ke kontrétním (nap°."EthernetInterface"). Popis modulo je postaven na XSD schématu. Na schéma modulu jsou kladeny ur£ité poºadavky. Musí být popsána funk£nost, typ a cesta pro adresaci jednotlivých uzl·. Modul musí mít p°id¥leno unikátní jméno a denovaný ko°enový element. Ten se vyuºívá p°i spojování více modul· dohromady. Popis za°ízení je také zaloºen na XML schématu. To °íká kam se mají mapovat jednotlivé moduly.

3.3.1 Oznamovací zprávy Sou£ástí specikace je i popis jakým zp·sobem jsou °e²eny zprávy upozorující managera na mimo°ádnou událost u agenta (oznamovací zprávy). V SNMP jsou sou£ástí datového modelu i kdyº neobsahují ºádná data. V navrºeném systému je jim vyhrazen speciální modul za°ízení. Manager proto m·ºe snadno zjistit jaké oznamovací zprávy m·ºe za°ízení zaslat.

3.3.2 Adresace dat Poslední £ástí specikace informa£ního modelu je zp·sob adresace dat. Protoºe je zaloºen na XML je moºné vyuºít dotazy zaloºené na XPath, nebo XQuery.

3.4 Mapování MIB do XML Pro komunikaci se za°ízeními nepodporujícími XML protokol mají slouºit d°íve zmín¥né protokolové brány. Vzhledem k roz²í°ení protokolu SNMP je XML-SNMP brána prioritou. Aby bylo v·bec moºné zahájit implementa£ní práce, musel být navrºen zp·sob mapování MIB za°ízení do XML schématu brány. Tento úkol znamenal vy°e²it t°i díl£í problémy. Prvním byl p°eklad datových typ·, druhým jak importovat a skládát jednotlivé MIB do sebe a t°etím samotné konverze MIB stromu.

3.4.1 Datové typy Primitivní datové typy (integer, string,...) je moºné mapovat p°ímo na jejich ekvivalenty v XML schématu. Mapování datových typ· specických pro SNMP (Gauge, IpAddress,...) si ºádalo vytvo°ení zvlá²tních pravidel. Na obrázku 3.1 je uveden zp·sob mapování datových typ· SMIv1 do XML schématu. Protoºe SMI umoºnuje denovat nové datové typy bylo nutné navrhnout i zp·sob konverze pro tyto p°ípady. Detailní popis v²ech navrºených pravidel je uveden v kapitole 5.3.1 v [23].


12

Obrázek 3.1: Mapování datových typ· SMIv1 do XML schématu ([23])

3.4.2 Import MIB Návrh protokolu po£ítá s p°id¥lením unikátního prostoru jmen kaºdé MIB odvozením z jejího názvu. Importy jsou provád¥ny odkazem na typ s uvedením jeho jmenného prostoru.

3.4.3 P°eklad MIB stromu P°i mapování MIB stromu dojde k odd¥lení denic typ· od struktury stromu. Denice je pak moºné pouºívat i v jiném modulu, nebo pokud má uºivatel omezená p°ístupová práva k £ásti stromu. Objekty jsou v MIB denovány pomocí maker popisujících n¥kolik typ· uzl·. V SMIv1 jsou specikována makra OBJECT TYPE a TRAP TYPE. OBJECT TYPE denuje uzel obsahující data. Takovým uzlem m·ºe být jednoduchá hodnota, poloºka tabulky, nebo celý °ádek tabulky. Transformace se °ídí hodnotou v £ásti SYNTAX makra. Na obrázku 3.2 je uveden p°íklad transformace základního datového typu (simpleType). Zp·sob mapování dal²ích typ· je op¥t uveden v [23]. Makro TRAP TYPE denuje schopnost za°ízení odeslat zprávu o mimo°ádné události. Protoºe neobsahuje data není jeho p°ítomnost ve stromu nezbytná. Je proto mapováno mezi denice typ·. Povaºuje se za typ jednoduché datum a £as (datetime) se zvlá²tním tagem v elementu appinfo. Pro spojení t¥chto uzl· vyuºívá MIB makra OBJECT IDENTIFIER. Dal²í makra jsou denována v SMIv2. Jedná se o MODULE IDENTITY slouºící jako ko°en MIB stromu a OBJECT IDENTITY, který lze zjednodu²en¥ popsat jako pojmenovaný OBJECT IDENTIFIER. SMIv2 také nahrazuje makro TRAP TYPE makrem NOTIFICATION TYPE. Pravidla jejich p°evod jsou také uvedena v [23].

3.5. KOMUNIKANÍ MODEL

13

Obrázek 3.2: Mapování makra OBJECT TYPE (simpleType) ([23])

3.5 Komunika£ní model Jako zlep²ení proti nepotvrzovanému p°enosu SNMP by protokol m¥l vyuºívat spolehliv¥j²í potvrzovaný p°enos. Sou£asn¥ by zprávy m¥ly mít co nejednodu²²í formát. Jako nejvhodn¥j²í se ukázalo pouºít protokol HTTP s p°enosovým protokolem TCP. Takto se zajistí spolehlivost p°enosu. Zprávy protokolu jsou p°ená²eny jako XML dokumenty pomocí HTTP zprávy POST. HTTP pouºívající webové rozhraní mají dnes i velmi levná/jednoduchá za°ízení. Pouºití t¥chto protokol· tedy nep°edstavuje významné zvý²ení HW náro£nosti protokolu v porovnání s SNMP. Pouºití HTTP také velmi usnad¬uje otázku bezpe£nosti. Pro zabezpe£ení HTTP komunikace existují vyzkou²ené a osv¥d£ené postupy (HTTPS, IPSec,...). XML dokument zprávy má jasn¥ daný formát. Ko°enovým uzlem je element Ten má n¥kolik atribut·. Nepovinný atribut

queue

ale nemusí prioritu zpráv zohled¬ovat. Dal²í atributy mezení p°ístupových práv uºivatele. Element

message.

ur£uje prioritu zprávy. Agenti a brány

message

password

a

context

slouºí k vy-

pak m·ºe obsahovat n¥kolik dotaz·.

Podporované dotazy jsou popsány dále.

3.5.1 DICOVERY Zpráva kterou si manager vyºádá popis monitorovaných dat. Atribut £uje jakou verzi protokolu manager pouºívá.

objectId

protocolVersion

ur-

ur£uje o popis kterého za°ízení má

manager zájem. Hodnota 0 pak slouºí k získání seznamu za°ízení agenta.

<message password="1234">

3.5.2 PUBLICATION Odpov¥¤ agenta na DISCOVERY. Obsahuje informace o verzi protokolu a spravovaných za°ízeních, nebo detailní popis jednoho za°ízení.


14

<message> <xpath>1.0 ... XML schéma spravovaného za°ízení

3.5.3 GET Dotaz na hodnotu n¥jakého uzlu. Uzel je specikován pomocí XPath.

<message password="1234"> "; <xpath> iso/org/dod/internet/mgmt/mib-2/system/sysDesc

3.5.4 SET Podobná zpráva jako GET, ale slouºí k nastavení hodnoty uzlu. Obsahuje tedy navíc element

value

s novou hodnotou.

<message password="1234"> <xpath> iso/org/dod/internet/mgmt/mib-2/system/sysDesc Testovaci zarizeni

3.5.5 RESPONSE Odpov¥¤ na zprávu GET, nebo SET. Obsahuje hodnotu uzlu. U zprávy SET obsahuje hodnotu uzlu po provedení p°íkazu. Slouºí tedy jako kontrola, jestli operace usp¥la.

Testovaci zarizeni

3.5. KOMUNIKANÍ MODEL

15

3.5.6 EVENT Asynchonní zpráva od agenta managerovi o mimo°ádné události. Obsahuje informace specikující mimo°ádnou událost, odesílatele, datum a £as.

<message> <event msgid="1" senderid="1" eventSpec="device/notifications/linkDown">

3.5.7 SUBSCRIBE Pomocí této zprávy se manager p°ihlásí k opakovanému odb¥ru hodnoty n¥jakého uzlu. Pokud je operace úsp¥²n¥ provedena agent odpoví první zprávou DISTRIBUTION s hodnotou

frequency ur£uje dobu ve vte°inách po které mají být zprávy zasílány. Atributy delete se pouºívají p°i ru²ení pravidelného zasílání.

uzlu. Atribut

distrid

a

<message password="1234"> <subscribe msgid="1" objectId="1" frequency="10"> <xpath> iso/org/dod/internet/mgmt/mib-2/tcp/tcpInSegs

3.5.8 DISTRIBUTION Zpráva obsahuje pravideln¥ zasílaná data. Pokud je sou£asn¥ odebíráno více hodnot, mají ve zpráv¥ stejné po°adí jako v ºádosti SUBSCRIBE. Atribut stran¥ managera.

9450

distrid

identikuje data na

16


Kapitola 4

Implementované projekty 4.1 Java manager a brána Teoretický návrh XML protokolu a XML-SNMP brány bylo nutné prakticky ov¥°it. To bylo cílem práce Michala Tre²a. V rámci své diplomové práce implementoval prototyp agenta(XMLSNMP brány) a jednoduchého managera pro navrhovaný protokol. Pro implementaci zvolil programovací jazyk Java, p°esn¥ji platformu J2SE 1.5. Sou£ástí návrhu bylo i uºivatelské (webové) rozhraní zaloºené na servletech. Z £asových d·vod· bylo nakonec implementováno ovládání jen pomocí administra£ní konzole. Pro ukládání dat bylo zvoleno ukládání do souborového systému.

Obrázek 4.1: Schéma prototypové brány ([27])

17

KAPITOLA 4. IMPLEMENTOVANÉ PROJEKTY

18

4.1.1 Informa£ní model Informa£ní model implementované brány se drºí princip· popsaných v kapitole 3. Oproti p·vodnímu návrhu ale bylo provedeno n¥kolik zm¥n. P°edev²ím XSD schéma neumoº¬uje do jednoho souboru vkládát denice z více jmenných prostor·. To pon¥kud komplikuje vytvo°ení jednoho XSD schématu popisujícího celou bránu, pokud její popis tvo°í více MIB soubor·. esením se ukázalo p°ekládát více MIB do jednoho schématu se spole£ným jmenným prostorem. Jeho jmého je ur£eno z jmen jednotlivých MIB. Pro dotazování nad XML reprezentací brány má být pouºívám jazyk XPath. Ten ale pracuje s prohledávaným dokumentem jako s b¥ºným XML, tedy není schopen pracovat p°ímo s XSD schématem brány. Z toho d·vodu brána ze schémat generuje instance XML dokument· a dotazování provádí nad nimi. Z t¥chto d·vod· tedy probíhá p°eklad MIB do XML ve dvou fázích. V první je MIB dokument(y) p°eloºen do XSD schématu a ve druhé je z n¥j vygenerována XML instance. P°i p°ekladu je MIB z dokumentu pomocí knihovny

Mibble

vytvo°ena stromová struktura.

Na ní pak jsou rekurzivn¥ od ko°ene aplikována transforma£ní pravidla. Výsledkem jsou dv¥ XSD schémata. Jedno obsahující stromovou reprezentaci MIB a druhé denice typ·. Generování XML instance pak probíhá velmi podobn¥. Je tedy budována rekurzivním pr·chodem stromu XSD schématu. P°i tomto postupu je MIB objekt mapován na element XML dokumentu. Jeho atributy, v XSD schématu reprezentované jako elementy, jsou ukládány jako atributy element·. Výsledný dokument tedy není proti svému schématu validní. To ale nep°edstavuje problém, protoºe XPath adresace bude probíhat jen pomocí názv· element· a ne jejich atribut·.

4.1.2 Komunika£ní model Ob¥ strany komunikace (brána i manager) musí být, bez ohledu na konkrétní implementaci, schopny dvou základních komunika£ních úkon·. Prvním je odesílání zpráv. V p°ípad¥ brány se jedná o zprávy EVENT a v p°ípad¥ managera o zprávy DISCOVERY, GET, SET a SUBSCRIBE. Speciální p°ípad pak p°edstavují zprávy DISTRIBUTION. Druhým komunika£ním úkonem je p°íjem zpráv. Manager odesílá zprávy DISCOVERY, GET, SET a SUBCRIBE. Brána pak zprávy EVENT a DISTRIBUTION. Komunikace probíhá pomocí protokolu HTTP na principu vým¥ny ºádostí (request) a odpov¥dí (response). Strana p°ijímající zprávy se v n¥m nazývá HTTP server. Ten je v práci realizován jako vloºený (embedded) pomocí knihovnycom.sun.net.httpserver. Aby se zabránilo jeho zahlcení p°ijímanými zprávami implementoval Bc. Tre²o v brán¥ systém p°ijímacích front. Kaºdá zpráva(HTTP request) je p°ijata serverem a p°edána do pracovní fronty. Pokud je fronta plná, zpráva není p°ijata a komunice je ukon£ena. Z fronty jsou poºadavky vybírány ve stejném po°adí v jakém dorazily. U poºadavku jsou nejprve ov¥°ena p°ístupová práva. Pokud má uºivatel právo operaci provézt je po°adavek za°azen podle priority do jedné z front k provedení. Po provedení je vygenerována odpov¥¤ a zaslána managerovi jako HTTP response. Pro odesílání zpráv EVENT a DISTRIBUTION pouºívá brána podobný systém. V p°ípad¥ zpráv EVENT modul brány p°ijímá zprávy TRAP SNMP protokolu. Po obdrºení takové zprávy vytvo°í objekt a za°adí ho do pracovní fronty. Ta plní stejný ú£el jako fronta

4.2. XML-SNMP BRÁNA V C++

19

p°ijímaných zpráv - tedy zabránit zahlcení brány. Objekty jsou z fronty vybrány, dopln¥ny o data z informa£ního modelu a za°azeny do odesílací fronty. Z ní je vybírá HTTP klient a odesílá manager·m. U zpráv DISTRIBUTION se postupuje stejn¥. Jen jejich objekty nejsou generovány p°íjmem SNMP zprávy, ale £asova£em v infroma£ním modelu. Ten je nastaven p°i zpracování zprávy SUBSCRIBE.

4.1.3 Zhodnocení Tato implementace úsp¥²n¥ ov¥°ila pouºitelnost navrºeného protokolu. Jako prototyp ale má ur£ité nedostatky. Implementace managera poskytuje jen velmi základní funkce (odesílání a p°íjem p°íkaz·). Ovládání pomocí administra£ní konzole také není zcela uspokojivé. Uº autor zmi¬uje, ºe pouºití jazyka Java pro implementaci XML-SNMP brány není zcela ²ástné. P°edpokládá se, ºe roli brány mohou plnit i relativn¥ jednoduchá za°ízení (nap°. router). Základním poºadavkem na takovou bránu tedy je pokud moºno co nejmen²í náro£nost na systémové prost°edky. Jazyk Java není z tohoto hlediska p°íli² vhodný. V Jav¥ napsaná aplikace také k fungování vyºaduje Java Virtual Machine (JVM), respektive Java Runtime Enviroment (JRE). Na takto jednoduchém za°ízení nemusí být jejich provoz moºný.

4.2 XML-SNMP brána v C++ S v¥domím t¥chto nedostatk· p°istoupil k implementaci XML-SNMP brány Tomá² Hroch. Pro implementaci brány pouºil jazyk C++ a v¥noval pozornost omezení náro£nosti na systémové prost°edky. Protoºe mnoho (i jednoduchých) síóvých za°ízení pouºívá opera£ní systém LINUX je tato volba velmi vhodná. P°i zvládnutí náro£n¥j²í implementace je aplikace napsaná v C++ mén¥ náro£ná na zdroje, neº pokud by byla napsaná v Jav¥. Také s jejím provozem na opera£ním systému LINUX je velmi málo komplikací. Po volb¥ této implementa£ní platformy se ukázalo jako logické bránu strukturovat jako démona. Za cenu hor²í p°enositelnosti a platformové nezávisloti se tak povedlo dosáhnout rychlé reak£ní doby. Brána byla navrºena tak, aby podporovala verze protokolu SNMPv1 a SNMPv2c v£etn¥ modelu zabezpe£ení. Aby se usnadnilo pozd¥j²í roz²í°ení, byla brána navrºena jako modulární systém. V rámci implementace tedy musel být navrºen SNMP modul, XML modul a zp·sob propojení obou modul·. Oba moduly jsou popsány dále v této kapitole. Komunikace mezi nimi probíhá pomocí zasílání poºadavk·. Aby se zabránilo zahlcení modul· jsou jejich vstupy a výstupy °e²eny jako fronty. B¥h programu brány probíhá podobn¥ jako v p°edchozí implementaci. Brána nejprve na£te kongura£ní soubor. V n¥m jsou uloºeny informace o spravovaných za°ízeních a konguraci samotné brány. Popis kaºdého za°ízení obsahuje adresu za°ízení a seznam jeho MIB. B¥hem inicializace SNMP modul ov¥°í, ºe je za°ízení popsané v kongura£ním souboru aktivní. V dal²ím kroku je provedena transformace dat z kongura£ního souboru a odkazovaných MIB do XML. Pro kaºdé za°ízení a pro samotnou bránu je vygenerován samostatný XML dokument. Tato úprava si vyºádala zm¥nu komunika£ního protokolu, p°esn¥ji zprávy DISCOVERY. Brána na první zprávu tohoto typu zareaguje odesláním jen svého popisu (v£etn¥ seznamu p°ipojených za°ízení). Schémata konkrétních zaºízení si pak manager vyºádá dal²ími zprávami pomocí atributu

objectId.

V posledním kroku pln¥ ini-


20

Obrázek 4.2: Schéma C++ brány ([20])

cializovaná brána p°ijímá poºadavky manager·, p°ekládá je do protokolu SNMP a vrací výsledky.

4.2.1 SNMP modul

Obrázek 4.3: Vlákna a fronty SNMP modulu ([20])

I tento modul vyuºívá systému front. Pro kaºdé pod°ízené za°ízení je v modulu vyhrazeno obsluºné vlákno a fronta zpráv. Pro komunikaci v SNMP protokolu pouºívá modul knihovnu

net-snmp. Kaºdé obsluºné vlákno vykonává v nekone£ném cyklu n¥kolik díl£ích úkon·. Nejprve zjistí jestli nemá ve své front¥ n¥jaký poºadavek. Pokud ne, tak se uspí. Pokud ano, tak vyjme v²echny poºadavky a zpracuje je. Poºadavky na nastavení, nebo zji²t¥ní hodnoty

4.2. XML-SNMP BRÁNA V C++

21

koncovéhu uzlu jsou provedeny jako Set, nebo Get p°íkazy SNMP. Pokud není cílem koncový uzel, je poºadavek proveden jako série p°íkaz· GetNextRequest protokolu SNMP. Po získání v²ech dat je vytvo°ena odpov¥¤ pro XML modul.

4.2.2 XML modul XML modul aplikace se stará o p°eklad MIB do XML a o zpracovávání zpráv XML protokolu. P°eklad MIB do XSD schématu probíhá i v této práci pomocí rekurzivního sestupu MIB stromem a aplikaci p°ekladových pravidel. Kaºdému uzlu je p°i°azeno identika£ní £íslo (OID), datový typ a p°ístupová práva. Uzel je pak za°azen na své místo ve stromové struktu°e XSD schématu. Paraleln¥ s tímto schématem je vytvá°ena i jeho XML instance na provád¥ní dotaz·. Pokud je poºadavek sm¥rován na centrální uzel. Pro zpracování kaºdého p°íchozího poºadavku se pouºívá samostatné vlákno. To nejprve ov¥°í, ºe je p°ijatá zpráva typu POST. Pokud není, pak je odeslána chybová odpov¥¤ a ukon£eno spojení. Jinak je pomocí XML parseru ov¥°eno, ºe zpráva má správný formát. Kdyº je v²e v po°ádku, je vytvo°en poºadavek a za°azen do vstupní fronty SNMP modulu. V p°ípad¥ zpráv typu SUBSCRIBE je je²t¥ tato operace zaznamenána v XML dokumentu brány. XML modul se pak stará a pravidelné zasílání poºadavku SNMP modulu a zaslání hodnoty managerovi. Vlákno po odeslání poºadavku kontroluje frontu odpov¥dí XML modulu a £eká aº SNMP modul ºádost zpracuje. Po doru£ení výsled· je sestavena a odeslána odpov¥¤. I v této práci musela být vy°e²ena otázka volby HTTP serveru. Podobn¥ jako práci Bc. Tre²a se ukázalo vhodn¥j²í pouºít vloºený (embedded) server, tentokáte z knihovny

libMicroHTTPD.

4.2.3 Zhodnocení Poºadované funkce tato brána plní dob°e. Protoºe spl¬uje i poºadavek malé náro£nosti, je vhodné jí pouºít p°i dal²í práci na projektu. P°i implementaci managera (viz. dále v této práci) se objevilo n¥kolik drobných nedostatk·. Ale jejich oprava byla velmi snadná. V¥t²ina z nich navíc byla zp·sobena nedokumentovanými vlastnostmi pouºitých knihoven.

22


Kapitola 5

Výsledky výzkumu P·vodní práce Petera Macejka obsahovala shrnutí výsledk· podobných výzkumných projekt·. Protoºe od jejího sepsání ub¥hlo jiº nekolik let je na míst¥ pokusit se o podobné srovnání znovu. P°i hledání podklad· pro tuto kapitolu bylo prvním cílem zjistit aktuální stav projekt· uvedených v práci Petera Macejka. Dal²í postup pak sm¥°oval k nalezení jiných, p·vodn¥ neuvedených, prací a v porovnání jejich výsledk· s navrhovaným protokolem a aplikacemi. Hledání dal²ích výsledk· p·vodn¥ uvedených projekt· se neukázalo jako p°íli² úsp¥²né. N¥které projekty se uº nepovedlo v·bec najít. U jiných se povedlo najít dal²í publikované výsledky, ale jejich zhodnocení je obtíºné z jazykových d·vod·, nebo pro chyb¥jící datum publikace. P°es tyto problémy se povedlo najít n¥kolik zajímavých publikací.

5.1 TU Braunsweig Práce výzkumné skupiny F. Strausse z Technische Universität Braunschweig je zmi¬ována uº v práci Petera Macejka. Ta publikovala v období 2001-2004 n¥kolik £lánk· na téma vyuºití XML a SMNP. Podle webových stránek[17] byl projekt aktivní aº do roku 2008. Zjistit detailní informace je ale sloºité. Webová prezentace obsahuje jen základní uºivatelské informace ve form¥ manuálových stránek. Podrobnosti jsou s nejv¥t²í pravd¥podobností obsaºeny v jednotlivých studentských pracích. Ty se ale nejsou k dispozici. I v p°ípad¥, ºe by se je povedlo získat, by bylo zpracování n¥mecky psaných technických text· pro autora této práce p°inejmen²ím obtíºné.

5.2 POSTECH Výzkum provedený na universit¥ v Pohangu v Jiºní Korei je také citován v p·vodní práci ing. Macejka. Vyuºití a nalezení dal²ích výsledk· velmi komplikuje tém¥° neexistující datování t¥chto prací. P°esto je vhodné zmínit £lánek An Embedded Web Server Architecture for XML-Based Network Management [19] z roku 2002. V síóvých prvcích se stále £ast¥ji objevují vestav¥né (embedded) webové servery. Tento trend sice v mnoha sm¥rech usnadnil konguraci jednotlivých za°ízení, ale zatím nep°inesl ºádné zlep²ení v oblasti centralizované správy. Kolektiv autor· zde navrhuje zlep²ení práv¥ v této oblasti. Navrhovaný postup se v mnoha sm¥rech podobá námi navrhovanému °e²ení. Tedy pouºít p°es HTTP p°ená²ené

23

KAPITOLA 5. VÝSLEDKY VÝZKUMU

24

XML zprávy pro komunikaci mezi agenty a managery. Agenti pak slouºí jako protokolové brány mezi XML protokolem a jinými protokoly - nap°. SNMP. Roli agent· mají plnit práv¥ zmi¬ované vestav¥né webové servery. Struktura takového agenta je na obrázku 5.1. Agent si udrºuje DOM objekt reprezentující spravovaná za°ízení a data. Nad ním pak provádí XPath dotazy zaslané managerem. Toto °e²ení ale není jediné moºné. V dal²ím £láku[28] je analyzováno n¥kolik moºností, jak realizovat p°eklad XML protkolu na SNMP. Popisované moºnosti jsou:

•

P°eklad na úrovni Managera: Manager udrºuje DOM odpovídající MIB stromu zpravovaných za°ízení. Dotaz na list DOM stromu je p°eloºen na SNMP p°íkaz a odesán SNMP agentovi.

•

P°eklad na úrovni Klienta: Manager odesílá HTTP request s XPath, nebo XQuery jako parametry. Agent si udrºuje DOM a dotazy na jeho listy p°ekládá na SNMP dotazy. Hlavním rozdílem je tedy p°esun DOM stromu a souvisejících funkcí z managera do agenta.

•

Pouºití SOAP: Princip fungování je stejný jako v p°edchozím p°ípad¥. Jen XPath/XQuery dotaz není posílán v URI, ale proveden jako volání vzdálené funkce pomocí SOAP.

Obrázek 5.1: Struktura POSTECH agenta ([19])

Oba £lánky obsahují mnoho podn¥tných my²lenek, ale nejsou bez nedostatk·. V návrhu není kladen ºádný d·raz na omezené HW prost°edky síóvých prvk·. P°edev²ím pam¥óv¥ náro£ný DOM m·ºe být nad jejich moºnosti.

5.3 Web services for network management Práce[25] Bernarda Thurma z university v Karlsruhe nabízí mnoho poznatk· o realizaci skute£n¥ distribuovaného systému správy sít¥. Základní my²lenkou je rozd¥lení funkcí správy

5.4. ÍNSKÝ VÝZKUM

25

na logické celky a ty realizovat jako samostatné moduly. Kaºdý modul pak poskytuje své funkce jako sluºby pomocí XML a SOAP. Podle úkol· je systém rozd¥len na £ty°i vrstvy. Celá struktura systému je na obrázku 5.2. Nejvy²²í vrstvou jsou r·zná uºivatelská rozhraní tlustý klient, webová aplikace, nebo klient do mobilního telefonu. O úrove¬ níºe jsou moduly infrastrukturních sluºeb. Ty fungující jako adapta£ní vrstva mezi klienty a vrstvou managerských sluºeb. Na této vrstn¥ se také nacházejí moduly spravující politiky a "submoduly". Vrstvu managerských slouºeb pak tvo°í moduly starající se o samotné vykonávání úkon· správy. Protoºe modul se spravovanými za°ízeními komunikuje p°ímo, tak musí obsahovat submoduly starajících se o p°eklad p°íkaz· do formátu srozumitelného pro cílové za°ízení. Práv¥ pro centralizovanou správu takových p°ekladových modul· slouºí repozitá° modul· ve vrstv¥ infrastrukturních sluºeb.

Obrázek 5.2: Architektura systému ([25])

Velkou výhodou této práce je, jak promy²lený návrh, tak existence pokusné implementace pro správu MPLS (Multiprotocol Label Switching) sítí. Za nedostatky lze povaºovat snad jen nedostate£né zd·vodn¥ní pouºitých technologií a chyb¥jící moºnost vytvá°ení víceúrov¬ové struktury managementu.

5.4 ínský výzkum Problematikou uplatn¥ní XML v managementu po£íta£ových sítí se zabývá i n¥kolik ínských v¥dc·. Publikované práce ale v¥t²inou neposkytují mnoho informací. Anglicky psaný text je velmi ²patn¥ srozumitelný. V citacích uvedené práce v¥t²inou nejde mimo ínu sehnat. V pozitivním smyslu lze zmínit práci od Meijuan Wei, Debao Xiao a Jintao Guo [15].


26

Tato práce nabízí n¥kolik zajímavých podn¥t·. P°edev²ím zmi¬uje problematiku hierarchie manager· a s tím souvisejících poºadavk· na výstupy(sledování trend·). Také se zabýva bezpe£ností a konzistencí vzhledem k existenci n¥kolika rozhraní na koncových za°ízeních (SNMP, Web, telnet). Zajímavý je d·raz na správu zaloºenou na formulování politik. Struktura navrhovaného systému je na obrázku 5.3.

Obrázek 5.3: Architektura systému ([15])

Jednotlivé prvky mají tyto funkce:

Manager, GUI

ást p°edstavující prezentaci stavu systému pro uºivatele, nebo manager-

skou aplikaci vy²²í úrovn¥.

Management Server

Manaºer poskytjící webové rozhraní pro uºivatele a rozhraní pro

nad°azené managerské aplikace.

Independent Management Entity

Agent starající se o vykonávání p°íkaz· a vynucování

ur£ené politiky na pod°ízených za°ízeních. Sou£ástí £lánku je i popis experimentální implementace. V n¥m ale chybí, nebo je z textu nejasné, vysv¥tlení funkcí a vlastností n¥kterých základních prvk·. Za mén¥ poda°ený lze ozna£it £lánek od Wenli Dong[16]. V £lánku jsou o navrhované aplikaci jen základní informace a práce uvedené v referencích není moºné najít. V podstat¥

5.5. XMLN OVER VOIP

27

jde celý £lánek shrnout do jedné v¥ty: "Pomocí mapování MIB do XML lze vytvo°it systém pro správu sít¥".

5.5 XMLN over VoIP Tato práce[24] pochází ze soukromého sektoru. Popisuje po£áte£ní fáze implementace na XML zaloºeného protokolu pro správu sít¥. Zmínka o Voice Over IP (VoIP) v názvu souvisí s hlavním oborem £innosti rmy Qovia. V popisu °e²ení nemá ºádné uplatn¥ní. Protoºe se jedná o po£áte£ní implementaci, bez rozsáhlé analýzy, má projekt mnoho závaºných nedostatk·. I kdyº pouºívá XML, tak nevyuºívá moºnosti vytvá°et strukturované dokumenty. MIB není do XML mapováno jako strom, ale jen jako mapa klí£ MIB kód. Struktura XML zpráv mezi agenty a managery je také p°íli² jednoduchá. Obsahuje jen páry klí£ hodnota. Pokud manager zji²úje stejné informace od více za°ízení, není pak moºné poznat, od koho odpov¥¤ p°i²la.

5.6 Zhodnocení Ve v¥t²in¥ prostudovaných £lánk· se na realizaci navrhuje pouºití technologií odvozených od jazyka Java. Je na míst¥ otázka jestli se jedná o optimální °e²ení. U manager· se dá o£ekávat d·raz na budování hierarchické struktury a pot°ebu sloºitých výstup·. Sou£asn¥ se dá p°edpokládat dostate£n¥ výkonný HW. Pro managery je tedy pouºití Javy, aplika£ních server· a JSP logické a vhodné. U agent· uº to tak jednozna£né není. Agent musí fungovat s výrazn¥ mén¥ zdroji. Proto je pouºití mén¥ náro£ného C++ výhodn¥j²í. Je ale také pot°eba zváºit, jestli je vhodné vytvá°et a udrºovat dva zdrojové kódy ve dvou jazycích. Opakovan¥ je jako hlavní nedostatek SNMP uvád¥na jen dvouúrov¬ová struktura agentmanager. Nalezené £lánky tuto problematiku ale tém¥° ne°e²í. Bylo by tedy na míst¥ jí v¥novat pozornost. Pozornost by také bylo vhodné v¥novat zaji²t¥ní bezpe£nosti a konzistence v XMLBNM. Zhodnocení vhodnosti pouºitých technologií a návrhu vlastností navrhovaného systému se v¥nuje následující kapitola.

28


Kapitola 6

Návrh systému 6.1 Stav projektu Ob¥ p°edchozí implementa£ní práce se zam¥°ily na ov¥°ení konceptu XML/SNMP brány. První zkoumala, jestli je v·bec moºné takovou bránu napsat. Druhá se snaºila je²t¥ splnit striktní poºadavky na malou náro£nost na systémové prost°edky. V C++ provedená brána od Bc. Hrocha tyto poºadavky zcela splnila. Ob¥ práce ale obsahují jen velmi základní implementaci managera, vhodnou jen na ov¥°ení základních funkcí brány. Pro dal²í vývoj projektu je tedy nutné navrhnout serverovou/managerskou aplikaci. Tak bude dokon£ena pilotní implementace projektu pouºití XML p°i správ¥ po£íta£ových sítí. V del²ím horizontu by pak managerská aplikace mohla poslouºit jako odrazový m·stek pro napojení na dal²í systémy vy²²í úrovn¥. Tím by se m¥lo poda°it splnit poºadavek na vytvo°ení víceúrov¬ového systému pro správu a dohled na po£íta£ové sít¥. Tento poºadavek je uvedený jak v p·vodní specikaci protokolu, tak opakovan¥ zmi¬ovaný v publikovaných v¥deckých £láncích.

6.2 Managerská aplikace Hlavním úkolem managerské aplikace je spravovat a dohlíºet na za°ízení s pomocí XML/SNMP brány. Aby mohla plnit tento úkol musí navrhovaná aplikace poskytovat tyto funkce:

•

P°ipojit se k XML/SNMP brán¥. Brána odpoví seznamem sledovaných za°ízení a jejich parametr·. Tedy dojde k vým¥n¥ zpráv DISCOVERY a PUBLICATION.

•

Ze získaného seznamu jde vybrat n¥jaký parametr a je moºné zjistit, nebo nastavit jeho hodnotu. To odpovídá vým¥n¥ zpráv typu GET/SET a RESPONSE.

•

P·jde vytvo°it dohledovou operaci. Vybere se parametr, který se má sledovat. Ur£í se frekvence sledování a nastaví horní a dolní meze hodnot. Po úsp¥²né vým¥n¥ zpráv SUBSCRIBE a DISTRIBUTION se check za°adí do dohledového systému.

•

Dohledový systém poskytuje informace o stavu sledovaných za°ízení a upozor¬uje ho na p°ekro£ení nastavených parametr·.

•

Aplikaci musí být moºné snadno a p°ehledn¥ ovládat.

29

KAPITOLA 6. NÁVRH SYSTÉMU

30

Krom¥ vý²e uvedených poºadavk· je poºadována je²t¥ jedna vlastnost. Je to maximální modularita. Ú£elem je umoºnit dal²í rozvoj managerské aplikace prostým nahrazením n¥jakého modulu a také moºnost pouºít samostatný modul jako knihovnu v dal²ím projektu. Pomocí vý²e uvedených poºadavk· si aplikaci m·ºeme rozd¥lit do £ty° základních modul·:

•

komunika£ní

•

dohledový

•

uºivatelský

•

kongura£ní

Dále je uvedena jejich detailn¥j²í specikace, alternativy °e²ení a zd·vodn¥ní volby implementa£ní platformy.

6.2.1 Programovací jazyk Prvním krokem je volba vhodného programovacího jazyka. Nabízejí se dv¥ moºnosti. Bu¤ pouºít jazyk C++, pak bude moºné vyjít z uº existujícího kódu XML/SNMP brány a dosáhnout dobré úrovn¥ sjednocení kódu. Nebo pouºít jazyk Java. Pro C++ hovo°í men²í nároky na systémové prost°edky. Nevýhodou jsou vy²²í nároky na programátora a s tím související vy²²í pravd¥podobnost výskytu chyb. Vzhledem k p°edpokládanému navázání managerské aplikace na programy vy²²í úrovn¥ (nap°íklad informa£ní systém) je vhodné zmínit snadné vyuºívání technologií, jako jsou webové sluºby, nebo vzdálené volání funkcí v Jav¥. Protoºe hlavní poºadavek na XML/SNMP bránu malé nároky na systém není u managera nutné uplat¬ovat tak striktn¥ a sou£asn¥ se v Jav¥ snadno integrují dal²ích technologie jeví se tento jazyk jako vhodn¥j²í. To ale neznamená, ºe je moºné se úpln¥ vzdát snahy o minimalizaci náro£nosti aplikace. V n¥kolika podobných výzkumných projektech se auto°i p°i volb¥ technologií spoléhají na zbyte£n¥ náro£né a robustní technologie, jmenovit¥ Javu Enterprise Edition. Tato volba není £asto ani nijak zd·vodn¥na. Vzhledem k plánovanému rozsahu aplikace je dostate£né pouºít technologii Java SE (p°esn¥ji Java SE 1.6). Sou£ástí poºadavk· na managerskou aplikaci je i p°ehledné uºivatelské rozhraní. Java SE obsahuje nástroje pro tvorbu jak b¥ºných, tak webových, uºivatelských rozhraní. Jako nástroj pro vytvá°ení webových rozhraní nabízí technologii Java Server Pages (JSP). Aby tuto technologii bylo moºné pouºít, je pot°eba do poºadavk· aplikace za°adit funk£ní instalaci vhodného servlet kontejneru (nap°íklad Apache Tomcat 6.0). Náro£nost takového kontejneru je ale výrazn¥ men²í, neº kompletního aplika£ního serveru, jako je Sun Glasssh.

6.2.2 Komunika£ní modul Ú£elem tohoto modulu je zaji²óvání komunikace pomocí navrºeného XML protokolu. Na jedné stran¥ musí modul obsahovat rozhraní pro odesílání a p°íjem zpráv a na druhé rozhraní pro komunikaci se zbytkem aplikace. Aby modul dokázal správn¥ komunikovat s XML/SNMP bránou musí ovládat tyto komunika£ní funkce navrºeného protokolu:

6.2. MANAGERSKÁ APLIKACE

31

•

vytvá°ení a odesílání zpráv DISCOVERY, p°íjem odpov¥dí PUBLICATION

•

vytvá°ení a odesílání zpráv GET, SET, p°íjem odpov¥dí RESPONSE

•

p°íjem zpráv EVENT

•

vytvá°ení a odesílání zpráv SUBSCRIBE, p°íjem zpráv DISTRIBUTION

Ze strany zbytku aplikace je nejvhodn¥j²í ovládání modulu °e²it jako volání funkcí. Aby se zabránilo zahlcení aplikace p°ijímanými zprávami bude pot°eba vytvo°it mechanizmus front zpráv v obou sm¥rech komunikace. Podle navrºeného protokolu probíhá komunikace pomocí HTTP, respektive HTTPS. Ten vyuºívá principu vým¥n ºádost-odpov¥¤ (request-response). Strana zahajující komunikaci se nazývá HTTP klient a strana p°ijímající ºádosti HTTP server. Do návrhu komunika£ního modulu je tedy pot°eba za°adit i zp·sob realizace HTTP klienta a serveru. Nabízejí se t°i moºná °e²ení:

•

naprogramovat vlastní http/https server a klienta

•

vyuºít server a klienta z existující knihovny

•

pouºít API http serveru pracujícího mimo aplikaci.

Vzhledem k tomu, ºe provád¥ná HTTP komunikace není nijak sloºitá, mohlo by se první °e²ení jevit jako nejhospodárn¥j²í. P°i bliº²ím pohledu se ale ukáºe, ºe to tak není. P°edev²ím se ani od serveru, ani od klienta neo£ekávají jiné, neº naprosto standartní vlastnosti. Není proto d·vod nepouºít n¥jakou uº existující implementaci. Pro tuto moºnost hovo°í problematika zabezpe£ení protokolu. V sou£asné implementaci není komunikace nijak zabezpe£ena. Specikace XML protokolu ale hovo°í o moºnosti komunikaci ²ifrovat. P°i pouºití vlastní implementace HTTP serveru, nebo klienta by se i taková funk£nost musela programovat. Naopak vhodn¥ zvolená knihovna uº v sob¥ pot°ebnou funk£nost bude obsahovat. Proti poslední moºnosti hovo°í poºadavek na modularitu aplikace. Pouºití externího HTTP serveru by omezilo moºnosti samostatného pouºití tohoto modulu. HTTP server a klient budou tedy v aplikaci °e²eny pomocí existujících knihovních implementací. P°i volb¥ konkrétních knihoven je na míst¥ uplatit zku²enosti z prototypové implementace. Jako server bude pouºíta implementaci z balíku

com.sun.net.httpserver [6]. I p°es svou jednoduchost

tato volba pln¥ spl¬uje poºadavky na funk£nost. Volba vhodného klieta je o n¥co sloºit¥j²í. Nabízí se moºnost pouºít t°íd z balíku

Java.net [5]. Výhodou je, ºe je b¥ºnou sou£ástí Javy.

P°idání funkcí souvisejících se zabezpe£ením komunikace protokolem HTTPS by bylo ale v budoucnu sloºit¥j²í. Výhodn¥j²í tedy bude pouºít knihovnu

HTTP Client

[1] od Apache

Software Foundation. Jedná se o robustní a sou£asn¥ snadno ovladatelnou knihovnu s mnoha uºite£nými vlastnostmi.

6.2.3 Dohledový modul Uº název by m¥l nazna£ovat, ºe tento modul je jádrem navrhované aplikace. Plní roli prost°edníka mezi uºivatelskou, komunika£ní a kongura£ní £ástí aplikace. Sou£asn¥ se musí starat o fungování dohledových operací. Jeho funkce se dají shrnout do t°í axiom·:


32

•

na základ¥ vstup· z komunika£ního modulu upravovat informace prezentované v uºivatelském modulu

•

podle vstup· z uºivatelského modulu volat operace v komunika£ním modulu.

•

Udrºovat informace o spravovaných za°ízeních a o provád¥ných dohledových operacích .

Sou£ástí modulu musí být i mechanizmy pro informování uºivatele o nestandardních událostech na sledovaných za°ízeních. M·ºe se jednat bu¤ o asynchronní události typu EVENT, nebo o p°ekro£ení stanovených limit· u dohledové operace. Moºností jak takové upozorn¥ní provést je více. Základem je zobrazení takové informace v uºivatelském modulu, ale nabízejí se i dal²í moºnosti nap°íklad odeslání upozorn¥ní e-mailem.

6.2.4 Uºivatelský modul Tento modul zprost°edkovává komunikaci mezi uºivatelem a zbytkem aplikace. Moºností jak toto zajistit je mnoho. P°edchozí implementace managera se spokojily s pouºitím p°íkazové °ádky. To je implementa£n¥ nejjednodu²²í, ale uºivatelsky nejmén¥ pohodlné °e²ení. V rámci této implementace by m¥lo být pouºito n¥jaké pohodln¥j²í °e²ení. Jako nejvhodn¥j²í se jeví ovládaní aplikace pomocí webového rozhraní. To nabízí podobný komfort jako gracké rozhraní a sou£asn¥ umoº¬uje k aplikaci p°istupovat z jakéhokoliv po£íta£e vybaveného webovým prohlíºe£em. Jak uº bylo zmín¥no v £ásti v¥nované volb¥ programovacího jazyka, nabízí Java pro tvorbu webových rozhraní/aplikací technologii JSP. Ta je postavena na principech návrhového vzoru Model-View-Controller (MVC). Roli Modelu, tedy objektu obsahujícího n¥jaká data, plní tzv. Beany. Ty jsou implementovány jako t°ídy v jazyku Java. V JSP se jim nastavuje rámec (scope), který ur£uje jejich ºivotnost. Moºností je více, ale na tomto míst¥ posta£í zmínit moºnosti "application"a "session". P°i rámci

session

application

existuje bean po celou dobu b¥hu aplikace. P°i volb¥

pak po dobu trvání sezení uºivatele.

View ur£uje zp·sob, jakým jsou data z model· reprezentována v uºivatelském rozhraní. V JSP k tomu slouºí JSP stránky, podle kterých je tato technologie pojmenována. JSP stránka pouºívá syntaxi jazyka HTML dopln¥nou o vlastní sadu zna£ek (tag·). Umoº¬uje také denovat nové zna£ky. P°i prvním p°ístupu na stránku jí servletový kontejner p°eloºí na servlet. Ten podle pravidel generuje HTML stránky zobrazené uºivatel·m. Servlet je druhem t°ídy v jazyce Java, která roz²i°uje funkce serveru a vyuºívá model ºádost-odpov¥¤. Servlety bývají také popisovány jako applety b¥ºící na serveru a ne v prohlíºe£i uºivatele. Jejich pouºití p°i p°ekladu JSP stránek je ale pro uºivatele i programátora vícemén¥ skryté. Mnohem viditeln¥j²í je jejich uplatn¥ní p°i realizaci poslední £ásti návrhového vzoru MVC, tedy Controller·. Ty zpracovávájí vstupy od uºivatele a podle nich upraví data v modelech a aktualizují View. Je velmi zajímavé, ºe naprostá v¥t²ina na internetu dostupných materiál· se vý²e popsaných princip· nedrºí. P°edev²ím vytvá°ejí dojem, ºe správné pouºití JSP a p°edev²ím servlet· spo£ívá v generování HTML stránek. Tento p°ístup poru²uje celou sérii paradigmat o odd¥lení obsahu od jeho prezentace. Sou£asn¥ se velmi málo zdroj· zabývá problematikou nad rámec naprostých základ·.

6.2. MANAGERSKÁ APLIKACE

33

6.2.5 Kongura£ní modul Aby mohly moduly managerské aplikace plnit poºadované úkoly budu si muset dokázat ukládat nezanedbatelné mnoºství informací. Uº v této fázi návrhu je jasné, ºe se bude jednat minimáln¥ o:

•

vlastní kongurace

•

komunika£ní porty a adresy kongura£ní informace aplikace

informace o sledovaných XML/SNMP branách

adresy a porty p°ihla²ovací údaje sledovaná za°ízení probíhající dohledové operace

Kdyº vynecháme primitivní a sou£asn¥ nepraktickou moºnost pevného nastavení výchozích hodnot ve zdrojovém kódu programu, nabízejí se tyto moºnosti:

•

ukládat informace do soubor· ve vlastním formátu

•

ukládat do soubor· ve standardním formátu nap°íklad XML, nebo Property jazyku Java

•

pouºít plnohodnotnou databázi

Komunika£ní protokol pouºívá dokumenty ve formátu XML a s tímto formátem bude muset pracovat velká £ást navrhované aplikace. Pouºít na ukládání kongura£ních dat XML dokumenty je pak jen dal²ím pouºitím uº jednou vyzkou²ených postup·. Pouºití databáze by jen uvalilo dal²í poºadavek na provoz aplikace a p°i navrhovaném rozsahu nep°ineslo ºádnou výraznou výhodu. Kongurace aplikace a informace o p°ipojených XML-SNMP branách tedy bude ukládána do XML dokument· na pevný disk.

34


Kapitola 7

Realizace V této kapitole je popsána implementace managerské aplikace. Nejprve je vysv¥tlena struktura aplikace a popsány její moduly. U kaºdého modulu je uvedena jeho struktura, popis d·leºitých t°íd a jejich vztah·. Také je uvedeno, jaké knihovny modul vyuºívá. V dal²í £ásti jsou vysv¥tleny nutné zm¥ny v kódu XML-SNMP brány. V poslední £ásti je popsán výkonný cyklus aplikace od spu²t¥ní, p°es provád¥ní p°íkaz· aº po ukon£ení. Schéma aplikace s p°íkladem volání pro operaci SUBSCRIBE je na obrázku 7.1.

Obrázek 7.1: Schéma aplikace

7.1 Struktura aplikace Podle návrhu v kapitole 6 má být aplikace ovládána pomocí webového rozhraní vyuºívajícího JSP. Sou£asn¥ má být ale maximáln¥ modulární. Tedy musí být funk£ní i bez tohoto rozhraní, respektive bez závisloti na JSP. Aby byl spln¥n tento poºadavek, tvo°í aplikaci dv¥ £ásti. Jednu je nejlep²í popsat jako "pracovní". Tvo°í jí komunika£ní a kongura£ní modul, zast°e²ené modulem dohledovým. Tato £ást zabezpe£uje samotnou funk£nost aplikace. Tedy odesílání a p°íjem zpráv, ukládání a aktualizaci dat o p°ipojených branách a základní aplika£ní logiku. Druhou £ást tvo°í samotný uºivatelský modul. Jeho jedinou funkcí je prezentovat data uºivateli a poskytovat mu nástroje na ovládání aplikace. Z technického

35

KAPITOLA 7. REALIZACE

36

hlediska je toto rozd¥lení realizováno tak, ºe pracovní £ást je p°edstavována objektem v aplika£ním rámci webové aplikace. Ta je pak samotným uºivatelským modulem. Cílem tohoto uspo°ádání je zajistit aby jednu instanci pracovní £ásti mohlo vyuºívat více uºivatel·. Komunikace mezi moduly probíhá na principu volání funkcí. P°i implementaci byl kladen d·raz na omezení vzájemných závislostí datových typ·.

7.2 Uºivatelský modul Jak bylo zmín¥no v návrhu, tvo°í JSP aplikaci JSP stránky, servlety a beany. I v p°ípad¥ uºivatelského modulu tomu je tak. Uºivatelské rozhraní je postaveno na principu b¥ºném u webových prezentací. Tedy stránky rozd¥lené na plochu pro zobrazení aktuální záloºky a menu pro p°epínání mezi nimi.

7.2.1 JSP Stránky Základ prezentace tvo°í stránka

index.jsp.

Ta vytvá°í odkazy na p°epínání zobrazované

záloºky v záhlaví. Záloºku pak tvo°í samostatná JSP stránka vloºená do stránky pomocí zna£ky

index.jsp

jsp:include. Která stránka je takto vloºena ur£uje hodnota uloºená v sezení

uºivatele. Samotné p°epínání zaji²újí servlety. Vkládané stránky jsou:

DISC_Page.jsp

Stránka pro p°ipojení XML-SNMP brány.

Browse_Page.jsp

Stránka na zobrazení popisu p°ipojených za°ízení a pro zahájení ope-

rací GET, SET a SUBSCRIBE. P°i realizaci této stránky bylo pot°eba najít vhodný zp·sob reprezentace popisu brány. Jako nevhodn¥j²í se jevilo zobrazení v podob¥ stromového menu. Samotné JSP, ani hlavní knihovna zna£ek - JSP Strandard Tag Library (JSTL) - takové menu neobsahuje. Na²t¥stí je moºná najít n¥kolik jiných knihoven, které ho obsahují. Jako nejvhodn¥j²í se ukázala voln¥ dostupná knihovna

tree4JSP [8]

od spole£nosti Einovates.

EVENT_Page.jsp

Stránka pro výpis mino°ádných událostí

RES_Page.jsp

Stránka pro zobrazení výsledku operace GET, SET a SUBSCRIBE.

SET_Page.jsp

Stránka na zadání dodate£ných parametr· operace SET.

STATUS_Page.jsp SUBSC_Page.jsp

Stránka zaji²újící výpis stavu dohledových operací.

Stránka na zadání parametr· pro vytvo°ení dohledové operace.

7.2.2 Servlety Servlety v aplikaci slouºí k vykonávání p°íkaz· uºivatele. Jsou rozd¥lené do dvou balík·. Servlety v balíku

xml.edu.net.xmlbnm.GUI.Servlets.Navigation

sluºí k navigaci v aplikaci.

V²echny funkgují stejným zp·sobem. Nejprve ze sezení uºivatele získají jeho bean (t°ída

UserBean,

bude popsána dále). V n¥m nastaví novou hodnotu aktuáln¥ vloºené stránky a

vyvolají nové na£tení stránky

index.jsp.

7.3. DOHLEDOVÝ MODUL

37

Druhá skupina servlet· je v balíku

xml.edu.net.xmlbnm.GUI.Servlets.Action. Ty za-

ji²újí hlavní funkce aplikace, tedy provád¥ní operací DISCOVERY, GET, atd.. Stejn¥ jako naviga£ní servlety i ty ak£ní fungují v²echny na stejném principu. Nejprve ov¥°í, ºe mají od uºivatele v²echny pot°ebné informace. V dal²ím kroku získají z rámce sezení uºivatelský bean a z aplika£ního rámce samotnou managerskou aplikaci (obalenou beanem

CoreBean).

Na ní zavolají poºadovanou operaci a £ekají na výsledek. Pokud se v ur£itém £ase povede operaci dokon£it, tak zobrazí výsledek. Pokud ne, tak zobrazí chybové hlá²ení. U operací SET a SUBSCRIBE dochází na za£átku k je²t¥ jednomu kroku. Provedení obou operací totiº za£íná voláním servletu pro operaci GET -

BrowseActionServlet.

Na základ¥ vstup·

z formulá°e, ale tento servlet pozná, ºe má být provedena jiná operace. Provede tedy p°esm¥rování na dal²í stránku. Na ní se zadají dodate£né informace nutné pro provedení operace (nap°. hodnota, která se má nastavit) a zavolá se servlet který podle uvedeného scéná°e provede operaci.

7.2.3 Beany Jak

jiº

bylo

zmín¥no

aplikace

xml.edu.net.xmlbnm.GUI.Beans.

pouºívá

T°ída

dv¥

UserBean

t°ídy

bean·.

Ob¥

jsou

v

balíku

obsahuje informace o sezení uºivatele,

tedy hodnotu aktuální stránky, hondoty vloºené do formulá°· a výsledky operací. V t°íd¥

CoreBean

pak jsou data platná pro celou aplikaci. Jedná se p°edev²ím o objekt pracovní

£ásti aplikace. Dále jsou to seznamy s informacemi pro zobrazení globáních informací - stav· dohledových operací a informacce o mimo°ádných událostech. Sou£ástí beanu je i registr probíhajících operací. Ten slouºí k p°i°azení uºivatele k výsledk·m provedené operace. Instance této t°ídy je vytvo°ena b¥hem startu aplikace. P°i tom p°e£te ze souboru

web.xml

cestu ke

kongura£nímu souboru a ten pouºije na vytvo°ení instance pracovní £ásti.

7.2.4 Pomocné t°ídy xml.edu.net.xmlbnm.GUI.Support. V n¥m jsou uloºeny pomocné t°ídy. T°ída GUISubscriptionRep p°edstavuje poloºku v tabulce výpisu stavu dohledových operací. TreeNodeData pak uzel ve stromovém menu popisujícím p°ipojené brány a RemoteTask jednu operaci v registru probíhajících operací. Zajímavá je t°ída AppShutdownListener. Ta funguje jeko takzvaný Shutdown Hook. Pokud je zahájeno

Poslední £ást uºivatelského modulu tvo°í balík

vypnutí servletového kontejneru, je zavolána metoda této t°ídy. Ta zajistí korektní ukon£ení aplikace.

7.3 Dohledový modul Jak bylo uvedeno v popisu struktury aplikace dohledový modul zast°e²uje moduly komunika£ní a kongura£ní. Sou£asn¥ zaji²úje hlavní aplika£ní logiku. Jádro modulu p°edstavuje t°ída

ServerController. Ta implementuje interface ProtocolResponseHandler komunika£-

ního modulu. Ten jí umoº¬uje zpracovávat p°ijaté odpov¥di a zprávy. Konstruktor této p°ídy má jako parametr cestu ke kongura£nímu souboru aplikace. P°esná struktura tohoto souboru je popsána v p°íloze B. Pomocí p°e£tené kongurace vytvo°í a nastaví komunika£ní a kongura£ní modul. Také obnoví uloºené dohledové operace. Tím je pracovní £ást aplikace


38

p°ipravena k £innosti. Aplika£ní logiku pak p°edstavují metody této t°ídy. Jejich hlavním cílem je propojit funkce jednotlivých modul· do funk£ních °et¥zc·. V p°ípad¥ operací GET a SET to znamená p°íkaz z uºivatelského modulu p°eloºit na operaci modulu komunika£ního. Po p°íjetí odpov¥di pak modul zajistí doru£ení výsledku zp¥t do uºivatelského rozhraní. U operací DISCOVERY a SUBSCRIBE je také nutné vytvo°it novou bránu, respektive dohledovou operaci v kongura£ním modulu. Protoºe odpov¥¤ PUBLICATION na první zprávu discovery obsahuje jen popis samotné brány, je sou£ástí jejího zpracování i odeslání dal²ích zpráv DISCOVERY pro získání popisu jednotlivých za°ízení. O p°íjmu zprávy DISTRIBUTION je uºivatel informován jen p°í vytvo°ení dohledové operace. Následující zprávy jen nastavují hodnotu (a tedy i stav) dohledové operaci v kongura£ním modulu. Z n¥j pak jsou stavy v²ech dohledových operací periodicky na£ítány do uºivatelského modulu. V p°ípad¥ zpráv EVENT nejsou informace ukládány v kongura£ním modulu, ale jen p°edány uºivatelskému modulu k zobrazení. P°i ukon£ování aplikace shutdown hook v uºivatelském modulu zavolá metodu pro korektní vypnutí pracovní £ásti aplikace. P°ed zavoláním ukon£ovacích metod obou pod°ízených modul· jsou také ukon£eny v²echny dohledové operace. Tím se zabrání vzniku chaosu v hodnotách atributu

distrId

p°edávaných zpráv a tedy p°i°azování zpráv DISRIBUTION

k dohledovým operacím.

7.4 Kongura£ní modul Tento modul se stará o udrºování a ukládání informací o p°ipojených bránách, za°ízeních a probíhajících dohledových operacích. Sou£ástí této funkce je i vytvá°ení instance XML dokumentu z kaºdého XSD schématu za°ízení. Základem modulu je t°ída

StorageModule.

Ta jako parametr p°i vytvá°ení dostane cestu k adresá°i s uloºenými popisy p°ipojených bran v XML souborech. Jejich jména generuje kongura£ní modul z jmen p°ipojených bran. Musejí tedy být unikátní. Struktura takového souboru je následující:

http://192.168.0.132:8888/ <passw>testing <xsd:schema ...> ... XSD schéma brány ... <device> 1 VM1 <description>Virtual Machine 1 <xsd:schema ...> ... XSD schéma za°ízení ...

7.5. KOMUNIKANÍ MODUL

39

<subscription> <xpath>/iso/org/dod/internet/mgmt/mib-2/tcp/tcpInSegs <max>1000 <min>10 5 <device> ... dal²í za°ízení ... Gate.

Ko°enem dokumentu je element brány. Element

xsd:schema

passw

a

ur£uje IP adresu a port

pak ur£uje heslo pro p°ístup k dat·m brány. Následuje v elementu

uloºené XSD schéma brány. Kaºdá brána pak m·ºe mít denovaných n¥kolik

pod°ízených za°ízení. Kaºdé je ur£eno elementem

name

uri

Jeho podelement

description

a popis. V elementu

device.

Jemu pod°ízené elementy

id,

obsahují základní informace o za°ízení. Tedy identika£ní £íslo, jméno

xsd:schema

je, stejn¥ jako u brány, uloºeno schéma za°ízení. Element

subscription popisuje dohledovou operaci nad za°ízením. V jemu pod°azených elementech xpath, max, min a freq je uloºena ve form¥ XPath identikace hodnoty, horní a dolní meze korektních hodnot a frekvence s jakou je hodnota odebírána. P°i na£ítání dat ze soubor· do pam¥ti aplikace jsou z XSD schémat za°ízení vytvo°eny jejich XML instance. To má na starost t°ída

DeviceXsdVisitor. Podobn¥ jako v p°edcháze-

jících implementacích prochází rekurzivn¥ od ko°ene schéma a buduje z n¥j XML instanci. Podobnou strukturu mají popisy bran a za°ízení i v pam¥ti za b¥hu programu. Objekt

StorageModule

SNMPGate. Kaºdá brána pak GateDevice. A nakonec kaºdé za°ízení obsahuje své dohledové operace. Ty p°edstavuje t°ída Subscription. Sou£ástí t¥chto t°íd jsou i funkce obsahuje p°ipojené brány jako instance t°ídy

obsahuje svá za°ízení p°edstavovaná t°ídou

na vytvá°ení, úpravy, vyhledávání a odstra¬ování t°íd pod°ízených. Pravidelné

StorageWorker

ukládání

datových

struktur

z

pam¥ti

na

pevný

disk

zaji²úje

t°ída

b¥ºící v samostatném vlákn¥.

7.5 Komunika£ní modul Implementace komunika£ního modulu se ukázala jako velmi problematická. Hlavní vinu na tom nesly vlastnosti knihovny

libmicrohttpd pouºívané pro p°íjem zpráv XML-SNMP brá-

nou. Jak uº bylo uvedeno, zprávy XML jsou zasílány pomocí metody POST HTTP protokolu. Existují ale dv¥ r·zné verze této metody. První je jednoduchý post, v n¥m jsou data p°ená²ena spole£n¥ v t¥le ºádosti. P°íklad je v tabulce 7.1. Druhým typem je tzv. multipart. V této verzi jsou data rozd¥lena do blok· pomocí zna£ky denované v hlavi£ce. P°íklad je v tabulce 7.2. Auto°i

libmicrohttpd

nepovaºovali za nutné v dokumentaci uvést, ºe jejich


40

knihovna podporuje jen multipart verzi POST. Pokud dostane jednoduchý POST tak ho sice korektn¥ p°ijme, ale nedokáºe p°e£íst jeho t¥lo. O této události ov²em nijak neinfromuje a jednodu²e vrátí prázdný string jako t¥lo. Problém se na²t¥stí poda°ilo po jeho identikaci vy°e²it správnou kongurací

Apache HTTPClient

na stran¥ managerské aplikace. Ale

samotné nalezení problému bylo velmi zdlouhavou a obtíºnou záleºitostí. Po vy°e²ení tohoto problému bylo moºné p°istoupit k implementaci samotného modulu.

xml.edu.net.xmlbnm.CommModule. Modul zast°e²uje t°ída CommModule. Ta má na starosti vytvo°ení díl£ích komponent modulu a slouºí jako prost°edník

Jeho t°ídy jsou uloºeny v balíku

k jeho funkcím. Podobn¥ jako v p°edchozích pracích komunika£ní modul tvo°í dv¥ díl£í £ásti. ást na odesílání zpráv, p°edstavovanou t°ídou p°edstavuje t°ída T°ída

CommReciever.

CommSender

odesílací d¥lníci (t°ída

CommSender

a £ást na p°íjem zpráv. Tu

pouºívá princip odesílací fronty na zamezení zahlcení. Frontu tvo°í

SendWorker). P°i vytvo°ení dostane CommSender t°i parametry z kon-

gura£ního souboru aplikace. Prvním je port, který má být pouºit k odesílání zpráv. Druhým je velikost odesílací fronty a t°etím je po£et odesílacích vláken. Kdyº t°ída dostane p°íkaz k odeslání zprávy, tak nejprve zkontroluje, ºe v odesílací front¥ je místo. Pokud není, tak vrátí vyjímku

OutOfWorkersException. Pokud místo je, tak z fronty vybere volného d¥lníka

a nastaví ho na poºadovanou zprávu. Nakonec zaregistruje nastaveného d¥lníka k provedení. O to se stará t°ída

ExecutorService

z balíku

java.util.concurrent.

Tato t°ída spou²tí

jednotlivé (nastavené) d¥lníky tak, aby jich najednou pracovalo jen nastavené mnoºství. Samotný d¥lník pak provede vytvo°ení a odeslání zprávy a £eká na odpov¥¤. Po jejím obdrºení jí p°edá k zpracování. ást pro p°íjem zpráv pracuje na podobném principu. T°ída

CommReciever

dostane p°i

vytvo°ení IP adresu a port na kterém má naslouchat. Také dostane velikost p°ijímací fronty a po£et p°ijmacích vláken. Na základ¥ t¥chto informací t°ída nastartuje HTTP server a nastaví t°ídu na obsluhu p°ijímaných zpráv -

RecieveHandler. Ta £eká na p°íchozí spojení. Jakmile

n¥jaké dorazí, tak se ho pokusí p°edat k vy°ízení d¥lníkovi do p°ijímací fronty. Pokud se to nepovede (ve front¥ není místo) je komunikace p°eru²ena. Jinak je zpráva za°azena ke zpracování a zaregistrována u

ExecutorService.

Po spu²t¥ní d¥lník(t°ída

RecieveWorker)

p°e£t¥ ze spojení zprávu a spojení ukon£í (brán¥ sta£í jako potvrzení odpov¥¤ Status 200 OK). P°i návrhu modulu bylo pot°eba vy°e²it jednu d·leºitou otázku - jak informovat nad°azené moduly o p°ijatých zprávách? Protoºe volání funkcí na odeslání zprávy kon£í za°azením zprávy do odesílací fronty, bylo také nutné najít zp·sob jak informovat nad°azené moduly o hodnot¥ odpov¥di. e²ením se ukázalo vyuºít princip tzv. callback funkcí. T°ída nad°azená komunika£nímu modulu(CommModule) musí implementovat interface ProtocolResponseHandler. V p°ípad¥ na²í aplikace ho implementuje t°ída ServerController dohledového modulu. Tento interface denuje funkce, které komunika£ní modul volá pro zpracování odpov¥dí a p°ijatých zpráv.

7.6 Úpravy XML-SNMP brány Krom¥ uvedených problém· s

libmicrohttpd

bylo nutné vy°e²it jen jediný nedostatek v

kódu XML-SNMP brány. Ta o£ekává zprávu s hodnotou parametru

ContentType

rovnou

7.6. ÚPRAVY XML-SNMP BRÁNY

POST / HTTP/1.1 Content-Length: 83 Content-Type: text/xml; charset=ISO-8859-1 Host: 192.168.0.128:8888 Connection: Keep-Alive User-Agent: Apache-HttpClient/4.1.1 (java 1.5) <message password="testing">

msgid="1"/>

Tabulka 7.1: Jednoduchý POST

POST / HTTP/1.1 Host: 192.168.0.128:8888 Accept: */* Content-Length: 357 Content-Type: multipart/form-data; boundary=----------------------------f0094c869497 ------------------------------f0094c869497 Content-Disposition: form-data; name="selection" Content-Type: text/xml <message password="testing">

msgid="1" />

------------------------------f0094c869497-Tabulka 7.2: multipart POST

41


42

text/xml.

Kód si ale nedokázal poradit se situací, kdy za denicí

ContentType

následovala

na stejném °ádku informace o kódování. Nap°íklad:

Content-Type: text/xml; charset=ISO-8859-1 Problém byl vy°e²en drobnou úpravou zdrojového kódu.

7.7 Výkonný cyklus aplikace Po popsání jednotlivých £ásti aplikace je na míst¥ popsat její celkový výkonný cyklus.

CoreBean. Ten p°e£te ze souweb.xml aplikace cestu ke kongura£nímu souboru. Pomocí tohoto souboru vytvo°í t°ídu ServerController dohledového modulu. Ta následn¥ vytvo°í t°ídy CommModule a StorageModule komunika£ního a kongura£ního modulu. Tím je aplikace p°ipravena k pouPo spu²t¥ní servletového kontejneru s aplikací vznikne bean

boru

ºívání. Po p°ipojení uºivatele k aplikaci je mu zaloºeno sezení a s ním i bean

UserBean. Kdyº pak

uºivatel zavolá n¥jakou funkci (operace DISCOVERY, GET, SET, SUSCRIBE), tak je volání p°edáno

CoreBean. Ten jednak zajistí provedení v pracovní £ásti aplikace (ServerController)

a sou£asn¥ si zaregistruje probíhající operaci. Vlákno uºivatele pak £eká na odpov¥¤.

ServerController

zavolá p°íslu²né funkce komunika£ního modulu (CommModule). Tam je

operace p°edána odesílací £ásti (CommSender) a odeslána. Jakmile dorazí odpov¥¤ zavolá odesílací modul p°íslu²nou metodu dohledového modulu (z interface

ServerController).

Pokud se má odpov¥¤ dostat do uºivatelského rozhraní, tak dohledový modul zavolá metodu

processTask()

beanu

CoreBean

s hodnotou odpov¥di.Tato funkce najde v registru

p°íslu²nou operaci, nastaví hodnotu odpov¥di a probudí uºivatelovo vlákno. Pokud se má hodnota odpov¥di dostat do kongura£ního modulu (nap°. zpráva DISTRIBUTION), tak dohledový modul zavolá p°íslu²né funkce ("aktualizuj hodnotu dohledové operace", apod.) modulu kongura£ního. V p°ípad¥ p°íjmu zpráv (DISTRIBUTION a EVENT) je princip podobný, jen obsluºnou metodu nevolá odesílací, ale p°ijímací £ást komunika£ního modulu. Krom¥ uºivatelem zahájených akcí je²t¥ v aplikaci dochází k n¥kterým periodickým operacím. Jedná se p°edev²ím o pravidelné ukládání dat z kongura£ního modulu na pevný disk. Také se pravideln¥ £istí registr operací uºivatelského modulu od operací, kterým vypr²el £asový limit. P°i zobrazování stavu dohledových operací pak je pravideln¥ na£ítán jejich stav z kongura£ního modulu.

Kapitola 8

Testování 8.1 Testovací prost°edí Pro ú£ely testování byl pouºit po£íta£ s opera£ním systémem Windows 7. Na n¥m bylo pomocí aplikace VMWare Player spu²t¥no n¥kolik virtuálních po£íta£· s opera£ním systémem CentOS 5.5. Managerská aplikace byla spu²t¥na na fyzickém po£íta£i v servletovém kontejneru Apache Tomcat 6.0. Na virtuálních po£íta£ích pak byly spu²t¥ny jednotlivé instance XML-SNMP brány. Testy se zam¥°ily na ov¥°ení jednotlivých funkcí managerské aplikace. Prvním krokem tedy bylo zjistit, jestli se aplikace dokáºe p°ipojit k brán¥ a získat popis bránou spravovaných za°ízení. Dal²ím krokem bylo otestovat schopnost aplikace zasílat zprávy GET a SET. T°etím krokem bylo ov¥°it fungování dohledových operací. Tedy zda si aplikace dokáºe zaºádat o pravidelný odb¥r n¥jaké hodnoty a správn¥ zobrazovat její stav v uºivatelském rozhraní. Také byla ov¥°ena schopnost odb¥r dat zru²it. tvrtým krokem bylo ov¥°ení p°íjmu zpráv typu EVENT. Nakonec bylo nutné ov¥°it, ºe aplikace správn¥ ukládá data na pevný disk a dokáºe je úsp¥²n¥ na£íst. Tedy obnovení funkcí po restartování. Pro ov¥°ení výsledk· pomocí SNMP byl pouºit program iReasoning MIB Browser [4].

8.2 Výsledky test· 8.2.1 DISCOVERY Nejprve bylo nutné p°ipojit XML-SNMP bránu k managerské aplikaci. Po vypln¥ní formulá°e 8.1 byla odeslána zpráva DISCOVERY a brána úsp¥²n¥ p°ipojena. Stav po skon£ení je na obrázku 8.2. Pro dal²í kontrolu m·ºe poslouºit záloºka Browse webového rozhraní (viz. obrázek 8.3). Protoºe má ve stromovém menu hodnoty, dopadlo p°ipojení brány úsp¥²n¥. P°i testování operace DISCOVERY byl odhalen nedostatek v chování XML-SNMP brány. Ta vrátí sv·j popis i popis p°ipojených za°ízení i kdyº dostane neplatné heslo. Kontrolu hesla provádí aº p°i vykonávání operací GET, SET, SUBSCRIBE.

43

44

KAPITOLA 8. TESTOVÁNÍ

Obrázek 8.1: Formulá° operace DICSOVERY

Obrázek 8.2: Výsledek DISCOVERY

8.2. VÝSLEDKY TEST

45

8.2.2 GET První testovanou operací byl GET. P°íklad p°íkazu je na obrázku 8.3. Protoºe celé rozbalené stromové menu je relativn¥ rozsáhlé není na obrázku celé. P°i tomto testu byl proveden dotaz na hodnotu uzlu s XPath:

/iso/org/dod/internet/mgmt/mib-2/system/sysContact Jak je vid¥t na obrázku 8.4, výsledkem byla hodnota "nikdo". Dotaz pomocí programu MIB Browser tuto hodnotu potvrdil.

Obrázek 8.3: Operace GET

Obrázek 8.4: Výsledek GET


46

8.2.3 SET Dal²í testovanou operací byl SET. Aplikace m¥la nastavit hodnotu z testu SET na "Franta". Po vybrání uzlu a operace na záloºe Browse je uºivatel p°esm¥rován na dal²í stránku (viz. obrázek 8.5), kde vyplní novou hodnotu. Podle logu aplikace i uºivatelského rozhraní se operace povedla (viz. obrázek 8.6). Ov¥°ení pomocí MIB Browseru ale ukázalo, ºe se nastavení hodnoty nepoda°ilo. Výpis logu XML-SNMP brány, uvedený v tabulce 8.1, ukazuje, ºe brána p°íkaz p°ijala a zkusila provézt. Operace SET ale selºe i pokud se je provedelna pomocí MIB Browseru, aplikace naprosto nezávislé na XML protokolu a jeho implementacích. Problém tedy není na stran¥ managerské aplikace, ani XML-SNMP brány, ale v konguraci SNMP na testovacím stroji. P°es vynaloºené úsilí se d·vody tohoto problému nepovedlo najít.

Obrázek 8.5: Operace SET

Obrázek 8.6: Výsledek SET

8.2.4 SUBSCRIBE Test operace SUBSCRIBE prob¥hl lépe. Pro test byla zvolena neustále rostoucí hodnota parametru

tcpInSegs.

I kdyº její sledování tímto zp·sobem má malý praktický smysl, tak

dob°e ukazuje v²echny moºné stavy dohledové operace. Dohledová operace se zadává podobn¥ jako p°i operaci SET. Po výb¥ru uzlu a operace je uºivatel p°esm¥rován na stránku, kde zadá dal²í údaje. Hodnoty pouºité p°i testu jsou na obrázku 8.7. Po úsp¥²né registraci vrátí brána aktuální hodnotu uzlu jako potvrzení. Výsledek testu je na obrázku 8.8. Nyní bylo moºné p°ejít na záloºku Status a sledovat stav dohledové operace (viz. obrázek 8.9). Na

8.2. VÝSLEDKY TEST

47

---------Wed Dec 21 20:37:35 2011 <message password="testing"> <set msgid="1" objectId="1"> <xpath>/iso/org/dod/internet/mgmt/mib-2/system/sysContact Franta ------------------Wed Dec 21 20:37:35 2011 Dostali jsme GET/SET message ---------Tabulka 8.1: Výpis logu XML-SNMP brány

reprezentaci stavu se pouºívá barva pozadí poloºky. Vzhledem k po£áte£ní hodnot¥ byl stav operace nejprve uspokojivý (zelená barva). Jakmile ale hodnota p°esáhla horní mez zm¥nila se barva na £ervenou, tedy neuspokojivý stav. Následn¥ byl po£íta£ s bránou restartován (a tím vymazána hodnota sledovaného £íta£e). B¥hem restartu se zobrazovaný stav zm¥nil na "neznámý", reprezentovaný ²edou barvou. Po obnovení b¥hu brány se obnovil stav na neuspokojivý protoºe hodnota by pod nastavenou dolní mezí. asem se dostala mezi ob¥ meze stav se op¥t zm¥nil na uspokojivý. Nakonec bylo pomocí tla£ítka "Remove"úsp¥²n¥ otestováno zru²ení dohledové operace. Podle výsledk· testu tedy operace funguje správn¥.

Obrázek 8.7: Formulá° operace SUBSCRIBE

8.2.5 EVENT Poslední testovanou operací byl p°íjem informace o mimo°ádné události - operace EVENT. Její testování se ukázalo jako problematické. Op¥t se projevila nezku²enost autora s SNMP a

48


Obrázek 8.8: Výsledek SUBSCRIBE

Obrázek 8.9: Dohledová operace

8.2. VÝSLEDKY TEST

49

na XML-SNMP se nepovedlo vyvolat SNMP Trap. Jako jediný zp·sob jak operaci otestovat se nakonec ukázalo vytvo°it jednoduchý program. Ten pomocí HTTP POST za²le managerovi zprávu EVENT ve formátu popsaném v popisu protokolu. Takový test ov¥°í schopnost managera zprávu p°ijmout a zpracovat. Výsledek testu je na obrázku 8.10, test je moºné povaºovat za úsp¥²ný.

Obrázek 8.10: P°ijatá zpráva EVENT

8.2.6 Ukládání dat Schopnost managerské aplikace úsp¥²n¥ ukládat data byla ov¥°ena jednoducým testem. Aplikace byla spolu se servletovým kontejnerem ukon£ena a znovu spu²t¥na. Následn¥ se ov¥°ilo správne na£tení dat zopakováním test· operací GET, SET a SUBSCRIBE.

50


Kapitola 9

Záv¥r Zadání práce se povedlo úsp¥²ne splnit. Po prostudování dokon£ených projekt· a podobn¥ zam¥°ených výzkumných prací byla navrºena a implementována managerská aplikace. Spolu s jiº dokon£enou XML-SNMP bránou tak je k dispozici funk£ní dvojice agent-manager pro navrºený XML protokol. To ale neznamená, ºe je implementovaná aplikace bez nedostatk·. P°edev²ím v parsování XSD schématu za°ízení je velký prostor na zlep²ení. Ze schématu je moºné získat mnohem více dat a vyuºívat je v aplikaci. Projekt knihovny

tree4JSP nep·sobí

jako p°íli² aktivní. P°i dal²ím vývoji managerské aplikace bude pravd¥podobn¥ nutné najít náhradní knihovnu. P°i vytvá°ení této práce bylo nutné p°ekonat r·zné p°ekáºky. Nejprve se ukázalo, ºe instalace XML-SNMP brány je pro mén¥ zku²eného uºivatele obtíºná. Následovalo °e²ení problém· s knihovnou

libmicrohttpd.

To se ukázalo jako £asov¥ velmi náro£né. Poslední

problematickou £ástí byla implementace uºivatelského rozhraní. Zde byl zdrojem problém· hlavn¥ nedostatek kvalitních dokumnetace. Dal²í práce na projektu XML protokolu by m¥ly být zam¥°eny na komplexní otestování XML protokolu. Na základ¥ výsledk· t¥chto test· bude moºné upravit jak návrh protokolu, tak opravit odhalené nedostatky obou implementací. P°ímo v samotné managerské aplikaci je moºné pokra£ovat ve vývoji vylep²ením zmín¥ného parsovaní XSD schématu. Také programové °e²ení registru akcí v uºivatelském modulu by mohlo být moºné nahradit elegantn¥j²í implementací. Za hlavní nedostatek SNMP je povaºována práv¥ jen dvou úrov¬ová struktura agent-manager. V implementované podob¥ má XML protokol stejný nedostatek. Zajímavou moºností by tedy bylo modikovat managerskou aplikaci tak, aby dokázala komunikovat i s jinými managery. Pak bude moºné z nich vytvá°et hierarchické struktury.

51

52

KAPITOLA 9. ZÁVR

Literatura [1] HttpClient. Apache Software Foundation, http://hc.apache.org/httpcomponents-client-ga/, 2011. [2] DATA ENCRYPTION STANDARD (DES). National Institute of Standards and Technology, http://csrc.nist.gov/publications/ps/ps46-3/ps46-3.pdf, 1999. [3] IETF RFC Library. IETF, http://www.ietf.org/rfc/, 2011. [4] iReasoning MIB browser. iReasoning Inc., http://ireasoning.com/mibbrowser.shtml, 2011. [5] Package java.net. Oracle Corporation, http://docs.oracle.com/javase/6/docs/api/java/net/package-summary.html, 2011. [6] Package com.sun.net.httpserver. Oracle Corporation,

http://docs.oracle.com/javase/6/docs/jre/api/net/httpserver/spec/com/sun/net/httpserver/package summary.html, 2011. [7] Overview of SGML Resources. W3 Consortium, http://www.w3.org/MarkUp/SGML/, 2004. [8] tree4JSP. einnovates, http://www.soft82.com/download/windows/tree4jsp/, 2011. [9] The Extensible Stylesheet Language Family (XSL). W3 Consortium, http://www.w3.org/Style/XSL/, 2011. [10] A. DESCHON, R. B. Background File Transfer Program, 1988. [11] BERGLUND, A. Extensible Stylesheet Language (XSL) Version 1.1. W3 Consortium, http://www.w3.org/TR/xsl11/, 2006. [12] CLARK, J. XSL Transformations (XSLT) Version 1.0. W3 Consortium, http://www.w3.org/TR/xslt, 1999. [13] CORPORATION, O. SNMP Agent MIB Reference. Oracle Corporation, http://docs.oracle.com/cd/E12531_01/tuxedo100/snmpmref/1tmib.html, 2011.

53

LITERATURA

54

[14] DAVE RAGGETT, I. J. A. L. H. HTML 4.01 Specication. W3 Consortium, http://www.w3.org/TR/html401/, 1999. [15] DEBAO XIAO, J. G. A Distributed Network Management Model for Next Generation Internet Based on XML and Policy. In

Communication Technology, 2006. ICCT '06.

International Conference on, s. 1 4, 2007.

[16] DONG, W. XML Application for SNMP based Information Management. In WU, Y.

High Performance Networking, Computing, Communication Systems, and Mathematical Foundations, 66 / Communications in Computer and Information Science. : Springer Berlin Heidelberg, 2010. s. 8894. Dostupné z:
org/10.1007/978-3-642-11618-6_13>.

ISBN 978-3-642-11618-6, 10.1007/978-3-642-

11618-6_13. [17] F. Strauss. Dostupné

A Library to Access SMI MIB Information z:

de>.

[online]. 2011. [cit. 4. 12. 2011].

[18] H. KRAWCZYK, R. C. M. B.

HMAC: Keyed-Hashing for Message Authentication,

1997. [19] HONG-TAEK JU, S. H. M.-J. C. AL., Y. O. An Embedded Web Server Architecture

Network Operations and Management Symposium, 2002. NOMS 2002. 2002 IEEE/IFIP, s. 5 18, 2002.

for XML-Based Network Management. In

[20] HROCH, T.

SNMP/XML brána.

Praha : eské vysoké u£ení technické v Praze, Fakulta

elektrotechnická, 2009. [21] J. CASE, M. S. M. F. DAVIN, J. A Simple Network Management Protocol (SNMP), 1990. [22] JAMES CLARK, S. D. XML Path Language (XPath) Version 1.0. W3 Consortium, http://www.w3.org/TR/xpath/, 1999. [23] MACEJKO, P.

XML Based Network Management. Praha : eské vysoké u£ení technické

v Praze, Fakulta elektrotechnická, 2006. [24] SHIN, D. SHIM, C. XNMP an XML based NetworkManagement Protocol over VoIP.

Software Engineering, Articial Intelligence, Networking and Parallel/Distributed Computing, 2005 and First ACIS International Workshop on Self-Assembling Wireless Networks. SNPD/SAWN 2005. Sixth International Conference on, s. 208 213, 2005. In

[25] THURM, B. Web Services for Network Management A Universal Architecture and

Local Computer Networks, 2002. Proceedings. LCN 2002. 27th Annual IEEE Conference on, s. 463 472, 2002. Its Application to MPLS Networks. In

[26] TIM BRAY, C. M. S.-M. J. P. AL., E. M. Extensible Markup Language (XML) 1.1 (Second Edition). W3 Consortium, http://www.w3.org/TR/2006/REC-xml11-20060816/, 2006.

LITERATURA [27] TRE²O, M.

55

SNMP/XML brána.

Praha : eské vysoké u£ení technické v Praze, Fakulta

elektrotechnická, 2009. [28] Yoon-Jung Oh, Hong-Taek Ju and James W. Hong.

for XML/SNMP Gateway

Interaction Translation Methods

[online]. 2011. [cit. 4. 12. 2011]. Dostupné z:
postech.ac.kr/papers/DSOM/02/xml-snmp-gateway/xml-snmp-gateway.pdf>.

56

LITERATURA

P°íloha A

Seznam pouºitých zkratek SNMP

Simple Network Management Protocol

SMI

Structure and Identication of Management Information for TCP/IP-based Internet

MIB

Management Information Base

UDP IP

User Datagram Protocol

Internet Protocol

IPX

Novell Internet Packet Exchange

USM

User Security model

VACM

View-based Access Control Model

HMAC

Hash-based Message Authentication Code

DES

Data Encryption Standard

OID

Object identier

ASN.1

Abstract Syntax Notation One

SGMP

Simple Gateway Monitoring Protocol

UDP

User Datagram Protocol

SGML

Standard Generalized Markup Language

XML

Extensible Markup Language

DTD

Document Type Denition

XSL

Extensible Stylesheet Language

XSLT JVM

Extensible Stylesheet Language Transformations Java Virtual Machine

57

PÍLOHA A. SEZNAM POUITÝCH ZKRATEK

58

JRE

Java Runtime Enviroment

JSP

Java Server Pages

MVC

Model-View-Controller

JSTL

JSP Strandard Tag Library

P°íloha B

Instala£ní a uºivatelská p°íru£ka B.1 Kompilace Pro p°eklad programu jsou pot°eba tyto knihovny:

• commons-codec-1.4 • commons-logging-1.1.1 • dom4j-1.6.1 • httpclient-4.1.1 • httpclient-cache-4.1.1 • httpcore-4.1 • httpmime-4.1.1 • jaxen-1.1.3 • jstl-api-1.2 • jstl-impl-1.2 • tree4jsp_1.2 V²echny vý²e uvedené knihovny jsou uloºeny na p°iloºeném médiu. P°i p°ekladu se m·ºe

javax. P°i pouºítí servletového servlet-api.jar z adresá°e /lib

objevit problém s chyb¥jící knihovnou s balíkem

kontejneru

Apache Tomcat je °e²ením pouºít knihovnu

v instalaci

Tomcatu.

59

PÍLOHA B. INSTALANÍ A UIVATELSKÁ PÍRUKA

60

B.2 Instalace Instalace je velmi jednoduchá. Sta£í postupovat podle doporu£eného postupu pro zvolený servletový kontejner. Pro testování byl pouºit kontejner Apache Tomcat 6.0. Pro nasazení aplikace p°ed spu²t¥ním kontejneru sta£í do sloºky "$CATALINA_BASE/webapps" nahrát zkompilovaný zdrojový kód. Je jedno jestli v komprimované form¥ (Web Application Archive - WAR soubor), nebo jako tzv."Exploded web application", tedy nekomprimované sloºky a soubory. "$CATALINA_BASE"odpovídá sloºce ve které je nainstalovaný Tomcat. P°es spu²t¥ním Tomcatu je je²t¥ pot°eba zkontrolovat, jestli je v jeho konguraci nastaven parametr

deployOnStartup

na hodnotu "

true"a

aplikace je správn¥ nakongurovaná. Nasazení na

Tomcat je moºné i dal²ími zp·soby. Protoºe jsou dob°e popsané v ociální dokumentaci, je jejich popis na tomto míst¥ zbyte£ný.

B.3 Kongurace Pro správný chod aplikace se nutné nastavit správné hodnoty ve dvou souborech. V souboru web.xml aplikace (ne Tomcatu) v parametru <env-entry> se jménem initCong do zna£ky <env-entry-value> nastavit absolutní cestu ke kongura£nímu souboru aplikace. P°íklad:

<env-entry> <env-entry-name>initConfig <env-entry-type>java.lang.String <env-entry-value>D:/works/WebXMLBNMS/conf/XMLBNMS_Conf.xml Kongura£ní XML soubor má tuto strukturu:

<manager> 0 <listenAddress>192.168.0.2 <listenPort>7878 8888 2 10 2 10 <storageDir>D:\work\WebXMLBNMS\storage <storagePeriod>30 Jednotlivé elementy mají následující význam:

•

loglevel - Úrove¬ logování. Moºnosti jsou 0 - loguj vyjímky, 1 - vyjímky a varování, 3 - vyjímky, varovaní, informa£ní výpisy.

•

listenAddress - IP adresa na která p°ijímá aplikace zprávy od protokolových bran.

B.4. POUÍVÁNÍ

61

•

listenPort - Port na kterém aplikace p°ijímá zprávy od protokolových bran.

•

transmitPort - Port na kterém aplikace odesílá zprávy.

•

recWorkers - Po£et vláken pro p°íjem zpráv.

•

recTasks - Délka fronty pro p°íjem zpráv.

•

transWorkers - Po£et vláken pro vysílání zpráv.

•

transTasks - Velikost fronty pro odesílání zpráv.

•

storageDir - Absolutní cesta ke sloºce na ukládání XML dokument· popisujících p°ipojené protokolové brány.

•

storagePeriod - Perioda (v sekundách) ukládání infromací o p°ipojených protokolových bránách na disk (do XML soubor· ve sloºce denované v poloºce storageDir).

B.4 Pouºívání Po úsp¥²ném spu²t¥ní je aplikace dostupná na adrese "http://URL_Serveru/WebXMLBNMS/". Uºivatelské rozhraní tvo°í £ty°i hlavní stránky. Jako výchozí slouºí stánka "

Status".

K na-

vigaci slouºí naho°e umíst¥né menu. Vysv¥tlení ú£elu jednotlivých stránek následuje.

B.4.1 Status

Obrázek B.1: Stránka Status

Na stránce Status (B.1) se v tabulce zobrazuje stav sledovaných parametr·. Stav je vyjád°en barvou kaºdáho °ádku. edivá znamená neznámý stav, £ervená hodnotu mimo

Gate"je uvedeno jméno protokoDevice"pak obsahuje jméno

nastavené meze a zelená hodnotu uvnit° mezí. Ve sloupci "

lové brány, která aplikaci hodnotu parametru zasílá. Sloupec "

za°ízení, ze kterého protokolová brána hodnotu zji²úje. Textová podoba OID parametru je

Item". Jako odd¥lova£ je pouºito místo te£ky lomítko. Odkaz ve sloupci Unsubscibe"slouºí ke zru²ení sledování stavu parametru.

uvedena ve sloupci " "


62

B.4.2 Discover

Obrázek B.2: Stránka Discover

Tato stánka slouºí k p°ipojení protokolové brány k managerské aplikaci. Tato operace vyºaduje zadání adresy, portu a hesla. Do kolonky

Port

pro zadání portu a

Password

Address

se zadává IP adresa brány.

hesla. Pokud se povede ºádost odeslat. Objeví se pod

tla£ítkem zpráva "DISCOVER message send". Po úsp¥²ném p°ipojení je protokolová brána vid¥t ve stromu na stránce

Browse.

B.4.3 Browse Tato stránka slouºí k provád¥ní hlavních p°íkaz· aplikace - zji²t¥ní, nebo nastavení hodnoty parametru a nastavení pravidelného odb¥ru hodnoty parametru. Tedy k odesílání zpráv GET, SET a SUBSCRIBE. Stromová struktura s ko°enem "Gates"slouºí k reprezentaci jednotlivých protokolových bran, jejich za°ízení a MIB t¥chto za°ízení. Výb¥r brány, za°ízení a parametru se provádí vybráním n¥kterého radiobuttonu v listech stromu. Parametr

Action

pak slouºí k ur£ení provád¥né akce. P°i výb¥ru GET je odeslána zpráva GET a vypsán výsledek. P°i operaci SET p°ejde aplikace na dal²í stánku, kde je t°eba zadat novou hodnotu parametru a pak je zpráva odeslána. Pokud se operace povede (hodnotu lze zm¥nit, nová hodnota má správný formát) vrátí operace novou hodnotu. Pokud ne, vrátí p·vodní. I operace SUBSCRIBE si nejprve na dal²í stránce vyºádá dal²í parametry. Minimum Maximum udávají horní a dolní meze hodnot parametru pro ur£ení stavu na stránce Status. Frequency je frekvence v sekundách s jakou má brána hodnotu zasílat. Protoºe stránka Status se aktualizuje kaºdých 10s, není £ast¥j²í aktualizace p°íli² praktická. a

B.4.4 Events Pro jednoduchý výpis zaznamenaných asynchronních událostí - zpráv typu

EVENT - slouºí

tato stránka. Pro kaºdou událost je na ní zaznamenáno datum, £as a o jakou událost se jednalo.

B.5. TESTOVACÍ XML-SNMP BRÁNA

63

Obrázek B.3: Stránka Browse

B.5 Testovací XML-SNMP brána Postup instalace a spu²t¥ní XML-SNMP brány je popsán v dodatku C práce Tomá²e Hrocha [20]. Pro ú£ely testovaní je sou£ástí p°iloºeného DVD VMWare image testovacího virtuálního po£íta£e s p°ipravenou XML-SNMP branou. Pro spu²t¥ní virtuálního po£íta£e je pot°eba VMWare Player ve verzi alespo¬ 3.1.4. Pro p°ihlá²ení k virtuálnímu po£íta£i pouºijte uºivatele

root

s heslem

okoloa.

P°ed spu²t¥ním samotné brány je nutné upravit konguraci XML-SNMP brány. V kon-

/home/samba/conf.xml je nutné nastavit bránu a p°ipojené za°ízení. <device id="0">.... Pokud má být p°i testovánítak je nezbytné kaºdé nastavit unikátní jméno v elementu . Také

gura£ním souboru

Bránu reprezentuje element pouºito více bran,

je nutné nastavit správnou cílovou adresu pro odesílání zpráv EVENT. K tomu slouºí elementy

a <port> v traps/manager. V elementu xml je obsaºeno jádro kongurace

XML-SNMP brány. Jednotlivé elementy mají tento význam:

xsdPath

Cesta k uloºení do£asných soubor· a logu.

listenPort

Port na kterém brána p°ijímá zprávy.

transmitPort

Port ze kterého brána odesílá zprávy.


64

access

V elementech

read

a

write

jsou uloºeny community stringy SNMP protokolu. Ty

slouºí i jako hesla pro p°ístup k dat·m brány pomocí XML protokolu.

protocolVersion

Verze XML protokolu.

V konguraci pod°ízeného za°ízení (element

snmpAddr ifconfig.

nutné v elementu nap°. p°íkazem

<device id="1">...)

je pak

nastavit IP adresu virtuálního po£íta£e. Tu je moºné zjistit

snmpxmld /home/samba/conf.xml. /tmp/snmpg. K brán¥ se pak lze p°ipojit

Po dokon£ení kongurace je moºné bránu spustit p°íkazem Logovací a do£asné soubory brány jsou uloºeny v

na IP adrese virtuálního po£íta£e a portu zadaném v konguraci. Heslo je v kongura£ním souboru nastaveno na výchozí hodnotu

testing.

P°íloha C

Obsah p°iloºeného CD P°iloºené médium obsahuje tyto adresá°e a soubory:

• /source/src

- zdrojové soubory programu

• /source/prj

- celý projekt programu z Netbeans 6.9

• /source/lib

- knihovny programu

• /source/tst

- velmi jednoduchý program na otestování operace EVENT

• /vmimage • /config

- obraz virtuálního po£íta£e pro VM Ware

- p°íklad kongura£ního souboru

• /user_guide.txt

- instala£ní a uºivatelská p°íru£ka.

A

• /text/src

- zdrojový kód textu práce ve formátu L TEX

• /text/pdf

- text práce ve formátu pdf.

65

XML Správa sít. Bc. Pavel imon. ƒeské vysoké u ení technické v Praze Fakulta elektrotechnická Katedra po íta. Diplomová práce

Recommend Documents