Intelligens rendszerfelügyelet - házi feladatok

Ez az oldal a házi feladatokkal kapcsolatos tudnivalókat foglalja össze.

Általános tudnivalók

Célok

A házi feladaton a hangsúly azon van, hogy egy adott technológiát (LDAP, WMI, naplózás...) önállóan ismerjenek meg a hallgatók, majd a kiadott problémához egy igényes, mérnöki megoldást készítsenek el. Ezért hangsúlyos a technológia kipróbálása egy önálló munkában, valamint a jó minőségű kód elkészítése.

Kérdések: a feladatokkal kapcsolatos kérdéseket a Q&A oldalra várjuk.

Feltöltés formátuma

A megoldásunkhoz tartozó fájlokat és könyvtárakat egy darab ZIP fájlban kell feltölteni (nem RAR, nem gzip!).

A ZIP-en belül a következő könyvtáraknak kell szerepelniük (közvetlenül ezek szerepeljenek, ne legyenek ezek még egy könyvtárba berakva):

dist HF1, HF2 esetén üres, HF3 esetén az alkalmazás lefordított, kész változata
src a megoldás forrása (szkript vagy forrásfájlok)
test a teszteléshez használt szkriptek, bemenetek, adatok, kapott kimenet, esetleg képernyőképek

A feltöltendő tömörített állományt érdemes azon a gépen vagy virtuális gépen elkészíteni, ahol megoldottuk a feladatot (tapasztalat szerint a szkriptfájlokban a kódolás és egyes karakterek néha elromlanak, ha pl. Linux és OS X között mozgatjuk drag&drop segítségével vagy felhő tárhelyre töltjük fel).

Pontozás

Az egyes házi feladatokra 0-10 pontot lehet kapni, a kapott pont értelmezésében segít a következő lista:

  • 10 pont: kiváló házi feladat;
  • 8-9 pont: jó házi feladat, néhány kisebb hiba volt benne, amire később érdemes lehet figyelni;
  • 6-7 pont: súlyosabb hibák és/vagy sok kisebb hiba volt a házi feladatban, érdemes a későbbi feladatokra több figyelmet fordítani;
  • 4-5: sok súlyos hiba is lehetett benne vagy alapvetően nem jó minőségű megoldás;
  • 0-3: a házi feladat nincs elfogadva, nagyon súlyos hibák (nem fut, a feladat valami fontos kikötését nem teljesíti stb.) vagy nagyon rossz minőségű megoldás (pl. olvashatatlan kód).

Természetesen ezek csak irányelvek, minden feladat értékelése egy egyéni helyzet. Abban, hogy mi számít súlyos hibának, a következő ellenőrző lista segít.

Ellenőrző lista

A következő ellenőrző listán minden leadás előtt érdemes végigvenni.

MUST (kötelező, súlyos hibát jelent)
SZ1 Szintaktikai hibás megoldást nem értékelünk.

A Java/.NET kódok esetén a javítás során a leadott kódot mindig teljesen újrafordítják a javítók. Így leadás előtt érdemes ellenőrizni azt, hogy tényleg minden fájlt beadunk-e, ami a fordításhoz kell, és esetleg más könyvtárba rakva/más gépen fordítva is lefordul a kód.

Ugyanígy szkript esetén, ha a feladatkiírásban megadott példa paraméterezés esetén a parancsértelmező szintaktikai hibára panaszkodik (ismeretlen kulcsszó, hiányzó zárójel stb.), akkor általában nem is nézzük tovább a megoldást.

Két tipikus hiba szokott lenni ezzel kapcsolatban. Az egyik, hogy a saját környezetben tényleg lefordult, azonban nem dokumentáltuk pontosan, hogy milyen verziójú fordítót vagy parancsértelmezőt használtunk (nem elég az, hogy PowerShell kell a szkripthez, hanem adjuk meg a pontos verziót is, pl. PowerShell 3.0).

A másik tipikus hiba, hogy a leadás előtt egy perccel még átformázzuk kicsit a kódot, pár sortörést rakunk bele, majd nem futtatjuk le még egyszer a szkriptet az összes teszttel. Ne tegyük! Ne adjunk le olyan módosított kódot, amit nem fordítottunk és teszteltünk le újra!

SZ2 A programnak pontosan a specifikált interfészt kell nyújtania (elnevezés, bemeneti paraméterek neve és száma stb.)

