XML brána. Bc. Tomá² Hroch

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

Diplomová práce

SNMP/XML brána

Bc. Tomá² Hroch

Vedoucí práce:

Ing. Peter Macejko

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

Obor: Výpo£etní technika

12. kv¥tna 2009

iv

v

Pod¥kování Na tomto míst¥ bych rád pod¥koval vedoucímu práce panu Ing. Peteru Macejkovi za jeho rady a p°ipomínky, které vedly ke zdárnému dokon£ení práce. Zárove¬ m·j dík pat°í i rodin¥ za podporu po celou dobu mých studií.

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 13. 5. 2009

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

viii

Abstract The main aim of this project is to develop system, which could connect two communication protocols. The rst protocol is widely used SNMP and the second one is optimized XML-based protocol. The document describes implementation of the system which includes several optimalizations to reduce memory usage. The program is written in C++ programming language and is designed for OS Linux.

Abstrakt Cílem tohoto projektu je implementovat systém, jenº by dovoloval spojení dvou komunika£ních protokol·. Prvním z nich je ²iroce roz²í°ený protokol SNMP a druhým je navrºený optimalizovaný XML protokol. V dokumentu se krom¥ samotné implementace programu klade d·raz na optimalizace, které sniºují nároky na opera£ní pam¥´. Program je napsán v jazyce C++, cílový opera£ní systém je Linux.

ix

x

Obsah 1 Úvod

1

2 SNMP 2.1 Správní struktura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 SMI, MIB standardy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Verze SNMP protokolu . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 3 5 6

3 XML protokol 3.1 Obecný informa£ní model . 3.1.1 Odvození typ· . . . 3.1.2 Denice modul· . . 3.1.3 Popis za°ízení . . . . 3.1.4 Oznamovací zprávy . 3.1.5 Adresace dat . . . . 3.2 Mapování MIB do XML . . 3.2.1 Importy . . . . . . . 3.2.2 Datové typy . . . . . 3.2.3 MIB strom . . . . . 3.3 Zprávy . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

4 Návrh systému 4.1 Teoretické poºadavky . . . . . . . . . . . . 4.1.1 XML . . . . . . . . . . . . . . . . . 4.1.2 SNMP . . . . . . . . . . . . . . . . 4.2 Struktura programu . . . . . . . . . . . . 4.2.1 SOAP vs. démon . . . . . . . . . . 4.2.2 Navrhovaná aplikace . . . . . . . . 4.2.2.1 Inicializace . . . . . . . . 4.2.2.2 Transformace dat . . . . 4.2.2.3 Zpracovávání poºadavk· . 4.3 Správa protokolové brány . . . . . . . . . 4.4 XML manaºerská aplikace . . . . . . . . .

xi

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

. . . . . . . . . . .

11 11 11 12 12 12 13 13 13 13 13 16

. . . . . . . . . . .

21 21 22 27 27 27 28 28 29 29 30 30

xii 5 Implementace 5.1 T°ídy, vlastnosti a jejich vztahy . . . 5.2 Pouºité knihovny . . . . . . . . . . . 5.3 Popis výkonného cyklu . . . . . . . . 5.3.1 Inicializa£ní fáze . . . . . . . 5.3.2 Transforma£ní fáze . . . . . . 5.3.3 Komunika£ní moduly . . . . . 5.3.4 Zprávy . . . . . . . . . . . . . 5.3.5 Fronty a atomicita poºadavk· 5.3.6 Periodické zasílání informací . 5.3.7 Asynchronní události . . . . . 5.4 Pam¥óvé optimalizace . . . . . . . . 5.5 XML Manaºer . . . . . . . . . . . .

OBSAH

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

33 33 34 35 35 36 37 41 43 44 46 46 47

6 Testování

49

7 Záv¥r

55

Literatura

57

A Struktura kongura£ního souboru

59

B Uºivatelská p°íru£ka protokolové brány

63

C Uºivatelská p°íru£ka manaºerské aplikace

65

D Obsah p°iloºeného CD

69

Seznam obrázk· 2.1 2.2 2.3 2.4

Základní princip fungování SNMP spravované sít¥ . . . Komunikace mezi SNMP manaºerem a agentem . . . . Schéma datových paket· protokolu SNMPv1 a v2 ([1]) Schéma datového paketu protokolu SNMPv3 ([1]) . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. 3 . 4 . 7 . 10

3.1 Popis za°ízení v XML schématu ([1]) . . . . . . . . . . . . . . . . . . . . . 12 3.2 Mapování aplika£ních typ· SMIv1 do XML schématu ([1]) . . . . . . . . . 14 3.3 Struktura XML zprávy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.1 4.2 4.3 4.4 4.5 4.6 4.7

Schéma navrhovaného systému . . . . . . . . . . . . . . Obecná struktura XML dokumentu . . . . . . . . . . . . Struktura elementu device . . . . . . . . . . . . . . . . . Struktura elementu info . . . . . . . . . . . . . . . . . . HTTP zprávy p°edávané mezi manaºerem a bránou . . . HTTP komunikace mezi manaºerem a agentem/bránou . Fáze b¥hu programu . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

21 23 23 24 26 26 28

5.1 5.2 5.3 5.4 5.5 5.6 5.7

Schéma t°íd aplikace . . . . . . . . . . . . . . . . . . . . Inicializa£ní fáze . . . . . . . . . . . . . . . . . . . . . . P°íklad struktury hlavního XML dokumentu . . . . . . . Zpracování manaºerského poºadavku . . . . . . . . . . . Komunika£ní vlákna brány pro spojení se SNMP agenty Chyba prioritního zpracování poºadavk· . . . . . . . . . Element subscription v rámci hlavního XML dokumentu

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

34 37 38 39 41 43 44

xiii

xiv

SEZNAM OBRÁZK

Seznam tabulek 3.1 3.2 3.3 3.4

Mapování makra OBJECT-TYPE, jednoduchý typ (SMIv1) ([1]) Mapování SEQUENCE, makro OBJECT-TYPE ([1]) . . . . . . . Mapování SEQUENCE OF, makro OBJECT-TYPE ([1]) . . . . Mapování TRAP-TYPE makra ([1]) . . . . . . . . . . . . . . . .

xv

. . . .

. . . .

. . . .

. . . .

. . . .

14 15 15 16

xvi

SEZNAM TABULEK

Kapitola 1

Úvod Správa velkých po£íta£ových sítí je v dne²ní dob¥ naprosto samoz°ejmým úkolem v¥t²iny administrátor·. Velké mnoºství spravovaných sítí se neomezuje pouze na lokální prost°edí dané rmy £i instituce. M·ºe být naopak rozprost°ena v rámci jednoho m¥sta, státu £i dokonce n¥kolika stát· najednou. Efektivní spravování takové komunika£ní infrastruktury je úkolem velice náro£ným. Jedním z protokol·, který takovouto vzdálenou správu umoº¬uje, je SNMP. Na jeho základ¥ bylo vybudováno bezpo£et aplikací, které mají za úkol sledovat provoz na síti, zatíºení ur£itého systému a v neposlední °ad¥ umoºnit administrátorovi vzdálenou správu daného p°epína£e, routeru £i pracovní stanice. Protokol SNMP byl navrºen v d°ív¥j²ích dobách a nemusí pln¥ vyhovovat dne²ním poºadavk·m, a´ uº na bezpe£nost nebo efektivní vyuºití p°enosových médií. Pan Ing. Peter Macejko se ve své diplomové práci ([1]) zaobíral pouºitím technologií XML a návrhu protokolu, který by umoº¬oval minimáln¥ stejnou funkcionalitu jako protokol SNMP a tento zefektivnil. Tato práce se zaobírá vytvo°ením protokolové brány, která by umoºnila pouºít navrºený XML protokol ke správ¥ stroj·, které stále pouºívají protokol SNMP. Cílem je vytvo°it softwarový produkt, který bude plnit úkol prost°edníka mezi správcem a spravovaným strojem. Hlavními problémy jsou implementace navrºeného XML protokolu a jeho spojení s n¥kolika verzemi protokolu SNMP. D·leºitým aspektem vývoje je i orientace na sníºení nárok· na opera£ní pam¥´. Proto bude v kaºdé £ásti programu kladen d·raz na efektivní správu datových struktur. V kapitole 2 bude podrobn¥ popsán protokol SNMP, jeho komunika£ní struktury a typy zpráv. Kapitola 3 se zabývá rozborem navrºeného XML protokolu. Analýza systému a diskuse o moºných sm¥rech implementace bude popsána v kap. 4. V kapitole 5 bude probrána detailní funk£nost implementovaného programu. Ov¥°ení funkce a dal²í testování systému bude popsáno v kapitole 6. 1

2

KAPITOLA 1.

ÚVOD

Kapitola 2

SNMP SNMP, nebo-li Simple Network Management Protocol, je v dne²ní dob¥ jeden z nejroz²í°en¥j²ích protokol· na správu po£íta£ové sít¥. Je to aplika£ní protokol, který je sou£ástí TCP/IP rodiny protokol·. Byl vyvinut skupinout IETF (Internet Engineering Task Force) a p°ijat jako standard v roce 1989. Umoº¬uje sledovat síóvý provoz, hledat a °e²it problémy, které se p°i provozu vyskytnou. 2.1

Správní struktura

SNMP je tvo°en sadou standard·, které popisují správu sít¥, zahrnující samotný komunika£ní protokol, denici databázové struktury (SMI) a datové objekty (MIB). Základním funk£ním principem je model Klient - Server ([2]). Struktura spravované sít¥ se tak d¥lí na t°i klí£ové elementy - spravované za°ízení, agenta a manaºera (viz obrázek 2.1).

Obrázek 2.1: Základní princip fungování SNMP spravované sít¥

3

4

KAPITOLA 2.

SNMP

• Spravovaný systém - je za°ízení (p°epína£, router, atd.), na kterém je spu²t¥n

SNMP agent. Toto za°ízení shromaº¤uje sledované informace a pak je dává k dispozici manaºerovi pomocí SNMP protokolu.

• Agent - je software ur£ený pro pro správný p°eklad poºadavk· manaºera a jejich

vykonání na sledovaném systému. Navíc m·ºe p°i sledování posílat manaºerovi upozorn¥ní, ºe n¥co není se systémem v po°ádku.

• Manaºer (NMS - Network Managemet System) - je aplikace, která sleduje a spra-

vuje v²echny systémy na sledované síti. Tento systém získává od agent· data, zpracovává je do vizuální podoby, £ímº dává moºnost administrátorovi mít p°ehled o celé síti. Zárove¬ umoº¬uje m¥nit sledované parametry p°ímo u agenta.

Komunikace m·ºeme rozd¥lit do dvou kategorií dle toho, kdo ji zapo£al. Základní schéma je vyjád°eno na obrázku 2.2 ([3]).

Obrázek 2.2: Komunikace mezi SNMP manaºerem a agentem V první £ásti schématu je vyobrazeno standardní chování managera, který posílá dotazy agentovi, který mu odpovídá. P°esný výpis p°íkaz· a zpráv, které si mohou tyto dva systémy mezi sebou vym¥¬ovat, bude diskutován dále v této kapitole. Druhá £ást schématu popisuje moment, kdy na sledovaném systému nastala n¥jaká extrémní situace (nap°. zatíºení síóvého spoje se blíºí k maximu) a agent informuje manaºera pomocí zprávy Alert (v SNMP jsou to zprávy TRAP £i INFORM, ob¥ budou diskutovány dále). Je nutné zmínit, ºe SNMP protokol pracuje nad transportním protokolem UDP, který je nepotvrzovaný. Není tedy zaru£eno, ºe bude komunikace probíhat bezchybn¥. Je moºné, ºe n¥které dotazy a p°íkazy v·bec nedojdou ke svému cíli, o £emº se druhá strana nikdy nedozví. Tento fakt m·ºe být p°ekáºkou p°i správ¥ rozsáhlých sítí, kde jsou ²patné síóvé spoje.

2.2.

SMI, MIB STANDARDY

2.2

5

SMI, MIB standardy

Jak jiº bylo zmín¥no d°íve, SNMP je sada standard·, která krom¥ komunika£ního protokolu musí denovat i strukturu sledované databáze a samotná data. Tyto informace byly denovány ve standardech SMI a MIB.

SMI SMI je zkratkou pro Structure and Identication of Management Information for TCP/IPbased Internets. Tento standard ([4]) popisuje a denuje základní datové struktury a typy, které protokol vyuºívá. Jednotlivé objekty jsou pojmenovány a organizovány, aby bylo moºno k t¥mto dat·m logicky p°istupovat. Dle standardu musí mít kaºdý objekt jméno, syntaxi a kódování. Jméno jednozna£n¥ identikuje objekt. Datový typ (£íslo, °et¥zec) je ur£en syntaxí. Kódování zaji²úje správnou serializaci dat p°i p°enosu mezi systémy. Objekty, identikovány svým jménem (OID), jsou se°azeny do hierarchické struktury. K identikaci je pouºito Abstract Syntax Notation One (ASN.1). Kaºdý OID identikátor je sloºen ze skupiny p°irozených £ísel, které vyjad°ují jeho pozici v pomyslném stromu. Strom má ko°en, který je spojen hranami s o£íslovanými uzly. Kaºdý uzel m·ºe mít vlastní d¥ti, £ímº tvo°í vlastní podstrom. Takto je moºno pokra£ovat dále do zna£né hloubky stromu. Tento standard téº specikuje, jaké objekty tvo°í po£átek správní databáze.

MIB MIB je zkratka pro Management Information Base. Je to soubor denicí, které popisují parametry a vlastnosti sledovaného za°ízení. Existuje více neº 100 r·zných MIB, které popisují r·zná za°ízení. Kaºdý takovýto soubor denic musí spl¬ovat p°edpisy SMI, aby byla zaru£ena správná interpretace objekt·. Kaºdý objekt (n¥kdy také nazýván MIB objekt) je unikátn¥ identikován svým OID a v²echny dohromady jsou uspo°ádány do stromové struktury tak, jak to bylo popsáno v minulém odstavci. Objekty v dané databázi se d¥lí na skalární a tabelární. Skalární objekty reprezentují jeden parametr sledovaného za°ízení (nap°. po£et ethernetových karet v p°epína£i), kdeºto tabelární objekty jsou spojením n¥kolika sp°ízn¥ných objekt· (nap°. routovací tabulka je spojením jednotlivých záznam·, coby °ádk· dané tabulky). V rámci hierarchického uspo°ádání jsou vyhrazeny vy²²í úrovn¥ stromu (blíºe ko°enu) jednotlivým standardizujícím organizacím, niº²í úrovn¥ jsou poté zadány jednotlivými spole£nostmi. Kaºdý výrobce si m·ºe denovat svojí privátní v¥tev, do které umístí specické informace daného za°ízení. MIB, které nebyly standardizovány a ociáln¥ schváleny, jsou umíst¥ny do v¥tve experimentální.

