Skriptovací jazyky - PowerShell v praxi

Bankovní institut vysoká škola Praha Katedra informačních technologií a elektronického obchodování

Skriptovací jazyky - PowerShell v praxi Bakalářská práce

Autor:

Tomáš Hypš Informační technologie, MPIS

Vedoucí práce:

Praha

Ing. Vladimír Beneš Petrovický

duben, 2010

Prohlášení:

Prohlašuji, ţe jsem bakalářskou práci zpracoval samostatně a s pouţitím uvedené literatury.

V Praze dne:

Tomáš Hypš

Poděkování:

Děkuji vedoucímu práce panu inţenýru Vladimíru Benešovi, za jeho přístup a vedení bakalářské práce. Dále děkuji své manţelce Veronice Hypšové za toleranci a podporu.

Anotace práce Tato bakalářská práce na téma Skriptovací jazyky – PowerShell v praxi, seznamuje odbornou veřejnost v oblasti IT s novým skriptovacím prostředím PowerShell verze 1.0 a analyzuje jeho výhody při pouţití z pohledu systémového administrátora s důrazem na automatizaci rutinních činností srovnáním se staršími skriptovacími prostředími na operačních systémech MS Windows. Klíčová slova: PowerShell, WMI, VBScript, WSH, KiXtart, skriptování, skriptovací prostředí, automatizace rutinních činností, MS Windows

Annotation My baccalaureate work on “Scripting language – PowerShell in Use”, introduces to IT specialists a new scripting environment, Powershell 1.0, and analyzes its advantages in terms of using the system administrator with an emphasis on the automation of routine activities, while making comparisons with older scripting environments on MS Windows systems. Key words: PowerShell, WMI, VBScript, WSH, KixTart, scripting, scripting environment, automation routine activities, MS Windows

OBSAH 1

ÚVOD...................................................................................................................................................... 7

2

SKRIPTOVÁNÍ V PRAXI SYSTÉMOVÉHO ADMINISTRÁTORA ............................................. 8 2.1

HISTORIE OPERAČNÍCH SYSTÉMŮ SPOLEČNOSTI MICROSOFT ........................................................ 10

2.2

SKRIPTOVACÍ PROSTŘEDÍ POD MS WINDOWS ............................................................................... 14

2.2.1

MS příkazový řádek a dávkové soubory (Batch files)............................................................ 14

2.2.2

VBScript ................................................................................................................................ 15

2.2.3

WSH (Windows Script Host) ................................................................................................. 16

2.2.4

KIXTART ............................................................................................................................... 16

2.3 2.3.1

Přihlašovací skript ................................................................................................................ 18

2.3.2

Práce s registry Windows ...................................................................................................... 19

2.3.3

Skripty pro správu adresářů a souborů ................................................................................. 21

2.3.4

Skripty pro správu doménových služeb ................................................................................. 22

2.3.5

Inventarizace ......................................................................................................................... 22

2.3.6

Monitoring ............................................................................................................................ 23

2.4 3

PŘÍPADY UŢITÍ SKRIPTOVÁNÍ A JEJICH ŘEŠENÍ ............................................................................... 18

SHRNUTÍ KAPITOLY ....................................................................................................................... 25

SKRIPTOVACÍ JAZYK POWERSHELL........................................................................................ 26 3.1

ZÁKLADNÍ STAVEBNÍ PRVKY A NÁSTROJE JAZYKA POWERSHELL ................................................. 27

3.1.1

Základní příkazy PowerShellu............................................................................................... 27

3.1.2

Konstrukce jazyka, podmínky ................................................................................................ 29

3.1.3

Konstrukce jazyka, cykly ....................................................................................................... 30

3.1.4

Proměnné, pole a datové typy ............................................................................................... 31

3.1.5

Objektová roura .................................................................................................................... 33

3.1.6

Systém nápovědy, příklady a funkce WhatIf .......................................................................... 36

3.1.7

Zpracování textu.................................................................................................................... 37

3.1.8

DOTNet, COM objekty a doménové služby ........................................................................... 38

3.2

SKRIPTOVÁNÍ V POWERSHELLU .................................................................................................... 40

3.2.1

Skripty ................................................................................................................................... 40

3.2.2

Bezpečnostní politika............................................................................................................. 40

3.2.3

Uživatelský profil .................................................................................................................. 41

3.2.4

Pravidla při skriptování ........................................................................................................ 41

3.2.5

Funkce a podprogramy ......................................................................................................... 41

3.2.6

Bezpečnost a podepisování skriptů........................................................................................ 42

3.2.7

Ošetřování chyb ve skriptech ................................................................................................ 43

3.2.8

WMI....................................................................................................................................... 44

3.2.9

Správa vzdálených systémů ................................................................................................... 47

3.2.10

Další možnosti shellu ............................................................................................................ 48

3.3

PŘÍPADY UŢITÍ A POROVNÁNÍ SE STARŠÍMI SKRIPTOVACÍMI PROSTŘEDÍMI .................................... 49

3.3.1

Přihlašovací skripty .............................................................................................................. 49

3.3.2

Práce s registry Windows ...................................................................................................... 49

3.3.3

Skripty pro správu adresářů a souborů ................................................................................. 50

3.3.4

Skripty pro správu doménových služeb ................................................................................. 51

3.3.5

Inventarizace ......................................................................................................................... 51

3.3.6

Monitoring ............................................................................................................................ 52

4

ZÁVĚR ................................................................................................................................................. 53

5

SEZNAM POUŽITÉ LITERATURY ................................................................................................ 54

6

SEZNAM POUŽITÝCH OBRÁZKŮ ................................................................................................ 55

1 Úvod Cílem této práce je seznámit odbornou veřejnost se skriptovacím prostředím MS PowerShell 1.0 a analyzovat jeho výhody z pohledu systémového administrátora operačních systémů MS Windows s důrazem na zautomatizování rutinních činností. Při výběru tohoto tématu bakalářské práce, jsem se zabýval otázkou, proč byl vyvinut další skriptovací jazyk na této platformě OS a proč by jej měli administrátoři pouţívat na místo stávajících, jiţ léty prověřených, skriptovacích prostředí. Rozhodl jsem se pro rozdělení této práce na dvě základní kapitoly a to na obecné zhodnocení dosavadních obvyklých způsobů skriptování do vydání MS PowerShellu 1.0 a na vlastní MS PowerShell (dále jen PowerShell). V první části bakalářské práce se proto věnuji nejprve vývoji operačních systémů firmy Microsoft a podpoře skriptování v jednotlivých vývojových etapách. Dále porovnávám uplatnění nejčastěji pouţívaných skriptovacích prostředí platformy MS Windows pro vybrané činnosti z praxe systémového administrátora. Ve druhé části práce seznamuji čtenáře s prostředím skriptovacího jazyka PowerShell, s jeho základními stavebními nástroji a rozdíly při práci se vzdálenými a lokálními systémy. Samostatně se pak věnuji vyuţití rozhraní WMI (Windows Management Instrumentation). V závěru této kapitoly pak z důvodu porovnání, aplikuji PowerShell na stejné činnosti z praxe administrátora jako v předešlé kapitole.

7

2 Skriptování v praxi systémového administrátora Skriptování na úrovni operačních systémů, rozumíme jako procesu zautomatizování časově nebo jinak náročného úkonu, za účelem zvýšení efektivity práce systémového administrátora. Skriptování se provozuje na jakémkoliv prostředí, které umoţňuje konzolově spouštět a řídit běh vlastního operačního systému nebo jiných aplikací a programů, parametrizovat je a upravovat nebo dále zpracovávat jejich výstupy. Při psaní skriptů se pak vyuţívají interní funkce a příkazy skriptovacího jazyka, díky nimţ můţeme tvořit podmínky či cykly nebo zpracovávat vstupní či výstupní proměnné různých datových typů. Skripty, jsou pak soubory, jejichţ obsah je uloţen v čitelné textové resp. nešifrované podobě a odpovídá syntaxi konkrétního interpretoru skriptovacího prostředí. Jejich příkazy se spouští postupně a v této souvislosti mluvíme o prostředích jednoúkolových systémů, tedy systémů, kde v jeden okamţik můţeme spustit právě jen jeden příkaz a kdy interpretor čeká na jeho dokončení. Prostředí, na nichţ můţeme skriptování provozovat, jsou dána právě onou moţností konfigurace a řízení operačního systému a jeho aplikací. Do této kategorie samozřejmě spadají všechny počítačové systémy na bázi Unixu, MACu či Windows, ale jsou zde i operační systémy jiných zařízení jako například mobilních telefonů nebo různých herních konzol, které se svými funkcemi a technologiemi jiţ dávno přiblíţili osobním počítačům. Vyjma skriptování na úrovni operačních systémů ještě mluvíme o skriptování v interním prostředí aplikací, kde se skriptováním obvykle řeší moţnosti rychlejšího zpracování úloh konkrétní aplikace. Obvykle jsou tyto skripty obecně pojmenovány jako „makra“ a jsou uloţeny ve formě, čitelné většinou jen z prostředí dané aplikace. Např. produkty MS Office, kde je ke skriptování pouţit jazyk VBA1 nebo řada nejrůznějších textových editorů, kde makra řeší sloţité vyhledávací a nahrazovací funkce. Poslední kategorií, kterou zde uvádím, jsou skripty pro internetové stránky. Samostatnou kategorii jsem jim vyčlenil pro jejich multiplatformní a multiaplikační povahu, kdy jejich působení jde napříč operačními systémy i aplikacemi, které s nimi pracují jak na straně klienta tak serveru. 1

VBA (Visual Basic for Aplication) je skriptovací jazyk na bázi programovacího jazyka Visual Basic 6 a je určen ke tvorbě maker v aplikacích MS Office.

8

Protoţe se v této bakalářské práci chci věnovat převáţně skriptovacímu prostředí PowerShell, jeţ je vyvíjeno firmou Microsoft jako prostředí určené primárně ke správě operačních systémů MS Windows, budu se věnovat pouze skriptovacím jazykům určeným pro tuto platformu a nejčastěji uţívaným skriptovacím prostředím. Neţ však porovnáme konkrétní skriptovací prostředí, zaměřím se na historii a vývoj operačních systémů společnosti Microsoft a na historickou podporu skriptování. Dnes, kdy je v obchodech běţně dostupná literatura všeho druhu a na internetu se dá nalézt nepřeberné mnoţství příkladů, i hotových skriptů, si jen těţko dokáţeme uvědomit nesnadné začátky s drahou a navíc, co do mnoţství omezenou literaturou, a velmi malým mnoţstvím příkladů uţití, coţ tehdy jistě prodluţovalo čas potřebný pro zvládnutí jakéhokoliv skriptovacího prostředí a jeho technik. V kontextu následujících informací proto lépe pochopíme důvody vývoje právě takového produktu, jakým je MS PowerShell.

9

2.1

Historie operačních systémů společnosti Microsoft

Společnost Microsoft, představila v roce 1981 první verzi finálního operačního systému MS-DOS2 ve verzi 1.0, který byl určený pro IBM PC s 16 bitovými mikroprocesory Intel řady x86, tedy počítače čtvrté generace. Příkazová řádka, která dominovala tomuto systému, zahrnovala řadu vnitřních příkazů i vnějších aplikací, pomocí níţ se celý systém spravoval. Jak se později přesvědčíme ještě mnohokrát, můţeme tuto sadu vnitřních i vnějších příkazů povaţovat za skutečný základ MS skriptování a ačkoliv řada funkcí byla později změněna či upravena, původní účel přetrval aţ dodnes. Obrázek č. 1: Příklad výpisu interních příkazů operačního systému MS-DOS

Zdroj: Seznam těchto příkazů byl pořízen z příkazové řádky COMMAND.EXE na operačním systému MS Windows XP)

