Hálózatkezelő függvénykönyvtár készítése...

Budapesti Műszaki és Gazdaságtudományi Egyetem

Villamosmérnöki és Informatikai Kar

Méréstechnika és Információs Rendszerek Tanszék

Mezei Zsolt

HÁLÓZATKEZELŐ

FÜGGVÉNYKÖNYVTÁR

KÉSZÍTÉSE POWERSHELLHEZ

KONZULENS

Micskei Zoltán

BUDAPEST, 2013

Tartalomjegyzék

Összefoglaló ..................................................................................................................... 5

Abstract ............................................................................................................................ 6

1. Bevezetés .................................................................................................................. 7

2. Irodalomkutatás ...................................................................................................... 9

2.1 A PowerShell kiegészítési lehetőségei ................................................................... 9

2.1.1 Szkriptek .......................................................................................................... 9

2.1.2 Snap-Inek ....................................................................................................... 10

2.1.3 Modulok ......................................................................................................... 11

2.2 Jelenlegi parancssoros hálózatkezelési lehetőségek ............................................. 12

2.2.1 NetShell (netsh) ............................................................................................. 12

2.2.2 Windows Management Instrumentation (WMI)............................................ 13

2.2.3 A Windows 8-cal bemutatkozott PowerShell funkciók ................................. 14

2.3 Meglévő kiterjesztések.......................................................................................... 15

2.3.1 PowerShell Community Extension (PSCX) .................................................. 15

2.4 A kutatás eredménye ............................................................................................. 16

3. Tervezés ................................................................................................................. 17

3.1 Megvalósítandó funkciók ..................................................................................... 17

3.2 Irányelvek ............................................................................................................. 18

3.2.1 Elnevezések ................................................................................................... 18

3.2.2 Automatizálhatóság ....................................................................................... 18

3.2.3 Pipelining támogatása .................................................................................... 19

3.2.4 Súgó ............................................................................................................... 20

3.3 Tervezett cmdletek és adattípusok ........................................................................ 21

3.3.1 Cmdletek ........................................................................................................ 21

3.3.2 Adattípusok .................................................................................................... 22

3.4 Alapvető szerkezet ................................................................................................ 23

3.5 Architektúra .......................................................................................................... 24

3.6 A tervezés eredménye ........................................................................................... 25

4. Implementáció ....................................................................................................... 26

4.1 Környezet .............................................................................................................. 26

4.2 Felhasznált osztályok ............................................................................................ 26

4.3 Segédeszközök ...................................................................................................... 27

4.3.1 Visual Studio sablonok Powershell projektekhez .......................................... 27

4.3.2 Kódminőség-ellenőrzők ................................................................................. 27

4.4 A cmdletek rétege ................................................................................................. 29

4.4.1 Közös jellemzők ............................................................................................ 29

4.4.2 Osztályok, mint cmdletek .............................................................................. 29

4.5 A modell réteg ...................................................................................................... 33

4.5.1 Közös jellemzők ............................................................................................ 33

4.5.2 A cmdletek műveletei .................................................................................... 34

4.6 Az implementálás eredménye ............................................................................... 35

5. Tesztelés ................................................................................................................. 36

5.1 Beépített validálás ................................................................................................. 36

5.2 Metódusszintű tesztek ........................................................................................... 36

5.3 Modulszintű tesztek .............................................................................................. 38

5.3.1 Tesztesetek ..................................................................................................... 38

5.3.2 Adapterek szűrése .......................................................................................... 39

5.3.3 Adapterek engedélyezése és letiltása ............................................................. 40

5.3.4 Adapterbeállítások módosítása ...................................................................... 43

5.3.5 Egyéb funkciók .............................................................................................. 43

5.4 A tesztelés eredménye........................................................................................... 44

6. Összefoglalás.......................................................................................................... 45

Irodalomjegyzék ............................................................................................................ 46

Függelék ......................................................................................................................... 48

A melléklet tartalma .................................................................................................... 48

Használati útmutató .................................................................................................... 48

HALLGATÓI NYILATKOZAT

Alulírott Mezei Zsolt, szigorló hallgató kijelentem, hogy ezt a szakdolgozatot meg nem

engedett segítség nélkül, saját magam készítettem, csak a megadott forrásokat

(szakirodalom, eszközök stb.) használtam fel. Minden olyan részt, melyet szó szerint,

vagy azonos értelemben, de átfogalmazva más forrásból átvettem, egyértelműen, a

forrás megadásával megjelöltem.

Hozzájárulok, hogy a jelen munkám alapadatait (szerző(k), cím, angol és magyar nyelvű

tartalmi kivonat, készítés éve, konzulens(ek) neve) a BME VIK nyilvánosan

hozzáférhető elektronikus formában, a munka teljes szövegét pedig az egyetem belső

hálózatán keresztül (vagy autentikált felhasználók számára) közzétegye. Kijelentem,

hogy a benyújtott munka és annak elektronikus verziója megegyezik. Dékáni

engedéllyel titkosított diplomatervek esetén a dolgozat szövege csak 3 év eltelte után

válik hozzáférhetővé.

Kelt: Budapest, 2013. 05. 26.

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

Mezei Zsolt

Összefoglaló

Hajlamosak vagyunk a parancssorokra mint elavult és kényelmetlen

rendszerekre gondolni, rendszerfelügyeleti feladatok esetén azonban, ahol

kulcsfontosságú az automatizálhatóság és a tömeges végrehajtás lehetősége, a grafikus

felületek szóba sem jöhetnek.

Igaz, a hatékonyság néha a kényelem rovására ment: a ma elterjedt parancssoros

eszközök jellemzően karakterlánc alapúak, ezért kimenetük feldolgozása nehézkes.

Ezen volt hivatott változtatni a PowerShell szkriptkörnyezet, amely a .NET

keretrendszerre épülve teljesen objektumorientált feldolgozást tesz lehetővé megőrizve

a szkriptnyelvek tömörségét és hatékonyságát. PowerShell alatt már nem külső

programok meghívásával kell dolgoznunk, a parancsok a környezet részei, a

kiegészíthetőség révén pedig saját parancsaink is hozzáadhatók a rendszerhez.

A szakdolgozat célja olyan PowerShell függvénykönyvtár tervezése és

megvalósítása, melyek felválthatják az eddig használt parancssoros eszközöket és

rendelkeznek a PowerShell előnyeivel a lekérdezett információ kézi szűrésének

egyszerűsödésétől a parancsok „csövezhetőségén” (pipelining) át a felhasználóbarát

súgóig. A legújabb Windows rendszereken már ugyan kapott helyet kiterjedt

hálózatkezelési funkcionalitás, de a régebbi verziók elterjedtségét tekintve indokolttá

válik egy ilyen kiegészítő modul elkészítése.

Az Irodalomkutatás fejezetben bemutatom a jelenleg elterjedt hálózatkezelő

parancssoros eszközöket, illetve a PowerShell alapvető működését és kiegészítési

lehetőségeit. A Tervezés részben az elkészítendő modul adatmodelljéről és az általa

kiváltott jelenlegi eszközöktől való különbségekről lesz szó. Az architektúra alapvetően

két rétegre osztható, egy a felhasználói interfészt (parancsok, paraméterek)

megvalósítóra és egy a funkciókat tartalmazó modellre. Ezek működését az

Implementálás fejezetben mutatom be részletesen. A Tesztelés során pedig a kész

modul működését ellenőrzöm, és hasonlítom össze a korábbi parancssoros

hálózatkezelő eszközökkel. Az elkészült kiegészítő használatához a függelékben

található útmutató nyújt segítséget.

6

Abstract

We often say that command lines are outdated and uncomfortable tools,

however they have an important role in system administration, where automation and

scriptability are essential and using graphical interface is not an option.

Although, this efficiency does not come with comfort: today’s command lines

are typically string-based and this causes difficulties in processing their output. This

was about to change with PowerShell, a new, fully object-oriented scripting

environment based on .NET framework.

In PowerShell we do not have to use external programs, because its commands

are part of the environment, and we are also able to extend it with some custom

commands.

The purpose of this thesis is to design and implement a PowerShell add-on

which could replace current command line tools and provide the advantages of

PowerShell like easier output filtering, pipelining or user-friendly help. Latest editions

of Windows already offer extensive networking functionality, but older versions are still

in need of it, which is a great reason to create such an add-on.

First of all I introduce basics of PowerShell and current networking command

line tools, which is followed by chapter Designing with designs of the data model and

the interface of the extension. The structure of the add-on has two layers: an upper one

provides the user interface and a model which contains the core functionality. The

Implementation chapter presents both layers, while int he Testing chapter I present tests