6

KAPITOLA 2.

2.3

SNMP

Verze SNMP protokolu

Celkem byly doposud standardizovány t°i verze protokolu SNMP. Kaºdá z nich denuje svoje specické datové typy a pouºívané datové rámce pro komunikaci.

SNMPv1 V první verzi protokolu byly denovány dv¥ skupiny datových typ·: • Základní datové typy (Simple data types) • Aplika£ní typy

Základní typy jsou denovány v SNMPv1 SMI a denují základní pouºívané hodnoty: • INTEGER - celá £ísla od −231 do 231 − 1 • OCTET STRING • OBJECT IDENTIFIER - identikace jednotlivých objekt· v rámci normy ASN.1

Aplika£ní specické typy pak jsou: • Network Address - obecná síóvá adresa pro podporu mnoha rodin protokol· • IpAddress - p°ímo denovaný typ pro IP adresu. SMIv1 podporuje pouze 32

bitovou adresu (IPv4)

• Counter - £íta£, vyjád°en celým £íslem bez znaménka; jeho hodnota se pouze

zvy²uje a to aº do maxima a pak se vrací zp¥t na nulu

• Gauge - je denována jako nezáporné celé £íslo; m·ºe hodnotu zvy²ovat i sniºovat

a to v denovaných mezích minima a maxima

• Time Ticks - po£et hodinových tik· od n¥jaké události, m¥°eno v setinách vte°iny • Opaque - typ dovolující p°ená²et libovolná data v kódování ASN.1. Tato data jsou

zakódována jako OCTET STRING a následn¥ p°enesena médiem.

• Integers - celo£íselný typ, který p°edenovává specikaci v SMI • Unsigned Integer - celo£íselný typ bez znaménka, který stejn¥ jako p°edchozí

p°edenovává specikaci.

Komunika£ní mechanismus mezi manaºerem a agentem je denován pomocí datových rámc·, které je moºné v rámci SNMPv1 p°ená²et. Tyto jsou: • Get Request - získání hodnoty uzlu identikovaného OID (zpráva od manaºera

agentovi)

2.3.

VERZE SNMP PROTOKOLU

7

• Get Next Request - ºádost o hodnotu uzlu následujícího po zaslaném OID (od

manaºera k agentovi)

• Set Request - nastavení hodnoty uzlu specikovaném OID (od manaºera k agen-

tovi)

• Get Response - odpov¥¤ agenta manaºerovi na Get a Set zprávy. Obsahují po-

ºadovanou hodnotu

• Trap - zpráva od agenta manaºerovi, která upozor¬uje na nastalé situace na mo-

nitorovaném systému.

Strukturu jednotlivých SNMP paket· zobrazuje obrázek 2.3.

Obrázek 2.3: Schéma datových paket· protokolu SNMPv1 a v2 ([1]) Hlavní £ást datového paketu je tvo°ena poli Version a Community string. První popisuje verzi SNMP protokolu pouºitou p°i komunikaci a druhé je heslo pro p°ístup k poloºkám MIB. Blíºe k bezpe£nosti v dal²ím odstavci. Druhá £ást paketu se li²í dle typu zprávy. Paket odeslaný agentem p°i výskytu monitorované události obsahuje informace, které popisují druh problému. • Enterprise - identikuje typ za°ízení, které zprávu poslalo • Agent adress - adresa za°ízení, kde b¥ºí agent • Generic trap type - specikuje, zda-li se jednalo o n¥který z p°eddenovaných typ·

událostí (linkDown, linkUp, coldStart, aj.)

• Specic trap type - identikuje jednu z mnoha specických událostí

Druhým typem zprávy jsou dotazy a odpov¥di, které zasílá manaºer a agent na n¥ odpovídá. Jednotlivá pole mají následující význam:

8

KAPITOLA 2.

SNMP

• Request ID - po°adové £íslo dotazu (aby manaºer v¥d¥l, na co p°i²la odpov¥¤) • Error status - je nastaven pouze u odpov¥di a obsahuje druh problému, který se

p°i dotazu objevil

• Error index - asociuje problém s instancí objektu.

Spole£ným polem pro oba dva typy paketu jsou Variable bindings - jsou to dvojice polí, kde jedna £ást identikuje objekt a druhá £ást je jeho hodnota. Nap°íklad p°i dotazu p°íkazem GET se nastaví název objektu a v odpov¥di p°ijde nastavena i hodnota. Bezpe£nost v této verzi protokolu je zaloºena pouze na takzvaném community string u, který vystupuje jako heslo. Existují pouze dv¥ úrovn¥ zabezpe£ení p°ístupu a to - pouze pro £tení (read only) a £tení-zápis (read-write access). Je patrné, ºe se pouºívají pouze dv¥ hesla, kaºdé pro jednu úrove¬. Je to velice slabé zabezpe£ení, vezmeme-li v úvahu, ºe toto heslo se posílá neza²ifrované a kaºdý, kdo dokáºe odchytit jednotlivé pakety, si m·ºe tento °et¥zec p°e£íst. Tento nedostatek se pokou²ejí odstranit aº dal²í verze protokolu.

SNMPv2 Druhá verze protokolu SNMP byla zam¥°ena na odstran¥ní nedostatk· verze první. Bohuºel bylo vydáno n¥kolik soupe°ících specikací, ozna£ované názvy SNMPv2c, SNMPv2u, SNMPv2*, které byly vzájemn¥ nekompatibilní. Nicmén¥ zlep²ení oproti první verzi bylo n¥kolik. Byly denovány nové datové typy, nové zprávy a zlep²ená práce s chybami. Nové datové typy zahrnují roz²í°ení podpory z 32-bitových £ísel na 64-bitová ( Integer32, Integer64, Counter32, ...). P°idané zprávy jsou: • Get Bulk - tento operátor se snaºí efektivn¥ji vyuºít p°enosovou kapacitu kanálu

tím, ºe od agenta si vyºádá sérii informací pomocí jediného dotazu

• Inform - stejná funkcionalita jako zpráva Trap ve verzi 1, ale nutné je potvrzení

od manaºera, ºe zprávu p°ijal (Response paket)

• Response - odpov¥¤ na p°edcházející Inform zprávu (od manaºera k agentovi)

Ostatní zprávy SNMPv2 p°ebírá z p°edchozí verze a zachovává jejich strukturu. Stejn¥ tak je to i s bezpe£ností, kde je stále pouºito heslo ve smyslu community stringu.

SNMPv3 T°etí verze protokolu SNMP je denována sadou standard·, které nepostihují celkovou funk£nost protokolu jako takového, ale dodávají do systému chyb¥jící prvky, hlavn¥ bezpe£nosti. P°ímo v jednom ze standard· [5] je °e£eno, ºe tato verze m·ºe být chápána jako SNMPv2 s dodate£nými administrativními a bezpe£nostními schopnostmi. SNMPv3 denuje t°i základní sluºby:

2.3.

VERZE SNMP PROTOKOLU

9

• Autentikaci - datový p°enos od manaºera k agentovi m·ºe být autentikován, aby

se zajistilo ov¥°ení identity odesílajícího.

• Soukromí - ²ifrování p°ená²ených zpráv. • P°ístupová práva - agent m·ºe denovat p°ístupová práva, omezovat p°ístup ma-

naºer·m pouze k n¥kterým akcím a £ástem dat.

Základním principem SNMPv3 je modularita. Kaºdá SNMP entita je tvo°ena SNMP °ídícím systémem a vlastní aplikací. ídící systém má za úkol p°ijímat, odesílat, ²ifrovat a de²ifrovat v²echny zprávy a dále spravuje a kontroluje monitorované objekty. Tyto funkce jsou poté k dispozici jedné £i více aplikací. Stejn¥ jako p°edchozí verze, je SNMPv3 zaloºena primárn¥ na transportním protokolu UDP, ale není na n¥j vázána. Pro p°enos dat tak m·ºe být pouºit i jiný protokol. Vlastní aplika£ní protokol SNMP je rozd¥len do dvou úrovní. První zpracovává datové pakety (PDU processing layer) a druhá zpracovává zprávy (message processing layer). Nejvy²²í úrove¬ - PDU processing layer - se stará o zpracování p°íkaz· (Get, Get Next, ...), které p°ijdou v daném paketu. Zpracovaný paket pak p°edá niº²í úrovni - message processing layer - která tomuto paketu dodá hlavi£ku, kde jsou uloºena bezpe£nostní data. Na obrázku 2.4 je vyobrazen formát SNMPv3 zprávy. První £ást je tvo°ena systémem zpracování zpráv. Nese informace ohledn¥ verze protokolu, identikaci zprávy, maximální délce zprávy a nastavení bezpe£nostího modelu. Druhá £ást je generována bezpe£nostním systémem a obsahuje informace o kódování a autorizaci. T°etí £ást obsahuje samotná data. D·leºitou sou£ástí nového standardu je i systém p°ístupových práv (VACM - ViewBased Access Control Model). Tento model umoº¬uje nakongurovat agenta tak, ºe specickému manaºerovi bude umoºn¥n p°ístup pouze k £ásti MIB. Je moºné omezit manaºera pro p°ístup pouze k £ásti databáze monitorovaných dat a zárove¬ je²t¥ omezit operace, které nad touto mnoºinou m·ºe provád¥t. Omezení p°ístupu se provádí pro denované skupiny, kde sou£ástí jedné skupiny m·ºe být více manaºer·.

10

KAPITOLA 2.

Obrázek 2.4: Schéma datového paketu protokolu SNMPv3 ([1])

SNMP

Kapitola 3

XML protokol Pan Ing. Peter Macejko ve své diplomové práci navrh systém vzdálené správy stroj· pomocí komunika£ního protokolu, vyuºívajícího XML. V této kapitole budou shrnuty v²echny navrºené postupy od mapování SNMP informa£ního modelu aº, po komunika£ní struktury vyuºívané správcem a spravovanými za°ízeními. 3.1

Obecný informa£ní model

Informa£ní model je nedílnou sou£ástí celého systému správy dat. Do n¥j jsou mapována ve²kerá monitorovaná data a jsou zde i vyjád°eny vztahy mezi daty. Ve skute£nosti omezuje po£et a druh moºných dotaz·. Výsledný systém, který byl pro popis jednotlivých za°ízení navrºeni, vychází z n¥kolika r·zných p°ístup· abstrakce a popisu dat. Nejprve byla analýza problému zaloºena na dvou moºnostech - p°ímém mapování MIB stromu do XML dokumentu, kdy by jednotlivé uzly p°esn¥ odpovídaly MIB struktu°e; objektov¥ orientovaném vyuºívajícím objektové paradigma. První p°ístup má výhodu ve snadném p°evodu MIB databáze do nového formátu, ale naopak ztrácí výhodu snadné roz²i°itelnosti, která je vlastní XML technolgoii. Problém objektového mapování je nejednozna£né rozmíst¥ní uzl· ve stromu na objekty. Takovéto mapování by bylo nutno provád¥t neautomatizovan¥, tj. za asistence £lov¥ka. Výsledkem analýzy problému je systém vyuºívající kousek od obou p°ístup·. Na nejvy²²í úrovni abstrakce je kaºdé za°ízení sloºeno z modul·. Kaºdý modul obsahuje jistou funkcionalitu, která je úpln¥ odd¥lena od t¥ch zbývajících. Mezi tyto moduly pat°í i v této práci navrhovaná brána, která propojuje za°ízení bez XML podpory s ostatními £ástmi sít¥. V této chvíli se jedná pouze o obecný návrh kaºdého za°ízení.

3.1.1 Odvození typ· Odvozování typ· je zaloºeno na principu d¥di£nosti. Denice jako takové jdou od abstraktního aº po detailní popis. 11

12

KAPITOLA 3.

XML PROTOKOL

3.1.2 Denice modul· Jak jiº bylo °e£eno, kaºdé za°ízení se skládá z modul·. Jednotlivé moduly jsou téº popsány XML schématem. Kaºdé takové schéma musí spl¬ovat p°esné poºadavky na poskytované informace. Musí být detailn¥ popsána funk£nost, p°id¥leno unikátní jméno, typ a cesta ve stromové struktu°e, pouºitá pro adresaci jednotlivých uzl·. SNMP moduly mají denován ko°enový element, který je vyuºit pro spojování více MIB informa£ních bází dohromady. P°esný popis je moºné nalézt v [1] v kapitole 5.2.3.

3.1.3 Popis za°ízení Pro popis za°ízení je vyuºito XML schéma, stejn¥ jako pro popis dal²ích £ástí (modul· apod.). Na obrázku 3.1 je znázorn¥no, jak vypadá za°ízení popsané od nejvy²²í úrovn¥.

Obrázek 3.1: Popis za°ízení v XML schématu ([1])

3.1.4 Oznamovací zprávy Oznámení jsou takové zprávy, které jsou zasílány manaºerovi v p°ípad¥, ºe se na monitorovaném za°ízení vyskytne n¥jaká událost (shodné s SNMP Trap zprávami). V rámci SNMP jsou tyto zprávy sou£ástí datového modelu, nicmén¥ tyto specické uzly MIB stromu nenesou ºádná data, a jsou tudíº pouºité pouze p°i generování typu chyby £i události. V navrºeném systému jsou v²echna moºné upozorn¥ní (a´ jiº p°eddenované, £i denované administrátorem) umíst¥ny ve speciálním uzlu stromu notifications, kde je velice jednoduché dohledat, jaké události mohou zp·sobit zaslání oznamuvací zprávy. Kaºdý modul pak m·ºe mít specikován speciální typ NotificationType, který popisuje práv¥ onu událost.

3.2.

MAPOVÁNÍ MIB DO XML

13