I kdyţ se z pohledu skriptování jednalo o nepohodlné a na příkazy poměrně chudé prostředí, které nemohlo ani zdaleka konkurovat tehdy jiţ léty prověřeným UNIXovým systémům, mohly se za pomoci interních operátorů a primitivních konstruktorů vytvářet první skripty, resp. dávkové soubory tzv. batch files. Idea společnosti Microsoft se ubírala k nasazení jejich OS na počítače IBM PC Compatible a tedy oslovit co nejširší skupinu uţivatelů. K tomu se rozhodli přispět novým grafickým prostředím a tak koncem roku 1985 Microsoft představil původní operační systému s grafickým

uţivatelským

rozhraním,

Windows

1.0.

Tento

systém,

napsaný

v programovacím jazyce C, fungoval jako nadstavba nad MS-DOSem a tehdejší správci museli velmi dobře ovládnout manuální techniky nastavování jednotlivých aplikací a jejich

2

MS-DOS (Microsoft Disk Operating Systém) byl prvním OS firmy Microsoft pro počítače 4.generace

10

vyuţívání operační paměti (CONFIG.SYS a AUTOEXEC.BAT)3. Špatné nastavení pak mělo esenciální dopad na funkčnost celého počítače. Obrázek č.2 Přehled operačních systémů Windows společnosti Microsoft

Zdroj: http://en.wikipedia.org/wiki/File:Windows_Family_Tree.svg[5]

Roku 1992 pak Microsoft přepsal kritické části systému do assembleru4 , přemostil omezující a v té době jiţ nevyhovující 16 bitový MS-DOS a začal vyuţívat 32-bitový přístup k souborům. V následujícím roce pak Microsoft vydal první operační systém rodiny NT, Windows NT 3.1 ve verzi pracovní stanice a také první Windows NT advance server. Pro potřeby administrátorů byl vydán tentýţ rok Windows Resource Kit5 pro MSDOS 6.22, který byl dobrým základem pro skriptování v příkazovém řádku. Další podpory se Windows administrátorům dostalo aţ v roce 1996, kdy spolu s řadou operačního systému Windows NT 4.0, vydal Microsoft další sadu administrátorských aplikací Windows NT 4.0 Resource Kit, který opět podpořil tvorbu automatizačních skriptů, tentokrát i s podporou doménových sluţeb. V této době také vydává Microsoft

3

Asi nejznámější konfigurační soubory té doby, pomocí nichţ se nastavovaly nejen aplikace, které na systému poběţí, ale i správu vyšší paměti pro MSDOS s názvem HIMEM.SYS.

4

Assembler je nízkoúrovňový programovací jazyk, vyuţívající symbolické odkazy na strojové instrukce

5

MS Windows Resource Kit je balík aplikací a dokumentací společnosti Microsoft, který doplňuje základní operační systém o uţitečné administrátorské nástroje

11

první verze VBScriptu6 (Visual Basic Script) s podporou COM7 objektů (Component Object Model) a správcovského rozhraní WMI8. S vydáním operačního systému Windows 98, vydává MS v roce 1998 první verzi skriptovacího prostředí WSH9 1.0 (Windows Scripting Host). O dva roky později s vydáním operačních systémů MS Windows 2000 došlo k vydání první objektové databáze Active Directory10 (dále AD), s vyuţitím datového přístupu LDAP11. K tomuto systému byla také vydána nová verze MS Windows 2000 Resource Kitu, který obsahoval přes 300 nových administrátorských programů. V té době, jiţ operační systémy Windows obsahovaly skriptovací podporu WSH ve verzi 2.0, resp. 5.1 a došlo k přejmenování na Windows Script host. S nástupem Windows XP (2001) a Windows 2003 serveru (2003) došlo k rozmachu mnoha nejrůznějších technologií a sluţeb na platformě MS Windows. V dubnu roku 2003 byla vydána nová verze tradičního balíku MS Windows 2003 Resource Kit. Rozhraní WMI bylo stále vylepšováno o nové jmenné prostory (namespaces) a dokonce i dokumentace, včetně příkladů pouţití, byly jiţ v té době na poměrně dobré úrovni. V lednu roku 2007 byl konečně vydán dlouho testovaný a očekávaný operační systém Windows Vista s původním označením Windows Longhorn12. Z pohledu skriptování byl systém Windows Vista vybaven nejen standardním prostředím WSH jiţ ve verzi 5.7, ale měl i integrován nové administrátorské prostředí PowerShell ve verzi 1.0. Díky dlouhodobé nestabilitě celého systému, HW náročnosti i problémům s nejrůznějšími ovladači HW a bohuţel i zpětnou kompatibilitou SW, se společnost Microsoft snaţila co nejrychleji dokončit operační systémy Windows 7 a serverovou platformu Windows 2008

6

VBScript – Skriptovací prostředí zaloţené na principech programovacího nástroje Visual Basic

7

COM objekty je standardní rozhraní pro SW komponenty, pouţívané na platformě OS MS Windows.

8

WMI (Windows Management Instrumentation) administrátorské rozhraní určené ke správě a monitoringu operačních systémů MS Windows.

9

WSH (Windows Scripting Host) byl ve verzi 2.0 přečíslován na 5.1 a přejmenován na Windows Script Host

10

Active Direktory je adresářová sluţba s hierarchickým uspořádáním implementovaná společností Microsoft, která umoţňuje efektivně pracovat se síťovými prostředky domén.

11

LDAP (Lightweight Directory Access Protocol) jedná se o protokol pro přístupy k datům na adresářových serverech.

12

Windows Longhorn byl původní název OS Windows VISTA a byl změněn v létě roku 2005 po téměř dvou letech neúspěšného dokončování.

12

Server. Nicméně oba operační systémy a jejich různé prodejní verze vydala aţ v létě 2009. Skriptování zde bylo opět zastoupeno nejen prostředím WSH verze 5.8, ale i PowerShellem jiţ ve verzi 2.0 s celou řadou zajímavých změn a rozšíření. Z výše uvedeného přehledu by se dalo soudit, ţe skriptování na operačních systémech MS Windows bylo poměrně dobře podporováno. Úkoly, na něţ nestačily utility podpůrných balíků MS Windows Resource Kit, se daly řešit pomocí skriptovacích prostředí WSH, VBScript nebo jiným skriptovacím prostředím a řadu věcí pomáhalo řešit vyuţívání rozhraní WMI a pouţívání COM objektů. S rozvojem internetu vznikala celá řada portálů zabývajícími se právě podporou skriptování pro nejrůznější prostředí a dokonce Microsoft nakonec uvolnil své skriptovací úloţiště k volnému resp. neplacenému uţívání. Zároveň vidíme, ţe od oficiálního vydání skriptovacího prostředí PowerShell, společnost Microsoft jiţ nedistribuuje podpůrný balík aplikací MS Windows Resource Kit. Z toho můţeme soudit, ţe PowerShell by měl být dostatečně silný nástroj, který zastane kompletní správu systémů MS Windows, o čemţ se přesvědčíme v kapitole 3. Nyní si představíme jednotlivá skriptovací prostředí a podíváme se na jejich praktické uţití.

13

2.2

Skriptovací prostředí pod MS Windows

S kaţdým vydáním nového operačního systému, vznikaly nové funkcionality a sluţby operačního systému, díky nimţ rapidně narůstalo mnoţství i náročnost jednotlivých administrátorských úkonů. Zejména s rozvojem počítačových sítí, resp. hromadné správy pracovních stanic i serverů pak mnohdy vznikaly tak systémově náročné úkoly, ţe jejich standardní provedení (přes grafické rozhraní) bylo velmi neefektivní a to jak náročností na čas, tak v souvislosti s lidskými potaţmo finančními zdroji. Tím se otevíral prostor pro zautomatizování rutinních činností systémového administrátora a vzrůstala tak poptávka po vhodném skriptovacím prostředí. Následující seznam zahrnuje skriptovacích prostředí, která se dají označit za nejznámější a nejpouţívanější na platformě MS Windows: -

příkazový řádek CMD.EXE,

-

VBS (Visual Basic Script),

-

WSH (Windows Script Host),

-

KiXtart (Kick Start).

Existují samozřejmě další velká skriptovací multiplatformní prostředí jako například Perl nebo Python, jejichţ rozsah a moţnosti uplatnění jsou natolik obrovské a jejich funkce zasahují jak do oblasti správy operačních systémů, tak do oblasti správy a vývoje SW, ţe dnes jiţ bereme obě tato prostředí spíše za plnohodnotné programovací jazyky, určené převáţně k tvorbě aplikací a nikoliv jako prostředí určená k dynamické správě operačního systému. 2.2.1

MS příkazový řádek a dávkové soubory (Batch files)

Příkazový řádek je nejstarším, jednoúkolovým systémovým prostředím na operačních systémech MS Windows. Tento je na současných OS reprezentován 32-bitovou konzolovou aplikací CMD.EXE13 Základní výbava interních příkazů nikdy nebyla a dodnes není nijak ohromující, a proto jak výrobce systému Windows, tak ostatní vývojáři sáhli po další cestě, která se nabízela.

13

Původní 16-bitové prostředí COMMAND.EXE bylo z důvodu zpětné kompatibility se staršími systémy, pouţito naposledy v operačním systému MS Windows XP.

14

„Bohatství příkazového řádku“ je dnes zajišťováno pomocí tzv. příkazů externích, coţ není nic jiného neţ další 32bitové konzolové aplikace, jeţ běţně spouštíme voláním ze samotného prostředí CMD.EXE14. Jedná se o tak samozřejmou věc, ţe většina uţivatelů a správců ani nevnímá rozdíl mezi dvěma skupinami příkazů, jeţ jsme zmínili.[2] Ke zmíněné skupině externích příkazů bych dodal, ţe mnohé z nich nepocházejí z dílny společnosti Microsoft, ačkoliv právě MS Windows Resource Kit byl na takových aplikacích postaven. I to je patrně důvod k velké rozdílnosti jednotlivých příkazů, jejich syntaxí, vstupů i výstupů dat. Učení tohoto prostředí proto nebylo tak snadné a mnohá řešení systémových úkolů vyţadovala celou řadu mezikroků, které upravovaly nebo jinak zpracovávali jednotlivé výstupy. Co se skriptování v příkazovém řádku týče, šlo většinou o jednoduché dávkové soubory, tzv. Batch files. Programové konstrukce podmínek a cyklů sice byly proveditelné, nicméně se obecně pouţívaly jen omezeně a ke sloţitějším systémovým úlohám, se pouţívala jiná skriptovací prostředí. Zajímavou novinkou příkazového řádku, bylo vydání prvního operačního systému společnosti Microsoft, s omezeným grafickým rozhraním, pod názvem Windows Core Server 2008. Zde je přítomna pouze upravená systémová konzola, rozšířená o úplně nové příkazy operačního systému. Teorie tvrdí, ţe veškerá nastavení se provádí pouze spouštěním těchto příkazů, praxe však ukazuje, ţe daleko pohodlnější je nastavování systému vzdáleně. Paradoxem je, ţe právě pro tento operační systém, byl, před jeho vydáním, propagován PowerShell jako univerzální administrátorské prostředí. Bohuţel se vývojářům nakonec nepodařilo do tohoto systému implementovat MS Framework, který je pro toto prostředí nutný, a tak je tento server spravovatelný přes PowerShell pouze vzdáleně, tj. z jiného serveru. 2.2.2

VBScript

VBScript byl oficiálně vydán roku 1996 a od počátku se jednalo o aktivní skriptovací jazyk který byl postaven na vyuţívání COM objektů a rozhraní WMI. Jeho syntaxe příkazů

14

CMD.EXE není to samé jako COMMAND.EXE. Druhý zmíněný je starý, pouze 16-bitový program, který byl nedílnou součástí MS-DOS systému a z důvodu zpětné kompatibility přetrval aţ do verze MS Windows XP.

15

a struktura programového kódu vychází z programovacího jazyka Visual Basic z dílny společnosti Microsoft. Ačkoliv byl mateřskou společností propagovaný jako ideální skriptovací platforma pro jejich operační systémy, veřejností tak nadšeně přijat nebyl. Programátoři C/C++ i programovacího studia Visual Basic vytýkali jazyku VBScript nepřehlednost, neuspořádanost a benevolenci v definici proměnných a v syntaxi příkazů. Velkým problémem pak bylo časté pouţívání regulárních výrazů, které se pro řadu administrátorů, vyuţívající skriptování jen k urychlení své práce, staly noční můrou. 2.2.3