A szkriptnek, programnak betűre pontosan azt a fájlnevet és paraméterelnevezést kell használnia, ami a kiírásban van. Hasonlóan a be- és kimeneti fájloknak is a megadott formájúnak kell lennie. [A paraméterezésnél egy kivétel van: a specifikációba nem írjuk bele Python esetén a -h opciót (súgó), PowerShell esetén pedig a CommonParameters nevű opciókat (-Debug, -Verbose stb.), ezek szerepelhetnek a megoldásban, hisz ezeket a keretrendszer adja.]

A külső interfész pontos megvalósítása az egyik legkritikusabb pont egy programnál, ez alapján tudják majd mások használni a programunkat. Ha nem a specifikált elnevezést vagy paraméterezést használjuk, akkor nem fogják tudni használni a programunkat. Ráadásul a házi feladatok javítása részben automatizáltan történik, így például ha elírjuk a szkript nevét vagy valamelyik paraméterét, akkor a javítónak kézzel kell majd nekiállni futtatni a megoldásunkat, amit nagyon nem szeretünk.

Többször is ellenőrizzük, hogy pontosan a kiadott specifikációt valósítjuk-e meg, és a feladatkiírásban megadott módon futtatható-e a megoldásunk!

SZ3 A kódnak nem csak a fejlesztői környezetből indítva kell futnia.

A kódot mindig ellenőrizzük úgy is, hogy egy friss parancssorból próbáljuk meg kézzel elindítani.

Tipikus hiba, hogy a fejlesztői környezet beállít még valamit vagy benne marad egy korábban definiált változó, ami miatt később a javítás során nem fog a megoldásunk futni. Az éles környezetben legtöbbször nincs Visual Studio, nincs PowerGUI, így a fejlesztés során készüljünk fel arra, hogy így is fusson a megoldásunk.

SZ4 Használjunk nevesített paramétereket.

Ez azt jelenti, hogy script.ps1 input.txt output.txt helyett a paraméterezés ilyen: script.ps1 -i input.txt -o output.txt. A paraméterek sorrendje felcserélhető (tehát script.ps1 -o output.txt -i input.txt ugyanezt eredményezi), és a nevükkel (jelen esetben i és o) tudunk rájuk hivatkozni. Ezt ne az argumentum sztring kézi darabolásával érjük el, hanem használjuk az adott nyelv támogatását rá (Python esetén az argparse modul, PowerShell esetén a param kulcsszó, lásd a kapcsolódó előadásokat).

Így sokkal robusztusabb lesz a megoldásunk, könnyebben lesz használható bonyolultabb paraméterezés esetén is, és célzottabb hibaüzeneteket tudunk majd adni.

SZ5 A program ne tegyen olyat, amire nem kértük.

Tipikus eset sajnos, hogy egy távoli lekérdezést megvalósító szkriptet kell írni, a szkript pedig mindenféle jelzés nélkül elkezdi az adott gép beállításait módosítani (pl. tűzfalszabályokat vesz fel). Ez nem szerencsés, mert a lekérdező szkriptet lehet, hogy olyan felhasználó nevében futtatjuk, aki nem rendszergazda a helyi gépen, így például nincs joga ezt megtenni. Másrészt ha gyakran használjuk a szkriptet, akkor feleslegesen sokszor próbálja meg elvégezni a beállításokat. Szerencsésebb, ha a szükséges beállítás lépéseire van egy külön szkript, vagy pontosan dokumentáljuk azokat, vagy a lekérdező szkript csak ellenőriz és hibát jelez legfeljebb.

Hasonlóan problémás, hogy ha a szkript például törli a képernyőt a futás előtt. Ez segíti az adott szkript kimenetének értelmezését, de mi van, ha a felhasználó számára fontos adat volt a képernyő korábbi részén?

SZ6 Ne használjunk bedrótozott (fájl)neveket.

A kódba beégetni fájlneveket, elérési utakat nem jó szokás. Ha ideiglenes fájlokat használunk, akkor annak ne a temp.txt nevet használjuk, és ne írjunk bele vagy töröljük gondolkodás nélkül. Mi van akkor, ha az adott könyvtárban már volt egy temp.txt? A felhasználó nem fog örülni, ha azt a szkript a lefutása után kérdés nélkül törli. Lehet egzotikus neveket választani ilyenkor, de szebb és jobb megoldás, ha az adott programozási környezet beépített támogatását használjuk (pl. Linuxon az mktemp parancs, Windowson a New-TemporaryFile cmdlet generál egy garantáltan egyedi, még nem létező fájl vagy könyvtárnevet).