3.1.5 Adresace dat Pro adresaci dat je moºno vyuºít postup· XPath a XQuery. Jednotlivými výrazy a´ uº v jednom £i druhém p°ípad¥ se bude manaºer dotazovat na jednotlivé uzly v rámci spravované databáze. 3.2

Mapování MIB do XML

V p°edchozí £ásti byl rozebrán £ist¥ obecný model popisu za°ízení. Pro monitorované stroje, které nejsou kompatibilní s XML protokolem, musí existovat brána, která bude p°ekládat dotazy z jednoho protokolu na druhý a stejn¥ tak i odpov¥di. Je tedy nutné p°esn¥ denovat postup p°episu MIB na XML. Je nutné vy°e²it t°i základní problémy - jak importovat jednotlivé MIB do sebe; jak p°edenovat datové typy a jak konvertovat celý MIB strom.

3.2.1 Importy V rámci jednotlivých MIB jsou £asté odkazy na báze vy²²í úrovn¥, kdy pak na niº²ích úrovních denujeme jenom £ást podstromu. V rámci XML budou denovány odkazy jako prostory jmen, které jsou odvozeny od názvu daného MIB. Odkaz na jiné schéma bude proveden pouºitím odkaz· na typ s p°íslu²ným názvem prostoru jmen.

3.2.2 Datové typy V SNMP, jak bylo °e£eno v p°edchozí kapitole, existuje n¥kolik druh· datových typ·. Jednoduché (integer, string,...), aplika£n¥ roz²í°ené (Gauge, IpAddress,...) a uºivatelem denované. Jednoduché typy budou mapovány na jejich XML ekvivalent. Na obrázku 3.2 je soupis v²ech aplika£n¥ roz²í°ených typ· a jejich popis pomocí XML schématu (v rámci standardu SMIv1). Sou£ástí SMI je i moºnost denovat vlastní typy. I pro tyto p°ípady je nutno uvést denici p°ekladu. Existují t°i základní omezení p°i vytvá°ení vlastních typ· - vý£et, délka °et¥zce a rozmezí hodnot. V²echny tyto typy jsou detailn¥ popsány a vyobrazeny v [1], kapitola 5.3.1.

3.2.3 MIB strom Navrºený systém vyuºívá p°i mapování celého stromu odd¥lení denicí typ· od samotné struktury stromu. Typy jsou denovány globáln¥ a zárove¬ separátn¥ od struktury a to z d·vodu moºného pouºití typ· v rámci jiného modulu a zárove¬ p°i omezení p°ístupových práv do dané oblasti stromu. V MIB jsou objekty denovány makry (specikované v

14

KAPITOLA 3.

XML PROTOKOL

Obrázek 3.2: Mapování aplika£ních typ· SMIv1 do XML schématu ([1])

...

<xsd:element name="NodeName" type="MIBName:NodeNameType"/> ... <xsd:simpleType name="NodeNameType"> <xsd:annotation> <xsd:documentation xml:lang="en">DescrText <xsd:appinfo> <status>StatusType AccessType AbsoluteOID <xsd:restriction base="NodeType"/>

Tabulka 3.1: Mapování makra OBJECT-TYPE, jednoduchý typ (SMIv1) ([1])

3.2.

...

MAPOVÁNÍ MIB DO XML

15

<xsd:element minOccurs="0" maxOccurs="unbounded" name="NodeName" type="MIBName:NodeNameType"/>

... <xsd:complexType name="NodeNameType"> <xsd:sequence> <xsd:element name="..child.." type="..childType.."/> ...

Tabulka 3.2: Mapování SEQUENCE, makro OBJECT-TYPE ([1]) ... <xsd:element name="atTable"> <xsd:complexType> <xsd:sequence> <xsd:element ..SEQUENCE.. /> ...

Tabulka 3.3: Mapování SEQUENCE OF, makro OBJECT-TYPE ([1]) SMI), které popisují n¥kolik základních typ· uzl·. SMIv1 specikuje OBJECT-TYPE a TRAP-TYPE makra. OBJECT-TYPE makro denuje uzel, který obsahuje n¥jaká data. M·ºe to být samotná hodnota, poloºka, nebo celá °ádka tabulky. Mapování pak závisí na poloºce SyntaxType v samotné denici makra. Pakliºe je hodnota poloºky základním, roz²í°eným £i uºivatelsky denovaným typem, bude vytvo°ena globální denice typu a poloºka bude tvo°ena elementem s jednoduchým typem. Schematicky vyjád°eno v tabulce 3.1. Jestli bude hodnotou SEQUENCE, bude vytvo°en "°ádkový" typ (tabulka 3.2). Hodnota SEQUENCE OF pak vyjad°uje mnoºinu °ádkových typ· (tabulka 3.3). Dal²ím typem objektu jsou upozorn¥ní denované pomocí TRAP-TYPE makra. Tyto denují uzly bez hodnot, pouze specikují danou událost. V navrºeném systému tedy nemusí být sou£ástí stromu, ale pouze globálních typových denicí. Bude pouºit jednoduchý typ popisující £as a den (datetime type) se speciálním elementem v £ásti appinfo.

16

KAPITOLA 3.

XML PROTOKOL

<xsd:simpleType name="NodeNameType"> <xsd:annotation> <xsd:documentation xml:lang="en">DescrText <xsd:appinfo> <enterprise>EnterpriseName VariableType ReferenceType TrapNumber <xsd:restriction base="xsd:dateTime"/>

Tabulka 3.4: Mapování TRAP-TYPE makra ([1]) 3.3

Zprávy

Navrhovaný systém by m¥l vyuºívat spolehlivého a potvrzovaného p°enosového protokolu, na rozdíl od nepotvrzovaného SNMP. Zarove¬ by m¥lo být moºno p°ená²et zprávy v co nejjednodu²²ím formátu. Proto bylo rozhodnuto o pouºití protokolu HTTP, který vyuºívá p°enosový protokol TCP, £ímº je zaji²t¥n spolehlivý p°enos. V²echa data se budou p°ená²et pomocí HTTP zprávy POST. HTTP je bezestavový protokol. Ve²kerá komunikace se sestává z dvojice dotaz a odpov¥¤. Na serveru se neudrºují jakékoliv dal²í informace ohledn¥ probíhajícího spojení. Tato nenáro£nost dovoluje implementaci na velice r·znorodém hardwaru. Bezpe£nost p°enosu m·ºe být °e²ena za pouºití tunelování paket· (IPSec, STunel,...), nebo je moºno vyuºít výhody HTTPS (HTTP over SSL). Ve²kerá p°ená²ená data budou ve formátu XML dokumentu s ko°enovým uzlem message. Tento uzel má n¥kolik atribut·, které specikují jeho zpracování a p°ístupová práva. Jsou to queue, password, context. První atribut ur£uje frontu (m·ºe být zaloºeno na prioritním zpracování), ve které bude poºadavek zpracován. V principu ale nejsou agenti ani brány povinni takovouto funk£nost implementovat. Zprávy pak budou zpracovány sekven£n¥ a odpov¥di budou generovány v p°esném po°adí tak, jak p°i²ly dotazy. Zbylé dva atributy slouºí pro vymezení p°ístupu uºivatele (context) na ur£itý podstrom dat. Bylo jiº nazna£eno, ºe zpráva m·ºe obsahovat n¥kolik jednotlivých dotaz·. Struktura zprávy je vyjád°ena na obrázku 3.3. Dotazy a odpov¥di, které denují komunikaci mezi manaºerem a klientem, jsou popsány níºe. P°esné XML schéma denující úplnou strukturu zpráv obsahuje ([1], p°íloha D).

3.3.

17

ZPRÁVY

Obrázek 3.3: Struktura XML zprávy DISCOVERY

Tato zpráva je první, kterou za²le manaºer agentovi, aby zjistil, jaká monitorovaná data jsou k dispozici. Povinným atributem je £íslo verze protokolu (protocolVersion) a nepovinným je fullDescription pro bliº²í specikace typ· spravovaných dat. <message context="honza">

PUBLICATION

Agentova odpov¥¤ na manaºer·v dotaz DISCOVERY. V rámci zprávy je uvedeno, jakou verzi protokolu agent pouºívá a jaká data spravuje. Tato data jsou pak manaºerem zpracována a pouºita jako informa£ní model. <xpath>1.0 ... ... XML schema popisující spravovaná data ...

Pakliºe agent nepodporuje danou verzi protokolu, musí odpov¥d¥t chybovou zprávou: <error code="1">Protocol not supported

18

KAPITOLA 3.

XML PROTOKOL

GET

Tímto dotazem se manaºer ptá agenta na hodnotu n¥jakého uzlu. Pro specikaci jakého je nutno pouºít XPath £i XQuery. <xpath> device/data/interface

SET

Zpráva SET je ur£ena pro nastavení hodnoty uzlu. Struktura je podobná zpráv¥ GET, ale obsahuje navíc element value. <set msgid="123"> <xpath> device/data/interface/status 4

RESPONSE

Odpov¥¤ na zprávy GET a SET. V p°ípad¥ GET nese zpráva p°íslu²ná data. Pakliºe je to odpov¥¤ na SET, je to pouze potvrzení, ºe hodnota uzlu byla úsp¥²n¥ nastavena. 4

EVENT

Pro oznamování asynchronních událostí je tu zpráva EVEN (stejná funkcionalita jako TRAP u SNMP). P°ená²ené informace specikují, která událost vyvolala toto oznámení, kdo to poslal, datum a £as, p°ípadn¥ n¥jaká dal²í data, která by mohla být p°i °e²ení problému uºite£ná.

3.3.

ZPRÁVY

19

<event msgid="123" timestamp="" senderID="router1" eventSpec="/device/notifications/dhcp/noF 0 50

Je nutné, aby doru£ení této zprávy bylo potvrzeno. Coº bude dodrºeno pouºitým protokolem. SUBSCRIBE

Touto zprávou se manaºer p°ihlásí k opakovanému zasílání dat. Potvrzením je pak první doru£ení dat - zpráva DISTRIBUTION - nebo chybové zprávy, ºe je n¥co v nepo°ádku. Je moºné specikovat je²t¥ nepovinný atribut frequency - doba ve vte°inách, po které mají být opakovan¥ zasílány zprávy. Dal²í nepovinné atributy distrid a delete jsou vyuºity pro editaci £i smazání daného p°ihlá²ení. <subscribe msgid="123" frequency="150"> <xpath>/device/data/interface/status

DISTRIBUTION

Zpráva obsahuje data, o která si manaºer °ekl. Je nutné, aby odesílaná data byla ve stejném po°adí, ve kterém byla ve zpráv¥ SUBSCRIBE. Povinný atribut distrid je ur£ený k identikaci p°íchozích dat u manaºera. 1 500

P°íjem t¥chto dat je téº nutné potvrdit, coº zajistí transportní protokol.

20

KAPITOLA 3.

XML PROTOKOL

Kapitola 4

Návrh systému V p°edchozích dvou kapitolách byla rozebrána teoretická £ást problému. V této kapitole shrneme poºadavky vyplývající z teorie, které je nutno zakomponovat do výsledného systému. Nejprve bude schématicky vyjád°ena obecná funkcionalita systému, která se následn¥ bude rozebírat detailn¥ji. 4.1

Teoretické poºadavky

Nároky na systém, které vyplývají z teorie m·ºeme rozd¥lit do t°í £ástí - implementace SNMP protokolu, implementace navrºeného XML protokolu a propojení t¥chto dvou protokol· dohromady. Hlavním poºadavkem, který vyplývá i ze zadání práce, je vytvo°it modulární systém, který bude nejenom spojovat sou£asné verze protokol·, ale bude po£ítat i s potenciálním roz²í°ením do budoucna. Obecné schéma navrhovaného systému zobrazuje obrázek 4.1.

Obrázek 4.1: Schéma navrhovaného systému 21

22

KAPITOLA 4.

NÁVRH SYSTÉMU

Zde je vid¥t, ºe oba dva protokolové moduly jsou na sob¥ nezávislé a jejich interakce spo£ívá v p°edávání si zpráv. Nyní p°ejd¥me k detailn¥j²ím poºadavk·m na vý²e zmín¥né £ásti systému. V rámci SNMP protokolu je poºadováno • implementace komunika£ních struktur protokol· SNMPv1 a SNMPv2 • p°evzetí bezpe£nostního schématu z tohoto protokolu

XML orientovaná £ást programu má za úkol • implementovat komunika£ní struktury navrºeného protokolu • navrhnout efektivní správu XML struktur v pam¥ti • poskytnout XML manaºer·m transparentní získání dat z monitorovaných za°ízení • mapovat roz²í°enou mnoºinu funkcí v rámci XML protokolu do SNMP • s manaºery komunikovat pouze p°es HTTP/HTTPS protokol

Spojením protokol· je my²len p°echod od databázových struktur jednoho protokolu k druhému. V na²em p°ípad¥ je to transformace SNMP MIB do XML, jak bylo vysv¥tleno v kapitole 3.

4.1.1 XML Nejprve se zam¥°íme na reprezentaci dat, které budou v rámci XML popisovat jak bránu, tak monitorované za°ízení. Z p°edchozích kapitol vyplynulo, ºe bude pouºito £áste£n¥ objektového p°ístupu a p°ímého mapování MIB. Strukturu dat bude popisovat XML dokument, strom, který má strukturu vyjád°enou na obrázku 4.2. Ko°enový uzel specikuje celé za°ízení vystupující jako protokolová brána, obsahuje tyto elementy: • info - tento element obsahuje text, kterým je popsáno dané za°ízení • services - element vymezující poskytované sluºby (p°i ²ir²í implementaci m·ºe

obsahovat sluºby DNS, DHCP, apod.)

• xmlbnmGate - na²e sluºba poskytující spojení XML a SNMP protokolu • device - je podelementem xmlbnmGate a vymezuje jedno monitorované za°ízení

Prvky device jsou do XML dokumentu p°idávány na základ¥ informací v kongura£ním souboru (viz kapitola 4.2). Strukturu elementu device popisuje obrázek 4.3. Kaºdý takovýto element bude obsahovat následující informace:

4.1.

TEORETICKÉ POADAVKY

Obrázek 4.2: Obecná struktura XML dokumentu

Obrázek 4.3: Struktura elementu device

23

24

KAPITOLA 4.

NÁVRH SYSTÉMU

• info - stejn¥ jako ko°enový element popisuje dané za°ízení • notications - obsahuje elementy a typy upozorn¥ní (TRAP zprávy v rámci

SNMP), na které manaºer £eká