on the finished add-on. The Appendix contains a short user guide for the newly

developed module.

7

1. Bevezetés

Az átlagfelhasználóknak a parancssoros felületek kifejezés hallatán általában

régi, elavult rendszerek jutnak eszébe, amiket mára már kiváltottak a kényelmesebb,

barátságosabb grafikus szoftverek. Rendszerfelügyeleti feladatok esetén azonban, ahol

kulcsfontosságú az automatizálhatóság vagy akár több ezer gépen kell bizonyos

feladatokat végrehajtani, ezek a megoldások szóba sem jöhetnek, a grafikus felületen

ezt lehetetlen megoldani.

Itt mutatkozik meg a parancssorok igazi jelentősége, ahol sokáig a hatékonyság

a kényelem rovására ment: a ma elterjedt parancssoros eszközök jellemzően

karakterlánc alapon működnek, ezért kimenetük feldolgozása nehézkes (mert például

függ a felhasználói felület nyelvétől). Ezen volt hivatott változtatni a PowerShell

szkriptkörnyezet, amely, mivel a .NET keretrendszerre épül, teljesen objektumorientált

feldolgozást tesz lehetővé megőrizve a szkriptnyelvek tömörségét és hatékonyságát.

A PowerShell rendszergazda tevékenységek automatizációs platformja,

parancssori környezet és programozási nyelv egyben, amelyen keresztül kapcsolatba

léphetünk a számítógépes rendszerrel (ún. rendszerhéj). Nem csak parancsokat vagy

programokat hívhatunk, hanem deklarálhatunk változókat vagy függvényeket, akárcsak

egy programozási nyelvben, de azokkal ellentétben nincs szükség fordításra, a „kód”

soronként futtatható.

A PowerShell a .NET keretrendszerre épül, és annak objektumaival dolgozik,

így a parancsok sem karakterláncokat, sokkal inkább .NET objektumokat vagy azok

gyűjteményét adják vissza, vagy várják paraméterül (a karakterlánc csak egy ezek közül

az objektumok közül). Egy parancs kimenete könnyen átirányítható egy másik parancs

bemenetére ún. „csövezéssel” (piping), ha a megfelelő ki- és bemeneti objektumok

típusa megegyezik. A teljes .NET támogatás miatt összetettebb feladatoknál már

megnőhet a futásidő, ezért a sebességkritikus feladatok esetén a klasszikus parancssorok

hatékonyabbak.

A környezet egységessége érdekében az alapvető parancsok maguk a parancssor

részei, ellentétben a klasszikus cmd shellel, ahol az alapvető funkciókat is, mint például

a fájlmásolás, külső programok végezték. Ezek a parancsok, vagy PowerShell-

szóhasználattal cmdletek (ejtsd: kommandletek) megtalálásuk és használatuk

8

megkönnyítése végett elnevezésükben is egységesek: „ige-főnév” formában utalnak

arra, hogy pontosan milyen fajta objektumokon milyen művelet(ek)et lehet velük

végrehajtani (pl.: Copy-Item, Get-Help). Ha még nem szoktunk hozzá az

elnevezésekhez, használhatjuk a régi, megszokott parancsokat is, ezek ún. álnévként

(alias) valójában a PowerShelles megfelelőjüket hívják meg, például a dir

meghívásával a Get-ChildItem cmdlet fut le, ami (további paraméterek híján)

ugyanúgy az aktuális könyvtár gyermekelemeinek listáját adja vissza. Az egységesség

révén a fájlkezeléshez hasonló egyszerűséggel végezhetőek olyan rendszergazdai

feladatok is, mint a rendszerleíró-adatbázis (registry), vagy a tanúsítványtár kezelése.

A PowerShell másik fontos újítása a kiegészíthetőség: míg a klasszikus

parancssornál erre nem volt lehetőség (plusz funkciókat csak külső programok

formájában lehetett futtatni), itt lehetőségünk van saját modulok írására akár szkript

formájában, akár valamelyik .NET nyelven, amelyek nem külső programokként futnak,

hanem a rendszer részeivé válnak. Ez hasznos is, hiszen bizonyos területeken, mint

például a hálózatkezelés, még kevés beépített parancs áll rendelkezésre. Ugyan a

legújabb PowerShell 3.0-ban már kiterjedt hálózatkezelési parancsok állnak

rendelkezésre, ezek a funkciók csak Windows 8 esetén állnak rendelkezésre. Mivel a

piacon még sokáig a régebbi verzió, a Windows 7 dominál (illetve a következő egy

évben még a Windows XP-vel is számolni kell), indokolttá válik egy ilyen kiegészítő

modul elkészítése [1, 27-31. old.] [2, 9-15. old.].

A szakdolgozat célja egy olyan PowerShell függvénykönyvtár tervezése és

megvalósítása, amely felválthatja az eddig használt parancssoros eszközöket és

rendelkezik a PowerShell előnyeivel a lekérdezett információ kézi szűrésének

egyszerűsödésétől a parancsok „csövezhetőségén” (pipelining) át a felhasználóbarát

súgóig. Ehhez a következő feladatokat kell megoldani:

1. A PowerShell működésének, kiegészíthetőségi lehetőségeinek és a meglévő

parancssoros eszközök megismerése.

2. A megvalósítandó hálózatkezelési funkciók kiválasztása.

3. Az elkészítendő kiegészítő felhasználói felületének és adatmodelljének

megtervezése.

4. A funkciók implementálása a tervezésnél lefektetett alapokat követve.

5. Az elkészült modul tesztelése és bemutatása.

9

2. Irodalomkutatás

A feladat elvégzéséhez fontos a PowerShell alapjainak és kiegészítési

lehetőségeinek, illetve a már létező kiegészítők és egyéb fejlesztések megismerése,

hogy eldönthessük, indokolt-e egy hálózatkezelő kiegészítő elkészítése a környezethez,

és ha igen, a jelenleg elérhető megoldások miért nem töltik be ezt a szerepet. A leendő

funkcionalitás megtervezéséhez szükséges a meglévő parancssoros hálózatkezelő

eszközök ismerete is, hogy az új kiegészítő használata ezekhez hasonló lehessen.

2.1 A PowerShell kiegészítési lehetőségei

A PowerShell egyik igazi haszna a kiegészíthetőség, ami már a kezdetektől igaz

a környezetre. A legegyszerűbb, és rendszergazdák számára a legkézenfekvőbb mód a

saját szkriptek írása, ahogy erre minden parancssor esetén van lehetőség.

A környezet alapvető funkcionalitását ún. snap-inek (beépülők) tartalmazzák,

van lehetőség saját példányok telepítésére is, amivel bővíthető a parancskészlet.

Fejlesztők készíthetnek snap-int saját alkalmazásaikhoz, jellemzően

szerveralkalmazások PowerShell API-ja áll ilyen formában rendelkezésre.

A 2.0-s verziótól megjelent egy egyszerűbb kiegészítési lehetőség, a modulok,

amelyek már nem igényelnek telepítést, és több kiterjesztési és testreszabási lehetőséget

biztosítanak [1, 206-210., 279-293. old.].

2.1.1 Szkriptek

A szkriptek lényegében a kötegfájlok (*.bat) PowerShell-es megfelelői:

szöveges fájlok, amelyek minden sora egy-egy parancs, futtatáskor ezek hajtódnak

végre az előírt sorrendben, mintha csak a konzolba gépeltük volna be őket, így a

gyakori, de összetett feladatokat érdemes szkriptekbe menteni.

Mivel csak meglévő parancsok meghívásaiból állnak, és nem válnak a rendszer

részévé, a szkriptek nem tekinthetők valódi kiegészítőknek, fontos szerepük az

automatizálásban van.

Az idegen forrásból származó szkriptfájlok könnyen tartalmazhatnak kártékony

kódot, így alapértelmezésben a PowerShell tiltja digitálisan alá nem írt szkriptek

futtatását, ezen a korlátozáson a Set-ExecutionPolicy cmdlet használatával

10

enyhíthetünk. Például: Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

[1, 206-210. old.] [2, 81-83. old.].

2.1.2 Snap-Inek

A snap-in-ek a PowerShell építőelemei, a legalapvetőbb parancsokat is egy

Microsft.PowerShell.Core nevű tartalmazza. Lehetőségünk van saját snap-in-ek

telepítésére is, de a legtipikusabb eset, hogy külső alkalmazások telepítik fel a saját

PowerShell API-jukat ilyen formában. Saját snap-in készítéséhez valamilyen .NET

programnyelven kell megírnunk azt és a kódot egy .dll fájlba kell lefordítanunk. [1]