A másik gond a beégetett nevekkel, hogy ha több helyen is használjuk a kódban, akkor később egy változtatás során biztos elfelejtjük valamelyik helyen átírni. Érdemes megszokni, hogy kiemeljük az ilyen neveket változókba vagy a kód elején definiált konstansokba.

SZ7 A felhasználótól kapott bemeneti paramétereket mindig ellenőrizzük.

Próbáljunk meg szintaktikai (pl. megadták-e az összes kötelező paramétert, számot adott meg, ahol számot várunk) és szemantikai (pl. nézzük meg, hogy létezik-e a bemeneti fájl, mielőtt olvasni akarunk belőle) ellenőrzéseket is végezni, mielőtt felhasználjuk a bemenetről kapott értékeket.

Készüljünk fel arra, hogy a bemenetről bármilyen, akár rosszindulatú értéket is kaphatunk. Ha a szkriptünk egy adott paraméterezésre sorra dobja a nullával osztási meg kapcsolódási hibákat, és ötször próbál csatlakozni a nyilvánvalóan hibásan megadott távoli szerverhez, akkor az nem jó kifogás, hogy de a szkript súgójában le volt írva, hogy mi a helyes paraméterezés. Ugyanígy nincs kifogás arra, hogy ha például egy .NET vagy Java  program nem kezelt kivételt dob, és az visszajut a felhasználói felületre. A programunk kódjában gondoskodni kell a hibás bemenetek kezeléséről.

SZ8 A lekérdezések adatforgalmát gondoljuk át, általában szűrjünk a távoli gépen.

Ha a programunkban adatokat kell lekérdeznünk (pl. címtárból, CIMOM-ból vagy adatbázisból), a kódolás elkezdése előtt gondoljuk át az adatforgalmat, a lekérdezés erőforrásigényét és, hogy ténylegesen mire is van szükségünk.

Sokan nem figyelnek a kód alapvető hatékonyságára: enumerate műveletet használnak, amikor tulajdonképpen csak egy konkrét vagy néhány példányra volt szükség. A másik tipikus hiba, hogy ugyanazt a lekérdezést a kódban akár háromszor is lefuttatják egymás után közvetlenül, holott ugyanazt az eredményt adta vissza mind, és így elég lett volna az első eredményét eltárolni, majd kiszedni belőle a szükséges információt. Ha jó szoftverfejlesztők szeretnénk lenni, akkor figyelünk az ilyenekre is.

Nézzünk egy egyszerű példát. Egy távoli gépről kérdezzük le, hogy mik a Hotfix típusú javítások.

1. eset: teljesen buta lekérdezés, mindent lekérünk távolról, és kliens oldalon szűrűnk

Measure-Command -Expression {gwmi win32_quickfixengineering -computer server1 |
 ? {$_.description -eq "Hotfix"}}

Eredmény: 118653 Byte hálózati forgalom, 858 ms futási idő

2. eset: szerver oldalon szűrünk, a kliensre már csak a szükséges rekordokat kérjük le

Measure-Command -Expression {gwmi win32_quickfixengineering -computer server1 
 -filter 'description = "Hotfix"'}

Eredmény: 24807 Byte hálózati forgalom, 322 ms futási idő. A futási idő kevesebb, mint a fele, a hálózati forgalom az előző ötöde.

3. eset: ha tudjuk, hogy melyik tulajdonságok kellenek csak az eredményből, akkor még pontosabb szűrést hajthatunk végre

Measure-Command -Expression {gwmi -computer server1 -query
'select hotfixID from win32_quickfixengineering where description = "Hotfix"'}

Eredmény:  19451 Byte hálózati forgalom, 326 ms futási idő. A hálózati forgalom még tovább csökkent.

(Természetesen ez itt nem rendes mérés, mert többször kéne megismételni, zavaró hatásokat ki kéne küszöbölni, a cél pusztán csak a szemléltetés volt, hogy minimális odafigyeléssel is könnyen javíthatjuk az általunk készített kódot.)

SZ9 A távoli fél hibájára fel kell készülni.

Ha a programunk távoli gépet kérdez le, akkor mindig készüljünk fel arra, hogy a lekérdezés sikertelen.