• subscriptions - obsahuje informace o datech, které si nechává manaºer posílat v

pravidelných intervalech (více v popisu komunikace)

• data - d¥tmi tohoto elementu jsou ve²kerá data p°ímo z MIB.

Samotný element má atribut id, coº je jeho identikace v rámci xml dokumentu. Dle tohoto unikátního £ísla je pak moºné v sad¥ dotaz· rozpoznat, ke kterému za°ízení se dotaz vztahuje. Element info obsahuje elementy, které specikují jméno a popis za°ízení (viz obrázek 4.4).

Obrázek 4.4: Struktura elementu info Jednotlivé podelementy uzlu subscriptions musí z podstaty v¥ci obsahovat informace, které ur£ují, jaké objekty chce manaºer pravideln¥ sledovat, identikovat manaºera, aby mu mohla být data doru£ena a specikovat £asový interval, tj. frekvenci sledování p°íslu²né veli£iny. D¥ti uzlu notications ur£ují, které typy událostí jsou sledovány u daného za°ízení. V rámci kongurace systému je nezbytné, aby pro kaºdé za°ízení bylo jasn¥ denováno, kam mají být p°íslu²né zprávy o událostech zasílány. Tato informace bude sou£ástí kongura£ního souboru a systém ji bude intern¥ zpracovávat. Samotný XML tag bude obsahovat unikátní identika£ní £íslo (OID) dané události, aby jej bylo moºno poté identikovat a správn¥ formulovat XML zprávu manaºerovi. Mapování dat z MIB bylo obecn¥ popsáno v kapitole 3 a p°esný algoritmus bude specikován v následující kapitole. Pro adresaci jednotlivých objekt· je, jak bylo jiº nastín¥no v p°edchozí kapitole, pouºito mechanism· XPath £i XQuery. Dotaz na poloºku z MIB m·ºe vypadat následovn¥ /iso/org/dod/internet/mgmt/mib-2/...

D·leºitým faktem je, ºe manaºer se ptá p°ímo na uzly datového stromu. Nemusí tedy uvád¥t cestu v rámci celého stromu, který popisuje strukturu brány.

4.1.

TEORETICKÉ POADAVKY

25

Zprávy

Zprávy, které budou posílány mezi manaºerem a bránou, mají formu XML dokumentu. Schématicky je znázorn¥na a popsána v kapitole 3, obrázek 3.3. Ko°enový element message obaluje ve²kerá posílaná data. M·ºe obsahovat n¥kolik díl£ích dotaz·, nastavení a ostatních informací, které budou vykonávány postupn¥ jedna po druhé. V rámci teorie byla nastín¥na moºnost pouºití n¥kolika r·zných front, které by byly specikovány identikátorem a zaru£ovaly by r·znou prioritu zpracování. Navrhovaný systém bude podporovat rozd¥lení komunika£ních front dle monitorovaných za°ízení. Zajistí se tím správné po°adí vykonání p°íchozích poºadavk·. Komunikace mezi manaºerem a bránou je na XML úrovni omezena na zprávy • Get • Set • Discovery • Publication • Subscription • Distribution • Event

P°esná struktura a popis funkce jednotlivých zpráv byla popsána v p°edchozí kapitole. Komunika£ní protokol

Od protokolu SNMP se XML £ást komunikace li²í také tím, ºe bude probíhat na spolehlivém a potvrzovaném protokolu - HTTP. Kaºdá zpráva, která je poslána, musí mít potvrzeno doru£ení, coº tento aplika£ní protokol, vyuºívající transportního protokolu TCP, nabízí. Informace budou posílány ve formátu HTTP POST zprávy. Strukturu dotazu a odpov¥di zobrazuje obrázek 4.5 a komunikaci obrázek 4.6. Otázka bezpe£ného p°enosu dat byla °e²ena v p°edchozí kapitole a byl zvolen protokol HTTPS. Zaji²t¥ní distribuce a zpracování certikát· bude diskutováno dále v této kapitole.

26

KAPITOLA 4.

NÁVRH SYSTÉMU

Obrázek 4.5: HTTP zprávy p°edávané mezi manaºerem a bránou

Obrázek 4.6: HTTP komunikace mezi manaºerem a agentem/bránou

4.2.

STRUKTURA PROGRAMU

27

4.1.2 SNMP Druhou £ást komunikace tvo°í SNMP protokol. Z kapitoly 2 vychází seznam zpráv, které je nutné implementovat: • Get • Set • Response • GetNext • Trap

V rámci komunikace se v této práci budeme zaobírat verzemi SNMPv1 a SNMPv2. Samotná implementace a mapování SNMP zpráv na XML dotazy bude diskutována aº v kapitole 5. Bezpe£nost se v SNMP omezuje pouze na komunitní heslo. V rámci XML protokolu je bezpe£nost zaloºena jednak na ²ifrovaném p°enosu dat mezi manaºerem a bránou, druhak na p°ístupovém heslu, které vymezuje £tecí £i zápisová práva p°i p°ístupu k za°ízení. 4.2

Struktura programu

P°ed samotným návrhem jednotlivých funk£ních element· je nutno zvolit, jak bude program fungovat a jevit se globáln¥. Vzhledem k nabízeným sluºbám a komunikaci, je moºné zvolit koncepci podobnou webovým sluºbám (zaloºených na principu SOAP). Druhým moºným p°ístupem je zvolit na pozadí b¥ºící aplikaci - démona, který bude po celou dobu svého b¥hu monitorovat a zpracovávat p°íchozí poºadavky.

4.2.1 SOAP vs. démon Kompozice struktury jako webové sluºby zaloºené na SOAP architektu°e má n¥kolik p°edností. Je tím hlavn¥ p°enositelnost a jednoduchost nasazení. V²e, co je pot°eba k b¥hu, je aplika£ní server. Nainstalování a spu²t¥ní sluºby je jiº pak otázkou okamºiku. Samotná struktura kódu je téº o n¥co jednodu²²í, neº v p°ípad¥ démona. Je nutné se starat pouze o p°íchozí poºadavek a jeho zpracování. Bohuºel tento p°ístup má ale i mnoho nevýhod. Zaprvé je to reak£ní doba, za kterou je systém schopen zaslat manaºerovi odpov¥¤. Pro samotné zpracování poºadavku je nutno v pam¥ti (£i v souboru) udrºovat XML reprezentaci MIB tak, jak bylo popsáno d°íve. P°i pouºití tohoto postupu se po kaºdém p°ijatém poºadavku musí na£íst informace ze souboru a teprve poté je moºno data zpracovat.

28

KAPITOLA 4.

NÁVRH SYSTÉMU

Dal²ím sporným bodem je periodické zasílání zpráv manaºer·m, kte°í o to poºádali zprávou Subscription. V takovém p°ípad¥ musí b¥ºet jeden proces, který v ur£ených intervalech zasílá SNMP dotazy na monitorované za°ízení, coº je neslu£itelné se základní my²lenkou webových sluºeb. Asi nejv¥t²í nevýhodou tohoto p°ístupu je transformace dat z MIB do XML. P°i spu²t¥ní webové sluºby je nutné, aby jiº v²echna za°ízení m¥la své monitorované informace uloºeny v XML formátu, protoºe p°i poºadavku jiº není £as data transformovat. Tento akt by musel být od sluºby odd¥len a bu¤ sv¥°en periodicky se spou²t¥nému skriptu, nebo by jej administrátor musel provést pokaºdé, kdyº se zm¥ní po£et, druh £i monitorované údaje jednotlivých za°ízení. Oproti tomu stojí druhý p°ístup - strukturovat aplikaci jako démona. Je pravdou, ºe výsledný kód aplikace je sloºit¥j²í, p°enositelnost hor²í a není zde moºné mluvit o platformové nezávislosti (co se implementace v C++ tý£e). Nicmén¥ získáme tím výhodu v podob¥ relativn¥ malé reak£ní doby, protoºe ve²keré informace jsou za b¥hu uloºeny v opera£ní pam¥ti a není je nutno na£ítat z pevného disku. Systém periodického monitorování za°ízení m·ºe být jednodu²e spravován jedním vláknem procesu, zatímco ostatní vlákna se starají o p°íchozí a odchozí poºadavky. Transformace dat pak m·ºe být bez úhony sou£ástí samotného programu.

4.2.2 Navrhovaná aplikace Fáze b¥hu navrhovaného systému zobrazuje diagram na obrázku 4.7.

Obrázek 4.7: Fáze b¥hu programu

4.2.2.1 Inicializace

V první, inicializa£ní, fázi je na£ten kongura£ní soubor, jehoº specikace bude popsána v kapitole 5. Tento soubor obsahuje ve²keré informace o monitorovaných za°ízeních, stejn¥ tak jako základní nastavení protokolové brány. Kaºdé za°ízení musí mít denováno SNMP

4.2.

STRUKTURA PROGRAMU

29

spojení (adresu), seznam MIB, které vyjad°ují v²echny nabízené informace. Dále bude obsahovat nastavení ohledn¥ asynchronních událostí a jakému manaºerovi je nutno je p°eposílat. D·leºitým nastavením je i verze SNMP protokolu, jakou za°ízení podporuje. Protokolová brána bude mít sama o sob¥ speciální £ást, která bude denovat komunika£ní porty, na kterých budou p°ijímány a zpracovávány poºadavky, cesty k r·zným logovacím soubor·m a cesty k adresá°i s MIB a XML soubory. Sou£ástí inicializace je i ov¥°ení, zda-li v²echna monitorovaná za°ízení fungují. Pakliºe n¥které nebudou funk£ní, systém je ze seznamu vy²krtne a nebude je nabízet manaºer·m ke správ¥. 4.2.2.2 Transformace dat

Transformace dat p°edstavuje samotné mapování MIB do XML tak, jak bylo popsáno d°íve. Pro kaºdé za°ízení m·ºe být specikováno n¥kolik r·zných MIB, jak ve°ejné, tak proprietární. Pro kaºdé za°ízení je tedy nutno vytvo°it XML dokument, popisující ve²keré MIB informace. V tomt míst¥ jsou moºné dv¥ cesty, jak vybudovat výstupní XML dokument. Jednou moºností je zahrnout ve²keré informace o v²ech za°ízeních do jednoho souboru, který potom bude rozesílán kaºdému manaºerovi, jenº si o n¥j °ekne. Tato varianta je sice praktická, ale neefektivní. Pro za°ízení s velkým mnoºstvím informací by byl výsledný dokument opravdu veliký. Kdyby manaºer cht¥l spravovat pouze jediné za°ízení, byl by stejn¥ nucen stáhnout velký objem dat, neº by mu bylo dovoleno pracovat dále. Proto bude pouºito následujícího schématu. Systém bude p°i prvním kontaktu s manaºerem publikovat pouze informace týkající se po£tu a typu za°ízení, které spravuje. Jednotlivá za°ízení budou mít sv·j samostatný soubor s daty. Manaºer si pak bude moci zvolit pouze ur£itá data, která ho zajímají. Tím se velmi sníºí po£áte£ní zatíºení linky. 4.2.2.3 Zpracovávání poºadavk·

Po úsp¥²ném pr·chodu ob¥ma p°echozími fázemi se program dostává do situace, kdy vy£kává na p°íchozí poºadavky, a´ jiº ze strany manaºera £i SNMP za°ízení. Jak jiº bylo popsáno na za£átku této kapitoly, o komunikaci se starají dva moduly SNMP a XML. Proto taky komunika£ní rozhraní se d¥lí na dv¥ £ásti. SNMP modul bude komunikovat pomocí protokolu UDP, posíláním SNMP zpráv. Tato £ást rozhraní bude blíºe popsána v následující kapitole. Komunikace v rámci XML je na bázi HTTP protokolu. Pro zpracování mnoha poºadavk·, které je nutno o£ekávat, bude pouºito HTTP serveru. V tomto p°ípad¥ se nám nabízí dv¥ moºnosti °e²ení - vyuºijeme n¥jakého jiº stávajícího webového serveru (Apache, Tomcat, ...), na kterém budeme spou²t¥t CGI script a tak komunikovat s na²ím programem, nebo do aplikace n¥jaký jednoduchý server naimplementujeme. Výhodou jiº existujícího °e²ení by byla pouhá konstrukce komunika£ního kanálu mezi protokolovou

30

KAPITOLA 4.

NÁVRH SYSTÉMU

branou a zmín¥ným serverem. Je ale pravd¥podobné, ºe bude pot°eba mít v¥t²í kontrolu nad p°ijímanými a odesílanými zprávami, coº vlastní implementovaný server poskytuje. P°ednostn¥ tedy bude vybrána varianta s embedded HTTP serverem. Ve spojitosti s protokolem HTTP je nutné zmínit pouºití certikát· pro zabezpe£ený p°enost a pouºití protokolu HTTPS. Pakliºe by bylo vyuºito externího webového serveru, bude ponechána ve²kerá zodpov¥dnost a kongurace na administrátorovi serveru, který se bude muset postarat o obdrºení a distribuci certikátu. Jestli bude server sou£ástí protokolové brány, bude nutno p°iloºit certikát k aplikaci a v kongura£ním souboru zajistit jeho pouºití. 4.3

Správa protokolové brány

V rámci spravovaných za°ízení se naskýtá otázka, jestli by bylo moºno spravovat i samotnou bránu p°es navrºený XML protokol (je my²lena aplikace jako taková). Navrºený systém tuto skute£nost neumoº¬uje. Samotná brána nebude vykazovat vlastnosti agenta. Ke správ¥ stroje, na kterém brána pob¥ºí, bude nutné pouºít XML £i SNMP agenta, který tuto funkcionalitu bude zaji²óvat. Je moºné pak v kongura£ním souboru nastavit, aby brána nabízela komunikaci se SNMP agentem na tomtéº stroji. XML agent bude komunikovat s manaºerem p°ímo na denovaném portu. Implementace takového agenta ale jiº p°esahuje rámec této práce. Správa aplikace je pak omezena pouze na kongura£ní soubor a bude ji nutné p°i kaºdé zm¥n¥ restartovat (jak je tomu nap°íklad i u kongurace webových server·). Je to z d·vodu zachování integrity poskytovaných dat. P°i zm¥n¥ informa£ních bází jednotlivých za°ízení, p°idání £i odebrání monitorovaných stroj·, je nutno p°egenerovat v²echny XML dokumenty, které jsou pak distribuovány manaºer·m. Nekorektnost dat, které manaºer obdrºel a které by byly aktuální, kdyby se zm¥nily za plného provozu, by mohla mít pak váºné následky na data, která by manaºe°i dostali zp¥t. 4.4