A telepített snap-in-ek megjelennek a rendszerleíró adatbázisban, de ennél

egyszerűbben is lekérdezhetjük a listát a Get-PSSnapin cmdlet segítségével.

1. ábra: Példa a Get-PSSnapin kimenetére

Ha csak a külső snap-ineket szeretnénk látni, a -Registered

kapcsolóparamétert kell megadnunk.

2. ábra: Példa a Get-PSSnapin –Registered kimenetére

Telepítésre csak rendszergazda jogosultsággal van lehetőségünk a .NET

keretrendszer parancssoros szerelvénytelepítőjének (InstallUtil.exe) használatával.

A telepített snap-inek (a beépítettek kivételével) igény szerint hozzáadhatók

illetve eltávolíthatók a környezetből az Add-PSSnapIn illetve a Remove-PSSnapIn

cmdletekkel. [1, 279-281. old.] [3]

11

2.1.3 Modulok

A modul egy a PowerShell 2.0-ban bemutatkozó egyszerűbb és rugalmasabb

kiegészítési lehetőség, egy-egy snap-in-eket, szkripteket és egyéb PowerShell

objektumokat tartalmazó mappa tekinthető egy modulnak.

A modulokat a PowerShell könyvtárában lehet elhelyezni, ez az ún.

rendszermodulok helye, ezekhez a számítógép minden felhasználója hozzáfér, de a

felhasználóknak lehetőségük van a saját személyes mappájukban privát használatra

szánt modulokat is elhelyezni.

Ha használni akarjuk a rendelkezésre álló modulokat, először importálnunk kell

őket, ebben néhány modulkezelő cmdlet van a segítségünkre. A Get-Module paranccsal

listázhatjuk ki a már importált modulokat, a -ListAvailable kapcsolót használva az

importálható (azaz a fent tárgyalt mappákban található) modulok listáját kapjuk meg.

Azonban ezzel még nem importáltuk őket, ahhoz az Import-Module cmdletet kell

meghívnunk, eltávolításukban pedig a Remove-Modul segít.

Létrehozhatunk továbbá ún. szkriptmodulokat meglévő szkriptekből (.psm1

fájl), vagy összefoghatunk snap-in-eket vagy más modulokat egyetlen modulba egy

moduljegyzék (manifest, .psd1 fájl) segítségével, de snap-in-eket tartalmazó dll-fájlokat

is importálhatunk ún. bináris modulként.

3. ábra: Az importálható modulok listája

Akár felhasználói, akár fejlesztői vagyunk a PowerShell környezetnek, a

moduloknak nagy hasznát vehetjük: csoportosíthatjuk szkriptjeinket egy tetszőleges

rendszer szerint, testreszabhatjuk a környezetet azzal, hogy a nekünk kellő modulokat

12

importáljuk, vagy fejlesztőként saját cmdleteinket egyetlen hordozható csomagként

publikálhatjuk. [1, 282-293. old.] [4]

2.2 Jelenlegi parancssoros hálózatkezelési lehetőségek

A klasszikus parancssor esetében is számos lehetőségünk van hálózatkezelési

feladatok elvégzésére. A legismertebbek az alapvető diagnosztikai feladatokat ellátó

„ipconfig” és „ping” eszközök, a névfeloldásra használható „nslookup”, vagy az

útvonalkereső „tracert”, de rendelkezésre állnak gazdagabb funkcionalitású lehetőséges

is, mint a NetShell vagy a WMI lekérdezések. Ezek a klasszikus parancssor többi

parancsához hasonlóan PowerShell alatt is elérhetők, bár értelemszerűen nem

rendelkeznek annak előnyeivel: a konzolon a szokásos karakterlánc-alapú kimenetet

kapjuk.

4. ábra: Az ipconfig kimenete

2.2.1 NetShell (netsh)

A NetShell egy széleskörű funkcionalitással rendelkező hálózatkezelő

parancssoros eszköz. A funkciók kategóriák szerint ún. környzetekbe (context)

csoportosítva állnak rendelkezésre, amelyek közt navigálhatunk. Ha ismerjük egy

parancs pontos „helyét”, magát a netsh-t a környezetek neveivel paraméterezve

hívhatjuk meg azt, így szkripteket is készíthetünk. Fejlesztők saját környezetekkel

egészíthetik ki a netsh-t további testreszabás végett. [5]

13

5. ábra: Az adapterek IP-címeinek lekérdezése NetShellből

6. ábra: A fenti parancs meghívás közvetlenül a parancssorból

2.2.2 Windows Management Instrumentation (WMI)

A WMI egy egységes eszközrendszer Windows rendszereken arra, hogy a

programok a rendszer elemeiről információt szerezzenek vagy módosítsák azok

beállításait akár távoli számítógépeken is. A rendszer elemeit egy-egy WMI osztály

reprezentálja, amelyekre kódból lekérdezéseket fogalmazhatunk meg az SQL-hez

hasonló WQL (WMI Query Language) nyelven, az információt objektumok formájában

kapjuk. A PowerShellben a Get-WmiObject cmdlet képes WQL lekérdezéseink

14

lefuttatására. Hálózatkezelési feladatokra pedig felhasználhatjuk a

Win32_NetworkAdapter és a Win32_NetworkAdapterConfiguration osztályokat.

Az alábbi lekérdezés listázza gépünk hálózati adaptereinek minden elérhető

adatát:

Get-WmiObject -Query "SELECT * from Win32_NetworkAdapter"

A -Class paramétert használva a megadott osztály példányait kérhetjük el, ezzel

a fenti lekérdezés egyszerűbben is megfogalmazható:

Get-WmiObject -Class Win32_NetworkAdapter

Összetettebb lekérdezéshez érdemes a PowerShell szűrő-cmdleteit használni, így

kiszűrhetőek például az adapterek fizikai címei: [2, 105-108. old.]

Get-WmiObject -Class Win32_NetworkAdapter | Select-Object Name,

MACAddress | Where-Object MACAddress -NE $null

7. ábra: WMI használatával lekérdezett fizikai címek

2.2.3 A Windows 8-cal bemutatkozott PowerShell funkciók

A PowerShell 3.0-ban már helyet kaptak komolyabb hálózatkezelési

lehetőségek, de ezek egyedül a legújabb Windows verziókban elérhetők (Windows 8 és

Windows Server 2012 alatt), a Windows 7-re telepíthető változatban nem, a régebbi

rendszerek pedig nem is kompatibilisek a legújabb PowerShellel. Az új modulok közül

a NetAdapter például 64 új hálózatkezelő cmdletet tartalmaz (pl. Get-NetAdapter,

Enable-NetAdapter, Disable-NetAdapter), de vannak további hálózatkezelő

modulok is (pl. NetSecurity, NetConnection).

15

8. ábra: A Windows 7 alatti PowerShell 3.0-nak nem része a NetAdapter modul

9. ábra: A Get-NetAdapter és a Disable-NetAdapter parancsok használata

2.3 Meglévő kiterjesztések

A meglévő PowerShell kiegészítők egyáltalán nem, vagy csak elvétve

tartalmaznak hálózatkezelő funkciókat.

2.3.1 PowerShell Community Extension (PSCX)

A PSCX egy közösségileg fejlesztett általános célú kiegészítő modul, amely a

felhasználók által legjobban hiányolt PowerShell funkciókat hivatott pótolni.

Hálózatkezelés terén azonban kevés parancs került bele, főleg a klasszikus diagnosztikai

eszközök PowerShelles megfelelőivel találkozhatunk, mint a Ping-Host (ping), vagy a

Resolve-Host (nslookup), hiányzik belőle a hálózatkezelés valamely területének teljes

lefedése, például adapter- vagy tűzfalkezelő cmdletek egy csoportja. [6]

16

10. ábra: A Resolve-Host parancs kimenete

2.4 A kutatás eredménye

A PowerShell környezet sokféle kiterjesztési lehetőséggel rendelkezik, de az

elterjedt verziókhoz még nem áll rendelkezésre széleskörű hálózatkezelési

funkcionalitás, ezért mindenképpen indokolt egy ilyen kiegészítő megtervezése és

megvalósítása.

17

3. Tervezés

A tervezés során az elsődleges feladat kialakítani a modul felhasználói felületét

és funkcionalitását, valamint definiálni a megvalósításhoz szükséges alapvető

szerkezeteket.

3.1 Megvalósítandó funkciók

A modul néhány fontosabb funkciót fog tartalmazni a meglévő eszközök

funkcionalitásából, elsősorban hálózati adapterekkel kapcsolatos feladatok kerülnek

bele: lehetőség lesz az adapterek listájának lekérdezésére (az ipconfig-hoz hasonló

módon), azok letiltására, engedélyezésére, néhány beállításuk módosítására, ezen kívül