Sok leadott feladatban egyáltalán semmi ellenőrzés nem szokott lenni, az első kérés meghibásodása után is végrehajtja a szkript a további öt felesleges lekérdezést. Ráadásul a távoli lekérdezés nagyon sok minden miatt meghibásodhat (nem létezik a távoli gép, nem feloldható DNS névvel volt megadva, nem figyel az adott porton, nem volt jó a jelszó, a távoli CIMOM hibát adott vissza...), ezeket gondoljuk végig és ellenőrizzük a tesztelés során. Később bármilyen rendszert is fejlesztünk, ahol van valami távoli művelet (mobil, felhő vagy beágyazott alkalmazás), sosem bízhatunk abban, hogy a távoli művelet sikeresen fog lefutni.

SZ10 Legyenek részletes, megtervezett tesztesetek.

Az elkészült megoldás tesztelése nem azt jelenti, hogy a fejlesztés során ad-hoc módon kipróbálgatjuk különböző bemenetekkel. A program működésének ellenőrzését, az elkészült megoldás minőségének értékelését akkor hívhatjuk tesztelésnek, ha valami átgondolt, szisztematikus módszert használunk a tesztelési célok és tesztesetek kiválasztására.

Sokféle módszer létezik erre, a feladatban elég valami egyszerűbbet használni, például szedjük össze, hogy milyen típusú helyes és helytelen bemeneteket kaphat a program, milyen főbb esetei vannak a kimenet előállításának, és ez alapján származtassunk teszteseteket.

Olvassuk el ezt mindenképp: Tesztelési alapismeretek összefoglalása

SHOULD (ajánlott, kevésbé súlyos hibát jelent)
SZ20 Hibakezelés Igazodjunk az adott környezet megszokott hibakezelési ajánlásaihoz. Például a beépített PowerShell cmdleteket általában kivételt (exception) dobnak hiba esetén, ezt követve a mi kódunkat is könnyebb később használni, mert igazodik a platform megszokott működéséhez.
SZ21 Használjunk értelmes, differenciált hibaüzeneteket.

Írjunk olyan hibaüzeneteket, amik segítenek a felhasználónak. Például ha rossz valamelyik bemeneti paraméter értéke, akkor ne csak azt írjuk ki, hogy „Hibás bemenet!”, hanem mondjuk is meg, hogy melyik paraméter, melyik értéke, miért hibás. (Ilyen szempontból például a klasszikus UNIX parancsok sem a legjobb példák, mert ott sokszor hiba esetén csak a használati útmutatót írja ki program, szerintünk jobb megoldás a pontos hibajelzés és a használati útmutató kiírása.)

Ne csak a szöveges hibaüzenetekre figyeljünk oda, hanem például a program visszatérési értékére is. Érdemes más-más hiba esetén más-más hibakóddal kilépni, így ha programból akarják felhasználni a mi kódunkat, akkor is könnyű a kimenetét értelmezni, feldolgozni.

SZ22 Kerüljük a kód duplikálását. Próbáljuk kerülni az egy-egy hosszabb vagy bonyolultabb kód másolgatását. Ha például egy bonyolult paraméterezésű lekérdezés három helyen is szerepel minimális eltéréssel, akkor, ha később gyorsan változtatunk valamit rajta, akkor általában kimarad valamelyik másolat. Próbáljuk inkább kiemelni a közös részeket, és a különböző részeken csak a változtatásokat hozzárakni. Ez később nagyobb rendszereknél is hasznos lesz, lásd itt.
SZ23 Legyen fejkomment minden egyes fájlban.

Mindegyik leadott szkriptnek vagy forrásfájlnak legyen fejkommentje, ami tartalmazza a fájl fontosabb információit (szerző, elkészítés ideje, leírás, paraméterek, stb.).

Érdemes megszokni, mert így később sokkal könnyebb lesz visszakövetni az általunk írt forráskódban, hogy mi az az adott fájl, kit kell keresni vele kapcsolatban. Sok céges belső kódolási konvenció vagy publikus ajánlás tartalmaz egyébként ilyesmit.

SZ24 Legyen kommentezve a kód.

A kód legyen érthető, követhető kommentekkel ellátva. Felesleges általában minden sorhoz kommentet írni, de a kommentek segítsenek a kód főbb egységeit elkülöníteni, egyes bonyolultabb vagy szokatlanabb utasítást megérteni.