XML manaºerská aplikace

Sou£ástí této práce je i implementace základního XML manaºera tak, aby dovolil ukázat ve²keré funk£ní aspekty protokolové brány. Program bude mít implementován celý XML komunika£ní protokol tak, jak byl navrºen v kapitole 3. Tudíº základní p°íkazy - Discovery, Publication, Get, Set, Subscription, Distribution. Správu monitorovaných za°ízení zahajuje komunikací bu¤ p°ímo s agentem £i bránou. Vyºádá si od nich dokument, který popisuje nabízené informace. Pakliºe se jedná o komunikaci s bránou, tak nejprve zjistí, jaká za°ízení jsou k dispozici a pak si n¥které vybere a teprve pak poºádá o jejich XML popis dat. Algoritmus budování XML stromu pouºitelného pro dal²í interakci se za°ízeními je stejný jako v p°ípad¥ brány a bude popsán v dal²í kapitole.

4.4.

XML MANAERSKÁ APLIKACE

31

Aplikace bude napsána v jazyce C++ stejn¥ jako protokolová brána. Vyuºití podpory grackého rozhraní je moºné.

32

KAPITOLA 4.

NÁVRH SYSTÉMU

Kapitola 5

Implementace Vlastní implementace protokolové brány je v této kapitole vysv¥tlena v rámci n¥kolika £ástí. Nejprve je popsána struktura programu, popis t°íd, jejich vztah mezi sebou a hlavní funkce, kterou plní. Následuje p°ehled v²ech pouºitých knihoven pro lep²í pochopení dal²ího popisu funkce aplikace. Dal²í £ást tvo°í vysv¥tlení výkonného cyklu programu krok za krokem od spu²t¥ní aº po zpracování jednotlivých zpráv. Jsou vysv¥tleny dosaºené výsledky p°i pam¥óvé optimalizaci a detailn¥ rozebrán systém komunika£ních front. Jako poslední je popsán XML manaºer, který byl navrºen v p°edchozí kapitole.

5.1

T°ídy, vlastnosti a jejich vztahy

Jak bylo p°edesláno v p°edchozí kapitole, p°i tvorb¥ byl dáván velký d·raz na modularitu jednotlivých sou£ástí programu. V praxi to znamená, ºe jednotlivé komunika£ní jednotky brány nemají tu²ení, jak ta druhá provádí konkrétní operace, ale jediným spojením jsou p°esn¥ denované struktury obsahující ve²keré nutné informace. Strukturu programu tvo°í £ty°i t°ídy: • SnmpXmlGate - hlavní t°ída, která ovládá b¥h programu. P°i spou²t¥ní inici-

alizuje ve²keré datové struktury, p°ipraví oba komunika£ní moduly a p°edá jim °ízení.

• SnmpModule - komunika£ní modul pro zpracování ve²kerých SNMP poºadavk·.

Plní dv¥ funkce. První je získávání dat z agent· v reakci na dotaz od manaºera (resp. XML modulu). Druhou je zpracování asynchronních událostí (Trap, Notication), které se na agentech vyskytnou a získané informace za²le denovaným manaºer·m.

• Mib2Xsd - transforma£ní t°ída pro p°eklad MIB databáze do XML schématu.

Netvo°í v²ak jenom tento popis, ale zárove¬ i vytvá°í nální XML dokument, se kterým pak hlavní program pracuje. 33

34

KAPITOLA 5.

IMPLEMENTACE

• XmlModule - druhý komunika£ní modul pro zpracování XML poºadavk·. Tato

t°ída je vlastní implementací navrºeného XML protokolu a je pro tuto práci st¥ºejní.

Vzájemné vztahy t¥chto t°íd jsou vyjád°eny na obrázku 5.1.

Obrázek 5.1: Schéma t°íd aplikace

5.2

Pouºité knihovny

P°i tvorb¥ programu bylo pouºito n¥kolik knihoven, které zaji²újí pot°ebné vyuºívané funkce. •

•

Xerces-C++ a Xalan-C++

- knihovny zaji²újící manipulace s XML dokumenty, vyhledávání pomocí XPath výraz· ([6], [7]).

Net-SNMP - knihovna napsaná v jazyce C, ur£ená pro interpretaci a manipulaci s daty MIB databází, zasílání a p°ijímání datových SNMP paket· ([8]).

5.3.

•

•

POPIS VÝKONNÉHO CYKLU

35

libMicroHTTPD - voln¥ dostupný HTTP server s podporou pouºití SSL protokolu p°i spojení ([9]). libCUrl

- voln¥ dostupná knihovna ur£ená pro klientskou stranu spojení. Podporuje mimo jiné protokoly HTTP, FTP a umoº¬uje pouºít i SSL certikáty pro zabezpe£ení daného spojení ([10]).

Knihovny Xerces, Xalan, libCUrl a libMicroHTTPD vyuºívá XML modul, který má na starosti b¥h HTTP serveru, operace s XML dokumenty a periodické zasílání informací. SNMP modul vyuºívá knihoven Net-SNMP a libCUrl. Druhou jmenovanou vyuºívá vlákno pro zpracování asynchronních událostí (viz dále v této kapitole). 5.3

Popis výkonného cyklu

Detailní popis funkcí jednotlivých t°íd je sou£ástí popisu fungování protokolové brány. Jak bylo napsáno v p°edchozí kapitole, v rámci b¥hu programu je n¥kolik p°esn¥ denovaných fází, ve kterých se systém m·ºe nacházet. Tyto jsou vyobrazeny na obrázku 4.7. N¥které z t¥chto fází byly oproti návrhu lehce pozm¥n¥ny, £i roz²í°eny, dle pot°ebného rozsahu spl¬ovaných funkcí.

5.3.1 Inicializa£ní fáze Je d·leºité p°ipomenout, ºe jiº v návrhu bylo stanoveno, jako optimální °e²ení, ºe program bude b¥ºet jako démon. Tomu odpovídá i manipulace s programem. Byl vytvo°en spou²t¥cí skript, který ovládá b¥h programu - spou²tí, zastavuje £i restartuje (popis instalace, struktura spou²t¥cího skriptu a pouºití je v p°íloze B). Jediným vstupním parametrem systému je kongura£ní soubor, který je formátován jako dokument XML (p°esná struktura souboru se v²emi povolenými a nutnými elementy je v p°íloze A). Tento obsahuje ve²keré nutné informace pro b¥h systému. Kongura£ní soubor

Informace jsou strukturovány do element·, kdy kaºdý popisuje jedno spravované za°ízení. Kaºdé za°ízení je nutné identikovat unikátním £íslem, které bude pouºito pozd¥ji p°i komunikaci s manaºery. Dále je nutné specikovat SNMP p°ístupové informace k agentovi: • IP adresu £i url • verzi SNMP protokolu • MIB báze, které popisují za°ízení • p°ístupová hesla (community string) pro zápis a £tení

36

KAPITOLA 5.

IMPLEMENTACE

Poslední poloºkou, která je £ist¥ volitelná, je moºné denovat manaºery, kte°í obdrºí informace o asynchronních událostech. Kaºdý manaºer je denován IP adresou £i url a portem, na který se budou zasílat jednotlivé zprávy. Specickým elementem je denice samotné brány. Tento element obsahuje ve²keré informace vý²e popsány, ale jsou p°idány je²t¥ povinné elementy: • logFile - identikuje soubor, do kterého budou ukládány ve²keré textové výstupy • snmp - obsahuje informace o cest¥ k soubor·m denujícím MIB databáze a portu,

na kterém budou poslouchány asynchronní události

• xml - denuje xml modul systému. Je zde verze XML protokolu; p°ístupová práva

pro £tení a zápis; cesta k ukládání XSD popisu za°ízení; porty pro poslouchání poºadavk· a odesílání odpov¥dí.

• security - obsahuje p°ípadné informace o certikátu a klí£i pouºitém p°i p°ístupu

p°es protokol HTTPS.

Zpracování a ov¥°ení informací

Poté, co je bezchybn¥ zpracován vstupní soubor, je p°istoupeno ke zpracování informací ohledn¥ jednotlivých za°ízeních. Tuto fázi má na starosti t°ída SnmpModule. Nejprve je ov¥°eno, jestli dané za°ízení v·bec funguje a je na n¥m p°ítomen SNMP agent. Ode²le se tedy základní poºadavek a je o£ekávána jakákoliv odpov¥¤. Kdyº je agent aktivní, je za°azen do seznamu spravovaných za°ízení. Jinak systém tuto poloºku vynechá a nebude ji dále brát v úvahu. Následuje zpracování seznamu MIB soubor·, které popisují nabízené informace. Tyto soubory je nutné vlastnit a p°iloºit je do d°íve specikovaného adresá°e, odkud si je systém na£te a pozd¥ji zpracuje. Jestli v²echny soubory existují a jsou na£teny, za°ízení je náln¥ "odsouhlaseno" (viz schéma 5.2). Po zpracování údaj· o v²ech za°ízeních, inicializa£ní fáze kon£í a systém zapo£ne fázi transforma£ní.

5.3.2 Transforma£ní fáze V této chvíli p°ebírá úlohu t°ída Mib2Xsd, která se stará o p°evod MIB popisu databáze do XSD formátu. Pro manipulaci se SNMP je pouºita knihovna net-snmp ([8]). Samotný p°evod a generování XSD popisu je rekurzivní sestup po jednotlivých uzlech virtuálního stromu MIB databáze. Pro kaºdé za°ízení systém na£te v²echny specikované MIB soubory a zapo£ne s transformací. Proces se °ídí pravidly, které byly denovány v kapitole 3. Jednotlivé uzly jsou popsány svým typem, který obsahuje jejich unikátní identika£ní £íslo (OID), typ dat a p°ístupová práva. Samotné uzly jsou pak za°azeny do stromové hierarchie v rámci dokumentu.

5.3.


37

Obrázek 5.2: Inicializa£ní fáze Informace, vztahující se k jednotlivým za°ízením, jsou generovány do odd¥lených soubor·. Samostatný soubor pak obsahuje schéma brány a pouze identikaci spravovaných za°ízení. Tento systém byl vytvo°en pro u²et°ení komunika£ní zát¥ºe mezi manaºerem a bránou. Bliº²í popis výhod tohoto p°ístupu dále v této kapitole. Oproti navrºenému systému mapování MIB do XSD ([1]) byla vynechána nutnost pouºití prostor· jmen pro jednotlivé MIB databáze. Vzhledem k tomu, ºe kaºdý element je popsán unikátním jménem a OID, nedojde p°i zpracování poºadavk· ke koniktu. Abychom u²et°ili procesorový £as, je paraleln¥ s generováním schématu vytvá°en i XML dokument, který za b¥hu slouºí k vyhledávání a ostatním pot°ebným operacím. Oproti schématu vypadá element specikující uzel v MIB databázi jako na obrázku 5.3. Tento dokument je pak spravován a vyuºíván t°ídou XmlModule.

5.3.3 Komunika£ní moduly Po úsp¥²ném zpracování a trasformaci MIB databází je moºné p°istoupit k inicializaci komunika£ních jednotek a otev°ení síóvých spojení k brán¥. V této fázi p°edává t°ída SnmpXmlGate °ízení t°ídám SnmpModule a XmlModule . Tyto moduly pak zaji²újí kompletní provoz protokolové brány. XmlModule

Dle návrhu programu v kapitole 4 bylo uvedeno, ºe pro komunikaci mezi bránou a manaºery bude pouºit HTTP server zabudovaný do aplikace, abychom m¥li v¥t²í kontrolu nad posílanými daty. Proto byl pouºit nejvhodn¥j²í kandidát - microHTTP server ([9]). Tento server je napsán v jazyce C.

38

KAPITOLA 5.

IMPLEMENTACE

Obrázek 5.3: P°íklad struktury hlavního XML dokumentu Jednotlivá spojení jsou zpracovávána samostatnými vlákny, aby bylo zaru£eno co nejrychlej²í odbavení poºadavk·. Funk£ní cyklus vlánka je znázorn¥n na schématu 5.4. Nejprve je zpracována HTTP zpráva. Systém operuje pouze s HTTP zprávami typu POST. Jakékoliv GET zprávy jsou zahazovány a zp¥t klientovi je zasláno chybové upozorn¥ní. Poté je na data pouºit XML parser, který zpracuje poºadavek a ujistí se, ºe je ve formátu specikovaném v kapitole 3. V²echny zprávy jsou zpracovávány najednou, aby byla zaru£ena integrita dat a "atomicita" operací. Více v kapitole 5.3.5. P°esné zpracování jednoho poºadavku je popsáno dále v této kapitole. Pro komunikaci vláken s druhým modulem byly vytvo°eny fronty poºadavk· (pro sm¥r od XML modulu k SNMP modulu) a jedna odpov¥dní fronta, ze které se poté vybírají vy°ízené poºadavky. Kdyº jsou v²echny zprávy v po°ádku zpracovány, jsou odeslány do fronty k p°íslu²nému monitorovanému za°ízení, nebo jsou rovnou za°azeny jako odpov¥di (obsahují-li chybu, která znemoº¬uje její dal²í zpracování). Za°azení do fronty k vláknu má na starosti SNMP modul a zárove¬ i on probouzí p°íslu²né vlákno ke zpracování poºadavk·. Vlákno se následn¥ p°esune do £ekajícího cyklu, kde kontroluje odpov¥dní frontu na svoje poºadavky do doby, neº se dostaví v²echny odpov¥di. Poté vygeneruje odpov¥dní zprávu a za²le manaºerovi. Tím jeho ºivotní cyklus prakticky kon£í. Je na serveru, jak s vlákny poté naloºí a jak je recykluje. Takzvané zamrznutí a nekone£né £ekání vlákna je o²et°eno maximální prodlevou pro jeden poºadavek v SNMP modulu. Tím je zaru£eno,

5.3.


Obrázek 5.4: Zpracování manaºerského poºadavku

39

40

KAPITOLA 5.

IMPLEMENTACE

ºe manaºer ur£it¥ dostane odpov¥¤. Jednotka komunikace