WSH (Windows Script Host)

Skriptovací prostředí WSH (Windows Skript Host) společnosti Microsoft, které se stalo součástí operačních systémů Windows jiţ od verze MS Windows 98, je dalším velmi uţívaným prostředím pro správu systémů pomocí automatizačních skriptů. Syntaxe kódu je výrazně přehlednější, neţ tomu je u VBScriptu. Pouţití tohoto prostředí je rovněţ velmi otevřené a proto se dají, mimo jiné, také vyuţívat COM objekty i rozhraní WMI. Díky dobré podpoře ActiveX komponent, můţe prostředí WSH pomocí skriptů vyuţívat i grafické rozhraní Windows. Od verze WSH 5.6 byl implementován další, velmi důleţitý prvek pro spouštění skriptů běţící na této skriptovací platformě. Tímto bezpečnostním opatřením bylo umoţněno podepisování skriptů a nastavení skriptovacího prostředí WSH tak, aby se mohly spouštět pouze takto podepsané skripty15. 2.2.4

KIXTART

Jedním z prostředí, které bylo vyvinuté firmou třetí strany a se kterým se dalo velmi dobře pracovat jiţ od počátku, byl produkt KiXtart (poprvé vydán 1991) stejnojmenné firmy. Jeho síla z pohledu automatizace rutinních činností byla poměrně velká, zejména pro explicitně dané příkazy, snadnou syntaxi a velkou přehlednost kódu. Nicméně jeho

15

Digitální podpis skriptu – je cesta jak zapouzdřit zkontrolovaný skript a zabezpečit tak nezaměnitelnost pouţívaného skriptu. Podpis se provádí pomocí externího programu, který do hlavičky skriptu umístí blok znaků reprezentujících digitální podpis. V případě otevření takového souboru k zápisu a následného uloţení (i kdyby nedošlo k ţádné změně) by způsobilo narušení tohoto podpisu a skript by se na správně nastaveném prostředí, jiţ nedal znovu nespustit.

16

primární pouţití bylo jiţ od počátku koncipováno jako Logon Scripting Language, tedy jazyk určený pro přihlašovací skripty uţivatelů. Stejně jako ostatní produkty se časem s novými technologiemi vylepšoval i KiXtart. Přibyly doménové funkce s přístupem pomocí LDAP, řada funkcí na úpravu či hledání textových řetězců, plná podpora 64bitových operačních systémů a mnoho dalšího, čímţ se tento produkt pevně drţí na předních pozicích skriptovacích prostředí i dodnes a je pouţíván primárně pro přihlašovací skripty.

17

2.3

Případy užití skriptování a jejich řešení

Jak jsem jiţ zmínil v úvodu, skriptování by se mělo pouţít všude tam, kde náročnost či četnost úkonů převyšuje mez splnitelnosti úkolu a to hlavně z časového hlediska. U OS MS Windows se pohybujeme převáţně v grafickém prostředí, které sice můţe být vizuálně zajímavé, ale v případě nastavování, úprav či monitoringu u více neţ deseti pracovních stanic či serverů, je GUI spíše na obtíţ. Proto se pak vyuţívají skriptovací prostředí, která rutinní práce nebo sloţitá nastavování zajistí s vysokou spolehlivostí. Ačkoliv jsem prošel řadu knih i internetových stránek, nikde jsem nenašel uspořádání činností pro administrátory, které by postihlo všechny nebo alespoň zásadní oblasti skriptování na MS Windows. Proto jsem se nakonec rozhodl vytvořit seznam oblastí z celé řady dalších, neméně důleţitých administrátorských činností, ve kterých je skriptování zapotřebí a na kterých porovnám funkčnosti jednotlivých prostředí. Jsou to: -

přihlašovací skripty,

-

úpravy registrů, nastavování proměnných systému,

-

skripty pro správu adresářů a souborů,

-

skripty pro správu doménových sluţeb,

-

inventarizace,

-

monitoring.

V následujících podkapitolách se budu věnovat kaţdé této oblasti samostatně, rozeberu nejdůleţitější aspekty a porovnám vyuţití skriptovacích prostředí, která jsem vybral v předešlé kapitole. 2.3.1

Přihlašovací skript

Tento skript slouţí pro provádění administrátorských činností a změn na uţivatelském účtu či počítači. Na rozdíl od aplikování doménových politik, které se spouští při přihlašování počítače do domény, se přihlašovací skripty spouští pro konkrétního uţivatele po jeho přihlášení a zpracovává se v nich: -

připojování síťových adresářů a tiskáren,

-

individuální nastavení systému, 18

-

individuální nastavování aplikací,

-

inventarizace,

-

instalace aplikací, SW balíků.

Prostředí CMD sehrává v tomto případě většinou jen malou roli. V profilu uţivatele se sice obvykle vyskytují soubory s koncovkou BAT nebo CMD, nicméně většinou fungují jen jako spouštěče jiného prostředí. Třeba KiXtartu. Pravděpodobně nejčastějším pouţitím je skutečně produkt KiXtart. Obsahuje totiţ řadu efektivních a jednoduše pouţitelných funkcí a samotní konzultanti společnosti Microsoft, doporučují, pro tento účel, pouţití tohoto produktu. VBScript ale i WSH jsou pro svou komplexnost pro přihlašovací skripty také vyuţívány. Pravdou ovšem zůstává, ţe KiXtart je asi nejpouţívanější. Příklad z praxe: V nadnárodní bance, která v současnosti čítá něco přes 43.000 uţivatelů pouţíváme pro řízení přihlašovacího skriptu prostředí KiXtatr. Logon skript, ve kterém se řídí mapování celopodnikových síťových adresářů, kde některé jsou řízeny úrovní pracovní pozice, příslušnosti k útvaru, oddělení nebo týmu, spouští se instalátory menších aplikací a nastavují se oprávnění k nim, připojují se tiskárny dle aktuálního místa přihlašování (lokality), kontrolují se nezbytná nebo podmíněná nastavení systému opět v závislosti na druhu činnosti a příslušnosti k oddělení a mnoho dalšího. Tento logon script má v současnosti 3174 řádek a o jeho údrţbu a návaznost na vnitropodnikovou aplikaci, která zajišťuje instalace SW balíků se stará celé jedno oddělení čítající 6 administrátorů. 2.3.2

Práce s registry Windows

Získávání informací z registrů Windows nebo jejich úpravy jsou častým prostředkem správy těchto systémů a tudíţ i častým objektem zájmu administrátorských skriptů. Všechna testovaná skriptovací prostředí mají své moţnosti ke správě registrů a tudíţ se dá říci, ţe je jen a pouze na volbě administrátora, které prostředí zvolí. Protoţe práce s registry Windows je opravdu důleţitou oblastí, rozhodl jsem se pro názorný příklad a ukázku kódu jednotlivých skriptovacích prostředí. Příklad: Zjistit aktuální produktové jméno operačního systému Windows. Prostředí příkazového řádku CMD.EXE 19

Export registrů do souboru je sice poměrně rychlý a jednoduchý, prostředí však postrádá variabilitu a více moţností a navíc výsledek musí být zpracován dalšími programy. Obrázek č.3 Čtení z registru Windows v prostředí příkazového řádku REGEDIT /E c:\temp\verze_windows.REG "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion“ Zdroj: Vlastní tvorba

Prostředí VBScript Pro přístup do registrů Windows vyuţívá sluţeb WMI Obrázek č.4 Čtení z registru Windows v prostředí VBScript const HKEY_LOCAL_MACHINE = &H80000002 strComputer = "." Set StdOut = WScript.StdOut Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" &_ strComputer & "\root\default:StdRegProv") strKeyPath = "SOFTWARE\Microsoft\Windows NT\CurrentVersion" strValueName = "ProductName" oReg.GetStringValue KEY_LOCAL_MACHINE,strKeyPath,strValueName,strValue StdOut.WriteLine strValue Zdroj: Vlastní úprava, inspirováno Jones, Don. Microsoft Windows Administrator’s Automation Toolkit[x]

Prostředí WSH Má své vlastní funkce jak pro čtení informací z registru Windows, tak pro zápis a mazání. Obrázek č.5 Čtení z registru Windows v prostředí WSH var regPath = "HKLM\\SOFTWARE\\Microsoft\Windows NT\\CurrentVersion\\"; var key = " ProductName"; var shell = WScript.CreateObject("WScript.Shell"); var verzeWindows = shell.RegRead(path+key); Wscript.Echo verzeWindows Zdroj: Vlastní úprava, inspirováno http://technet.microsoft.com/en-us/library/ee156602.aspx[7]

20