Érdemes kipróbálni, hogy előveszünk egy általunk egy évvel ezelőtt írt kódot, és megpróbáljuk csak a kód alapján felidézni a működését. Ez legtöbbször nem triviális feladat. Olyan döntések, amik akkor egyértelműnek tűntek, most már hosszú gondolkodást és keresgélést igényelhetnek. Egy-egy komment sokat segíthet ilyenkor.

SZ25 Használjunk angol változó és függvényneveket.

Ha megszokjuk, hogy magyar nyelvű változókat használunk, akkor a világ nagy részének eleve megnehezítjük, hogy megértse a kódunkat.

A megjegyzések lehetnek magyar nyelvűek, bár az informatikában talán ez sem túl jó szokás. Gondoljunk bele, mennyire segítene minket egy norvég nyelvű komment. Ha mégis magyar kommentet használunk, akkor érdemes az ékezeteket kerülni, vagy legalább bizonyosodjunk meg róla, hogy a karakterkódolást jól állítottuk be, és más platformokon is jól jelenik majd meg a szöveg.

A UI szövegek lehetnek magyar nyelvűek, ez éles környezetben is nyilván attól függ, hogy milyen célközönség számára fejlesztünk.

SZ26 Ügyeljünk a kód helyes tagolására.

Egy szkript kód is ugyanolyan kód, mint bármi más programozási nyelven írt kód. Ennek megfelelően a helyes behúzásokra ügyeljünk, ez nagyban megkönnyíti a kód olvasását. Sok helyen a while / if után nem volt bentebb kezdve a kód, és így nagyon nehéz átlátni a struktúrát.

Erre nem jó kifogás a nem volt a végén elég időm, mert már rögtön a fejlesztés közben érdemes tagolni a kódot. Ha leírunk egy foreach kulcsszót és rakunk egy nyitó zárójelet, akkor a következő sort bentebb kezdjük. (Figyeljünk arra is, hogy vagy mindenhol TAB-ot vagy mindenhol szóközöket használjunk a behúzásra.) Ha nincs rendesen tagolva a kód, akkor az olvasónak az azt jelzi, hogy a kód írója se értette a kód szerkezetét.

SZ27 Használjuk ki az adott környezet lehetőségeit. Egy-egy részfeladat megoldása előtt érdemes legalább minimálisan körbenézni, hogy van-e az adott fejlesztési környezetben arra beépített támogatás. Például PowerShellben CSV fájl előállítására ott az Export-Csv vagy XML készítésére a ConvertTo-Xml. Ha valaminek a megoldásához első körben sztringekkel kéne bűvészkedni, az tipikusan jó jelzés arra, hogy érdemes picit utánanézni a feladatnak a beépített támogatások között.
SZ28 Használjunk beszédes változóneveket.

Nyugodtan használjunk hosszabb, de beszédes változóneveket. Gondoljunk mindig arra, hogy a kódot csak egyszer írjuk le, de olvasni sokkal többször fogják, segítsük a kódunk megértését!

Volt olyan leadott megoldás, ahol a változónevek sorban az $a, $b, $c neveket kapták. Máshol pedig a $newG és $Gnew változóneveket is használta, természetesen két teljesen különböző dolgot tartalmaztak ezek. Mondani sem kell, hogy teljesen olvashatatlan lett a kód.

Virtuális gépek

A házi feladatok megoldásához szükséges virtuális gépek elérhetőek a VCL rendszerben és néhány esetben offline használatra is ezen az oldalon, ahol egyértelműen feltüntettük, hogy melyik házi feladathoz melyik virtuális gépek tartoznak.

HF0 - Gyakorlás

A 0. házi feladat opcionális, nem számít bele a teljesítendő feladatok közé, ezt nem pontozzuk. A HF0 beadása nem jelent később semmiféle előnyt, és kihagyása semmiféle hátrányt.

A célja csupán annyi, hogy meg lehessen ismerkedni a házi feladatok beadására szolgáló rendszerrel és a később használandó szkript nyelvekkel.

  • Python: a 0PY feladatot Python3 segítségével kell megoldani, ehhez segítségként elérhető egy Fedora virtuális gép a VCL rendszerben, és offline használatra ezen az oldalon.
  • PowerShell: a 0PS feladatot PowerShell 5.0 segítségével kell megoldani, ez a verzió érhető el alapértelmezetten a Windows 10 rendszerekben. Ehhez lehet saját gépet használni vagy pedig a VCL rendszerben elérhető egy virtuális gép.