Neº p°istoupíme k popisu zpracování jednotlivých XML zpráv, je d·leºité popsat, jak spolu komunikují oba moduly. Z navrºeného protokolu jasn¥ vyplývá, ºe XML manaºer komunikuje s bránou tak, jako by to byl samotný XML agent. O protokolu SNMP nesmí v¥d¥t. Proto byl jiº p°i návrhu brán z°etel na striktní odd¥lení t¥chto dvou protokol·. Pro komunikaci byla navrºena struktura, která v sob¥ obsahuje ve²keré informace o poºadavku a odpov¥di, ale je protokolov¥ neutrální. D·leºité poloºky struktury, které oba moduly vyuºívají jsou: • typ zprávy - denuje, jaký poºadavek byl vyslán (Get, Set). Dle toho se pak

vytvá°ejí SNMP poºadavky na agenta.

• seznam uzl· - seznam dvojic (jméno, hodnota), které manaºer poºaduje. • chyba - identikace a textová reprezentace chyby, která v celém zpracujícím pro-

cestu nastala.

Tato struktura pak obsahuje informace o jednom poºadavku (Get, Set, Subscribe), který byl v XML zpráv¥ obsaºen. SnmpModule

Komunikace se SNMP agentama je zaloºen na systému front. Kaºdé monitorované za°ízení má na stran¥ protokolové brány k dispozici jedno obsluºné vlákno a frontu zpráv. Schématicky nazna£eno na obrázku 5.5. Zpracování a vytvá°ení SNMP zpráv se d¥je pomocí knihovny net-snmp. Práce komunika£ních vláken probíhá v "nekone£ném" cyklu. Vstupní informací pro vlákno je identika£ní £íslo monitorovaného za°ízení, ke kterému pat°í. S touto informací získá p°ístup k front¥ zpráv a dal²ím pot°ebným strukturám, p°íslu²ející pouze danému agentovi. V cyklu se pak opakuje n¥kolik díl£ích blok· stále dokola. Vlákno zjistí, jestli v p°íslu²né front¥ je p°ítomen n¥jaký poºadavek na vy°ízení. Kdyº není, vlákno se uspí. Jinak vyjme v²echny dotazy, tím frontu vyprázdní a poºadavky zpracuje. Tento funk£ní blok závisí na typu zprávy, která se má vy°ídit. Zprávy Get a Set, které mají za úkol dostat nebo nastavit hodnotu koncového uzlu stromu, pln¥ korespondují se SNMP. Je vytvo°en SNMP packet, do kterého je vloºeno heslo (community string) na základ¥ p°ístupových práv, které manaºer má, je napln¥no daty, které se mají nastavit £i získat a dotaz je odeslán. Po p°ijetí odpov¥di jsou data op¥t z paketu vyjmuta, upravena do poºadovaného formátu v rámci komunika£ní struktury. Pakliºe se vyskytla chyba p°i zpracování, op¥t je nastaven chybový p°íznak ve struktu°e, aby manaºer dostal informace o problému.

5.3.


41

Obrázek 5.5: Komunika£ní vlákna brány pro spojení se SNMP agenty Takto vygenerovaná odpov¥¤ je poslána do odpov¥dní fronty a je probuzeno vlákno, které na data £eká (samotná funkce je ve správ¥ XML modulu). Sloºit¥j²í je zpracování poºadavku na uzel, který není koncový a obsahuje pod sebou celý podstrom dal²ích uzl· (z hlediska MIB databáze). Poté je nutno opakovat vytvá°ení paket· a zasílání dotaz· ve form¥ SNMP zprávy GetNextRequest. Aº poté, co jsou získána v²echna data, je navrácena odpov¥¤ klientskému vláknu v XML modulu.

5.3.4 Zprávy Zpracování jednotlivých druh· zpráv se odvíjí od navrºeného modelu. Následuje popis chování systému p°i p°ijetí jednotlivých poºadavk·. Discovery

Jediným omezením p°i zpracování poºadavku je verze XML protokolu, kterou manaºer posílá ve zpráv¥. Kdyº se rozchází s nastavenou verzí v systému, odpov¥dí je zpráva Publication a chybové hlá²ení. Jedním z implementa£ních poºadavk· bylo téº sníºit mnoºství dat mezi manaºerem a bránou. P°edpokládáme, ºe brána spravuje desítky SNMP za°ízení. Celý dokument, popisující v²echny informace, který je odpov¥dí na tento poºadavek by pak nabyl obrovských rozm¥r·. Pro zlep²ení protokolu tak systém za²le manaºerovi pouze hlavní popis brány s identikací jednotlivých za°ízení, bez ostatních dat. Manaºer si m·ºe vybrat, které za°ízení chce spravovat a za²le novou zprávu Discovery s volitelným atributem objectid. Po zpracování mu brána za²le pouze XSD dokument popisující práv¥ to jedno za°ízení.

42

KAPITOLA 5.

IMPLEMENTACE

Get a Set

Zpracování t¥chto poºadavk· prochází n¥kolika fázemi v rámci samotného XML modulu. Nejprve je nutné zjistit, jestli má manaºer právo tyto operace provád¥t. Heslo, které se zasílá v elementu message, ur£uje, jestli je povoleno £tení, £i zápis. Nastavení hesel probíhá p°i inicializa£ní fázi, kdy jsou £tena z kongura£ního souboru. Celý p°ístupový model je zaloºen na dvou heslech XML protokolu - pro £tení a zápis. Kaºdé SNMP za°ízení má pak denovány op¥t dv¥ hesla, která jsou odli²ná od t¥ch prvních jmenovaných. Systém na základ¥ dodaného XML hesla zjistí, jaké má uºivatel práva a pouºije p°íslu²né SNMP heslo pro poºadavek. M·ºe se stát, ºe mangaºer zadal ²patné heslo a systém mu p°ístup odep°e. Pak je odpov¥dí na tyto poºadavky chybová zpráva. Kdyº uºivatel má dostate£né oprávn¥ní, je nutné zjistit, zda-li uzly, na které se dotazuje, opravdu existují. Dotazování probíhá pomcí jazyka XPath. Pakliºe je dotaz ²patn¥ formulován, nebo element neexistuje, systém poºadavek zamítne. V druhém p°ípad¥ mohou nastat dv¥ eventuality. Element je koncovým uzlem stromu, tj. obsahuje pouze hodnotu danou denovaným typem. Systém takový dotaz interpretuje jako jediný SNMP dotaz GET. Kdyº se ale jedná o ko°enový uzel (obsahuje podstrom uzl·), je nutné tento dotaz interpretovat jako SNMP zprávu GETNEXT a získat v²echny hodnoty daného podstromu (o coº se stará SNMP modul). Jestli bylo poºadavkem nastavení ur£ité hodnoty, pak je sou£ástí datové struktury jméno uzlu a p°íslu²ná hodnota. Vygenerovaná komunika£ní jednotka je vloºena do fronty poºadavk· a pak sou£asn¥ se v²emi ostatními odeslána SNMP modulu ke zpracování. Subscribe

Touto zprávou se manaºer upisuje k zasílání pravidelných informací o daném agentovi, nebo tyto údaje m¥ní a maºe. Kaºdý takový záznam se zanese do hlavního XML dokumentu, aby bylo p°i úpravách a mazání moºné vyhledávat pomocí XPath výrazu. Reakce na p°idání a úprava vnit°ních struktur je ponechána na speciální vlákno, které slouºí k obsluze daných záznam·. Bliº²í specikace dále v této kapitole. Jediný problém p°i implementaci nastal v rámci mazání jednotlivých záznam·. Vzhledem k tomu, ºe v navrºeném protokolu je odpov¥dí manaºerovi zpráva Distribution s daty, která poºaduje, nebo chyba, je nutno p°i smazání záznamu poslat op¥t zprávu Distribution, ale nyní prázdnou. Práva k mazání a úpravám daného záznamu jsou ponechána pouze na znalosti unikátního identikátoru daného záznamu.

5.3.


43

Zm¥ny oproti navrºenému XML protokolu

Oproti navrºenému XML protokolu bylo nutno ud¥lat n¥kolik drobných zm¥n, abychom mohli celý systém implementovat. Jedná se pouze o minoritní zm¥ny - p°idání volitelného atributu objectid ke v²em typ·m poºadavk·, které manaºer zasílá. Je to z d·vodu identiace monitorovaného za°ízení, coº by bez tohoto zásahu nebylo v·bec moºné. Zárove¬ tento zásah umoº¬uje ponechat stejnou strukturu protokolu (co se tý£e dotaz· a odpov¥dí) pro stroj agenta a brány. Abychom nezm¥nili dosavadní protokol, byl tento atribut zvolen jako volitelný. Jeho nep°ítomnost signalizuje, ºe dotaz je mí°en na samotné za°ízení brány, která následn¥ p°epo²le poºadavek na SNMP agenta b¥ºícího na tom samém stroji.

5.3.5 Fronty a atomicita poºadavk· Systém p°edávání poºadavk· pomocí front vychází z navrºeného protokolu ([1]), ale byl p°epracován pro pot°eby této protokolové brány. Navrhovány byly fronty, které by zpracovávaly poºadavky dle priority a mamaºer by si mohl °íci, které dotazy budou mít jakou prioritu. To bohuºel zcela nevyhovuje poºadavku zaji²t¥ní posloupnosti provád¥ní dotaz· a tím pádem i integrit¥ dat. P°edpokládejme situaci, kdy manaºer v jedné XML zpráv¥ za²le dotaz na hodnotu jednoho uzlu s niº²í prioritou a zárove¬ také nastavení jiné hodnoty s vy²²í prioritou (viz obrázek 5.6). Stalo by se, ºe p°i zpracovávání se nastavení provede d°íve a manaºer by se nikdy nedozv¥d¥l starou hodnotu.

Obrázek 5.6: Chyba prioritního zpracování poºadavk· Druhým problémem je "atomicita" provád¥ných operací. Kdyby systém zpracovával jeden poºadavek z p°ijaté zprávy, £ekal na odpov¥¤ agenta, a pak p°e²el na dal²í, mohlo

44

KAPITOLA 5.

IMPLEMENTACE

by se stát, ºe druhý manaºer by mohl do tohoto cyklu vstoupit a naru²it tak výsledek celé posloupnosti operací. Proto byl systém p°epracován tak, ºe kaºdé monitorované za°ízení má v SNMP modulu jedno obsluºné vlákno a frontu poºadavk· (jak bylo vysv¥tleno d°íve v této kapitole). Nyní se v XML modulu zpracují v²echny poºadavky v rámci jedné zprávy, vygenerují se p°íslu²né komunika£ní struktury a ty jsou následn¥ v²echny najednou vloºeny do p°íslu²né fronty poºadavk·. Tato funkce je ponechána na SNMP modulu, který zajistí, pomocí systému výlu£ného p°ístupu k dané front¥, aby v²echny zprávy tvo°ily souvislý blok, který bude sekven£n¥ zpracován. Je moºné, ºe uºivatel v rámci jedné zprávy za²le dotazy na více za°ízení. Kaºdé takové za°ízení obdrºí sv·j blok dotaz· individuáln¥. P°edávání odpov¥dí ze SNMP do XML modulu slouºí pouze jediná odpov¥dní fronta. Do ní se vkládají postupn¥ vy°ízené poºadavky ze v²ech za°ízení. Vºdy, kdyº je vloºena odpov¥¤, jsou probuzena klientská vlákna, zkontrolují frontu a p°ípadn¥ si vyberou jim ur£ené odpov¥di. Zde by se mohlo zdát, ºe bude naru²ena posloupnost jednotlivých odpov¥dí v p°ípad¥, ze komunikujeme s více za°ízeními. Tento fakt je o²et°en unikátním identikátorem kaºdého poºadavku v zasílané zpráv¥. Odpov¥di poté obsahují stejný identika£ní °et¥zec, díky kterému pak manaºer pozná, k jaké zpráv¥ se vztahuje obdrºená hodnota.

5.3.6 Periodické zasílání informací Jednotlivými zprávami typu Subscribe se manaºer upí²e k pravidelnému zasílání informací. Tuto £innost zahrnuje v sob¥ XML modul, kde na obsluhu t¥chto rozesílání je vyhrazeno speciální vlákno. To se stará o ve²keré manipulace s jednotlivými záznamy, získávání informací od agent· (pomocí SNMP modulu) a jejich p°edávání dále. Celý systém správy záznam· je zaloºen na hlavním XML dokumentu. Kaºdé spravované za°ízení má ve své £ásti element subscriptions, kam jsou ukládány informace o jednotlivých manaºerech. Jeden p°íkladný záznam je schematicky vyjád°en na obrázku 5.7.

Obrázek 5.7: Element subscription v rámci hlavního XML dokumentu Kaºdý záznam je identikován jedine£ným £íslem a zárove¬ i za°ízením, ve kterém se nachází. Dále element subscription obsahuje informace o frekvenci zasílání, url manaºera,

5.3.


45

kam se mají pakety doru£ovat a v poslední °ad¥ jsou to jednotlivé XPath výrazy pro identikaci uzl· z databáze dat. Ve²keré úpravy - p°idávání, zm¥na a mazání - jsou ponechány ve správ¥ tohoto vlákna. P°idání záznamu

Kdyº manaºer za²le poºadavek na zapsání, je obsluhujícím vláknem vytvo°en nový element subscription, napln¥n daty, umíst¥n do XML dokumentu a distribu£ní vlákno je upozorn¥no, ºe nastala zm¥na. Jsou prohlédnuty v²echny záznamy a vygenerovány interní datové struktury k správné obsluze. Úprava záznamu

Vlákno, které zpracovává poºadavek klienta, upraví daný záznam v XML dokumentu a oznámí distribu£nímu vláknu zm¥nu. To se pak, identicky jako v p°edchozím p°ípad¥, p°esv¥d£í, jaké zm¥ny nastaly a upraví interní data. Smazání záznamu

Záznam, pakliºe existuje, je ozna£en jako smazaný, ale vlastní smazání provádí aº distribu£ní vlákno. Zasílání informací