Prostředí KiXtart Rychlý a efektivní přístup k registrům předvádí jednoznačně právě KiXtart Obrázek č.6 Čtení z registru Windows v prostředí KiXtart $verzeWindows = READVALUE ("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\" ,"ProductName") $verzeWindows Zdroj: Vlastní úprava, inspirováno http://www.KiXtart.org[8]

2.3.3

Skripty pro správu adresářů a souborů

Ve spojitosti s administrátorskou činností, se nejčastěji řeší: -

kopírování či přesuny souborů,

-

vytváření a mazání,

-

nastavování NTFS práv,

-

zálohování.

V této oblasti kupodivu vede nebo dlouhou dobu vedl příkazový řádek. XCACLS.EXE je totiţ konzolová aplikace určená pro nastavování práv na souborovém systému, poprvé uvedená v MS Windows 2000 Resource Kitu. Protoţe je snadno konfigurovatelná, je i často vyuţívaná administrátory v prostředí jako VBScript, WSH či KiXtart. Aţ v září roku 2006 uvedl Microsoft skriptovou verzi této aplikace napsanou ve VBScriptu (pod názvem XCACLS.VBS), která věrně kopíruje moţnosti původní utility. Nastavení práv cestou programového kódu se pak provádí pomocí COM objektů a to jak jsem jiţ uvedl, zvládají v současnosti všechna výše uvedená skriptovací prostředí (samozřejmě s výjimkou CMD.EXE) jen s rozdíly pouţité syntaxe. Kopírovat, mazat či vytvářet soubory samozřejmě umí všechna prostředí. Co se zálohování týče,

zde bych

se

opět

přiklonil

k příkazovému řádku a

vyzdvihl aplikaci

16

ROBOCOPY.EXE , která je velmi dobře konfigurovatelná a má tak nedocenitelné funkce, ţe tento produkt dodnes vyuţívají ve skriptech všechna jmenovaná prostředí.

16

Robocopy.exe je velmi efektivní konzolová aplikace, určená ke kopírování, zálohám a přesunům dat na souborovém systému MS Windows.

21

2.3.4

Skripty pro správu doménových služeb

S příchodem doménových sluţeb Active directory velmi vzrostl počet poţadavků na úpravu dat v této databázi prostřednictvím skriptů. Důvodem byla hlavně velikost této databáze a spousta času stráveného ruční správou uţivatelských účtů, pracovních stanic, serverů a jejich vztahy a mnoho dalšího. Vybírat proto v této oblasti nějaké specifické odvětví je celkem zbytečné, protoţe správa domény se provádí pomocí poskytovatelů LDAP nebo WinNT17 za pouţití COM objektů a to jak jsem jiţ uvedl, umí opět všechna testovaná prostředí resp. VBScript, WSH i KiXtart. V prostředí

příkazového

řádku

CMD

jsou

například

vyuţívány

programy

z administrátorské sady MS Windows Resource Kitu, které jsou sice povětšinou jednoúčelové, nicméně ve spojení s BATCH skripty, popřípadě jinými skriptovacími prostředími, se dají poměrně rychle a efektivně vyřešit mnohé i vcelku náročné doménové úlohy. 2.3.5

Inventarizace

Inventarizací rozumíme proces získávání statických informací o HW a SW instalovaném na síťových počítačích, ukládání těchto informací na bezpečném místě a následně zpracování do poţadované formy výstupu. Tyto reporty jsou pak často pouţívány pro různé zprávy, grafy a jiné dokumentace potřebné pro různá manaţerská rozhodnutí, zejména v oblasti plánování a řízení projektů IS/IT. Z toho vyplývají následující potřeby na skriptovací prostředí:

17

-

přístup do registrů,

-

snadný přístup do souborového systému,

-

práce s bezpečnostními oprávněními adresářových sloţek a souborů,

-

přístup k licencím a certifikátům systému,

-

podpora vzdáleného přístupu,

-

přístup do WMI,

-

rozšířené moţnosti zpracovávání textu,

WinNT tento poskytovatel (provider) je sice snazší na pouţití neţ LDAP, je však určen pro starší model domén NT. Ačkoliv tedy zvládne komunikaci s AD, některé atributy nedokáţe vyuţívat a proto je LDAP upřednostňován.

22

-

matematické, logické a vyhledávací funkce,

-

práce s MS Excelem nebo jinou tabulkovou aplikací,

-

a další.

U prostředí CMD platí to samé jako v předešlé podkapitole. Softwarový balík Resource Kit nabízí řadu programů zajišťujících dílčí úlohy, dále existuje řada konzolových aplikací třetích stran, které opět více či méně zajišťují další potřebné funkce, nicméně obecně se dá říci, ţe se jedná o nejednotné a nekonzistentní prostředí nevhodné pro inventarizace většího rozsahu. Většina výše zmiňovaných bodů se řeší za pomoci rozhraní WMI nebo COM objektů a proto všechna prostředí vyhovují a je jen na výběru administrátora, jaké prostředí pouţije. 2.3.6

Monitoring

Monitoring je v tomto pohledu chápán jako periodická činnost skriptu, při které se aktivně dohledují vzdálené systémy, jsou z nich periodicky získávány potřebné informace a ty jsou dynamicky zpracovávány a vyhodnocovány. Nejčastější sledované oblasti: -

Vyuţití zdrojů systému,

-

Chybové stavy resp. katalog událostí,

-

Uţivatelská činnost,

-

Dostupnost systému,

-

a další potřebné informace.

Prostředí CMD je v tomto směru pro svou absenci rozšířených skriptovacích funkcí poměrně nevhodné, nicméně i zde se za pouţití externích příkazů, resp. aplikací, dají získávat nejrůznější informace. Avšak díky nekonzistentnosti a nekompatibilitě jednotlivých výstupů je další zpracování velmi obtíţné. Ostatní skriptovací prostředí mohou fungovat jako základ monitorovacím procesům, nebo sami generovat například HTML kód pro pouţití webových stránek. Obecně je samozřejmě přehlednější, mít monitorovací SW v grafickém provedení a proto v těchto případech fungují skriptovací prostředí hlavně jako podpora pro monitorovací nebo

23

konfigurační aktivity. V tomto směru je pravděpodobně nejčastěji vyuţíván VBScript a to nejen pro svou velkou variabilitu, ale hlavně pro velkou podporu jak ze strany Microsoftu, tak skriptařské obce. Např. dohledový software NETIQ, který vyuţívá právě VBScript jako svou výkonnou sloţku. Produkt KiXtart je pak například vyuţíván pro monitorovací SW s webovým rozhraním pod názvem “KiXtart Helpdesk“[5], který dynamicky generuje HTML stránky.

24

2.4

Shrnutí kapitoly

Je vidět, ţe představená skriptovací prostředí, dokáţí poskytnout systémovému administrátorovi dostatečně široké portfolio moţností pro skriptování rutinních činností. Dokonce i příkazový řádek má řadu příkazů resp. externích aplikací, které jsou vyuţívány i ve skriptech ostatních prostředí. VBScript, WSH i KiXtart potom mají výhodu v pouţívání rozhraní WMI a COM objektů a proto se stávají univerzálními jazyky pro administrátorskou činnost. WSH a KiXtart potom mají přehlednější kód a snadněji se proto pouţívají. VBScript pak nabízí obecně nejširší moţnosti pouţití a dá se říci, ţe dnes je i díky MS Skript Center velmi univerzálním skriptovacím jazykem.

25

3 Skriptovací jazyk PowerShell Koncem roku 2006 přichází tým Jeffreyho Snovera ze společnosti Microsoft s údajně revolučním prostředím PowerShell ve verzi 1.0, s kódovým označením Monad18. Šlo o volně dostupné, plně objektové skriptovací prostředí nové generace, určené pro administraci operačních systémů Windows. Dle tehdejších informací, mělo poskytnout dostatečně silné zázemí jak pro vlastní administrátorskou činnost na úrovni pracovních stanic i serverů, tak pro tvorbu automatizačních, resp. rutinních skriptů. První verze PowerShell 1.0 oficiálně vyšla společně s jednou z beta verzí systému Windows Vista a společně s ní vyšly i instalační balíky pro starší prostředí Windows XP a Windows 2003 Server. V červnu roku 2009 vydal Microsoft novou verzi operačních systémů Windows 7 a Windows Server 2008 R2, jejichţ součástí byla i dlouho očekávaná finální verze prostředí PowerShell 2.0. S touto verzí přišla opravdu velká řada změn, z nichţ bych zmínil hlavně přímou podporu vzdálené administrace, řadu rozšíření pro rychlejší správu domén, lepší management procesů nebo podporu nových MS technologií. Nicméně protoţe rozdíl ve verzích je velký a to hlavně z pohledu rozšířených funkcionalit a čas od vydání nové verze je poměrně krátký a ani já jsem se v mé profesní kariéře prozatím nedostal k plně nasazenému prostředím PowerShellu 2.0, budu se v této práci věnovat pouţití PowerShellu ve verzi 1.0.

18

Pochází z Řecké filozofie a jedná se o označení „Prvního“ nebo také Boha mezi všemi.

26

3.1

Základní stavební prvky a nástroje jazyka PowerShell

Zmínil jsem, ţe PowerShell je revolučním prostředím na operačních systémech Windows, coţ však je i není pravda. Průlomové totiţ není vybavení, ale cesta a geniálnost provázání jednotlivých přidruţených prostředí. Kloubí se zde totiţ léty prověřené technologie jako jsou COM objekty, rozhraní WMI anebo prostředí DotNet Framework, s obdivuhodnou promyšleností a provázaností s původním skriptovacím jazykem PowerShellu a jeho sadou interních příkazů. Právě tato příkazová sada spolu s objektovou rourou, jsou klíčovými prvky pro jakoukoliv další administraci systému. 3.1.1

Základní příkazy PowerShellu

Jiţ v raném stádiu vývoje PowerShellu se stanovil obecný název pro interní příkazy tohoto prostředí. Název CMDLET vznikl ze spojení slov Command a Applet. Cmdlet je nativním příkazem PowerShellu v zásadě proto, ţe je odvozován od třídy stejného jména, která je definována v běhovém prostředí DOTNet Framework. Nejedná se tedy o „cokoliv“ co by programátor spáchal a pojmenoval v souladu s konvencí, ale o naprosto striktně danou strukturu, čímţ je mimo jiné zajišťována tolik ţádoucí a uţitečná jednostrannost a způsob pouţití všech cmdletů, na které narazíme[2]. Z výše uvedené citace Patrika Maliny je zřejmé, ţe ačkoliv je kaţdý příkaz logicky předurčen pro jinou činnost, syntaxe, pouţití či systém nápovědy je vţdy stejný a právě to pomáhá zvládnout základy PowerShellu za poměrně krátkou dobu. Seznam základních dostupných příkazů prostředí získáme příkazem: PS C:\> Get-Command Ve verzi PowerShell 1.0 je k dispozici 129 cmdletů. Zajímavostí je skutečnost, ţe vlastních příkazů je jen 40. Všechny cmdlety jsou totiţ dvouslovné a skládají se z vlastního příkazu (slovesa), z přepínače (switch), který je reprezentován znakem pomlčky „-“ a poté následován podstatným jménem, které by mělo logicky poukazovat na smysl příkazu. Toto jméno bývá také pojmenováváno jako parametr příkazu. Co do četnosti výskytu, vede příkaz GET, který slouţí k získávání informací o operačním systému a jeho nastaveních a příkaz SET, který pak logicky provádí změny v nastaveních.

27

Mezi dalšími příkazy pak nalezneme ADD, CLEAR, CONVERT, COPY, EXPORT, FORMAT, IMPORT, MOVE, NEW, SELECT, START, STOP, WRITE a jiné. O tom, ţe i tyto příkazy podléhají objektovým pravidlům a dá se s nimi tudíţ inteligentně pracovat, ať slouţí příklad výpisu všech dostupných příkazů pro práci se sluţbami systému. Tím, ţe samotné příkazy mají objektový charakter, můţeme je zavolat příkazem Get-Command s parametrem konkrétního podstatného jména, v tomto případě sluţby systému (Service). Obrázek č.7 Výpis příkazů pro práci se sluţbami systému Windows

Zdroj: Vlastní tvorba

Ačkoliv je pouţití většiny příkazů optimalizováno k rychlému pouţití s přednastavenými hodnotami parametrů, neznamená to, ţe by příkazy samotné nešly sloţitěji rozvíjet. Pro výpis všech parametrů příkazu se dá pouţít spojení příkazů Get-Help a konkrétního příkazu. Více pak v kapitole o nápovědě v PowerShellu. Jedním ze zajímavých a jistě velmi uţitečných příkazů je cmdlet Get-Eventlog, který umoţňuje efektivně zpracovávat a vyhledávat v systémovém logu událostí. Zpracovávání katalogu událostí bylo doposud vţdy časově náročné. Tento CMDLET však pracuje s událostmi velmi efektivně a díky objektovému přístupu a filtrům, můţeme získat konkrétní poţadované informace během velmi krátké doby(řádově 1-2 sec.). Bohuţel však tento příkaz neobsahuje parametr pro vzdálené systémy a tak je pouţití omezeno jen na lokální systém. V seznamu příkazů však jiţ od počátku chyběly příkazy pro správu síťových a doménových sluţeb, správu tiskáren či jiných periférií, vzdálenou administraci systémů apod. Všechny tyto uvedené příklady se musejí řešit jinými cestami, většinou za pomoci COM objektů nebo rozhraní WMI, se kterými však PowerShell umí pracovat velmi efektivně viz samostatná kapitola o WMI.

28

3.1.2

Konstrukce jazyka, podmínky

Základní podmínkou kaţdého skriptovacího prostředí jsou moţnosti uţití podmínek a různých cyklů. PowerShell v tomto ohledu nijak nevybočuje z řady ostatních skriptovacích prostředí. Pro vytvoření podmínek jsou zde k dispozici dvě standardní konstrukce a to IF a SWITCH a pro uţití filtru za objektovou rourou, pak příkaz WHERE. Uţití podmínkového konstruktoru IF je velmi podobné jiným jazykům. Jednotlivé podmínky se dají logicky spojovat jako je tomu v příkladu na obrázku č.5 kde jsem uţil logický operátor AND. Podmínka se dá dále libovolně členit prostřednictvím ELSEIF a následné příkazy se spojují do bloku ohraničeným sloţenými závorkami. Následující příklad ukazuje pouţití logických operátorů, podmínek a uţití bloků. Obrázek č.8 Podmínka IF s pouţitím operátorů IF () {} Else {} Zdroj: Vlastní úprava, inspirováno Malinou, Patrikem[2]

Ve vlastních podmínkových výrazech se nepouţívá rovnítko, jako je tomu u většiny skriptovacích jazyků, ale musí se pouţívat následující operátory: -

eq(rovná se),

-

ne(nerovná se),

-

gt (větší neţ),

-

ge (větší nebo rovno neţ),

-

lt (menší neţ),

-

le (menší nebo rovno neţ),

-

like/notlike (je/není podobno – nezáleţí na velikosti písmen, uţívá se „*“ coby zástupného znaku),

-

match/notmatch (je/není obsahem).

Příkaz SWITCH je pak podmínkový konstruktor pro výběr z většího mnoţství předdefinovaných moţných hodnot určité proměnné. 29

Obrázek č.9 Konstrukce příkazu SWITCH Switch(<$řídící_proměnná>) { Hodnota1 { } Hodnota2 { } Default { } } Zdroj: Malina,Patrik. Microsoft Windows POWERSHELL[2]

Podmínka WHERE rozšiřuje moţnosti podmiňování v PowerShellu novým směrem. Jedná se o vyhledávání objektů vyhovujících podmínce, v proudu výstupu objektů z určitého příkazu za objektovou rourou. Protoţe se objektové rouře budu věnovat v samostatné kapitole podmínku WHERE názorně předvedu aţ v této kapitole. 3.1.3

Konstrukce jazyka, cykly

Co se cyklů týče, ani zde PowerShell nevybočuje nikterak ze standardu. Přítomny jsou všechny klasické cykly For, Foreach, Do until, Do while a While. Následující obrázek názorně ukazuje syntaxi nečastějších cyklů FOR, FOREACH a WHILE. Je opět patrné, ţe PowerShell se orientuje hlavně na rychlost pouţití a přehlednost příkazu ve skriptu. Obrázek č.10 Konstrukce cyklů FOR, FOREACH a WHILE Cyklus FOR # na začátku cyklu je A rovno 0 # pro cyklus platí podmínka , ţe A musí být menší neţ 100 # A se navyšuje kaţdý cyklus o hodnotu 1 For ($a=0; $a –lt 100; $a++) { blok příkazů }

Cyklus FOREACH # Pro tento cyklus platí, $b musí být pole nebo kolekce objektů Foreach ($a in $b) { blok příkazů }

30

Cyklus WHILE # Dokud je výraz platný, cyklus se opakuje While ($a –ne 1) { blok příkazů } Zdroj: Vlastní úprava, inspirováno Malina,Patrik. Microsoft Windows POWERSHELL[2]

3.1.4

Proměnné, pole a datové typy

Názvy proměnných se v PowerShellu uvozují znakem „$“, podobně jako v prostředí KiXtartu a ani zde se nemusí explicitně deklarovat jejich datový typ. Nicméně je moţné takto učinit a určit tak trvale charakter konkrétní proměnné či celého datového pole a zabránit tak případnému konfliktu proměnných jiného datového typu uvnitř skriptu. Pokud ale není datový typ určen, nastaví se datový typ proměnné automaticky z načítané informace, čehoţ se vyuţívá například u datových polí, kde nemusí mít všechny poloţky jednotný datový typ. Právě datová pole v PowerShellu jsou velmi zajímavě řešena a jsou plně přizpůsobena povaze dat se kterými PowerShell pracuje. Datové typy jednotlivých buňek polí se totiţ nemusí vůbec shodovat, resp. pole proměnných nemusí mít jednotnou datovou strukturu. Dokonce i jen jedna proměnná z pole můţe sama obsahovat kolekci dalších objektů, čímţ vznikne de facto nesourodé n-dimenzionální pole. Následující obrázek ukazuje vytvoření datového pole o 5 prvcích (v hodnotách 1 aţ 5, bez deklarace) a následném zapsání kolekce objektů, v tomto případě výpisu procesu, namísto původního čísla 3. Následný výpis pak dokazuje uloţení všech vlastností objektu „proces“. Jen dodám, ţe s objektem se dá dále pracovat a pouţívat všechny standardní metody i vlastnosti. Obrázek č.11 Ukázka práce s polem proměnných.

Zdroj: Vlastní tvorba

31

Další moţností jsou asociativní pole, kde můţeme indexovat pole a přiřadit libovolnou klíčovou hodnotu. Například uloţení procesů kaţdou hodinu pod jménem symbolizující datum a čas viz následující obrázek. Na příkladu nejprve zapíši procesy do pole na první pozici pole a pojmenuji ji Den0210.Hod10. Poté rozšířím pole o další objektovou poloţku zkráceným tvarem “ +=“ a třetím příkazem vypíši obsah celého pole. Obrázek č.12 Ukázka práce s asociativním polem

Zdroj: Vlastní tvorba

Datové typy přebírá PowerShell od svého mateřského prostředí, běhové platformy .NET Frameworku, a proto jeho datové typy odpovídají této platformě. Je jich tak k dispozici velké mnoţství, jeţ při běţném skriptování zdaleka nevyuţijeme. Následující tabulka přináší přehled alespoň těch základních a k nim příslušné zkratky, které je moţno pouţít při přímé deklaraci v PowerShellu.[2] -

[datetime]

Datum nebo čas,

-

[string] Řetězec znaků,

-

[char]

-

[double] Desetinné číslo s dvojnásobnou přesností,

-

[int]

Celé číslo reprezentováno 32 bity,

-

[wmi]

Instance nebo kolekce objektů WMI,

-

[adsi]

Objekt rozhraní Active directory Services (ADSI),

-

[wmiclass]

Třída objektového modelu WMI,

-

[boolean]

Logická hodnota dle Booleovy algebry. [2]

Jednotlivý znak,

K výše uvedené citaci výčtu datových typů bych doplnil, ţe ono zmíněné „velké mnoţství“ je dáno hlavně tím, ţe do proměnné, můţeme uloţit libovolný objekt z platformy .NET

32

Framework. Proto třeba libovolný proces, získaný příkazem Get-Process je datového typu [Systém.ComponentModel.Component] a jeho jednotlivé vlastnosti mají pak další datové typy. 3.1.5

Objektová roura

Objektová roura v PowerShellu slouţí k přeposlání určitého výsledku předešlého příkazu k dalšímu zpracování. Je symbolizovaná znakem „|“ a syntaxe jejího pouţití je podobna té, kterou známe z unixových systémů19. Na unixových systémech, stejně jako na dosavadním MS příkazovém řádku byl výstup za rourou téměř výhradně textový. To znamená, ţe výstup za určitým příkazem byl pouze formátovaný text. Originalita powershellové roury spočívá hlavně v tom, ţe výstup příkazů se nijak neformátuje a rourou se posílá skutečný výstup v podobě plných objektů se všemi svými metodami, vlastnostmi či spouštěcími událostmi, přesně podle rámce DotNet Frameworku. Výstup za objektovou rourou můţeme resp. měli bychom dále zpracovávat. Cest jak ji zpracovat je velmi mnoho a závisí jen na libovůli zpracovatele, nicméně nejčastěji se provádí aplikování filtrů, vyhledávacích funkcí na objekty či vlastnosti a dále pak dalšími příkazy shellu. Samozřejmostí je moţnost ukládat data a dále s nimi objektově pracovat, definovat formát výstupu do souborů jako XML, CSV a jiných. Nebo můţeme objektový výstup převést to textového výstupu a zformátovat data přímo na obrazovku do konfigurovatelných tabulek (format-table, format-list). Aby byla předešlá část jednodušší na pochopení, uvedu zde příklad pouţití standardního příkazu v kombinaci s rourou v prostředí příkazovém řádku a poté obdobnou funkcí v prostředí PowerShell. Prostředí příkazového řádku Aplikace TASKLIST.EXE vypisuje aktuální běţící procesy v podobě textového výpisu. Roura předává výpis dál a interní příkaz MORE rozdělí výpis tak, aby vyhovoval velikosti okna, ve kterém se příkaz zpracovává. To je přibliţně vše, co můţeme s rourou v klasickém prostředí CMD.EXE dělat.

19

Windows sice rouru také pouţívali, její role byla hlavně spojována s formátováním výstupu

prostřednictvím aplikace MORE.EXE

33

Obrázek č.13 Pouţití aplikace TASKLIST.EXE k získání objektů

Zdroj: Vlastní tvorba

Prostředí PowerShell Protoţe PowerShell výstupy svých příkazů neformátuje na text, ale ponechává všechny objekty v původním datovém formátu, vytváří se tak výstup v podobě objektových kolekcí, kterými můţeme jednoduše procházet a zjišťovat tak potřebné informace. Podíváme-li se tedy na výpis aktuálně běţících procesů příkazem Get-Process, získáme podobný výpis jako v předešlém případě. Obrázek č.14 Pouţití příkazu Get-Process

Zdroj: Vlastní tvorba

Pokud pouţijeme v návaznosti za objektovou rouru příkaz Get-Member zjistíme, ţe na výstupu jsou skutečně kolekce objektů, jejich vlastnosti a dostupné metody. V daném případě u příkazu Get-Process se nabízí 51 vlastností a 87 metod. Ukázka v příloze č.1. Formátování výstupu je, jak jsem jiţ uvedl, explicitní a následuje ukázka výpisu konkrétní informace formátována příkazem Format-Table. Za pouţití optimalizovaných dotazovacích mechanizmů, které rozeberu v kapitole o skriptování, docílíme např. odpovědi na dotaz, kdy byl spuštěn program MS Outlook.

34

Obrázek č.15 Formátování výstupu

Zdroj: Vlastní tvorba

V kapitole o podmínkách jsem se jiţ zmínil o pouţití příkazů WHERE. Podmínka WHERE, která se dá téţ reprezentovat zástupným znakem „?“ vyhledává objekt vyhovující dané podmínce a poté celý objekt pošle k dalšímu zpracování. Funguje tedy jako takové objektové síto. Pro zpracovávání dat za objektovou rourou se také velmi často pouţívá příkaz FOREACH, který se dá reprezentovat zástupným znakem „%“, je v souvislosti s objektovou rourou vyuţíván pro provedení určité akce pro všechny objekty přicházející na vstup příkazu, obvykle pak v návaznosti na podmínku WHERE. S rourou je pak spojena ještě jedna proměnná, kterou jsem v minulé kapitole záměrně přešel. Jedná se o univerzální objektovou proměnou, která je symbolizována znakem „$_”, a která zastupuje kaţdý celistvý objekt procházející rourou. V případě procesů je to tedy kaţdý proces, u výpisu sluţeb je to kaţdá sluţba a podobně. Následující příklad ukazuje pouţití nejprve funkce WHERE (?), kdy budeme hledat ve výpisu aktuálních běţících procesů aplikaci s názvem „Calc“(Kalkulačka) a následně pak, za pouţití funkce FOREACH (%), tyto procesy násilně ukončíme metodou Kill(). Obrázek č.16 Pouţití podmínky WHERE a cyklu FOREACH pro ukončení běţících procesů

Zdroj: Vlastní tvorba

35

3.1.6

Systém nápovědy, příklady a funkce WhatIf

Systém nápovědy se v prostředí PowerShellu dělí do několika úrovní. Kdyţ pomineme dokumentaci a dostupné materiály z internetu nebo knih, je PowerShell velmi dobře připraven na pomoc začínajícím administrátorům svými elektronickými systémy nápověd. Jsou to: -

reference jednotlivých příkazů,

-

elektronický manuál ABOUT,

-

bezpečnostní pojistka WhatIf

Elektronická forma nápovědy nebo také elektronická referenční příručka se volá příkazem Get-Help a jako parametr se uvádí konkrétní příkaz (výpis příkazů prostřednictvím getcommand). Tímto dotazem získáme základní informace o konkrétním příkazu a jeho standardní syntaxi. Doplňkově se dají pouţít následující parametry pro získání rozšířené nápovědy a tedy pro detailní výpis „–detailed“, pro plný výpis pak „-full“ anebo jen příklady uţití a pak parametr „-examples“. Další formou nápovědy spojenou tentokrát spíše s vlastním PowerShellem resp. se správným uţitím interních funkcí potřebných pro skriptování je spojení příkazu GetHelp a souborů nápovědy „ABOUT“ (Kompletní přehled nápovědních souborů získáme příkazem Get-Help About*). V těchto jednotlivých souborech jsou přehledně vysvětleny a uvedeny principy uţívání například podmíněných příkazů, parametrů, cyklů, funkcí atd. Tuto kapitolu zakončím pomocnou funkcí resp. parametrem příkazů, které mají za úkol měnit nastavení systémů (obvykle příkazy SET), s názvem „-WhatIf“. Tento parametr sice není přímo nápovědou, ale funguje jako bezpečnostní pojistka některým příkazům. Umoţňuje totiţ otestovat příkaz, který má přímý vliv na systém, tj který něco mění, spouští či zastavuje a jeho uţití způsobí výpis co by se stalo, kdybychom konkrétní příkaz skutečně spustili. Jako ukázku této funkce jsem vybral násilné ukončení procesu „kalkulačky“ za pomoci příkazu Stop-Process. Ačkoliv se můţe zdát tato funkce triviální v následujícím podání, při odlaďování sloţitějších vyhledávacích funkcí je tento parametr velmi vítaný.

36

Obrázek č. 17 Pouţití funkce WHATIF

Zdroj: Vlastní tvorba.

3.1.7

Zpracování textu

I zpracování čistého textu je v PowerShellu na velmi vysoké úrovni. Moţností jak z textu získat poţadované informace, nebo jak jej převést do lépe zpracovatelné podoby je hned několik. Níţe uvedené příklady rozhodně nezahrnují všechny cesty zpracování textu a dá se i říci, ţe variabilita PowerShellu nabízí opravdu rozmanité mnoţství, coţ povětšinou závisí jen na schopnostech a fantazii administrátora. funkce Split() je pravděpodobně nejpouţívanější funkcí pro zpracování textu rozdělením dle definovaného znaku či znaků. V tomto případě dělíme text podle mezery a větné čárky. Obrázek č. 18 Pouţití funkce SPLIT()

Zdroj: Vlastní tvorba.

Dalšími často pouţívanými funkcemi jsou konverze proměnných (většinou v případech pevně definovaných datových typů), kdy jednoduše explicitně definujeme do jaké proměnné se má konkrétní hodnota převést.

37

Obrázek č.19 Pouţití konverze proměnné [string]$a = “123” # $a je datový typ text a tudíţ se nedá pouţít čísla 123 jako čísla. # je nutná konverze do nového datového typu. Cest je opět několik. $b = [int]$a Zdroj: Vlastní tvorba.

Silnějším prostředkem je pak vyuţití regulárních výrazů. Viz následující příklad uţití funkce SPLIT() za pomoci regulárního výrazu. Obrázek č.20 Pouţití regulárních výrazů PS C:\> $s = "Hello-1-there-22-World!" PS C:\> [regex]::split($s,'-[0-9]+-') Hello there World! PS C:\> [regex]::split($s,'-[0-9]+-').count 3 Zdroj: Manning Windows PowerShell in Action[3]

Často pouţívanou funkcí nejen při zpracovávání textů je tzv. seskupování. V PowerShellu je k tomuto účelu vytvořen příkaz Group-Object, který umoţňuje seskupovat libovolné objekty podle celé řady kritérií. Následující příklad ukazuje jedno z pouţití tohoto příkazu při seskupování událostí se systémového logu. Obrázek č.21 Pouţití příkazu Group-Object PS C:\> $events = get-eventlog -logname system -newest 1000 PS C:\> $events | group-object -property eventID Zdroj: Nápověda PowerShell příkazem Get-Help Group-Object, example 4.

3.1.8

DOTNet, COM objekty a doménové služby

Samotné uţívání DOTNET Frameworku, jsem zmínil jiţ mnohokrát. Nyní bych rád poukázal na moţnosti PowerShellu aktivně vyuţívat těchto tříd. Jak Bruce Payette zmiňuje ve své knize: „Jediné co musíme pro úspěšné zvládnutí úkolu při práci s objekty .NET

38

udělat, je najít jejich přesné jméno a typ.[3] (kontextový překlad). Pokud totiţ administrátor zvládne tento krok, je schopen v PowerShellu naskriptovat téměř cokoliv, grafické rozhraní, navazovat databázová spojení, vyuţívat doménové sluţby, spravovat MS Exchange, pracovat s COM objekty či rozhraním WMI, zkrátka téměř všechno, co můţe vyuţívat skutečný programátor .Net C#. Pro vyuţití výše zmíněných objektů se pouţívá příkaz New-Object a definice konkrétní třídy či objektu. Následující příklad otevírá třídu Shell.Application. Po spuštění druhým příkazem se skutečně objeví okno Windows Exploreru, otevřeného na adresáři C:\. Obrázek č.22 Ukázka otevření COM objektu PS C:\> $shell = new-object -com Shell.Application PS C:\> $shell.Explore("c:\") Zdroj: Manning Windows PowerShell in Action[3]

Podobným způsobem se dá navázat spojení s doménou AD, jen místo Shell.Application pouţijeme některou ze sluţeb “System.DirectoryServices”. Vzhledem k náročnosti, komplexnosti a sloţitosti tohoto konkrétního tématu, uvedu dále jen odkaz na knihu Bruce Payetta[3], kde na stránkách 345-437 rozebírá praktické vyuţití uvedených moţností.

39

3.2

Skriptování v PowerShellu

PowerShell je, jak jiţ z uvedeného vyplývá, předurčen k tvorbě automatizačních skriptů. Výbava prostředí co do variability větvení programu nebo tvorby cyklů je na velmi vysoké úrovni a syntaxe uţití příkazů je velmi intuitivní a je zaměřena na efektivní a rychlé pouţívání i z příkazového řádku resp. konzole PowerShellu. 3.2.1

Skripty

Co se spouštění skriptů týče, PowerShell má jistá omezení a pravidla která se musí dodrţovat. Prvním je integritní omezení na spouštění skriptů a to na soubory s koncovkami *.PSC1 resp. *.PS1 a *.PS1XML. Jiná koncovka není pro PowerShell skript přípustná, nicméně se samozřejmě dají prostřednictvím PowerShellu spouštět například soubory prostředí VBScriptu nebo WSH. Navíc hned po čerstvé instalaci prostředí PowerShell se nedá z bezpečnostních důvodů spustit ţádný skript, protoţe jsou zde aplikována poměrně silná, bezpečnostní pravidla. 3.2.2

Bezpečnostní politika

Pomocí příkazů GET/SET-ExecutionPolicy se nastavuje úroveň těchto pravidel, resp. bezpečnostní politiky pro lokální systém. Vzhledem k důleţitosti těchto informací, zde nyní uvádím všechny moţnosti nastavení: -

restricted (omezená) PowerShell nenahrává konfigurační soubory a nespouští ţádné skripty. Toto nastavení je výchozí,

-

allSigned (vše podepsáno) Všechny skripty a konfigurační soubory musí být podepsány důvěryhodným vydavatelem. Toto opatření je platné i pro skripty napsané na lokálním systému,

-

remoteSigned (Vzdáleně podepsané) Digitální podpis musí být platný pro všechny staţené skripty z internetu, skripty napsané na lokálním systému podepsány být nemusí,

-

unrestricted (Neomezené) PowerShell spustí všechny skripty bez omezení, jen u skriptů staţených z internetu se dotazuje na potvrzení spuštění skriptu.

40

3.2.3

Uživatelský profil

Další důleţitou věcí pro skriptování je nastavení uţivatelského profilu. PowerShell totiţ po instalaci vyuţívá standardní, předdefinované nastavení, které je určeno pouze pro čtení a proto se nedají do profilu ukládat například nové funkce, aliasy a podobně. Vytvoření vlastního resp. uţivatelského profilu se provede následujícím příkazem: Obrázek č.23 Tvorba uţivatelského profilu PS C:\> New-Item –path $profile –itemtype file -force Zdroj: Malina,Patrik. Microsoft Windows POWERSHELL[2]

3.2.4

Pravidla při skriptování

Při psaní skriptů v PowerShellu není mnoho pravidel, která musíme dodrţovat. Limitováni jsme samozřejmě syntaxí příkazů, Komentáře Pro zapsání komentářů nebo dalších doplňujících informací, se pouţívá uvozující znak „#“. Tento znak můţeme pouţít i v rámci jedné řádky za příkazy. Uvozovky Častým problémem vypisování proměnných a informačních textů jsou uvozovky spojené s pojícími znaky jako „+“ nebo „&”. V PowerShellu se dají vyuţít standardní uvozovky i pro interpretaci proměnných a to pouhým uvedením proměnné kdekoliv v textu. Pokud chceme zajistit zobrazení skutečných znaků, které v textu jsou, pouţijeme obrácené apostrofy. Obrázek č.24 Pouţití uvozovek a obrácených apostrofů

Zdroj: Vlastní tvorba

3.2.5

Funkce a podprogramy

Funkce je opakovaně pouţitelná část skriptu, která má alespoň jednu výstupní hodnotu. Pouţití funkcí skripty zpřehledňuje a usnadňuje pozdější čtení kódu. V PowerShellu máme k dispozici dvě místa pro umístění funkcí: -

do profilu uţivatele

-

do konkrétního skriptu 41

Do skriptu se kód funkce musí ukládat před vlastním pouţití funkce, tj. obvykle na začátek souboru, ale není to dogma. Interpretor PowerShellu totiţ při spuštění skriptu nekontroluje syntaxi příkazů, ale jen rozloţení cyklů a podmínek co do počtu závorek. Druhou moţností je umístění funkce do profilu uţivatele. To se vyplatí zejména v případech, kdy často provádíme různé sekvence příkazů nebo často potřebujeme zpracovat určitou informaci a chceme ji mít k dispozici kdykoliv spustíme skriptovací prostředí. Příklad z praxe: Nadnárodní oddělení správy aplikačních serverů banky ve které pracuji, spravuje přibliţně 700 serverů rozmístěných v různých lokalitách po celém světě. Naše praţské oddělení má sice na starosti pouze určité lokality, ale často musíme řešit v rámci analýzy určitého problému, příslušnost serveru ke konkrétnímu segmentu našeho oddělení. Proto jsem vytvořil funkci na kontrolu příslušnosti daného serveru konkrétnímu oddělení pod jménem „Get-ServerInfo“, která je uloţena v mém uţivatelském profilu. Nastavil jsem jí alias „gsi“ a jako vstupní parametr pouţívá jméno serveru. Skript pak sahá do síťového adresáře do souboru, který se pravidelně aktualizuje a v němţ jsou uloţena jména serverů, jejich role a příslušnost k oddělení. Výstupem funkce je plný výpis proměnné, která má tři atributy (Jméno, Role, Oddělení), coţ dává další moţnosti pouţití, jako například získání jen příslušného oddělení příkazem z prostředí: Obrázek č.25 Příklad volání vlastní funkce Get-ServerInfo PS C:\> (gsi ServerName).oddeleni Zdroj: Vlastní tvorba

Tato funkce se však dá pouţít zavoláním i z jakéhokoliv externího skriptu za předpokladu, ţe uţivatel, který funkci volá, jí má uloţenou ve svém uţivatelském profilu. 3.2.6

Bezpečnost a podepisování skriptů

Důvodem pro zabezpečení skriptů je samozřejmě bezpečnost na síti, jistota, ţe spouštěný skript je ověřený, zkontrolovaný a funkční a ţe se nejedná o podvrh s případnými destruktivními účinky. Digitální podepisování se řídí platnými a příslušnými certifikáty pro podepisování původu softwaru od vydavatele SW, instalovanými pod OS Windows. Cest, jak získat platný certifikát je hned několik, já však zde představím dvě nejstandardnější: 42

-

První je zakoupit certifikát od vyšší certifikační autority. Tato cesta je poměrně pohodlná, ale drahá.

-

Druhá moţnost je pak instalace vlastní certifikační autority a certifikátu pro podepisování skriptů. K tomuto účelu slouţí aplikace MAKECERT.EXE.

Po korektní instalaci certifikátu do kaţdého operačního systému na kterém ho chceme pouţívat, jej dokáţe PowerShell ihned vyuţívat. Seznam dostupných certifikátů získáme příkazem: Obrázek č.26 Výpis dostupných certifikátů PS C:\> Get-ChildItem cert:\CurrentUser\My –CodeSigning Zdroj: Vlastní tvorba

Podepsání jakéhokoliv skriptu se pak prování příkazem: Obrázek č.27 Podepsání skriptu PS C:\> $cert = @(Get-ChildItem cert:\CurrentUser\My -CodeSigning)[0] PS C:\> Set-AuthenticodeSignature MUJSKRIPT.PS1 $cert Zdroj: Vlastní úprava, inspirováno PAYETTE, Bruce. Windows PowerShell in Action [3]

Po zadání výše uvedeného příkazu, se podpis konkrétního certifikátu (znak [0] v daném případě charakterizuje první nalezený certifikát) umístí na konec souboru. Spuštění takového skriptu je pak řízeno jak nastavením politiky spouštění skriptů v prostředí PowerShell, tak přítomností konkrétního certifikátu instalovaného na operačním systému Windows. V případě komplexní správy sítě a optimálního nastavení bezpečnostních politik ve firmě, se administrátorům nabízí poměrně široké spektrum správy uţivatelů, stanic i serverů. 3.2.7

Ošetřování chyb ve skriptech

Protoţe celý .NET Framework – PowerShell v něm běţící nevyjímaje – je vlastně přísně řízeným prostředím, je i vznik chyb poměrně dobře řízený sled událostí. Nastane-li při běhu skriptu situace, jeţ brání dalšímu hladkému postupu vpřed, mohou se udát vlastně jen dvě věci: je-li problém příliš zásadní, samotný PowerShell ani .NET Framework situaci nezvládnou a jejich běh se fatálně ukončí (coţ moc často, pravda, nenastává). Ve druhém případě nastane situace, označovaná jako výjimka, a ta je jiţ pod plným řízení .NET Frameworku. V praxi to znamená, ţe máme moţnost nastavit chování PowerShellu v takovéto situaci.[2]

43

Jaké jsou tedy mechanismy pro řízení chyb v PowerShellu? Jednak se dá přesměrovat chybový výstup například do souboru, coţ můţe být uţitečné, ale odpovídá to spíše prostředí příkazového řádku a ne tak univerzálnímu prostředí jakým PowerShell beze sporu je. Druhou, daleko zajímavější a inteligentnější metodou je pak zpracovávání chyby pomocí proměnné $error, která standardně narůstá a nabývá chybových hodnot od spuštění konkrétní konzole s PowerShellem. Proměnná $error[0] je vţdy nejnovější chyba. Ve skriptech se potom pouţívá testování chybového stavu za pomoci dotazu „$?“, kdy se vlastně ptáme, zda předešlá operace proběhla v pořádku a odpovědí je booleanovská pravda nebo nepravda. Další moţností je řízení reakce na běhové chyby a tou je vyuţití univerzálního přepínače Error-Action. Při pouţití tohoto přepínače, můţeme určit, jak má skript reagovat, zda má tiše pokračovat (silently continue), zda má vypsat chybu ale nezastavovat (continue), zda se má skript zastavit (stop) nebo zda se má zeptat administrátora, co chce udělat (inquire). Skutečně programové řízení chyb poté řeší příkaz TRAP který má následující formát. Obrázek č.28 Zachytávání chyb v Powershellu Trap {blok příkazů při chybě} Testovaný příkaz Zdroj: MALINA,Patrik. Microsoft Windows PowerShell[2]

V bloku příkazů pak řídíme co se má při chybě stát, zda má skript něco napsat, zda má pokračovat atd. 3.2.8

WMI

Svým způsobem bylo vyvrcholením skriptování na platformě Windows před příchodem PowerShellu

ovládání

systémů

prostřednictvím

rozhraní

Windows

Management

Instrumentation ve skriptech na bázi WSH. Samotné WMI je jakýmsi univerzálním prostředkem pro pokročilou administraci Windows a jako takové je jeho vyuţití součástí řady „velkých“ nástrojů, jako Microsoft Operation Manager či Systém Management Server. Jeho zpřístupnění ve skriptovacím rozhraní pak znamenalo velký krok vpřed díky otevření nových monitorovacích a ovládacích rozhraní bez nutnosti psát sloţité aplikace či zakupovat náročný a drahý software.[2] WMI rozhraní je ideálním prostředkem k získávání detailních informací o systému Windows tedy zejména vhodné pro monitoring, správu a nastavování systému, 44

systémových procesů, vlastností objektů, parametrů a událostí. Jak se jiţ objevilo v citaci Patrika Maliny, WMI bylo vyuţíváno jiţ před příchodem PowerShellu, ať uţ tedy za pomoci různých generátorů skriptů, jako například „WMI Code Creator“, či prostřednictvím „WMI Exploreru“ nebo za vyuţití skriptovacího prostředí WSH, VBScript nebo třeba KiXtartu. Rozebrat do detailu strukturu WMI by bylo na samostatnou bakalářskou práci. Proto zde uvedu některé základní třídy tohoto rozhraní: -

třídy Win32 – Jedná se o základní třídy pro práci s operačními systémy Windows, které jsou součástí jmenného prostoru (namespace) „root\cimv2“. Právě tento jmenný prostor je nejpouţívanější a obsahuje většinu důleţitých informací o operačním systému,

-

třídy WMI Registry – Tyto třídy umoţňují práci s klíči registrů Windows. K dispozici jsou změny, přidávání i mazání nejen klíčů, ale i jejich hodnot,

-

třídy WMI System – Jedná se o předdefinované třídy, které jsou v kaţdém jmenném prostoru WMI. Jsou uvozeny dvojitým podtrţítkem a poskytují mnohé informace o základních funkcionalitách WMI. Tyto třídy jsou v určitém smyslu podobné systémovým tabulkám v SQL serveru,

-

třídy Monitor Display – obsahují informace od WDM poskytovatele (Windows Driver Model) o zobrazovacích jednotkách. Třídy jsou definovány v WMIcore.mof a jsou umístěny ve jmenném prostoru „root\wmi“,

-

třídy WMI Troubleshooting – které poskytují data o operacích WMI,

-

nebo třeba třídy CIM (Common information model) – jeţ slouţí pro vývoj vlastních WMI tříd klonem ze stávajících WMI vzorů,

-

a jiné.

V kaţdém případě vyuţívání WMI vyţaduje jistou dávku znalostí a pochopení souvislostí a vztahů objektů v OS Windows obecně. Navíc byl kód do příchodu PowerShellu poměrně sloţitý a vhodný jen pro skriptování. Abychom lépe ocenili otevřený a přesto nesrovnatelně jednoduchý přístup PowerShellu k WMI, ukáţi nyní příklad přístupu k WMI pro stejnou úlohu nejprve prostřednictvím VBScriptu a poté přes skript PowerShellu a pak také jen jako příkaz z příkazové řádky pro rychlé uţití.

45

Úloha: Ukončit všechny procesy CALC.EXE tedy kalkulačky na vzdáleném počítači „Pokusnik“. Řešení pomocí skriptu jazyka Vbscript: Obrázek č.29 Ukončení všech procesů calc.exe pomocí VBScriptu strComputer = "Pokusnik" svcName = "calc.exe" Set objWMIService = GetObject("winmgmts:" _ & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2") Set colProcessList = objWMIService.ExecQuery _ ("Select * from Win32_Process Where Name = svcName") For Each objProcess in colProcessList objProcess.Terminate() Next Zdroj: Vlastní úprava, inspirováno Jones, Don. Microsoft Windows Administrator‟s Automation Toolkit[1]

Řešení pomocí skriptu jazyka PowerShellu za pouţití stejných prostředků. Obrázek č.30 Ukončení všech procesů calc.exe pomocí skriptu PowerShell $Computer = "Pokusnik" $Name = "calc.exe" $ProcessList = Get-WmiObject Win32_Process –computername $computer | where{$_.name –like $name} ForEach Process in colProcessList {$process.terminate()} Zdroj: Vlastní tvorba

Řešení pomocí skriptu jazyka PowerShellu z příkazové řádky, tj co nejrychlejším způsobem, vyuţitelným samozřejmě i ve skriptu. Obrázek č.31 Ukončení všech procesů calc.exe pomocí příkazové řádky PowerShellu PS C:\> Get-WmiObject Win32_Process –comp „Pokusnik“ | ?{$_.name –like „calc.exe“} | %{$_.terminate()} Zdroj: Vlastní tvorba

46

Zhodnocení úlohy Přestoţe nechci hodnotit vzhled nebo syntaktické principy prostředí VBScriptu, ale jiţ na první pohled se kód zdá být výrazně sloţitější. Část kódu, která má na starost vlastní připojení k WMI a načtení jednotlivých objektů, v tomto případě procesů, se zdá být v porovnání s PowerShellem zbytečně náročná a rozhodně nevhodná pro psaní z ruky. Naproti tomu se zdá být stejná pasáţ v prostředí PowerShellu výrazně jednodušší na pochopení.

Uţivatel

není

zatěţován

nepotřebnými

a

těţko

zapamatovatelnými

syntaktickými frázemi a dá se říci, ţe první tři řádky příkazu ve VBScriptu nám zajišťuje v PowerShellu prosté Get-WmiObject. Kdyţ se navíc podíváme na třetí řešení úlohy, je jasné, ţe sestrojit takový příkaz kdykoliv jej administrátor potřebuje, je poměrně jednoduché. 3.2.9

Správa vzdálených systémů

Právě správa vzdálených systémů je pravděpodobně nejslabší stránkou PowerShellu 1.0. Většina standardních příkazů totiţ nemá podporu pro vzdálené systémy a tak je v základní verzi k dispozici téměř výhradně k administraci těchto systémů, jen rozhraní WMI. Tam se totiţ jen pouţije parametr „-computername <jméno_počítače>“ a jakýkoliv příkaz je prováděn s uvedeným vzdáleným systémem. Znovu zmíním v základní verzi, protoţe určitá síťová rozšíření pro PowerShell 1.0 nabízí některé produkty třetích stran viz následující kapitola. Podstatnější podpory síťových sluţeb se dostalo PowerShellu aţ ve verzi 2.0. Zde jsou sice síťové funkce podporovány, je zde však důleţitá podmínka uţívání. Tou je nutnost, mít na všech spravovaných systémech nainstalovanou verzi PowerShellu 2.0 a správně nastavenou sluţbu WinRM (Windows Remote Management). Teprve poté je moţno pouţívat příkazy pro vzdálené systémy, coţ například ve standardizovaných velkých, mnohdy nadnárodních společnostech, můţe být prozatím problém.

47

3.2.10

Další možnosti shellu

PowerShell je jak jsem jiţ několikrát naznačil otevřený systém, do kterého je moţné přidávat další cmdlety které mohou funkce tohoto prostředí velmi zlepšit. Mezi nejznámější prostředí určená pro PowerShell 1.0 patří: -

prostředí Quest PowerShell – vydaný společností Quest Software, Inc. Jedná se o velmi propracované prostředí PowerShellu s velkou podporou doménových sluţeb, filtrů a dotazů na AD či poštovní sluţby MS Exchange,

-

NetCmdlets vydaný společností /n software inc. (má řadu integrovaných síťových funkcí, od správy poštovního klienta, přes AD, vzdálené přístupy, správu DNS, nebo třeba šifrovacích metod,

-

nebo PowerShell Comunity Extensions vydaný komunitou CodePlex Open Source Comunity, který vytvořil také řadu zajímavých cmdletů většinou lokálního charakteru.

Za zmínku také stojí fakt, ţe i na internetových stránkách MSDN jsou podrobné návody, jak si vytvořit vlastní cmdlety.

48

3.3

Případy užití a porovnání se staršími skriptovacími prostředími

Skriptovací prostředí PowerShell z výše uvedeného jednoznačně dokazuje, ţe se jedná o velmi dynamický a otevřený administrátorský nástroj s řadou moţností vyuţití. Syntaxe příkazů je optimalizovaná na rychlé a efektivní pouţívání z příkazové konzoly i ve vlastních automatizovaných skriptech. Proto nyní pouţiji příkladů uţití z kapitoly 2, kde jsem porovnával jednotlivá skriptovací prostředí, a aplikuji na ně prostředí PowerShell 1.0. 3.3.1

Přihlašovací skripty

PowerShell

je

prostředí

určené primárně

pro

administraci

systémů.

Prostředí

přihlašovacích skriptů je specifické v realizaci připojování sdílených sloţek, tiskáren apod. PowerShell sice umí všechny tyto úkoly zvládnout, nicméně mnohdy daleko sloţitějšími cestami a i oficiální doporučení ze strany Microsoftu je, pouţívat pro přihlašovací skripty jiná prostředí, která lze ovšem spustit právě prostřednictvím PowerShellu a pak vyuţívat ve skriptech příkazů tohoto prostředí. Jako příklad zde uvedu následující část kódu přihlašovacího skriptu PowerShellu, kde spouštíme původní skript napsaný v jazyce VBScript. Obrázek č.32 Spuštění VBScriptu přes PowerShell set objShell = CreateObject( “Wscript.Shell” ) objShell.run( “powershell.exe -noexit c:\scripts\logon.ps1” ) Zdroj: WERNER, Brad. Microsoftblog.globalknowledge.com[8]

3.3.2

Práce s registry Windows

Obecně lze říci, ţe práce s registry Windows je určitou doménou PowerShellu. Stejně jako k ostatním částem systému i k registrům Windows přistupuje Powershell objektově a nabízí rozšířené moţnosti práce s nimi, počínaje prohledáváním a získáváním informací, přes editace či mazání. Navíc můţeme z důvodů vzdálené práce s registry Windows pouţít rozhraní WMI o kterém jsem jiţ mluvil a které je prostřednictvím Powershellu dobře přístupné.

49

Úkol z kapitoly 2, přečíst hodnotu z registru, provedeme v PowerShellu následujícím způsobem. Obrázek č.33 Čtení hodnoty z registru PS C:\> $regKey = „HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion„ PS C:\> (Get-ItemProperty $regKey).ProductName Zdroj: Vlastní tvorba

Rozšířené moţnosti pak dovolují například tvorbu nových PSDrives (coţ jsou ukazatele na jednotlivé zdroje, které PowerShell vyuţívá jako souborové systémy, funkce, registry a jiné), které budou třeba ukazovat na část registrů, kde budeme častěji pracovat. Obrázek č.34 Tvorba nových zdrojů PS C:\> New-PSDrive mojeMisto registry "HKLM:\Software\Microsoft\Windows NT\CurrentVersion" PS C:\> Dir mojeMisto: Zdroj: Vlastní tvorba

3.3.3

Skripty pro správu adresářů a souborů

V této oblasti sice došlo k jistým změnám, nicméně opět spíše k urychlení práce. Klasické příkazy jaké známe z příkazového řádku byly odstraněny a nahrazeny několika obecnými příkazy. Protoţe by ale práce s nimi vyţadovala jisté úsilí, vývojáři rovnou implementovali několik multiplatformních příkazů, resp. aliasů včetně většiny původních příkazů z MSDOSu či obecných příkazů z Uniového světa, které pokrývají všechny potřebné příkazy pro práci se soubory a adresáři. PS C:\> Get-Alias Powershell si však po novu poradí i se sloţitějšími úkoly, jako například změnou práv na souborovém systému, coţ se aţ doposud, většinou řešilo externími aplikacemi např. XCACLS.EXE. PowerShell však díky objektovému přístupu dokáţe i s těmito právy pracovat velmi efektivně a přitom poměrně bezpečně.

50

Obrázek č.35 Nastavení přístupových práv na vybraný soubor systému $fileName = “C:\pokus.txt” $userName = “mojedomena\tomash” $Right="FullControl" # Nacteni aktualnich prav $acl=get-acl $fileName # vytvorime nove bezpecnostni pravidlo $rule=new-object System.Security.AccessControl.FileSystemAccessRule ($userName, $right, “Allow”) # Nastavime nove pravidlo do ulozene promenne, nicmene jeste nebude aktivni $acl.SetAccessRule($rule) # aplikujeme pravidlo na soubor set-acl $FileName $acl Zdroj: Vlastní úprava, JONES, Don. Technet.microsoft.com [6]

3.3.4

Skripty pro správu doménových služeb

Powershell sice dokáţe ve své základní verzi s databází Active Directory pracovat pomocí WinNT i LDAP protokolu, jeţ se řídí standardními pravidly syntaxe. Ze své osobní zkušenosti však musím znovu zmínit a doporučit rozšiřující moduly společnosti Quest Software, Inc., které jsou zaměřeny právě mimo jiné na práci s AD a přidávají do PowerShellu celou řadu uţitečných příkazů pro práci s jednotlivými objekty této databáze a jejich vlastnostmi. 3.3.5

Inventarizace

Z jiţ uvedeného je patrné, ţe jestli PowerShell v něčem vyniká, tak je to získávání informací všeho druhu. Ve verzi 1.0 jsme tedy trochu omezeni standardními příkazy platnými pouze pro lokální systém. Nicméně protoţe stejně většinu informací o systému nakonec získáme prostřednictvím WMI rozhraní, problém s inventarizací vzdálených systémů tímto celkem odpadá. Ve verzi PowerShell 2.0 jiţ můţeme plně vyuţívat i standardních proměnných systému, např. získané příkazem Get-PSProviders.

51

3.3.6

Monitoring

V naší firmě PowerShell primárně vyuţívám právě k monitorování vzdálených systémů. Opět zde musím zmínit vyuţití rozhraní WMI, které poskytuje všechny potřebné informace o vzdáleném systému. Je tedy jen na administrátorovi, aby určil periodiku a předmět testování. V této souvislosti je také namístě zmínit pouţití příkazů s parametrem PSJob (Start, Get, Receive, Stop, Wait, Remove), který je však dostupný opět aţ ve verzi PowerShell 2.0. S jeho pouţitím, lze spouštět různé úlohy na pozadí, coţ lze účinně pouţít právě při monitoringu například aktivace nějaké události nebo změny určitého procesu apod.

52

4 Závěr V této bakalářské práci jsem chtěl odbornou veřejnost seznámit s relativně novým skriptovacím prostředím PowerShell 1.0 a porovnat jeho uplatnění se staršími skriptovacími prostředími na operačních systémech MS Windows. Skriptovací prostředí PowerShell 1.0 je z mého pohledu dynamické a otevřené skriptovací prostředí zaměřené primárně na administraci operačních systémů Windows. Disponuje širokým spektrem nástrojů, uzpůsobeným pro rychlé a efektivní pouţívání jak v příkazovém reţimu, tak v samotných skriptech. Kdyţ jsem porovnával starší skriptovací prostředí v kapitole 2, zjistil jsem, ţe s vyuţitím rozhraní WMI a COM objektů se síly mezi testovanými produkty poměrně vyrovnaly. PowerShell však všechna prostředí předčí svou plně objektovou architekturou, která má velký potenciál. Navíc se PowerShell, ve spojení s objektovou rourou a WMI rozhraním či vyuţitím COM objektů, stává opravdu velmi účinným administrátorským nástrojem. Dále musím velmi kladně ohodnotit příkazovou konzolu PowerShellu, která umoţňuje díky jednoduchosti a intuitivnosti většiny příkazů, efektivně a hlavně dynamicky administrovat systémy Windows. Během studie tohoto výjimečného skriptovacího prostředí, jsem několikrát narazil na překvapující moţnosti a funkce, díky nimţ jsem pochopil skutečnou šíři a potenciál pouţití PowerShellu. V rámci dodrţení osnovy práce a rozsahu vlastní bakalářské práce, jsem se bohuţel nemohl věnovat detailně všem těmto moţnostem a „zákoutím“ PowerShellu. Proto jako námět pro další zkoumání této problematiky, navrhuji samostatné téma PowerShell, nejlépe pak jiţ ve verzi 2.0, se zaměřením na správu vzdálených systémů, popř. administraci operačních serverů MS Windows Server 2008 s podporou technologie Hyper-V.

53

5 Seznam použité literatury Tištěná dokumentace [1] JONES, Don. Microsoft Windows Administrator’s Automation Toolkit: Automatizace správy a skriptování. Brno : Computer Press, a.s. 2006. 404 s. ISBN 80-251-1261-6. [2] MALINA, Patrik. Microsoft Windows PowerShell : Podrobný průvodce skriptováním. Brno : Computer Press, a.s. 2007. 340 s. ISBN 978-80-251-1816-0. [3] PAYETTE, Bruce. Windows PowerShell in Action Greenwich, CT : Manning Publication Co. 2007. 576 s. ISBN 1932394-90-7. Internetové odkazy [4] En.wikipedia.org [online]. 15.1.2009, 23.3.2009 [cit. 1.2.2010]. Windows_Family_Tree.svg. Dostupné z WWW: . [5] Helpdesk.kixtart.org [online]. 2003, 1.5.2003 [cit. 16.3.2010]. KiXtart HelpDesk Network Monitor. Dostupné z WWW: . [6] JONES, Don. Technet.microsoft.com [online]. 2008 [cit. 2010-04-16]. Automate changes to Permissions with Get-ACL, Set-ACL in Windows PowerShell. Dostupné z WWW: . [7] Powershell.com [online]. 5.12.2008 [cit. 16.2.2010]. Multidimensional array - Power Tips. Dostupné z WWW: . [8] Technet.microsoft.com [online]. 2000 [cit. 22.2.2010]. Microsoft Windows 2000 Scripting Guide - Reading From and Writing to the Local Registry. Dostupné z WWW: . [9] WERNER, Brad. Microsoftblog.globalknowledge.com [online]. 14.9.2009 [cit. 16.3.2010]. Power to the People (Windows PowerShell Logon Scripts). Dostupné z WWW: . [10]

Www.kixtart.org [online]. 6.11.2004 [cit. 3.3.2010]. List Registry Startup Items.

Dostupné z WWW: . 54

6 Seznam použitých obrázků Obrázek Stránka číslo

Popis

číslo 1

10 Příklad výpisu interních příkazů operačního systému MS-DOS

2

11 Přehled operačních systémů Windows společnosti Microsoft

3

20 Čtení z registru Windows v prostředí příkazového řádku

4

20 Čtení z registru Windows v prostředí VBScriptu

5

20 Čtení z registru Windows v prostředí WSH

6

21 Čtení z registru Windows v prostředí KiXtart

7

27 Výpis příkazů pro práci se sluţbami systému Windows

8

28 Podmínka IF s pouţitím operátorů

9

28 Kontrukce příkazu SWITCH

10

29 Kontrukce cyklů FOR, FOREACH a WHILE

11

30 Ukázka práce s polem proměnných.

12

31 Ukázka práce s asociativním polem

13

32 Pouţití aplikace TASKLIST.EXE k získání objektů

14

33 Pouţití příkazu Get-Process

15

33 Formátování výstupu

16

34 Pouţití podmínky WHERE a cyklu FOREACH pro ukončení běţících procesů

17

35 Pouţití funkce WHATIF

18

36 Pouţití funkce SPLIT()

19

36 Pouţití konverze proměnné

20

36 Pouţití regulárních výrazů

21

37 Pouţití příkazu Group-Object

55

22

37 Ukázka otevření COM objektu

23

39 Tvorba uţivatelského profilu

24

39 Pouţití uvozovek a obrácených apostrofů

25

40 Příklad volání vlastní funkce Get-ServerInfo

26

41 Výpis dostupných certifikátů

27

41 Podepsání skriptu

28

42 Zachytávání chyb v Powershellu

29

44 Ukončení všech procesů calc.exe pomocí VBScriptu

30

44 Ukončení všech procesů calc.exe pomocí skriptu PowerShell

31

44 Ukončení

všech

procesů

calc.exe

pomocí

příkazové

PowerShellu 32

46 Spuštění VBScriptu přes PowerShell

33

47 Čtení hodnoty z registru

34

47 Tvorba nových zdrojů

35

48 Nastavení přístupových práv na vybraný soubor systému

56

řádky