hálózatkezelő függvénykönyvtár készítése...
TRANSCRIPT
-
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
megkísérlése rendszergazdai jogosultság
nélkül (hibát eredményez)
Get-NetworkAdapter |
Enable-NetworkAdapter
A kiválasztott adapterek sikeres
engedélyezése
Get-NetworkAdapter |
Enable-NetworkAdapter
A kiválasztott adapterek újraindításának
megkísérlése rendszergazdai jogosultság
nélkül (hibát eredményez)
Get-NetworkAdapter |
Reset-NetworkAdapter
A kiválasztott adapterek sikeres
újraindítása
Get-NetworkAdapter |
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 |
Set-DnsClientConfiguration –
DnsDomain
Adapter DNS utótagok átállítása Get-NetworkAdapter |
Set-DnsClientConfiguration –
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
http://msdn.microsoft.com/en-
us/library/system.management.automation.cmdlet(v=vs.85).aspx
[10] Microsoft Developer Network (MSDN) - PSCmdlet class
http://msdn.microsoft.com/en-
us/library/system.management.automation.pscmdlet(v=vs.85).aspx
[11] Microsoft Developer Network (MSDN) - Writing a Windows PowerShell
snap-in:
http://msdn.microsoft.com/en-
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
http://msdn.microsoft.com/en-
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.