Vlastní zasílání informací probíhá v jednoduchém cyklu. Jestli není jediný záznam k dispozici, vlákno se uspí a £eká na p°íchozí zprávy Subscribe. Jsou-li záznamy k vy°izování, zvolí se nejmen£í £asový krok, který je nutný £ekat (dle frekvence zasílání jednotlivého záznamu) a vlákno se uspí. Po probuzení je ode£ten prospaný £as ode v²ech záznam· a u t¥ch, které jsou p°ipraveny k vy°ízení, p°edá distribu£ní vlákno p°ipravené komunika£ní jednotky SNMP modulu, pro vy°ízení vlastní komunikace. Poté, co dostane odpov¥¤, inicializuje spojení pomocí knihovny libCUrl a zprávu Distribution za²le manaºerovi na p°íslu²nou adresu. Pakliºe zpráva nedojde z jakéhokoliv d·vodu - manaºer je vypnutý, nem·ºe být zahájeno spojení - je zapo£ítán neplatný pokus o odeslání. V momentu, kdy tento po£et p°ekro£í stanovenou hranici, je daný záznam smazán a manaºer bude muset poºádat o nové zapsání zprávou Subscribe. Tento systém je zvolen pro zamezení zahlcení distribu£ního vlákna, které by pak v extrémním p°ípad¥ mohlo spravovat desítky aº stovky nefunk£ních záznam·, které si nikdo nevyzvedne.

46

KAPITOLA 5.

IMPLEMENTACE

5.3.7 Asynchronní události P°ijímání a zpracování ve²kerých asynchronních událostí, které agenti posílají na protokolovou bránu, má za úkol speciální vlákno ve správ¥ SNMP modulu. Funkce tohoto vlákna je p°ijmout SNMP zprávu (Trap, Notication), zjistit o jaké za°ízení se jedná, zvolit v²echny manaºery, kte°í jsou nastaveni pro p°íjem XML zprávy Event a zprávu odeslat. Ve²keré nastavení monitorovaných za°ízení z hlediska p°íjemc· t¥chto zpráv je v kongura£ním souboru. P°i inicializaci vlákna je zpracován tento seznam pro kaºdé za°ízení. Vlákno se pak p°esune do nekone£ného cyklu, kde £eká na denovaném portu na p°íjem zprávy. P°íjem a získání SNMP paketu z p°íslu²ného datového spojení je ponecháno na knihovn¥ net-snmp . Samotné zpracování pak v sob¥ zahrnuje získání informací o události, inicializaci jednotlivých spojení pomocí knihovny libCUrl a zaslání XML zprávy Event jednotlivým manaºer·m. Z navrºeného protokolu vyplývá povinnost získat potvrzení o doru£ení paketu. To za nás vykoná transportní protokol TCP, který je knihovnou libCUrl pouºit. Není-li moºné paket doru£it - manaºer neexistuje £i je vypnutý - pak je informace zahozena a brána se jiº o tento fakt nezajímá. 5.4

Pam¥óvé optimalizace

Hlavním bodem zadání této práce není jenom implementace protokolové brány, ale i optimalizace vyuºití opera£ní pam¥ti. P°i vývoji se objevily dva body, kdy bylo nutno vymyslet optimalizaci systému. Oba dva body se opírají o manipulaci a uloºení XML dokument·, které v pam¥ti zabírají velký prostor. Prvním je správa XSD schémat, která popisují jednotlivá monitorovaná za°ízení. Kaºdou p°íchozí zprávou Discovery se manaºer dotazuje na tato popisná schémata. Bylo by, pro rychlej²í odbavení poºadavku, snadn¥j²í uchovávat celá schémata v pam¥ti. Za p°edpokladu, ºe jedno schéma zabírá minimáln¥ n¥kolik stovek kB (p°i pouºití pouze standardní sady MIB databáze) pam¥ti a ºe bychom spravovali n¥kolik desítek za°ízení, mohla by se nutná pam¥´ rozr·st do desítek MB. Proto se kaºdé takovéto schéma ukládá do souboru na pevném disku a v p°ípad¥ pot°eby je soubor na£ten a zaslán manaºerovi. asový rozdíl je relativn¥ malý v porovnání s mnoºstvím pam¥ti, která se u²et°í. Druhým bodem je minimalizace velikosti hlavního XML dokumentu, který je udrºován po celou dobu chodu protokolové brány v pam¥ti. Není dost dob°e moºné, bez zásadních zm¥n navrºeného protokolu, sdílet £ásti virtuálního stromu dat. Proto vycházejme z p°edpokladu, ºe na spravované síti reáln¥ existují identická za°ízení, která pouºívají stejnou sadu MIB databází. Zárove¬ je tu druhý p°edpoklad, ºe v rámci b¥ºné sít¥ se nepouºívá mnoho jednotlivých za°ízení, která by v rámci SNMP protokolu nabízela ke správ¥ odli²ná data. Kdybychom m¥li u kaºdého takového za°ízení spravovat v hlavním XML dokumentu celý datový strom, nebylo by moºné udrºet tento v pam¥ti a zárove¬ na n¥m provád¥t efektivn¥ vyhledávání a jiné operace.

5.5.

XML MANAER

47

Proto byl stanoven takzvaný sdílený systém, který se dotýká i prvního bodu. Za°ízení, která mají v kongura£ním souboru nastavenu stejnou sadu MIB databází, jsou prohlá²ena za shodná, co se tý£e dat, a je vytvo°eno pouze jedno popisné XSD schéma a do hlavního dokumentu je uloºen pouze jeden takovýto strom. Ostatní za°ízení mají nastaveno identika£ní £íslo shodného agenta. P°i jakémkoliv poºadavku na vyhledání element· ve stromu £i popisné schéma, je vyhledáváno práv¥ v tom jediném sdíleném stromu, nebo navráceno jediné sdílené schéma. Tímto nejenom, ºe v rámci p°edpoklad· u²et°íme aktuální opera£ní pam¥t, ale zárove¬ i místo na pevném disku, kde jsou popisná schémata ukládána. Z hlediska spln¥ní zadání bylo tedy dosaºeno optimálního °e²ení. 5.5

XML Manaºer

Nedílnou sou£ástí implementa£ní £ásti je vytvo°ení XML manaºera, který by dovolil otestovat protokolovou bránu v praxi. Vzhledem k tomu, ºe není náplní práce vytvo°it plnohodnotného klienta, který by postkytoval ve²keré uºivatelské pohodlí gracké aplikace a jiných moºných aspekt·, byl vývoj omezen na tvorbu aplikace ovládané pomocí p°íkazového °ádku. K tvorb¥ manaºerské aplikace byly pouºity knihovny: • •

libCUrl - zaji²tující klientské spojení s HTTP serverem na brán¥ ([10]) libMicroHTTPD - HTTP server pouºitý pro p°íjem asynchronních událostí a

periodické distribuce dat ([9]) •

libargtable2

programu ([11])

- knihovna zaji²újící pohodlné zpracování vstupních parametr·

Aplikace funguje ve dvou moºných formách - aktivní nebo pasivní (kompletní instala£ní a uºivatelská p°íru£ka je v p°íloze C). Aktivní mód

V tomto módu je sou£ástí vstupních parametr· URL protokolové brány, XML heslo a soubor, který obsahuje jednotlivé poºadavky, které chce uºivatel provést. Systém na£te vstupní soubor a pakliºe je v²e bez chyby zpracováno, vygeneruje XML zprávu dle navrºeného protokolu. Tuto zprávu pak ode²le a £eká na odpov¥¤. V p°ípad¥, ºe byla odeslána zpráva Subscribe a jsou tedy o£ekávány periodické dodání informací, je spu²t¥n HTTP server a jako v p°edchozím p°ípad¥, aplikace £eká na odpov¥di. P°i ukon£ení tohoto £ekání za²le aplikace XML zprávu, kterou zru²í ve²keré Subscribe záznamy, které p°edtím odeslala.

48

KAPITOLA 5.

IMPLEMENTACE

Pasivní mód

Tento mód slouºí jako takzvaný "poslouchací". P°i n¥m se pouze aktivuje webový server a o£ekávají se p°íchozí zprávy ohledn¥ asynchronních událostí. V tomto módu nelze odesílat ºádné poºadavky.

Kapitola 6

Testování Cílem této práce bylo vytvo°ení funk£ního prototypu protokolové brány v jazyze C++. Proto ve²keré testování bude zam¥°eno na ov¥°ení funkce a prov¥°ení reakce-schopnosti na jednotlivé manaºerské poºadavky. Z podstaty práce vyplývá, ºe krom vý²e zmín¥ných parametr· není nutné provád¥t jakákoliv m¥°ení, jelikoº povaha programu není zaloºena na rychlosti odpov¥dí, ani jiných £asových parametrech.

Testovací systém Sí´ agent· spojená s bránou, na které bylo provád¥no m¥°ení, se sestává ze dvou autonomních systém·. Prvním je notebook, na kterém je nainstalován SNMP agent. Druhým systémem je za°ízení brány, na kterém krom¥ samotné protokolové aplikace b¥ºí téº SNMP agent. Testy se sestávají z ov¥°ení funkce pomocí odeslání jednotlivých poºadavk· dle navrºeného protokolu a obdrºení odpov¥dí. V kaºdé zpráv¥ je nejprve uvedeno, co manaºer odeslal a následuje výpis, co brána odpov¥d¥la.

Test zprávy Discovery Dotaz: <message password="zapis">

Zpráva má vyvolat odpov¥¤ obecného popisu a seznamu v²ech za°ízení, které brána spravuje. Schéma jednotlivých za°ízení je natolik obsáhlé, ºe jej není moºné do této práce vloºit.

49

50

KAPITOLA 6.

TESTOVÁNÍ

Odpov¥¤ (výstup zkrácen kv·li lep²í £itelnosti): <message> <xpath>1.0 <xsd:schema attributeFromDefault="unqualified" ...> ... <xsd:element name="devices"> <xsd:complexType> <xsd:sequence> <xsd:element id="0" name="device"> <xsd:complexType> <xsd:sequence> <xsd:element name="name">SNMP Gate <xsd:element name="description"> Popis brany <xsd:element name="data"/> <xsd:element name="notifications"/> <xsd:element id="1" name="device"> <xsd:complexType> <xsd:sequence> <xsd:element name="name">notebook <xsd:element name="description"> Domaci notebook <xsd:element name="data"/> <xsd:element name="notifications"/> ...

51

Test zprávy Get Dotáºeme se na popis systému jednotlivých za°ízení. <message password="zapis"> <xpath>/iso/org/dod/internet/mgmt/mib-2/system/sysDescr <xpath>/iso/org/dod/internet/mgmt/mib-2/system/sysDescr

Odpov¥¤: <message> Linux zoo 2.6.26-1-amd64 #1 SMP Sat Jan 10 19:55:48 UTC 2009 x86_64 Linux zoo 2.6.26-hrosi-jadro #4 SMP Fri Nov 21 19:19:38 CET 2008 i686

Test zprávy Subscribe V intervalech 5 vte°in se chceme dotazovat na po£et TCP paket·, které p°i²ly na vstup za°ízení £íslo 1 (domácí notebook). <message password="zapis"> <subscribe msgid="1" objectId="1" frequency="5" > <xpath>/iso/org/dod/internet/mgmt/mib-2/tcp/tcpInSegs

Odpov¥dí nám jsou data, £ímº brána potvrzuje p°ijetí a bezchybnost zápisu. Ihned manaºer zapíná HTTP server, který poslouchá na denovaném protu a £eká na do²lé informace (v na²em p°ípad¥ jsme nechali p°ijmout 5 zpráv).

52 <message> Counter32: 6114 -----------------Starting server for distributions ----------------Data received: <message context=""> Counter32: 6114 ---------------------------------------------------------Data received: <message context=""> Counter32: 6114 ---------------------------------------------------------Data received: <message context=""> Counter32: 6114 ---------------------------------------------------------Data received:

KAPITOLA 6.

TESTOVÁNÍ

53 <message context=""> Counter32: 6114 ---------------------------------------------------------Data received: <message context=""> Counter32: 6114 -----------------------------

Test zprávy Event V této fázi je manaºer nastartován pouze s HTTP serverem poslouchajícím na denovaném portu. O£ekává se p°ijetí zprávy Event, nebo ukon£ení programu. V na²em p°ípad¥ simulujeme nastalou událost pomocí aplikace snmptrap. Simulujeme výpadek jednoho síóvého spojení (linkDown), coº je jedna ze standardních událostí (generic trap). P°ijatá zpráva manaºerem: -----------------Starting server for notifications -----------------------------Data received: <message> <event msgid="1" senderid="0" eventSpec="device/notifications/linkDown"> -----------------------------

54

KAPITOLA 6.

TESTOVÁNÍ

Kapitola 7

Záv¥r Úsp¥²n¥ se poda°ilo splnit zadání této práce. Po detailním prozkoumání jak navrºeného, tak stávajícího komunika£ního protokolu, byl implementován poºadovaný systém pro jejich spojení. Byly vytvo°eny postupy, které optimalizují pam¥óvé nároky protokolové brány. P°i konstrukci jednotlivých £ástí programu se v²ak vyskytly p°ekáºky, které nebyly vºdy zcela uspokojiv¥ vy°e²eny. První z nich je pouºitý HTTP server, který byl vytvo°en jako voln¥ ²i°itelný projekt a není tudíº pln¥ optimalizován pro práci s mnoha desítkami sou£asných dotaz·. Téº není optimalizována jeho práce s vlákny. Dal²í obtíºí je knihovna pracující s protokolem SNMP. Tato vznikla op¥t jako otev°ený projekt bez jakékoliv záruky funk£nosti. Vyskytly se proto problémy s funkcemi pro práci s MIB databázemi. P°i transforma£ní fázi tak není moºné získat naprosto v²echny informace ohledn¥ jednotlivých uzl· datového stromu, nap°. popis. Nejsou to v²ak nikterak závaºné informace, které by ohrozily hlavní funkci programu £i navrºeného protokolu. Podobným problémem je i zpracování asynchronních událostí, kde knihovna ne zcela jasn¥ denuje, jak p°istoupit ke specickým informacím. Budoucí roz²í°ení programu je moºné sm¥°ovat do optimalizace jednotlivých sou£ástí programu. První je jiº vý²e zmi¬ovaný HTTP server, kde by se dalo implementovat vlastní °e²ení, nebo p°ed¥lat systém na komunikaci se samostatným serverem. Bylo by moºné pouºít jinou knihovnu, neº net-snmp, p°ípadn¥ si komunikaci mezi SNMP agentem a bránou spravovat dle vlastního implementovaného p°ístupu.

