PowerShell po polsku

Większość z nas ma profil. Na nk, fejsbuku, golden lajn itd. itp. Ale czy nie byłoby świetnie móc podobnie przygotować sobie środowisko pracy? Pracując z cmd, czy nawet z vbs, takich możliwości w zasadzie nie było. A nawet jeśli były, niczym nie przypominały profili znanych z powłok *nixowych. PowerShell i tutaj nas nie zawodzi. Dziś chcę wspomnieć jedynie o podstawach: jakie profile posiadamy (potencjalnie), do czego służą i jak w prosty sposób “dobrać się” do nich z poziomu samego hosta.

1. Od ogółu do szczegółu.

PowerShell, jak wiadomo, może objawiać się w wielu postaciach: powershell.exe, ISE, PowerGUI… Każdy z tych hostów może wymagać innego traktowania. Oprócz tego część rzeczy może być przydatna dla wszystkich, część jest bardziej osobista i wymaga profilu osobnego. MS uwzględnił te potrzeby definiując cztery podstawowe profile:

Ścieżki wszystkich profili są na sztywno zdefiniowane. Ma to oczywiście i wady (potencjalny wektor dla ataków typu ‘inject code’) jak i zalety (na każdym komputerze można bez trudu je odnaleźć i skonfigurować). Co w nich umieszczać? W najbardziej ogólnych można zdefiniować korporacyjne środowisko: przydatne dla wszystkich aliasy, funkcje, dyski. W tych przeznaczonych dla konkretnego hosta dodatkowo ustawić parametry dla tego hosta właściwe (menu w ISE, czy rozmiar kursora w powershell.exe). A dla poszczególnych użytkowników: ładowane na starcie moduły, własne funkcje, zmienne, aliasy. I oczywiście na ostatnim poziomie wszystko to, co przyda się tylko nam, w danej aplikacji (w ISE startowe ustawienie zakładek, kolory we wbudowanym edytorze a  w powershell.exe kolorki dla informacji typu debug i error np.). Oczywiście to tylko luźna propozycja, a raczej opis tego jak ja bym to podzielił. Plus takiej granularnej budowy jest chyba oczywisty: pewne rzeczy możemy narzucić (jeśli zależy nam na spójnej bazie aliasów np.) i ustawić przy pomocy GPO na wszystkich komputerach w naszej organizacji – dzięki temu siadając do każdego komputera możemy założyć pewne rzeczy odnośnie środowiska. A jeśli czegoś nam osobiście brakuje – wystarczy zdefiniować to w naszym osobistym profilu. Drugi plus jest taki, że profile ‘AllUsers’ wymagają odpowiednio wysokich uprawnień, więc nie ma możliwości by ktoś z niższymi uprawnieniami nam te profile ‘zepsuł’.

2. Znaleźć, stworzyć, zmodyfikować.

Zespół tworzący PowerShella zadbał o naszą wygodę. Stworzył zmienną o dość jednoznacznej nazwie: $profile. Zmienna jest typu string i zawiera ścieżkę do ostatniego elementu naszego profilowego łańcucha: CurrenUserCurrentHost. Dzięki temu mamy łatwy dostęp do profilu, który określa naszą bieżącą powłokę. Ale to nie wszystko – nazwy wyszczególnione w tabeli powyżej odnoszą się do nazw właściwości dodanych do zmiennej $profile by uczynić pracę z profilami jeszcze prostszą: $profile.AllUsersAllHosts, $profile.CurrentUserAllHosts itd. Dzięki temu wszystko mamy ‘na tacy’. Praca z profilami jest rzeczą, która zwłaszcza na początku może nieco zirytować. Aby tego uniknąć, trzeba pamiętać o trzech rzeczach:

1. Profile nie istnieją ‘domyślnie’, a zmienna $profile zawiera jedynie string, jej obecność niczego nie przesądza.
2. Folder, w którym profile mają być przechowywane zwykle też nie istnieje, więc notpepad $profile raczej nie zadziała.
3. Profil to skrypt – by działał musi być zgodny z naszą ExecutionPolicy. Jeśli więc mamy inną niż Unrestricted (takie ustawienie zdecydowanie odradzam) to może nie zadziałać, nawet jeśli go już stworzymy.

Więc po pierwsze primo: stwórzmy nasz profil:

if (!(Test-Path $profile)) {            
    New-Item -ItemType File -Path $profile -Force            
}

Jak widać najpierw upewniamy się, że profilu nie stworzyliśmy wcześniej. Jeśli nie – zostanie on stworzony (razem z folderem, w którym powinien się znajdować – dzięki parametrowi –Force).

Po drugie: otwórzmy go przy pomocy edytora. Odradzam notepad.exe, nawet jeśli chcecie używać tylko powershell.exe najlepiej skorzystać z ISE. Piszemy więc:

ise $profile

I dodajemy wszystko, co nam potrzebne. Na koniec pozostaje plik ten zapisać i wczytać. Teraz możliwości są dwie: restart hosta (zwykle to przesada) lub wgranie profilu na żywym organiźmie. Ponieważ z założenia profil modyfikuje naszą sesję odpowiednikiem restartu byłoby uruchomienie $profile bez tworzenia nowej przestrzeni nazw (scope –> na pewno da się to przetłumaczyć lepiej…). Aby to zrobić używamy operatora: . $profile

Z ExecutionPolicy może być pewien problem. Idealnym rozwiązaniem byłoby ustawienie jej na AllSigned (czyli podpisujemy wszystkie skrypty) i podpisanie profili. To często jednak wymaga sporego nakładu pracy, jeśli nie mamy własnego certyfikatu do podpisywania kodu źródłowego. Zalecany kompromis to opcja RemoteSigned. W kolejnych częściach przedstawię ciekawe rozwiązanie, które pozwala tego uniknąć na poziomie systemu a pozwala ustawić na poziomie interaktywnej sesji. Alternatywą – niezbyt wygodną, a na pewno bezpieczną – jest ręczne uruchamianie PowerShella z odpowiednią ExecutionPolicy, ale na to pozwala tylko powershell.exe (ma on parametr –ExecutionPolicy, który pozwala w dowolny sposób wartość ExecutionPolicy zmienić).

Cudownie. Mamy więc profil, profil śmiga, ale co tam wepchnąć? Moje propozycje na ten temat postaram się umiescić w drugiej części tego cyklu. 🙂

~ - autor: Bartek Bielawski w dniu 15 marca, 2011.

Napisane w PowerShell
Tagi: Początki, PowerShell, profile