helyet kap még pár további lekérdező funkció is.

Felhasználó

Hálózati adapterek lekérdezése

Hálózatkezelő modul

Adapterek engedélyezése«extends»

Adapterek letiltása

Adapterek újraindítása

«extends»

«extends»

DNS-konfiguráció módosítása

«extends»

Aktív TCP kapcsolatok lekérdezése

Forgalmi statisztikák lekérdezése

Nyitott portok lekérdezése

Távoli fájl letöltése

11. ábra: A modul használati esetei

18

3.2 Irányelvek

Az elkészült kiegészítő cmdleteinek bele kell illeszkednie a PowerShell

környezetbe az előírt szabályok betartása által. A legalapvetőbb konvenciók, mint

például a megfelelő osztályokból való leszármaztatás és a szükséges attribútumok

használata, a modul működéséhez elengedhetetlenek, a nem kötelező, de erősen ajánlott

irányelvek betartása pedig elsősorban a felhasználóinkat segíti.

3.2.1 Elnevezések

Saját cmdleteink és paramétereink elnevezésének a PowerShell kötelező

előírásainak kell megfelelniük: a cmdletnevek ige-főnév felépítésűek, ahol az ige csak

egy előírt halmazból választható (a szinonimák kizárásával a parancsaink könnyebben

megtalálhatóak lesznek), a főnévnek pedig minél pontosabban utalnia kell a cmdlet

funkciójára.

A paramétereknevek esetén egyedül a közös paraméterek nevei foglaltak, de

ezeken túl érdemes az azonos típusú paramétereinknek következesen ugyanazt a nevet

adni. Az elnevezések terén javasolt az ún. pascal case használata (a nevekben minden

szókezdet nagybetű, beleértve a kezdőbetűt is).

Cmdleteinknek javasolt azon .NET névtér alá kerülnie, ahol a hozzájuk hasonló

funkciók találhatók, így a hálózatkezelő parancsok számára a System.Net.Commands

névtér ajánlott.

3.2.2 Automatizálhatóság

Ha cmdleteink valamilyen visszavonhatatlan vagy a rendszert módosító

műveleteket végeznek, ajánlott a felhasználótól a tényleges módosítás előtt megerősítést

kérni, ehhez a ShouldProcess és a ShouldContinue metódusok állnak rendelkezésre.

Azonban szkriptek futtatásakor ezek a kérdések akadályozhatják az automatikus

lefutást, így szükség van olyan paraméterekre, amelyekkel szükség esetén

kikapcsolhatóak.

A ShouldProcess-szel kért megerősítés csak külön paraméter (-Confirm)

hatására jelenik meg, míg a ShouldContinue alapértelmezésben kérdést tesz fel,

használatakor egy -Force paramétert is kell definiálni, amellyel minden kérdéses

műveletre megerősítést lehet adni. [8]

19

12. ábra: A -Confim paraméterrel megerősítést kérünk törlés előtt

3.2.3 Pipelining támogatása

Egy cmdlet kimenetét könnyen egy másik cmdlet bemetére irányíthatjuk a

csővezeték (pipeline) használatával, így nem csak az összetettebb feladatok

megfogalmazása lesz tömörebb, hanem a feldolgozás sebessége is: a kimeneten

megjelenő első objektumot már akkor fogadhatja a következő cmdlet, amikor az utolsó

még elő sem állt. Ezen előny kihasználásához érdemes a kimenetre szánt objektumat

már létrejöttükkor a kimenetre küldeni a WriteObject metódussal. A csupán

módosítást végző cmdleteknek, amelyek alapesetben nem küldenek semmit a kimenetre,

javasolt támogatniuk a -PassThru kapcsolót, amelyet megadva a kimenetre

irányíthatók az általuk módosított objektumok.

Ha a cmdletünkkel szeretnénk fogadni a csővezetékből érkező bemenetet, egy az

elvárt típusú paraméter attribútumában tüntessük fel a ValueFromPipeline = true

értéket.

13. ábra: A paraméter átadása változó használatával

14. ábra: A csővezeték használatával tömörebben fogalmazhatunk meg feladatokat

20

A cmdletek által visszaadott objektumok típusát érdemes egy az osztályra

helyezett attribútum formájában jelezni.

3.2.4 Súgó

A PowerShell cmdleteihez részletes súgó tartozik, amit a Get-Help paranccsal

lehet megtekinteni, itt információt kaphatunk a cmdlet paraméterezéséről, működéséről,

további paraméterek alkalmazásával pedig még részletesebb segítséget kaphatunk.

15. ábra: A Get-ChildItem cmdlet súgója

16. ábra: Az –Examples kapcsoló példákat mutat a megadott cmdlet használatára

21

Saját súgótartalmat a modulunkba helyezett, előírt nevű és szerkezetű xml

fájlban hozhatunk létre cmdleteinkhez. Az alábbi részlettel egy cmdlet alapvető adatait

lehet megadni, de ehhez hasonlóan paraméterlistát vagy akár példakódokat is

hozzáadhatunk.

Get-NetworkAdapter

Gets network adatpters and their configuration

Get

NetworkAdapter

1.0

3.3 Tervezett cmdletek és adattípusok

A tervezett funkciók cmdletek formájában kerülnek megvalósításra, amelyek a

szintén általam definiált adattípusokat fogják felhasználni.

3.3.1 Cmdletek

A funkciók az alábbi táblázat által felsorolt cmdletek formájában állnak majd

rendelkezésre. Az elnevezések a konvenciónak megfelelően egy-egy szabványos igéből

és egy jellemző főnévből állnak. A főnevek megválasztása attól függ, hogy az adott

cmdlet mely típusú objektumokkal dolgozik illetve milyen módosításokat hajt végre, az

igék esetében a konkrét funkciókon kívül (pl. Enable, Diasble) a lekérdezéseket a Get,

a beállításokat a Set jelöli.

Get-NetworkAdapter Lekérdezi a gép hálózati adaptereit, és a kimenetre írja

azokat NetworkAdapter objektumok formájában. A

név alapján való szűrésre külön paraméter (-Name) áll

rendelkezésre, amely támogatja a joker karakterek

használatát is. Elsősorban az ipconfig parancs

alapfunkciójának szerepét hivatott átvenni.

22

Enable-NetworkAdapter Engedélyezi a paraméterként kapott hálózati adaptert,

amit NetworkAdapter típusban vár, célszerű a Get-

NetworkAdapter kimenetét a csővezeték

használatával átadni.

Disable-NetworkAdapter Letiltja a paraméterként kapott NetworkAdaptert az

Enable-NetworkAdapter cmdlethez hasonló módon.

Reset-NetworkAdapter Újraindítja a paraméterként kapott NetworkAdaptert

az Enable- és a Disable-NetworkAdapter

cmdlethez hasonló módon.

Set-DnsClientConfiguration A megadott adapter DNS-konfigurációját módosítja, a

megfelelő paraméterek megadásával megváltoztatható

az alapértelmezett átjárók, a DNS szerverek és a DNS

utótagok listája, valamint a tartománynév.

Get-ActiveTcpConnection Az aktív TCP kapcsolatok listáját adja vissza.

Get-IpStat Adapterek forgalmi statisztikáit adja vissza, az

adapterek nevére a -Name paraméterrel szűrhetünk.

Get-Listener Kilistázza a nyitott portokat, protokollt a megfelelő

paraméterekkel lehet választani (-Tcp ill. -Udp),

alapértelmezésben mindet megjeleníti.

Get-RemoteFile Letölti a megadott távoli fájlt (-FileUrl) a megadott

néven (-SaveAs).

3.3.2 Adattípusok

A legtöbb cmdlet hálózati adapterekkel dolgozik, amelyet a NetworkAdapter

osztály példányai reprezentálnak, a Get-IpStat pedig NetworkAdapterStatistics

objektumokkal tér vissza. Az adattípusok tulajdonságai a nekik megfeleltethető WMI

osztályok alapján lettek meghatározva, hogy a legtöbb, WMI által szolgáltatott adat

lekérdezhető legyen a cmdletek segítségével.

A kivételkezelést az Exception osztály különböző leszármazottai segítik,

amelyek PowerShell ErrorRecorddá konvertálhatók.

23

+DeviceId : string+Name : string+Description : string+MacAddress : PhysicalAddress+AdapterType : string+DnsDomain : string+PhysicalAdapter : bool+NetEnabled : bool

Model::NetworkAdapter

+Name : string+CurrentBandwidth : int+PacketsPerSec : int+PacketsReceivedPerSec : int+PacketsSentPerSec : int+BytesReceivedPerSec : int+BytesSentPerSec : int+BytesTotalPerSec : int