55

56

KAPITOLA 7.

ZÁVR

Literatura [1] Peter Macejko. XML Based Network Management. Diplomová práce, eské vysoké u£ení technické v Praze, Fakulta elektrotechnická, Praha, 2006. [2] Internetworking Technology Handbook - Simple Network Management Protocol. Cisco, Inc., http://www.cisco.com/en/US/docs/internetworking/technology/handbook/SNMP.html. [3] Charles M. Kozierok. TCP/IP Simple Network Management Protocol Overview. http://www.tcpipguide.com/free/ t_TCPIPSimpleNetworkManagementProtocolSNMPProtocol.htm. [4] Keith McCloghrie Marshall T. Rose. Structure and Identication of Management Information for TCP/IP-based Internets. RFC1155, IETF, 1990. [5] J. Case, R. Mundy, D. Partain, and Bob Stewart. Introduction to Version 3 of the Internet-standard Network Management Framework. RFC2570, IETF, 1999. [6] Apache Xerces. Knihovna pro manipulaci s XML dokumenty v jazyce C++. The Apache Software Foundation, http://xerces.apache.org/. [7] Apache Xalan. Knihovna pro vyhledávání v XML dokumentech v jazyce C++. The Apache Software Foundation, http://xalan.apache.org/. [8] Net-SNMP. Knihovna pro práci s protokolem SNMP v jazyce C++. http://www.net-snmp.org/. [9] Christian Grotho. GNU libmicrohttpd. http://www.gnu.org/software/libmicrohttpd/.

C++

HTTP

server.

[10] cURL. C++ knihovna pro práci s HTTP dotazy. http://curl.haxx.se/. [11] Stewart Heitmann. ANSI C command line parser. http://argtable.sourceforge.net/.

57

58

LITERATURA

Dodatek A

Struktura kongura£ního souboru Kongura£ní soubor je samostatný XML dokument, který se skládá z n¥kolika denovaných £ástí. Hlavní element je <devices>.... Tento vymezuje v²echna spravovaná a monitorovaná za°ízení. Existují dva typy za°ízení - protokolová brána a jakékoliv jiné.

B¥ºné za°ízení Kaºdé za°ízení musí být specikováno dle následujícího p°íkladu: <device id="XY"> Název za°ízení <description>Popis pro lep²í pochopení. <snmpAddr>ip_adresa <protocolVersion>2 <mibs> <mib>RFC1213-MIB.txt ... <manager>
ip_adresa
<port>7878 ... public <write>private

59

60

DODATEK A.

STRUKTURA KONFIGURANÍHO SOUBORU

Nejprve je nutné denovat identika£ní £íslo za°ízení. Id 0 je rezervováno pro protokolovou bránu a systém nepovolí za°azení jiného za°ízení místo ní. Tímto identika£ním £íslem jsou pak opat°eny jednotlivé zprávy. Následuje jméno a popis za°ízení. To v²e pro lep²í uºivatelský p°ístup administrátora p°i správ¥ brány. Je nutné denovat adresu snmp agenta (url £i ip adresa) a verzi SNMP protokolu (je podporována verze 1 a 2). Dal²ím prvkem jsou vyjmenované jednotlivé MIB databáze, které specikují ²kálu nabízených informací. Tyto soubory s denicí dat musejí být p°ítomny na stroji brány. Budou zpracovávány v transforma£ní fázi. Pakliºe není specikována ani jedna, je nahrána základní sada MIB databází dle knihovny net-snmp. Element ... denuje mnoºinu manaºer·, kte°í budou obesláni, pakliºe nastane n¥jaká asynchronní událost. Kaºdý manaºer je denován adresou a portem, na kterém poslouchá. Posledním základním elementem je denice p°ístupu. Zde je moºné denovat SNMP hesla (community °et¥zce) pro £tení a zápis. Tyto nemají nic spole£ného s denovavými hesly XML protokolu (viz níºe). Danému manaºerskému poºadavku se p°i°adí takový °et¥zec, jaká práva mu p°íslu²ejí dle XML hesla.

Protkolová brána Samotná brána má, oproti b¥ºným za°ízením, je²t¥ n¥kolik speciálních XML element·, které denují podstatné sou£ásti chování programu. Úplný soupis element· následuje: /tmp/snmpxmld.log <snmp> <mibPath>/usr/share/snmp/mibs/ <listenPort>3111 <xml> <xsdPath>/tmp/ <listenPort>8888 2555 cteni <write>zapis <protocolVersion>1 <security> key.pem cert.pem

61 Je moºné specikovat logovací soubor, nebo pouºívat jiº p°eddenovanou cestu. Následující elementy specikují £ásti SNMP a XML modul·. V rámci SNMP lze nastavit cestu k MIB soubor·m a port, na kterém jsou poslouchány asynchronní události. XML modul je moºné denovat o poznání více. Nejprve cesta, kam se budou ukládat Xsd popisné soubory. listenPort specikuje, na kterém portu bude pu²t¥n HTTP server. Zde se o£ekávají

poºadavky od manaºer·.

transmitPort denuje port, na který se odesílají zprávy Distribution.

Element p°ístupu specikuje, stejn¥ jako v SNMP £ásti b¥ºného za°ízení, jaká jsou hesla pro £tení a zápis. Posledním elementem je denice klí£e a certikátu, které HTTP server pouºívá p°i spojení s manaºery. Tento element je volitelný.

P°íklad souboru Následuje p°íklad funk£ního kongura£ního souboru o dvou monitorovaných za°ízeních. <devices> <device id="0"> SNMP Gate <description>Popis brany <snmpAddr>localhost <protocolVersion>2 <mibs> <mib>RFC1213-MIB.txt <manager>
127.0.0.1
<port>7878 public <write>private

62

DODATEK A.

STRUKTURA KONFIGURANÍHO SOUBORU

/tmp/snmpxmld.log <snmp> <mibPath>/usr/share/snmp/mibs/ <listenPort>3111 <xml> <xsdPath>/tmp/ <listenPort>8888 2555 cteni <write>zapis <protocolVersion>1 <device id="1"> notebook <description>Domaci notebook <snmpAddr>192.168.1.100 <protocolVersion>2 <mibs> <mib>RFC1213-MIB.txt <manager>
192.168.1.50
<port>1048 home <write>house

Dodatek B

Uºivatelská p°íru£ka protokolové brány Samotná protokolová brána funguje jako démon. Je ovládána pomocí spou²t¥cího skriptu, který je k programu p°iloºen. Vzhledem k tomu, ºe za cílový opera£ní systém je zvolen Linux, budeme se v dal²ím popisu adresá°· opírat o jeho strukturu soubor·.

Instalace Pro úsp¥²nou instalaci je nejprve nutné program zkompilovat. Pro p°eloºení je nutné mít v systému nainstalovány následující knihovny (pro kaºdou knihovnu platí, ºe je nutné mít hlavi£kové soubory, nikoliv jenom runtime verzi). • Xerces-C++ - verze 2.8.0 a vy²²í • Xalan-C++ - verze 1.10 a vy²²í • libsnmp - verze 5.4.1 • libmicrohttpd - 0.4.0 • libcurl - 7.18.2

Zkompilovaný program zkopírujeme do libovolného adresá°e (nejlépe v²ak /usr/bin £i /usr/share/bin). Spou²t¥cí skript umístíme do adresá°e /etc/init.d/. Je nutné jej v²ak upravit a nastavit p°esné umíst¥ní binárního souboru, který bude spou²t¥n.

Spu²tení a b¥h Samotné spu²t¥ní a b¥h není nikterak náro£né. Jediným parametrem, který program p°ijímá je umíst¥ní kongura£ního souboru. Cesta k souboru je uvedena v rámci spou²t¥cího skriptu. Proto jakékoliv zm¥ny je nutné promítnout i tam, aby program nahrával aktuální konguraci. Protokolovou bránu lze spou²t¥t p°i startu programu, £i pozd¥ji manuáln¥. V²e je ponecháno na administrátorovi systému. 63

64

DODATEK B.

UIVATELSKÁ PÍRUKA PROTOKOLOVÉ BRÁNY

MIB soubory

P°i specikaci MIB databázových soubor· v kongura£ním souboru je nutné dbát na to, aby v²echny uvedené existovaly v umíst¥ní, které je sou£ástí kongurace za°ízení brány. Pakliºe n¥které soubory jsou nedostupné, systém nebude moci dané za°ízení spravovat.

Dodatek C

Uºivatelská p°íru£ka manaºerské aplikace Manaºerská aplikace byla vytvo°ena jako dokumenta£ní a testovací nástroj, kterým je moºné ov¥°it rozsah funkcí protokolové brány. Aplikace je konstruována pro práci v rámci p°íkazové °ádky. Není dostupné ºádné uºivatelsky p°íjemné gracké rozhraní.

Instalace Pro úsp¥²nou kompilaci programu je nutné mít v systému nainstalovány následující knihovny ve vývojové verzi. • libmicrohttpd - 0.4.0 • libcurl - 7.18.2 • libargtable2 - 9

Binární zkompilovaná forma je posta£ující k ve²keré práci. Není nutné provád¥t ºádné dal²í operace.

Spou²t¥cí parametry Program je moºné ovládat sadou vstupních parametr·. Seznam následuje: • -n - ur£uje, ºe instance programu bude poslouchat p°íchozí asynchronní události. • lport <port> - port, na kterém je spu²t¥n http server pro poslouchání. • -v <protocol> - verze XML komunika£ního protokolu (v sou£asnosti verze 1) • -a - url £i IP adresa brány • -p <port> - port, na kterém brána poslouchá poºadavky

65

66

DODATEK C.

UIVATELSKÁ PÍRUKA MANAERSKÉ APLIKACE

• password - heslo pro danou sadu poºadavk· • -m <soubor s daty> - soubor, ve kterém jsou obsaºeny poºadavky • no-listen - nezapne se http server

Aplikace pracuje v n¥kolika reºimech - b¥ºný dotaz/odpov¥¤; poslouchání asynchronních událostí; poslouchání periodicky zasílaných dat. B¥ºný mód se vyzna£uje tím, ºe v rámci souboru s poºadavky uvedeme n¥kolik dotaz·, které chceme provést. Dále vstupními parametry specikujeme agenta, port a heslo a ode²leme ºádost. Agent odpoví a systém vypí²e p°ijatá data. Poslouchání asynchronních událostí je specikováno prvním a druhým p°epína£em. Systém neo£ekává ºádný vstupní soubor s daty, ale pouze spustí HTTP server a poslouchá jakákoliv p°íchozí data. Distribution zprávy je moºné p°ijímat poté, co jsme v poºadavcích specikovali n¥jakou zprávu Subscribe. Nyní aplikace spustí HTTP server a o£ekává, ºe jí bude agent/brána zasílat v daných frekvencích data. Zárove¬ systém £eká na vstup od uºivatele, který zadá identika£ní £íslo daného zápisu, aby mohl ukon£it odebírání t¥chto informací a zárove¬ zaslat ukon£ující zprávu na bránu.

Zde je je²t¥ moºnost upravovat daný zápis k zasílání dat. Pouºijeme-li p°epína£ --no-listen, systém pouze provede poºadavky v souboru, ale i kdyº je tam p°ítomna zpráva subscribe, nespustí HTTP server. Tato funkce demonstruje moºnou zm¥nu jednotlivých parametr· zápisu na protokolové brán¥.

Struktura p°íkazového souboru Poºadavky v datovém souboru denují obsah jedné XML zprávy, kterou zasílá manaºer agentovi. Kaºdá °ádka specikuje jeden p°íkaz. Je moºné specikovat pouze £ty°i poºadavky - Discovery, Get, Set, Subscribe. Kaºdý p°íkaz má svoji p°esn¥ denovanou strukturu, která je odvozena od navrºeného protokolu. Jednotlivé elementy v rámci poºadavku jsou odd¥leny st°edníkem. Následný vý£et specikuje jednotlivé moºnosti poºadavk·. Discovery discovery; discovery;id_zarizeni;

Prvním p°íkazem se dotáºeme na seznam v²ech za°ízení, které brána spravuje. V druhém p°ípad¥ se ptáme na popisné schéma specického za°ízení.

67 Get get;id_zarizeni;xpath_vyraz;

V rámci zprávy Get je moºné se dotázat pouze jedním XPath výrazem na uzel £i skupinu uzl· v datovém stromu. Set set;id_zarizeni;xpath_vyraz;hodnota;

Zprávou Set je moºno nastavit hodnotu jednoho konkrétního uzlu. Subscribe subscribe;id_zarizeni;frekvence;distrid;delete;xpath;...

Pro zpracování zprávy Subscribe je nutné denovat, pro které za°ízení je tato zpráva ur£ena. Dále specikujeme frekvenci zasílání dat. Pro zm¥ny £i smazání zápisu slouºí dal²í dva parametry - distrid, delete - tyto mohou být nezadané a systém to interpretuje jako novou zprávu. Posledním argumentem je sekvence xpath výraz·, které denují data, jeº chceme dostávat. Argument delete je pouze booleovská hodnota. Pro smazání daného zápisu bude nabývat hodnoty 1. P°íklad sekvence poºadavk· discovery;0; get;1;/iso/org/dod/internet/mgmt/mib-2/system/sysDescr; get;0;/iso/org/dod/internet/mgmt/mib-2/tcp; subscribe;1;120;;;/iso/org/dod/internet/mgmt/mib-2/tcp;\ /iso/org/dod/internet/mgmt/mib-2/system;

68

DODATEK C.

UIVATELSKÁ PÍRUKA MANAERSKÉ APLIKACE

Dodatek D

Obsah p°iloºeného CD P°iloºené médium obsahuje následující adresá°e a soubory: • /source - zdrojové soubory programu • /manager - zdrojové soubory manaºerského programu • /initscript - spou²t¥cí skript pro spu²t¥ní démona • /config_file - ukázkový kongura£ní soubor protokolové brány • /gate_usrguide.txt - instala£ní a uºivatelská p°íru£ka protokolové brány • /manager_usrguide.txt - instala£ní a uºivatelská p°íru£ka manaºerské aplikace. • /text/source - zdrojové kódy práce ve formátu LATEX • /text/pdf - text této práce ve formátu pdf.

69

XML brána. Bc. Tomá² Hroch

Recommend Documents