Skriptovací jazyky - PowerShell v praxi

Transkript

1 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: Ing. Vladimír Beneš Petrovický Praha duben, 2010

2 Prohlášení: Prohlašuji, ţe jsem bakalářskou práci zpracoval samostatně a s pouţitím uvedené literatury. V Praze dne: Tomáš Hypš

3 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.

4 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

5 OBSAH 1 ÚVOD SKRIPTOVÁNÍ V PRAXI SYSTÉMOVÉHO ADMINISTRÁTORA HISTORIE OPERAČNÍCH SYSTÉMŮ SPOLEČNOSTI MICROSOFT SKRIPTOVACÍ PROSTŘEDÍ POD MS WINDOWS MS příkazový řádek a dávkové soubory (Batch files) VBScript WSH (Windows Script Host) KIXTART PŘÍPADY UŢITÍ SKRIPTOVÁNÍ A JEJICH ŘEŠENÍ Přihlašovací skript Práce s registry Windows Skripty pro správu adresářů a souborů Skripty pro správu doménových služeb Inventarizace Monitoring SHRNUTÍ KAPITOLY SKRIPTOVACÍ JAZYK POWERSHELL ZÁKLADNÍ STAVEBNÍ PRVKY A NÁSTROJE JAZYKA POWERSHELL Základní příkazy PowerShellu Konstrukce jazyka, podmínky Konstrukce jazyka, cykly Proměnné, pole a datové typy Objektová roura Systém nápovědy, příklady a funkce WhatIf Zpracování textu DOTNet, COM objekty a doménové služby SKRIPTOVÁNÍ V POWERSHELLU Skripty Bezpečnostní politika Uživatelský profil Pravidla při skriptování Funkce a podprogramy Bezpečnost a podepisování skriptů... 42

6 3.2.7 Ošetřování chyb ve skriptech WMI Správa vzdálených systémů Další možnosti shellu PŘÍPADY UŢITÍ A POROVNÁNÍ SE STARŠÍMI SKRIPTOVACÍMI PROSTŘEDÍMI Přihlašovací skripty Práce s registry Windows Skripty pro správu adresářů a souborů Skripty pro správu doménových služeb Inventarizace Monitoring ZÁVĚR SEZNAM POUŽITÉ LITERATURY SEZNAM POUŽITÝCH OBRÁZKŮ... 55

7 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

8 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 VBA 1 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

9 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

10 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-DOS 2 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

11 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: Roku 1992 pak Microsoft přepsal kritické části systému do assembleru 4, 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 Kit 5 pro MS- DOS 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

12 první verze VBScriptu 6 (Visual Basic Script) s podporou COM 7 objektů (Component Object Model) a správcovského rozhraní WMI 8. S vydáním operačního systému Windows 98, vydává MS v roce 1998 první verzi skriptovacího prostředí WSH (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 Directory 10 (dále AD), s vyuţitím datového přístupu LDAP 11. 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 Longhorn 12. 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 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

13 Server. Nicméně oba operační systémy a jejich různé prodejní verze vydala aţ v létě 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

14 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 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.EXE 13 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

15 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.EXE 14. 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 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 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

16 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 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é skripty 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

17 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

18 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 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

19 - 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 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ů 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

20 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 = &H 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 20

21 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 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 ROBOCOPY.EXE 16, 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

22 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 WinNT 17 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 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í: - 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, 17 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

23 - 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 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

24 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

25 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

26 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 Monad 18. Š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 Pochází z Řecké filozofie a jedná se o označení Prvního nebo také Boha mezi všemi. 26

27 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 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

28 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

29 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 (<rozhodující_podmínka>) {<příkazový_blok_při_platnosti>} Else {<příkazový_blok_při_neplatnosti>} 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

30 Obrázek č.9 Konstrukce příkazu SWITCH Switch(<$řídící_proměnná>) { Hodnota1 { <blok1> } Hodnota2 { <blok2>} Default { <blokd> } } 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 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

31 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] 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

32 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] Jednotlivý znak, - [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] 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

33 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 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

34 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

35 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

36 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 Get- Help 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

37 Obrázek č. 17 Pouţití funkce WHATIF Zdroj: Vlastní tvorba 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

38 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 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

39 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 rozebírá praktické vyuţití uvedených moţností. 39

40 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 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 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

41 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] 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 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