HF1 - Címtárak

  • Olvassuk végig és végezzük el a Címtárak kezelése gyakorlat feladatait.
  • Mindegyik feladat esetén bõvítsük saját elemekkel a címtárakat, és a megoldást már így teszteljük!

OpenLDAP + Python

  • A feladatok megoldásához letölthető egy Fedora VMware virtuális gép ezen az oldalon vagy használható a VCL rendszerben. Részletes használati útmutatót a virtuális gép mellé csomagolt README fájl tartalmaz (ebben vannak a szükséges belépési jelszavak és LDAP felhasználók).
  • A feladatok megoldása előtt érdemes megvizsgálni az LDAP címtár tartalmát, majd átgondolni, pontosan milyen eredményt is várunk. Az LDAP adatbázis megtekinthetõ a gépre telepített Apache Directory Studio segítségével. Az adatbázisstruktúra és cél megismerése után próbáljuk ki az elképzelt algoritmus egyes részeit pusztán csak a parancssori felületen: próbáljunk egyszerû lekérdezéseket, kiíratásokat és mindazon építőköveket, melyekre a feladat megoldása során szükség lehet. Ha minden eszközt magabiztosan alkalmazunk, akkor álljunk neki csupán a komplex szkript elkészítésének. Figyeljünk a fenti táblázatban lévõ követelményekre (fejkomment, hibakezelés, stb.) betartására és a feladatspecifikációban szereplõ formai elvárásokra (paraméterek sorrendje, szkript fájl neve, stb.).
  • Az elkészített szkriptet leadás elõtt feltétlenül ellenõrizzük a kiadott Fedora virtuális gépen, hiszen a javítók ebben a környezetben javítják.

Active Directory + PowerShell

  • A feladatok megoldásához egy Windows Server 2016-ot futtató virtuális gép elérhető a VCL rendszerben vagy pedig letölthető ezen az oldalon.
    • Figyelem: a VCL-ben elérhető gépen a bejelentkezéskor a tartománynevet (a \felhasználó előtti részt) át kell írni IRFHF-re az alapból felajánlott VCL-*** névről!
  • A feladatok megoldása előtt érdemes ismerkedni az Active Directory felületével. Az előadás alapján próbáljuk ki az Active Directory Users and Computers konzolt, hozzunk létre új elemeket. Ha nagyjából eligazodunk már a címtárban, akkor az AD Explorer segítségével nézzük meg a címtár belső felépítését. Nézzük meg az egyes elemek LDAP neveit és attribútumait. Ezután az előadásban és a segédletben szereplő példakódok alapján próbáljuk ki, hogy hogyan lehet egyszerű lekérdezéseket végrehajtani PowerShellbõl. Ha mindezzel készen vagyunk, akkor álljunk csak neki a feladat megoldásánák.

HF2 - Konfigurációkezelés

  • A kapcsolódó technológiákkal való ismerkedésben segít a részletes konfigurációkezelés gyakorlati segédlet.
  • A megoldás teszteléséhez legalább egy távoli gépet kell használni, ez lehet fizikai vagy virtuális gép is. Javasolt legalább két távoli gépet alkalmazni, hogy a szkript működését pontosabban tudjuk ellenőrizni.
  • A feladatnak jelentős része a konfigurációkezelési technológiák megismerése és beállítása, a megfelelő tesztkörnyezet összeállítása, ezeknek a részleteit (tűzfal szabályok és kivételek, távoli hozzáférés beállítása és menete, stb.) érdemes feljegyezni egy szöveges fájlba, és azt is beadni a szkripttel együtt!
  • Két különböző protokollt ismertünk meg (CIM-XML, WS-Management), amikhez teljesen más eszközök és beállítások tartoznak. Ne keverjük ezeket, figyelmesen olvassuk el a házi feladat kiírásunkat, hogy melyiket kell majd ezek közül használnunk!

Linux (Pegasus, openwsman, Python)

  • A feladat megoldásához használható Fedora virtuális gép letölthető ezen a linken vagy pedig a VCL rendszerben foglalalható. A beadott szkriptnek ezen a gépen kötelező futnia, de természetesen lehet más gépet is használni a fejlesztéshez.