Model::NetworkAdapterStatistics

17. ábra: A két főbb adattípus és néhány fontosabb publikus tulajdonságuk

+Message : string+InnerException : Exception

System::Exception

+ToErrorRecord() : ErrorRecord

+Id : string+Category : ErrorCategory

Model::NetworkingException

Model::InvalidParameterException Model::AccessDeniedException

Model::WmiException Model::HostUnavailableException

18. ábra: A modul által használt kivételek hierarchiája

Az információ szűréséhez tetszőleges feltételeket szabhatunk meg az osztályok

tulajdonságira a PowerShell szűrő cmdleteivel, az elérhető tulajdonságok listáját a Get-

Member használatával kérdezhetjük majd le.

3.4 Alapvető szerkezet

A kiegészítő egy a hálózatkezelő cmdleteket tartalmazó snap-in formájában

készül el, amely egy modulba csomagolva áll majd rendelkezésre. A .NET

keretrendszer osztályokat és attribútumokat biztosít saját snap-in ill. cmdlet készítéséhez

a System.Management.Automation névtérben. Több hasonló funkciójú osztályból

választhatunk, a legalapvetőbb módszer a Cmdlet és a PSSnapin osztályból való

leszármaztatás.

24

Ezen osztályok és a saját kiegészítő modul, a NetworkingModule kapcsolatát az

alábbi ábra mutatja be:

+Name : string+Vendor : string+VendorResource : string+Description : string+DescriptionResource : string

Automation::PSSnapIn

#ProcessRecord() : void#BeginProcessing() : void#EndProcessing() : void#StopProcessing() : void

Automation::Cmdlet

1 *

NetworkingModuleSnapIn +Force : SwitchParameter+PassThru : SwitchParameter

NetworkingCommand

19. ábra: Saját snap-in létrehozása

Az absztrakt NetworkingCommand osztályból származnak majd a konkrét

cmdletek, ez tartalmaz még pár közös paramétert is. [7]

3.5 Architektúra

A modul alapvetően két rétegre osztottam: a felhasználói felületet (cmdleteket)

adó felső rétegre, és a modellre, ami magukat a funkciókat valósítja meg.

+Adapter : NetworkAdapter

NetworkAdapterEnablementCommand

+Name : string

GetNetworkAdapterCommand

EnableNetworkAdapterCommand

+Adapter : NetworkAdapter+Gateway : string[]+DNSServer : string[]+DNSDomain : string+DNSSuffix : string[]

SetDNSClientConfigurationCommand

DisableNetworkAdapterCommand

ResetNetworkAdapterCommand

+Force : SwitchParameter+PassThru : SwitchParameter

NetworkingCommand

GetActiveTcpConnectionCommand

+Tcp : SwitchParameter+Udp : SwitchParameter

GetListenerCommand

+Adapter : NetworkAdapter+Name : string

GetIpStatCommand

+FileUrl : Uri+SaveAs : string

GetRemoteFileCommand

20. ábra: A modul cmdletei és azok paraméterei

25

21. ábra: A modul modell rétege

A legtöbb cmdlet osztályhoz (Command végződésűek) tartozik egy saját modell

osztály (Model végűek). A cmdletek hívják a modell metódusait és értesítik a

PowerShellt annak eseményeiről (hiba, üzenet, objektum kimenetre küldése). Az

architektúra előnye, hogy a modell réteg külön, PowerShell specifikus elemek nélkül

tesztelhető, a modell eseményeire pedig egy tesztkörnyezet iratkozhat fel.

3.6 A tervezés eredménye

A kész tervekkel megadtam az implementálandó modul vázát és tisztáztam

annak alapvető működését, az implementálás során ez a váz egészül ki a teljes kóddal a

PowerShell szabványnak megfelelő módon.

26

4. Implementáció

Az implementálás során a kész tervek alapján létrejön a végleges modul:

bemutatom a fejlesztéshez használt környezetet és segédeszközöket, valamit a tervezés

során megalkotott architektúra rétegeinek részleteit és működését.

4.1 Környezet

A modul fejlesztése Windows 8 alatt, Visual Studio 2012 használatával, C#

nyelven, a teszteléshez Windows XP és Windows 7 virtuális gépek álltak rendelkezésre

az adott rendszeren elérhető PowerShell környezettel (2.0, illetve 3.0) együtt. Fő

szempont volt, hogy a Windows XP-n futó PowerShell 2.0-val is kompatibilis legyen,

ami a 2.0-s .NET-en alapul, így a kiegészítő is ezzel a verzióval lett lefordítva.

4.2 Felhasznált osztályok

Új cmdlet létrehozásához saját osztályunkat a Cmdlet [9] osztályból kell

leszármaztatnunk, és el kell látnunk azt a Cmdlet attribútummal is. Egy másik lehetőség

a PSCmdlet [10] osztály, amely a Cmdlethez hasonlóan használható, de nagyobb

hozzáférést biztosít a PowerShell futtatókörnyezethez, cserébe nagyobb méretű cmdlet

objektummal kell számolnunk.

A működést az ún. bemenetfeldolgozó metódusok felüldefiniálásával

határozhatjuk meg (ProcessRecord, Begin-, End- és StopProcessing),

paramétereket pedig a Parameter attribútummal ellátott tulajdonságok formájában

definiálhatunk.

Saját snap-int a PSSnapIn [11] osztályból leszármaztatva hozhatunk létre,

amiben csak az alapvető információkat kell tulajdonságokként megadnunk, mint a snap-

in neve vagy a leírása, mert minden, a vele azonos szerelvényben található cmdlet

osztályt tartalmazni fog. Ha saját magunk akarjuk meghatározni a snap-in cmdleteit, a

CustomPSSnapin [12] osztályt kell használnunk, ebben az esetben a cmdletek az osztály

Cmdlets gyűjteményéhez adhatók hozzá, meg kell adnunk a nevet, az osztályt és a

súgófájl nevét:

27

this.Cmdlets.Add(new CmdletConfigurationEntry("Get-MyCmdlet",

typeof(GetMyCmdletCommand), "MyModule.dll-help.xml"));

4.3 Segédeszközök

Rendelkezésre áll néhány hasznos segédeszköz, amelyek segítenek létrehozni a

projekt vázát vagy karbantartani a kódot, ezáltal magát a fejlesztést is megkönnyítik.

4.3.1 Visual Studio sablonok Powershell projektekhez

Elérhető a Visual Studiohoz egy PowerShell kiegészítők létrehozását segítő

sablon-csomag, amellyel eleve snap-in és cmdlet osztályok vázát tartalmazó projektet

hozhattam létre, ezzel segítve a fejlesztés kezdeti lépéseit. [13]

22. ábra: PowerShell projekt létrehozása

4.3.2 Kódminőség-ellenőrzők

4.3.2.1 StyleCop

A Visual Studio egy beépülő modulja, ami a forráskódot segít rendezettebbé és

mások számára könnyebben érthetőbbé tenni azáltal, hogy konzisztens formai

követelményeket támaszt a dokumentációs fejlécektől kezdve a helyes tagolásokig. Az

ellenőrzés futtatásakor figyelmeztetések generálódnak, amelyek a megsértett

28

szabályokra hívják fel a figyelmet, szükség esetén a szabályokat magunk is

módosíthatjuk, vagy saját szabályokat adhatunk hozzá. [14]

A fejlesztés során minden saját forrásfájlon futtattam StyleCop ellenőrzést.

Legnagyobb előnye, hogy megkövetelte a kód helyes tagolását és dokumentáltságát, így

mások számára is könnyen olvashatóvá tette azt. Csak néhány szabályt hagytam

figyelmen kívül, amelyek csak nagyobb projektek esetén okozhatnak gondot, betartásuk

ebben az esetben csak feleslegesen bonyolította volna a kódot.

4.3.2.2 FxCop

Az FxCop segédprogrammal .NET szerelvények vizsgálhatóak meg

teljesítménybeli és biztonsági szempontok alapján. Az eszköz javaslatokat tesz a kód

lehetséges fejlesztéseire, felhívja a figyelmet az esetleges hibákra (pl. nem a lehető

legszűkebb láthatóság megadása, teljesítményt romlását okozható megoldások),

amelyek bizonyos esetekben problémák forrása lehet. Mind grafikus, mind

parancssoros, azaz automatizálható felülettel elérhető. [15]

23. ábra: Az FxCop grafikus felülete

Lefuttattam az FxCop ellenőrzést a lefordított szerelvényen, ami adott pár

hasznos tanácsot a kódminőség kapcsán (pl. láthatóságok helyes használata).

Teljesítménybeli gondok nem indokolták az összes szabály szigorú betartását, és a kód

29

egyszerűségének megőrzése érdekében figyelmen kívül hagytam őket (pl.

többnyelvűség támogatása, bizonyos adattípusok mellőzése).

4.4 A cmdletek rétege

Ez a réteg tartalmazza a modul cmdleteit reprezentáló osztályokat.

4.4.1 Közös jellemzők

Minden Command osztály őse az absztrakt NetworkingCommand, amely a

terveknél ismertetett módon a Cmdlet osztály leszármazottja, és a két közös

paraméteren kívül (Force és PassThru) tartalmaz még egy eseménykezelőt is, ami a

modelltől érkező eseményeket (hibaüzenet, objektum küldése a kimenetre, stb.)

dolgozza fel és jeleníti meg a kimeneten:

protected void ModelMessageOccured(object sender,

CmdletEventArgs e)

{

if (e.IsOutput)

{

this.WriteObject(e.OutputObject);

}

else if (e.IsWarning)

{

this.WriteWarning(e.Text);

}

…

}

A CmdletEventArgs objektum tartalmaz minden a feldolgozáshoz szükséges

információt.

4.4.2 Osztályok, mint cmdletek

A NetworkingCommand leszármazottait szeretnénk, ha cmdletként értelmezné a

PowerShell környezet, így el kell látni a szükséges attribútumokkal, amelyekkel

jelezzük a cmdlet nevét és pár további információt, például a kimeneti objektumok

típusát, vagy hogy a megerősítés-kérések támogatottak-e. Például a

30

GetNetworkAdapterCommand osztályból ezen attribútumok megadásával lesz a

PowerShell számára Get-NetworkAdapter cmdlet:

[Cmdlet(VerbsCommon.Get, "NetworkAdapter",

SupportsShouldProcess = true)]

[OutputType("NetworkAdapter")]

public class GetNetworkAdapterCommand : NetworkingCommand

Az itt alkalmazott kétrétegű architektúra esetén konkrét cmdletet reprezentáló

osztályoknak hivatkozniuk kell a megfelelő modell objektum egy példányára is privát

láthatósággal:

private GetNetworkAdapterModel model =

new GetNetworkAdapterModel();

Szükséges még egy paraméterek nélküli publikus konstruktor, hogy a

PowerShell példányosítani tudja az osztályt meghíváskor. Célszerű a modell

eseményeire itt feliratkozni az ősosztályban megvalósított eseménykezelővel.

4.4.2.1 Paraméterek

Paramétereket a Parameter attribútummal ellátott publikus tulajdonságokkal

definiálhatunk, az attribútumban írhatjuk elő többek közt, hogy a paraméterük kötelező

legyen-e (Mandatory) vagy hogy a híváskor a paraméternevek elhagyása esetén mely

pozíción kell megadni (Position, a sorszámozás 1-től kezdődik).

Példa egy nem kötelező, karakterlánc típusú paraméterre:

[Parameter(Mandatory = false, Position = 1)]

public string Name { get; set; }

Az így létrehozott paraméter megadása:

Get-MyCmdlet -Name "my name"

A pozíció definiálásával az alábbi hívás is működik:

Get-MyCmdlet "my name"

31

Paramétertípusokként a szokásos .NET típusok használhatóak, de van néhány

speciális típus, amellyel könnyebbé tehetjük cmdleteink használatát, leggyakoribb a

logikai értéket reprezentáló SwitchParameter:

[Parameter]

public SwitchParameter MySwitch { get; set; }

Egy bool paraméternél kötelező lenne mindig kiírni az értéket (pl. -MyBool

true), amíg a kapcsoló megléte jelenti az igaz, hiánya a hamis értéket:

Get-MyCmdlet -MySwitch

4.4.2.2 Feldolgozó metódusok

A cmdlet funkcióinak megvalósításához négy metódus áll rendelkezésre,

amelyet Command osztályaink a Cmdlet-ből örökölnek.

BeginProcessing Az elsőként lefutó feldolgozó metódus, kezdeti értékadásokat

érdemes itt megadni. Csak egyszer fut le, így amennyiben

cmdletünk nem fogad bemenetet a pipeline-on keresztül, érdemes

itt megvalósítani a teljes funkcionalitást.

ProcessRecord A fő feldolgozó metódus, csővezetékből érkező bemenet esetén

annak minden elemére (rekordjára) lefut.

EndProcessing Az utolsóként lefutó metódus, a BeginProcessinghez hasonlóan

csak egyszer fut le, de a lefutása nem garantált, így erőforrások

felszabadítását nem érdemes ide tennünk.

StopProcessing Akkor hívódik, ha a feldolgozást a felhasználó leállítja vagy az

más okból megszakad.

4.4.2.3 A kimenet kezelése

Cmdleteinknek jeleznie kell a futás eredményét a kimeneten, amelyhez

rendelkezésre áll néhány beépített metódus.

WriteObject

Objektum küldése a kimenetre/csővezetékbe, a legfontosabb metódus. Kiírás

után a csővezetékben soron következő cmdlet tudja fogadni az objektumokat, vagy ha a

csővezeték végén állunk, megjelenhetnek a kimeneten.

32

Egy egyszerűbb esetben, ha a bemeneten érkező összes objektumot szeretnénk

egyből a kimenetre küldeni, az a ProcessRecord és a WriteObject segítségével

tömören megfogalmazható:

[Parameter(Mandatory = true, ValueFromPipeline = true)]

public object ObjectParam { get; set; }

protected override void ProcessRecord()

{

this.WriteObject(this.ObjectParam);

}

WriteWarning

Figyelmeztetés küldése a felhasználónak, ha feldolgozás közben valami apróbb

hiba következett be, és nem biztos, hogy a várt eredményt kapja. Az üzenet a cmdlet

futására nincs hatással.

WriteError

Hiba jelzése a kimeneten. Paraméterként egy ErrorRecord objektumot kell

átadni, amely a hiba beazonosításához szükséges információt tartalmazza, mint például

a pontos hibaüzenet, vagy a hibát jelző .NET kivétel.

24. ábra: A kimeneten megjelenő hibaüzenet

Hiba esetén a feldolgozás alapértelmezésben folytatódik tovább a pipeline

további elemeivel. A PowerShell hibákra adott reakcióit minden cmdlet esetén az

-ErrorAction közös paraméterrel állíthatjuk.

33

ThrowTerminatingError

A WriteErrorhoz hasonlóan hiba jelzésére szolgál, de a

ThrowTerminatingError esetében a futás leáll, a csővezetékből érkező további

rekordok nem kerülnek feldolgozásra.

WriteVerbose

Tájékoztató jellegű üzeneteket jelenít meg a kimeneten. Ezek az üzenetek

alapértelmezésben nem látszanak, a -Verbose közös paraméterrel lehet engedélyezni a

megjelenítésüket.

4.5 A modell réteg

A modul funkcionalitását tartalmazó réteg, amelyet a cmdlet réteg vesz igénybe.

4.5.1 Közös jellemzők

A modell osztályok hierarchiája a cmdletekéhez hasonló, mivel a cél az, hogy

valamennyi cmdlet funkcióit egy-egy hozzárendelt modell osztály biztosítsa. A

modellek is egy közös ősből származnak, amiben az adatok a cmdletek felé való

továbbításához használatos esemény és segédmetódusai vannak implementálva.

public event EventHandler MessageOccured;

A leszármazottak nem közvetlenül az eseményt sütik el, az ősosztályban helyet

kap néhány segédmetódus (SendVerbose, SendError, stb.), amelyek az üzenet típusa

alapján (kimenet, hiba, stb.) összeállítják a megfelelő CmdletEventArgs objektumot,

így egyszerűsödik az üzenetek küldése a modell-rétegből a cmdlet-réteg felé. A modell

és az adattípus osztályok valamennyi metódusa a konstruktort is beleértve internal

láthatóságú, hogy a modul többi részének látható maradjon, de a felhasználók ne tudják

elérni vagy példányosítani ezeket az osztályokat, ahogyan azt public esetben

megtehetnék.

34

25. ábra: A NetworkAdapter kézi példányosítása nem megengedett

4.5.2 A cmdletek műveletei

A modell osztályok metódusai, mint tesztelhető egységek kerültek

megvalósításra, a funkcionalitást leginkább WMI használatával, néhány esetben a C#

hálózatkezelési lehetőségeit használva biztosítják.

Például a Get-NetworkAdapter esetében első lépésként a WMI lekérdezés

futtatjuk, majd annak az eredményéből készítjük el a NetworkAdapter objektumokat,