A feladatok megoldásának érdemes a következő módon nekikezdeni:

  • Nézzük át a konfigurációkezeléssel kapcsolatos előadást, és értsük meg mire jó a CIM, hogyan néz ki egy CIM osztály sémája, teljes elérési útja. A wbemcli és az YAWN eszköz segítségével ismerkedjünk a gépen lévő providerek által visszaadott információval.
  • Próbáljunk összerakni egy két gépből álló környezetet. Minden beállítást még itt menet közben írjunk fel magunknak, később ezeket nehéz lesz visszakövetni.
  • Végezzünk el egy-két egyszerűbb lekérdezést a két gép között.
  • Ha ez működik, akkor kezdjünk csak neki a feladat megoldásának a ténylegesen szükséges osztályok kikeresésével, majd a megoldás implementálásával.

Windows (WMI, WinRM, PowerShell)

  • A feladathoz fogalható Windows 10 virtuális gép a VCL rendszerben. Ha a feladat előírja Linux rendszer futtató távoli gép használatát is, akkor a fentebb emített Fedora virtuális gépet használjuk.

A feladat megoldásának a következő módon érdemes nekikezdeni:

  • Nézzük át a konfigurációkezelés alapok és a WMI előadásokat. Értsük meg, hogy mire jó a CIM, hogyan néz ki egy CIM osztály sémája, teljes elérési útja, hogyan épül fel a WS-Management protokoll.
  • Tanulmányozzuk a kapcsolódó cmdletek súgóját és leírását (pl. Set-WSManQuickConfig, Get-CimInstance, man about_remoting, man about_WSMAN).
  • Próbáljunk ki pár egyszerűbb lekérdezést a Get-CimInstance segítségével. Használjuk a PowerShell WMI Explorert a rendelkezésre álló osztályok felderítésére.
  • Próbáljunk összerakni egy két gépből álló környezetet (közben folyamatosan írjuk magunknak a beállításokat): figyeljünk a tűzfalbeállításokra, nézzük meg pontosan milyen WinRM listener jön létre, értsük meg, hogy mire jó a TrustedHosts és mikor kell használni stb.
  • Végezzünk el pár egyszerű lekérdezést a két gép között.
  • Ezután kezdjük csak el megírni a végleges szkriptet.

HF3 - Felügyeletre tervezés

  • A házi feladatban használatos technológiákat részletesen a "Felügyeletre tervezés" segédlet mutatja be.
  • Az UML modellek elkészítéséhez tetszőleges UML modellező eszköz használható (de modellező eszközt használjunk, és ne rajzprogramot!).
  • Bár az elkészült alkalmazások lefordított változatát is le kell adni, az értékeléskor mindig a forrásból teljesen újrafordított változatot ellenőrizzük. Ezért mindenki különösen figyeljen arra, hogy ne csak a saját gépén forduljon az alkalmazás, és legyen egyértelmű utasítás / szkript a fordításra.
  • Figyeljünk arra, hogy az src könyvtárban tényleg csak forrásállományok legyenek (tehát lefordított binárisok, class fájlok ne), így nem lesz feleslegesen nagy a feltöltendő állomány mérete.
  • A VCL rendszerben foglalható egy Windows 10 virtuális gép, amire a JDK 1.8, .NET FW 4.5, StyleCop és az Enterprise Library 6 már fel van telepítve.

Java platform, JMX

  • Mivel távfelügyeleti megoldás kialakítását célozzuk meg, a módosított szoftvert érdemes majd egy virtuális gépben futtatni; ennek megfelelően a fejlesztést is akár érdemes a virtuális gépben végezni.
  • A kód fejlesztéséhez Oracle JDK-t használjunk, és erősen javasolt 32 bites Java használata (64 bites operációs rendszer esetén is).
  • Ne felejtsük el az is megadni, hogy hogyan lehet az alkalmazáshoz távolról csatlakozni.

.NET platform

  • A gyakorlati útmutató részletesen foglalkozik a környezet kialakításával és a felhasználandó technológiákkal, a kiadott ConsoleGuessGame mintaalkalmazás pedig konkrét példát mutat ezek használatára (ezektől el lehet, és néhány helyen el is kell térni a feladat megoldása során, mivel ott egy más típusú alkalmazást kell majd kiegészíteni).
  • A megoldást tetszőleges fejlesztői környezetben el lehet készíteni (Notepad2, ingyenes Visual Studio Express, MSDNAA-ból elérhető Visual Studio stb.). Azonban figyeljünk arra, hogy a megoldást olyan gépen fogjuk újrafordítani, ahol nincsen Visual Studio, csak a .NET Framework 4.5 beépített MSBuild.exe programját használjuk majd.