és a megadott szűrőnek megfelelőket a kimenetre küldjük (27. ábra). Amikor a

felhasználó meghívja a PowerShell cmdletet, az létrehoz egy példányt a megfelelő

modell osztályból, amin meghívhatja a szükséges metódusokat. A modell létrehozza a

kimenetre szánt objektumokat, amiket azonnal elküld a cmdletnek, ami a felhasználó

(vagy a csővezeték) felé továbbítja azokat. A cmdlet példányt (Command osztály) maga a

PowerShell környezet hozza létre a hívás hatására.

A NetworkAdapter példányok tartalmazzák a hozzájuk tartozó WMI

objektumot is, hogy a többi cmdlet további műveleteket végezhessen rajtuk WMI

metódushívások formájában (engedélyezés, letiltás, stb.). A módosítások alkalmával

egy újabb lekérdezést kell futtatni, amely az objektum tulajdonságait kitölti a frissített

adatokkal. Ezt a frissítést a cmdletek maguktól meghívják, de szükség esetére a

felhasználók számára is publikálva van Refresh néven:

26. ábra: Refresh metódus hívása egy NetworkAdapter objektumon

35

Get-NetworkAdapter

cmdlet :

GetNetworkAdapter

Command

model :

GetNetworkAdapter

Model

User

SetCommonParameters()

networkAdapter

GetAdapterData()

managementObjectCollection

FilterNetworkAdapters()

loop

networkAdapter

[has network adapters]

CreateNetworkAdapters()

27. ábra: A Get-NetworkAdapter meghívása szekvenciadiagramon

4.6 Az implementálás eredménye

A fejlesztéshez felhasznált környezet és segédeszközök bemutatása után

ismertettem a cmdlet és a modell réteg felépítését és működését. A megvalósítás után

rendelkezésre áll a kész modul, amely 34 osztályt illetve 767 kódsort (loc) tartalmaz, de

teszteléssel ellenőriznem kell, hogy a megfelelő környezetben az elvártaknak

megfelelően működik-e.

36

5. Tesztelés

Az implementálást követően a modul helyes működéséről teszteléssel is meg

kell győződni. A modell réteg ellenőrzésére metódusszintű tesztek írásával van

lehetőség, a teljes modul a célkörnyezetekben (PowerShell 3.0 Windows 7 alatt, illetve

2.0 XP alatt) a legfontosabb tesztesetekre kipróbálva tesztelhető, a működést érdemes

összevetni a meglévő parancssoros hálózatkezelőkével is.

5.1 Beépített validálás

A cmdlet paraméterek alapvető validációjáról (kötelező paraméter meg legyen

adva, objektum típusa egyezzen) szerencsére a PowerShell alapból gondoskodik, ha a

forráskódban megadtuk a paraméter attribútumainak a megfelelő jellemzőket (pl.

Mandatory = true), így ezeknek az ellenőrzéséről nem kell külön gondoskodnunk.

5.2 Metódusszintű tesztek

A modell metódusait tesztek írásával és futtatásával vizsgálhatjuk meg, ezt a

funkciót a Visual Studio biztosítja. A következetesség végett minden modell osztályhoz

készült egy teszt osztály, amely az adott modell metódusaihoz tartalmaz teszteket,

ezeket a TestClass illetve a TestMethod attribútumokkal kell megjelölni. A tesztek

során inicializálunk egyet a megfelelő modell példányból, majd a metódus a megfelelő

paraméterekkel való meghívása után az Assert osztály segítségével ellenőrizzük az

eredmény helyességét.

A tesztek nem minősülnek unit teszteknek, mivel az adaptereken módosítást

végrehajtó metódusok tesztjének sikeres lefutásához szükség van egy adapter nevének

megadására, amin a tesztek futtathatók.

Az adaptereket WMI-on keresztül lekérdező metódus példájában az eredmény a

két kimeneti változóba kerül, amelyeknek a lefutás után tartalmazniuk kell legalább egy

elemet:

[TestMethod]

public void GetNetworkAdapter_GetAdapterDataTest()

{

ManagementObjectCollection networkAdapters,

37

networkAdapterConfigs;

this.getNetworkAdapterModel.GetAdapterData(

out networkAdapters, out networkAdapterConfigs);

Assert.IsNotNull(networkAdapters);

Assert.IsNotNull(networkAdapterConfigs);

Assert.AreNotEqual(0, networkAdapters.Count);

Assert.AreNotEqual(0, networkAdapterConfigs.Count);

}

A tesztek eredményét egy külön ablak mutatja, itt láthatjuk a lefutás idejét és

eredményét minden metódusra. Az első futtatások során még fény derült pár hibára,

amiket így könnyen megtalálhattam és javíthattam:

28. ábra: A futtatott tesztek eredményei az egyik első futás alkalmával

Az adaptereket módosító metódusokhoz adott egy mindig egy bizonyos adaptert

visszaadó statikus tulajdonság, ahol megadhatjuk azt az adaptert, amelyen a teszteket

futtatni akarjuk.

38

5.3 Modulszintű tesztek

Szükség volt a kész modul kipróbálására magában a PowerShellben is, hogy

biztosítani tudjuk, hogy az elvártaknak megfelelően működik.

5.3.1 Tesztesetek

A modul cmdleteit kézzel teszteltem le a legfontosabb esetekre. Valamennyi

módosító parancsot rendszergazdai jogosultsággal futtattam, kivéve ott, ahol ez jelölve

van (ekkor a futásnak hibát kell eredményeznie).

Teszteset Parancs

Minden hálózati adapter listázása Get-NetworkAdapter

A szűrőnek megfelelő nevű hálózati

adapterek listázása

Get-NetworkAdapter

A kiválasztott adapterek letiltásának

megkísérlése rendszergazdai jogosultság

nélkül (hibát eredményez)

Get-NetworkAdapter |

Disable-NetworkAdapter

A kiválasztott adapterek sikeres letiltása Get-NetworkAdapter |

Disable-NetworkAdapter

A kiválasztott adapterek engedélyezésének




Enable-NetworkAdapter

A kiválasztott adapterek sikeres

engedélyezése


Enable-NetworkAdapter

A kiválasztott adapterek újraindításának




Reset-NetworkAdapter

A kiválasztott adapterek sikeres

újraindítása


Reset-NetworkAdapter

Adapter átjáróinak átállítása Get-NetworkAdapter |

Set-DnsClientConfiguration –Gateway

Adapter névszervereinek átállítása Get-NetworkAdapter |

Set-DnsClientConfiguration –

DnsServer

39

Adapter tartományának átállítása Get-NetworkAdapter |


DnsDomain

Adapter DNS utótagok átállítása Get-NetworkAdapter |


DnsSuffix

Az aktív TCP kapcsolatok listázása Get-ActiveTcpConnection

Forgalmi statisztikák minden adapterről Get-IpStat

Forgalmi statisztikák a szűrőnek megfelelő

adapterekről

Get-IpStat

Minden nyitott port listázása Get-Listener

Nyitott TCP portok listázása Get-Listener –Tcp

Nyitott UDP portok listázása Get-Listener -Udp

Távoli fájl letöltése Get-RemoteFile –FileUrl

-SaveAs

5.3.2 Adapterek szűrése

A Get-NetworkAdapter alapértelmezésben több információt mutat az egyes

adapterekről az ipconfighoz és a netsh-hoz képest, de az adatok tetszés szerint szűrhetők

a szűrő cmdletekkel.

29. ábra: A Get-NetworkAdapter alapértelmezett kimenete egy virtuális gépen

40

30. ábra: Az adapterek jellemzői az ipconfig kimenetében

31. ábra: Lekérdezés a netsh-val

5.3.3 Adapterek engedélyezése és letiltása

A letiltás és az engedélyezés kipróbálásához kiválasztunk egy fizikai (azaz a

virtuális gép által fizikainak tekintett) adaptert:

41

32. ábra: A kiválasztott adapter

A letiltáshoz/engedélyezéshez rendszergazdai jogokkal kell rendelkeznünk, a

művelet előtt a -Force paraméter híján megerősítést is kell adnunk. (Az emelt szintű

jogosultság az ablak címsorában is látszik.) Az adapter átadásához célszerű a pipeline-t

használni.

33. ábra: Letiltás rendszergazdaként engedélykéréssel

42

34. ábra: Jogosultság híján nem sikerül a letiltás

35. ábra: A Force használatával nem szükséges megerősítés, a PassThru használatával láthatjuk az

eredményt a kimeneten

36. ábra: A NetEnabled tulajdonságra való szűréssel jobban látható a különbség

A Reset-NetworkAdapter cmdlet egy letiltást és egy engedélyezést futtat le, a

-Verbose kapcsoló használatával ezt a kimeneten is láthatjuk:

43

37. ábra: A Reset-NetworkAdapter működése

5.3.4 Adapterbeállítások módosítása

A Set-DnsClientConfiguration cmdlettel módosítható az adapterek néhány

beállítása, ezek hatása is a -PassThru kapcsoló használatával emelhető ki.

38. ábra: A névszerverek címének átállítása

39. ábra: Az alapértelmezett átjáró átállítása

5.3.5 Egyéb funkciók

A modulban helyet kapott még pár kisebb funkciót ellátó cmdlet is, amelyekkel

portokat listázhatunk vagy forgalmi adatokat kérdezhetünk le.

44

40. ábra: Portok listázása előbb szűrés nélkül, majd protokollok alapján

41. ábra: Forgalmi adatok megjeleítése az adapter nevére való szűréssel

5.4 A tesztelés eredménye

A tesztelés a főbb esetekre a fizikai(nak tekintett) adaptereken sikeresnek

bizonyult.

45

6. Összefoglalás

A dolgozatban egy hálózatkezelő kiegészítő modul megtervezésével és

megvalósításával foglalkoztam a PowerShell modern parancssoros környezethez.

Bemutattam a PowerShell alapvető tulajdonságait, hogy mitől nyújt többet a

hagyományos parancssoros eszközöktől, és hogy milyen módon lehet a környezetet

kiegészíteni, illetve ismertettem a jelenlegi hálózatkezelési lehetőségeket a klasszikus

parancssorok esetében. A kutatás során arra a következtetésre jutottam, hogy van igény

egy ilyen kiterjesztés elkészítésére.

A tervezés során definiáltam az elkészítendő modul főbb funkciót, és hogy a

kiegészítőnek milyen, a környezet támasztotta irányelveknek kell megfelelnie a helyes

működéshez. A cél egy a PowerShell környezetbe teljesen illeszkedő, mégis a korábbi

eszközökhöz hasonlóan hatékony modul létrehozása volt, ez indokolta, hogy a

kiegészítő egy a funkciókat cmdletek formájában tartalmazó modulként álljon

rendelkezésre.

Az implementálásnál ismertettem a felhasznált eszközöket és a funkciók

részletesebb megvalósítását, külön kitérve a modul kétrétegű szerkezetére, és az egyes

rétegek szerepére. A PowerShell környezet fejlesztői szemmel nézve is kényelmesnek

bizonyult, a kiegészítő és a cmdletek létrehozását részletes online dokumentáció

segítette.

A megvalósítást követően teszteltem az elkészült modult, elsőként az egyes

metódusok helyes működését vizsgáltam. Ezek a tesztek azonban a futtató gép fizikai

adaptereitől nem teljesen függetlenek, így továbbfejlesztési lehetőségként adódik egy

valódi unit teszteket futtató tesztkörnyezet hozzáadása is. A kész parancsokat magában

a PowerShellben is kipróbáltam, és a fontosabb esetekre be is mutattam azok hatását és

kimenetét, illetve az eredményt összevetettem pár jelenlegi parancssoros eszközzel.

Az elkészült modul nem fedi le a teljes hálózatkezelési funkcionalitást, így ezen

a téren adott a bővítési lehetőség, hogy a Windows 8-on elérhető új hálózatkezelő

cmdletekhez hasonló kiterjedt funkcionalitást nyújthasson.

46

Irodalomjegyzék

Az online hivatkozások 2013. április 30-án elérhető oldalakra mutatnak.

[1] Soós Tibor: „Microsoft PowerShell 2.0 rendszergazdáknak – elmélet és

gyakorlat” 2. kiadás, 2010.

http://mek.oszk.hu/10400/10402/10402.pdf

[2] Szalay Márton: „PowerShell-példatár”, SZAK Kiadó, 2008.

[3] Microsoft Developer Network (MSDN) - Installutil.exe (Installer Tool)

http://msdn.microsoft.com/en-us/library/50614e95.aspx

[4] Microsoft Developer Network (MSDN) - Writing a Windows PowerShell

Module

http://msdn.microsoft.com/en-us/library/dd878310.aspx

[5] Microsoft Developer Network (MSDN) - NetShell

http://msdn.microsoft.com/en-

us/library/windows/desktop/ms708353%28v=vs.85%29.aspx

[6] CodePlex - 2.4.1 PowerShell Community Extension

http://pscx.codeplex.com/

[7] Microsoft Developer Network (MSDN) - Cmdlet Overview

http://msdn.microsoft.com/en-us/library/ms714395(v=vs.85).aspx

[8] Microsoft Developer Network (MSDN) - Cmdlet Development Guidelines

http://msdn.microsoft.com/en-us/library/ms714657.aspx

[9] Microsoft Developer Network (MSDN) - Cmdlet class


us/library/system.management.automation.cmdlet(v=vs.85).aspx

[10] Microsoft Developer Network (MSDN) - PSCmdlet class


us/library/system.management.automation.pscmdlet(v=vs.85).aspx

[11] Microsoft Developer Network (MSDN) - Writing a Windows PowerShell

snap-in:


us/library/windows/desktop/ms714453(v=vs.85).aspx

http://mek.oszk.hu/10400/10402/10402.pdfhttp://msdn.microsoft.com/en-us/library/50614e95.aspxhttp://msdn.microsoft.com/en-us/library/dd878310.aspxhttp://msdn.microsoft.com/en-us/library/windows/desktop/ms708353%28v=vs.85%29.aspxhttp://msdn.microsoft.com/en-us/library/windows/desktop/ms708353%28v=vs.85%29.aspxhttp://pscx.codeplex.com/http://msdn.microsoft.com/en-us/library/ms714395(v=vs.85).aspxhttp://msdn.microsoft.com/en-us/library/ms714657.aspxhttp://msdn.microsoft.com/en-us/library/system.management.automation.cmdlet(v=vs.85).aspxhttp://msdn.microsoft.com/en-us/library/system.management.automation.cmdlet(v=vs.85).aspxhttp://msdn.microsoft.com/en-us/library/system.management.automation.pscmdlet(v=vs.85).aspxhttp://msdn.microsoft.com/en-us/library/system.management.automation.pscmdlet(v=vs.85).aspxhttp://msdn.microsoft.com/en-us/library/windows/desktop/ms714453(v=vs.85).aspxhttp://msdn.microsoft.com/en-us/library/windows/desktop/ms714453(v=vs.85).aspx

47

[12] Microsoft Developer Network (MSDN) - Writing a custom Windows

PowerShell snap-in


us/library/windows/desktop/ms714437(v=vs.85).aspx

[13] CodePlex - PowerShell Visual Studio 2008 templates

http://psvs2008.codeplex.com/

[14] CodePlex - StyleCop

http://stylecop.codeplex.com/

[15] Microsoft Developer Network (MSDN) - FxCop

http://msdn.microsoft.com/library/bb429476.aspx

http://msdn.microsoft.com/en-us/library/windows/desktop/ms714437(v=vs.85).aspxhttp://msdn.microsoft.com/en-us/library/windows/desktop/ms714437(v=vs.85).aspxhttp://psvs2008.codeplex.com/http://stylecop.codeplex.com/http://msdn.microsoft.com/library/bb429476.aspx

48

Függelék

A melléklet tartalma

A mellékletként beadott ZIP archívum tartalmazza az elkészült modult (Module

mappa) és annak forráskódját Visual Studio projekt formájában (Project mappa).

Használati útmutató

A melléklet Module\NetworkingModule mappáját másoljuk be Windows 7/8

alatt a „C:\Users\\Documents\WindowsPowerShell\Modules”,

Windows XP esetében a „C:\Documents and Settings\\My

Documents\WindowsPowerShell\Modules” helyre.

Ezután meg kell jelennie az elérhető modulok közt, amit például a Get-Module

*Networking* -ListAvailable paranccsal ellenőrizhetünk, importálni az Import-

Module NetworkingModule meghívásával tudjuk.

42. ábra: A NetworkingModule importálása

Ha szeretnénk, hogy minden indításnál automatikusan megtörténjen az

importálás, a parancsot helyezzük el a saját profilszkriptünkben (WindowsPowerShell

mappa, Microsoft.PowerShell_profile.ps1 fájl). A profilszkript használatához a

szkriptfuttatást engedélyezni kell a Set-ExecutionPolicy cmdlettel.

Magukról a cmdletekről a Get-Help meghívásával tudhatunk

meg többet.

Hálózatkezelő függvénykönyvtár készítése...

Documents

Transcript of Hálózatkezelő függvénykönyvtár készítése...