Etykiety

wtorek, 31 stycznia 2017

Jak ustawić przerwę techniczną witryny www

Podczas gdy możliwość ustawienia przerwy technicznej przeważnie nie ma większego sensu dla prostych serwisów web, to w przypadku bardziej złożonych witryn bywają sytuacje, w których warto tymczasowo całkowicie uniemożliwić dostęp użytkowników do treści stron. Są to przeważnie okoliczności związane z modyfikacją skryptów odpowiedzialnych za wyświetlanie treści lub z ingerencją w strukturę baz danych związanych z serwisem. Żaden webmaster raczej by nie chciał by osoby wówczas odwiedzające serwis napotykały się na wyświetlane błędy lub nieprawidłowe treści związane z wprowadzaniem modyfikacji lub z testowaniem nowych funkcjonalności serwisu.

Pomimo iż istnieje zgodny z dobrymi praktykami sposób na ustawienie przerwy technicznej serwisu www, to w praktyce webmasterzy posługują się w tym celu różnymi metodami mniej lub bardzie eleganckimi i mniej lub bardziej technicznie odpowiednimi. Niektóre z tych metod mogą bardzo negatywnie wpłynąć, nie tylko na reputację serwisu wśród odwiedzających, ale także na pozycję stron w wyszukiwarkach.

A może tak mała przerwa techniczna?
A może tak mała przerwa techniczna?

W przypadku konieczności ustawienia tymczasowej przerwy technicznej zdecydowanie odradzam wyłączać lub ograniczać funkcjonalność serwera www, ograniczać dostęp do serwisu za pomocą chronionych katalogów, reguł firewalla, bądź bezpośrednio wysyłając nagłówki z poziomu skryptów php za pomocą funkcji header(). Tego typu praktyki nie są przeważnie idealne dla przerwy technicznej, a mogą wręcz być przyczyną wielu negatywnych sytuacji.

W tym tutorialu przedstawię prosty i prawidłowy sposób ustawienia przerwy technicznej dla serwisu web obsługiwanym przez serwer Apache 2.x. Jest to sposób w pełni zgodny z dobrymi praktykami webmasterskimi.

W celu ustawienia przerwy technicznej w serwisie www w sposób omawiany w niniejszym artykule, muszą zostać spełnione następujące, wstępne warunki:

Moduł Apache mod_rewrite


Moduł Apache mod_rewrite (rewrite_module) umożliwia przekierowywania url, które w przypadku przerwy technicznej powinny kierować użytkownika na adres url, pod którym znajduje się dokument web informujący o tymczasowej sytuacji, w przypadku żądań HTTP dotyczących każdego innego adresu url, znajdującego się na domenie serwisu. Przed przejściem do dalszej części tego artykułu należy się upewnić, że moduł ten jest uruchomiony i działa prawidłowo. Można tego dokonać na kilka różnych sposobów. Najprostszym z nich może być, jeśli mamy dostęp do konsoli:

apachectl -M | grep rewrite_module

Innym prostym sposobem jest wywołanie polecenia php phpinfo() i sprawdzenie statusu modułu mod_rewrite w wyświetlanych wynikach skryptu.

Aby załadować moduł Apache mod_rewrite, jeśli nie jest jeszcze załadowany, należy dodać poniżej przedstawiony wiersz do pliku httpd.conf, lub do pliku /etc/httpd/conf.modules.d/, w zależności od dystrybucji systemu, po czym należy uruchomić ponownie serwer Apache:

LoadModule rewrite_module modules/mod_rewrite.so

Plik .htaccess


Plik .htaccess jest miejscem, w którym można ustawić wiele istotnych parametrów serwera www, które mają obowiązywać dla danego katalogu i ewentualnie jego podkatalogów, pod warunkiem, iż nie zawierają one kolejnych plików .htaccess z innymi ustawieniami, jeśli przetwarzanie plików .htaccess dla tych podkatalogów jest włączone. Aby ustawienia znajdujące się w tym pliku miały efekt, musi właśnie zostać włączona ich obsługa dla danego katalogu. Ustawień tych dokonujemy w głównym pliku konfiguracyjnym serwera Apache, czyli httpd.conf. Aby włączyć obsługę pliku .htaccess dla danego katalogu serwisu www, należy w sekcji <Directory> związanej z tym katalogiem dodać następujący wpis, jeśli jeszcze nie jest on tam obecny:

AllowOverride All

Przerwa techniczna: strona informująca o przerwie


Aby przekierowanie do dokumentu informującego o tymczasowej przerwie technicznej przyniosło efekt należy stworzyć dokument web z właściwą dla tej okoliczności informacją. Dla zgodności z niniejszym tutorialem, plik może mieć przykładową nazwę przerwaTechniczna.html i może znajdować się w głównym katalogu www serwera Apache, czyli lokalizacji określonej jako DocumentRoot w pliku konfiguracyjnym httpd.conf.

Przerwa techniczna: ustawienia .htaccess


Zakładając, że moduł mod_rewrite, o którym pisałem wcześniej, działa prawidłowo, a obsługa plików .htaccess jest włączona dla katalogów związanych z naszym serwisem, możemy teraz przystąpić do wprowadzenia odpowiednich, przykładowych wierszy „przerwy technicznej" do pliku .htaccess związanego z naszą witryną:

<IfModule mod_rewrite.c> RewriteEngine on RewriteCond %{DOCUMENT_ROOT}/przerwa-techniczna -f RewriteCond %{REMOTE_ADDR} !^192\.168\.0\.1 RewriteCond %{REQUEST_URI} !przerwaTechniczna.html$ [NC] RewriteCond %{REQUEST_URI} !\.(jpe?g?|png|gif) [NC] RewriteRule .* /przerwaTechniczna.html [R=302,L] </IfModule>

Świetnie! Ale, co to wszystko oznacza?

W sekcji rozpoczynającej się od <IfModule mod_rewrite.c>, a kończącej na &lt/IfModule&gt znajdują się dyrektywy serwera Apache, które są przetwarzane tylko w przypadku prawidłowo działającego modułu mod_rewrite, w celu uniknięcia błędów. Dyrektywa 'RewriteEngine on' włącza przekierowania url, a kolejne wiersze ustawień przekierowują użytkownika do dokumentu informującego o przerwie technicznej w przypadku żądań HTTP dotyczących każdego innego adresu url witryny. Warunkiem przekierowań jest obecność pliku o przykładowej nazwie przerwa-techniczna w głównym katalogu www, określonego jako 'DocumentRoot' w pliku httpd.conf. Przekierowanie jednak nie następuje w przypadku wywołania plików zawierających grafikę, bądź wywołania adresu url dokumentu informującego o przerwie (aby uniknąć nieskończonej pętli przekierowań). Dodatkowo, użytkownicy, którzy łączą się z witryną z adresu 192.168.0.1 (tutaj adres klasy 'C' - dla przykładu - ten adres można oczywiście dowolnie zmienić) nie zostają przekierowani do dokumentu informującego o przerwie technicznej, co oznacza, że mają pełen dostęp do treści serwisu. Dostęp do serwisu w trakcie przerwy technicznej może okazać się przydatny np. webmasterom.

Warto również zauważyć, że przekierowanie następuje z kodem HTTP Error 302 (moved temporarily), co stanowi cenną informację dla robotów indeksujących zawartość witryny. W przypadku prawidłowo ustawionej przerwy technicznej, klient żądający dostępu do przekierowywanych adresów uri, otrzymuje następującą, przykładową odpowiedź HTTP:

HTTP/1.1 302 FoundLocation: http://naszadomena/przerwaTechniczna.html

Ustawienia wstępne gotowe. Czas włączyć przerwę techniczną!


Po dokonanych ustawieniach wstępnych, aby włączyć przerwę techniczną, należy utworzyć plik, o przykładowej nazwie, zgodnej z nazwą obecną w regułach przekierowań w pliku .htaccess, która w naszym przykładzie brzmi 'przerwa-techniczna'. Dopóki plik ten będzie istniał we wskazanym katalogu, obowiązywała będzie przerwa techniczna, co oznacza, że odwiedzający będą przekierowywani do dokumentu web o niej informującym.

Podobnie, aby zakończyć przerwę techniczną i przywrócić pełną dostępność serwisu, wystarczy usunąć plik 'przerwa-techniczna' z katalogu.

Oczywiście nie ma sensu każdorazowo tworzyć i usuwać tego pliku ręcznie, gdyż można w tym celu przygotować bardzo prosty skrypt php, składający się z zaledwie kilku wierszy, który będzie wykonywał tą czynność za nas.

Powodzenia! W przypadku uwag lub wątpliwości bardzo proszę o komentarze. Będę starał się na nie odpowiadać tak szybko, jak tylko będzie to możliwe.

sobota, 28 stycznia 2017

Samba - kontroler domeny Active Directory

Samba jako kontroler domeny Active Directory


Nie mam zamiaru zanudzać czytelników kolejnym tutorialem związanym z instalacją i konfiguracją oprogramowania Samba w roli kontrolera domeny Active Directory. W sieci jest mnóstwo artykułów związanych z tym tematem, a niektóre z nich są naprawdę dobre i mogą się okazać bardzo przydatne. Tym, którzy chcieliby poznać prawidłową procedurę polecam anglojęzyczny artykuł Setting up Samba as an Active Directory Domain Controller.

W niniejszym artykule, skupiając się głównie na podstawowych etapach konfiguracji oprogramowania Samba jako kontroler domeny Active Directory, mam zamiar udzielić kilku ważnych porad i wskazówek, dotyczących typowych problemów i niejasności.

Gdzie jest Samba-Tool


Samba-Tool jest podstawowym narzędziem konfiguracyjnym oprogramowania Samba w roli kontrolera domeny Active Directory. Służy ono, między innymi, do wstępnego prowizjonowania domeny (domain provision), ale nie tylko. Samba-tool umożliwia wręcz rozmaite czynności administracyjne.

Wielu użytkowników dystrybucji Linux takich jak Centos, czy Scientific Linux, wpada w niepokój gdy po dokonanej instalacji pakietów Samba z oficjalnego repozytorium własnej dystrybucji, nie może zlokalizować narzędzia Samba-Tool. Gdzie jest Samba-Tool? Na to pytanie napotkałem się w wielu mailach, a nawet w licznych rozmowach z osobami chcącymi postawić kontroler domeny Active Directory rodem Samba. Otóż odpowiedź na pytanie „gdzie jest Samba-Tool” jest taka, że w niektórych dystrybucjach Linux oficjalnie narzędzie Samba-Tool nie jest dostępne, pomimo iż dostępne są tam pakiety Samba. Są to bowiem pakiety Samba nie wspierające funkcjonalności Samba jako kontrolera domeny Active Directory. Najbardziej dociekliwi użytkownicy wydają w takich przypadkach komendy typu:

yum whatprovides "*samba-tool"

Lecz jedyne co uzyskują w powyższy sposób, to pewność, iż oficjalna dystrybucja nie udostępnia narzędzia samba-tool.

Dystrybucje Linux, które do dziś oficjalnie nie wspierają funkcjonalności Active Directory pakietów Samba to:
  • Red Hat
  • Fedora
  • Centos
  • SL (Scientific Linux)

W takich przypadkach absolutnie nie polecam dodawania obcych repozytoriów, typu sernet, w celu skorzystania z narzędzia yum do instalacji pełnowartościowej wersji Samba Active Directory. Mogą z tego wyniknąć późniejsze kłopoty z kompatybilnością niektórych bibliotek. Najlepsze co można zrobić, w przypadku braku dostępności narzędzia samba-tool w oficjalnych pakietach Samba dla danej dystrybucji, to kompilacja oprogramowania Samba ze źródła, co gorąco polecam. Pliki źródłowe Samba można ściągnąć z oficjalnej witryny Samba. Proces kompilacji nie jest absolutnie skomplikowany i jest bardzo dobrze opisany w dokumencie Build Samba from Wource. Jeśli zdecydujecie się na kompilację oprogramowania ze źródła, radzę przeprowadzić operację standardowo, bez podawania dodatkowych parametrów konfiguracyjnych jeśli nie zachodzi taka konieczność. W efekcie oprogramowanie zostanie zainstalowane w:

\usr\local\samba

Wszystkie ścieżki systemowe oprogramowania Samba widniejące w niniejszym artykule zakładają kompilację ze źródła z domyślnymi parametrami konfiguracyjnymi.

Prowizjonowanie domeny


Jak już wspomniałem wcześniej, wstępna konfiguracja oprogramowania Samba w roli kontrolera domeny Active Directory wymaga użycia narzędzia samba-tool, które tworzy odpowiednie wpisy DNS jak również konfiguruje nowego użytkownika, administratora domeny.

Uwaga: przed użyciem narzędzia Samba-tool należy usunąć ewentualnie już istniejący plik smb.conf, ponieważ Samba oficjalnie nie umożliwia zmiany domeny Active Directory.

Aby uruchomić Samba Tool w trybie interaktywnym, w celach związanych z prowizjonowaniem nowej domeny Active Directory, wystarczy wpisać:

[root@amanda2 ~]# samba-tool domain provision

Samba-tool: Nazwa domeny Active Directory


Wybór nazwy domeny Active Directory nie powinien sprawiać większych kłopotów, jeśli będzie to jedyna domena dla naszych komputerów. Jednak jaką nazwę domeny wybrać, jeśli na jednym z naszych serwerów jest uruchomiona usługa DNS i komputery, które mają znaleźć się w nowej domenie, znajdują się już na jednej z obsługiwanych domen? Idąc w zgodzie w Microsoft Best Practices związanymi z tym tematem, najlepszym miejscem na nową domenę będzie pod-domena o krótkiej i niepowtarzalnej nazwie. Przykładowo, jeśli na serwerze mamy już domenę o nazwie domena.com, to najlepszym miejscem na nową domenę Active Directory będzie pod-domena o nazwie nowa.domena.com. Czyli przykładowo, postępując zgodnie z terminologią Active Directory:
[root@amanda2 ~]# samba-tool domain provision Realm [NOWA.DOMENA.COM]: Domain [NOWA]:

Samba-Tool: DNS Backend


Active Directory korzysta z wpisów DNS, co oznacza, że tego typu wpisy będą potrzebne dla prawidłowego działania usług. W zakresie automatycznego utworzenia początkowych wpisów DNS, niezbędnych do inicjalizacji usług Active Directory, oraz ewentualnie sposobu ich sukcesywnej aktualizacji, samba-tool daje nam możliwość wyboru jednej z kilku dostępnych opcji. Można dokonać wstępnej konfiguracji usługi Active Directory wybierając jedną z poniżej przedstawionych opcji DNS.

SAMBA_INTERNAL: Jest to wewnętrzna usługa DNS oprogramowania SAMBA. Warto ją wybrać jeśli na maszynie, na której instalujemy Samba, nie jest uruchomiony żaden serwer DNS, np. BIND.

BIND9_DLZ: Obsługa wpisów DNS strefy Active Directory poprzez moduł DLZ serwera BIND. Wybór tej opcji umożliwia automatyczne odświeżanie wpisów DNS strefy za pomocą kluczy dns. Warto wybrać tą opcję jeśli na naszej maszynie pracuje już serwer BIND, w wersji co najmniej 9.8, bądź mamy zamiar obsługiwać dużą domenę ze złożonymi usługami. W przypadku wyboru tej opcji i po pomyślnym prowizjonowaniu nowej domeny, w ścieżce \usr\local\samba\private pojawią się 2 ważne pliki, które trzeba będzie załączyć do pliku konfiguracyjnego named.conf. Uwaga: BIND musi działać na tej samej maszynie co serwer Samba! Dokładne instrukcje znajdują się na stronie: Konfiguracja modułu BIND DLZ

BIND9_FLATFILE: Ta opcja tworzy statyczny plik z wpisami DNS dla nowej strefy, który należy załączyć do konfiguracji serwera BIND. Wybór tej opcji nie jest zalecany, a w przyszłości opcja ta ma zostać wycofana.

NONE: Tej opcji oczywiście nie możemy wybrać, jeśli serwer Samba ma obsługiwać domenę z usługami Active Directory :-)

Ważne, lecz często pomijane, czynności konfiguracyjne


Po udanym skonfigurowaniu domeny Active Directory za pomocą narzędzia samba-tool należy pamiętać o utworzeniu symbolicznego powiązania:

ln -sf \usr\local\samba\private\krb5.conf \etc\krb5.conf

W przypadku dokonania wyboru backend DNS BIND9_DLZ należy pamiętać o dołączeniu plików konfiguracyjnych, o których wspomniałem wcześniej, do konfiguracji BIND named.conf, po czym należy zrestartować BINDa.

Przyłączanie maszyn Windows 10 do domeny AD


Uwaga: system w Windows w wersji HOME nie umożliwia przyłączenia maszyny do domeny!

W celu przyłączenia maszyny z systemem Windows 10 do domeny należy:
  • Zalogować się do systemu Windows 10 jako Administrator, bądź skorzystać z konta z odpowiednimi uprawnieniami;
  • Przejśc do: Panel sterowania\System i zabezpieczenia\System;
  • Przejść do sekcji "Nazwa komputera, domena i ustawienia grupy roboczej";
  • Zmienić ustawienia identyfikatora sieciowego, wybierając odpowiednią domenę;
  • Postepując z intrukcjami kreatora, wprowadzić i potwierdzić poświadczenia Administratora domeny, bądź użytkownika uprawnionego do przyłączania maszyn do domeny;


Przyłączanie komputera Windows 10 do domeny
Przyłączanie komputera Windows 10 do domeny


Typowe problemy z DNS w przypadku korzystania z modułu BIND_DLZ


Jeśli w trakcie przyłączania maszyny Windows do domeny AD pojawia się monit o poświadczenia uprawnionego użytkownika, po czym mija sporo czasu, a następnie otrzymujemy powitanie w nowej domenie, lecz w końcu pojawia się informacja, że Windows jednak nie może skontaktować się z kontrolerem domeny, oznacza to pewien problem z modułem BIND_DLZ. Typowy komunikat tego typu może wyglądać przykładowo tak:

Wystąpił błąd: "Nazwa DNS nie istnieje." (kod błędu 0x0000232B RCODE_NAME_ERROR) Zapytanie dotyczyło rekordu SRV dla _ldap._tcp.dc._msdcs.domena.com Najczęstsze przyczyny tego błędu są następujące: - Rekordy SRV DNS wymagane do zlokalizowania kontrolera domeny usługi AD dla domeny nie są zarejestrowane w usłudze DNS. Te rekordy są automatycznie rejestrowane na serwerze DNS podczas dodawania kontrolera domeny usługi AD do domeny. Są one aktualizowane przez kontrolera domeny usługi AD w ustalonych odstępach czasu. Ten komputer jest skonfigurowany do używania serwerów DNS z następującymi adresami IP: 192.168.0.10 - Jedna lub więcej stref nie zawiera delegowania do strefy podrzędnej: domena.com com . (strefa główna)


Powyższy, przykładowy, komunikat może się nieco różnić, a może też dotyczyć innego rodzaju wpisów dns. W takim przypadku, aby rozwiązać problem, należy - po stronie serwera Samba - wykonać poniżej przedstawione polecenie, po czym zrestartować BINDa:

samba_upgradedns --dns-backend=BIND9_DLZ


Skrypty Samba systemd


W przypadku kompilowania oprogramowania ze źródła, skrypty systemd nie są automatycznie tworzone, jak ma to miejsce w przypadku korzystania z oficjalnych repozytoriów dystrybucji. W takiej sytuacji trzeba samemu utworzyć odpowiednie pliki. Jak prawidłowo zarządzać serwerem Samba AD w środowisku systemd? Otóż cała procedura jest bardzo dokładnie opisana tutaj Samba w środowisku, więc nie ma sensu jej ponawiać.

Konfigurowanie usług i użytkowników AD


Po udanej instalacji i prawidłowym skonfigurowaniu oprogramowania Samba w roli AD DC, w celu skonfigurowania użytkowników i komputerów usługi Active Directory należy pobrać z witryny Microsoft i zainstalować pakiet RSAT, a następnie zalogować się do domeny, jako Administrator domeny, z dowolnej maszyny Windows, która została uprzednio przyłączona do domeny AD. Po zalogowaniu się do domeny AD w opisany sposób można zacząć zarządzać domeną i obiektami Active Directory, uruchamiając narzędzia zawarte w pakiecie RSAT, jak zostało to opisane w artykule Narzędzia administracji zdalnej serwera - omówienie:

Użytkownicy i komputery usługi Active Directory
Użytkownicy i komputery usługi Active Directory


Podsumowanie


Uważam, że poruszyłem tutaj kilka ważnych kwestii, których omówienia nie znalazłem w sieci. W przypadku pytań, wątpliwości, a nawet innych kwestii technicznych dotyczących tematu Samba, bardzo proszę o komentarze. Postaram się służyć pomocą.

środa, 25 stycznia 2017

Windows PowerShell - Informacje o dyskach

W niniejszym artykule mam zamiar omówić sposoby uzyskiwania szczegółowych informacji o dyskach fizycznych podpiętych do komputera pracującego pod kontrolą systemu operacyjnego Windows, w tym także informacji o dyskach podpiętych do maszyn Windows znajdujących się w sieci. Omówione tutaj sposoby oparte będą na poleceniach Windows PowerShell 5.0.

Windows PowerShell 5.0 omówiłem już wstępnie w artykule Wstęp do Windows PowerShell 5.0. Obiekty PowerShell też zostały już wstępnie omówione w artykule Wstęp do obiektów w PowerShell 5.0. Teraz mam zamiar skupić się głównie na cmdlecie get-PhysicalDisk, który służy do uzyskiwania informacji o fizycznych dyskach twardych podpiętych do komputera.

Zacznijmy od prostego zastosowania omawianego tutaj cmdleta. W swojej najprostszej formie, bez parametrów, cmdlet get-PhysicalDisk zwraca podstawowe informacje o dyskach fizycznych, podpiętych do lokalnego komputera. Zobaczmy przykładowo jak to działa:

PS C:\WINDOWS\system32> Get-PhysicalDisk FriendlyName SerialNumber CanPool OperationalStatus HealthStatus Usage Size ------------ ------------ ------- ----------------- ------------ ----- ---- KINGSTON SH103S3120G 50026B7239006B0C False OK Healthy Auto-Select 111.79 GB Samsung SSD 840 EVO 500GB S1DHNSBF607817L False OK Healthy Auto-Select 465.76 GB

W powyższym przykładzie uzyskaliśmy podstawowe informacje o dyskach. Jak łatwo zauważyć, tych informacji nie jest wiele.

Cmdlet get-PhysicalDisk zwraca obiekty klasy Microsoft.Management.Infrastructure.CimInstance#ROOT/Microsoft/Windows/Storage/MSFT_PhysicalDisk.

Jeśli pragniemy się dowiedzieć jakie właściwości i metody uwzględniają obiekty tej klasy, wystarczy przekierować obiekty wyjściowe polecenia get-PhysicalDisk do cmdleta gm, czyli get-Member, przykładowo można to zrobić w taki sposób:

Informacje o dyskach - Właściwości obiektów zwracanych przez get-PhysicalDisk
Dodaj Informacje o dyskach - Właściwości obiektów zwracanych przez get-PhysicalDisk


Jak widać jednak, można uzyskać niesłychanie dużo informacji związanych z dyskami twardymi.

Jeśli zatem zależy nam na większych szczegółach dotyczących dysków fizycznych, możemy przekierować wynik cmdleta get-PhysicalDisk do polecenia Format-List, uwzględniając interesujące nas właściwości obiektów wynikowych. Przykładowo można uwzględnić kilka dodatkowych właściwości, z tych, które mamy do wyspozycji dla obiektów tej klasy:

PS C:\WINDOWS\system32> Get-PhysicalDisk | Format-List FriendlyName, SerialNumber, HealthStatus, BusType, Size, AllocatedSize, FirmWareVersion, OperationalStatus FriendlyName : KINGSTON SH103S3120G SerialNumber : 50026B7239006B0C HealthStatus : Healthy BusType : SATA Size : 120034123776 AllocatedSize : 120034123776 FirmWareVersion : 521ABBF0 OperationalStatus : OK FriendlyName : Samsung SSD 840 EVO 500GB SerialNumber : S1DHNSBF607817L HealthStatus : Healthy BusType : SATA Size : 500107862016 AllocatedSize : 500106813440 FirmWareVersion : EXT0BB6Q OperationalStatus : OK

Ciekawostką wartą omówienia, a zarazem faktem, który może zainteresować zawodowych administratorów IT, jest to, że przekierowując obiekty wynikowe polecenia get-physicalDisk do cmdleta get-StorageReliabilityCounter możemy uzyskać informacje o aktualnym kompleksowym czasie użytkowania dysków, podanym w godzinach pracy. Daje to spore możliwości programistyczne, jeśli chodzi o pisanie skryptów powiadamiających o konieczności wymiany dysków na poszczególnych maszynach, co może być przydatne szczególnie w dużych sieciach:

PS C:\> get-PhysicalDisk | Get-StorageReliabilityCounter DeviceId Temperature ReadErrorsUncorrected Wear PowerOnHours -------- ----------- --------------------- ---- ------------ 1 0 6000 0 100 8302

Przejdźmy teraz do najciekawszej części tego artykułu, a mianowicie do pracy z poleceniem get-PhysicalDisk w środowisku sieciowym.

Wyjaśnię z góry, że wiele cmdletów PowerShell przyjmuje parametr -ComputerName, który umożliwia odnoszenie się do konkretnego komputera w sieci. Polecenie get-PhysicalDisk jednak nie przyjmuje takiego parametru. Jak zatem uzyskać informacje o dyskach podpiętych do dowolnego komputera w sieci? A co jeśli tych maszyn jest więcej i mamy zamiar zautomatyzować procedurę? Rozpoczynanie zdalnej sesji z wykorzystaniem enter-PSSession, dla każdej maszyny z osobna, byłoby w tym przypadku jednym z owszem działających, lecz raczej nieadekwatnych rozwiązań.

Windows PowerShell 5.0 dostarcza nam jednak bardzo pomocny w tym przypadku cmdlet, umożliwiający wykonywanie poiedyńczych poleceń na zdalnych komputerach. Jest to cmdlet o nazwie invoke-Command. Wyjaśnię, że ten cmdlet przyjmuje nie tylko parametr -Computername, pozwalający odnosić się do konkretnych maszyn w sieci, ale także, co ważne w przypadku rozległych sieci i konieczności zautomatyzowania całej tej procedury, parametr -Credential, który umożliwia zapodanie poświadczeń uprawnionego użytkownika, poświadczeń, które jak zobaczymy, można zachować w zmiennej, w celu ich póżniejszego wykorzystania.

Przypominam, że maszyny biorące udział w operacjach sieciowych powinny mieć uruchomioną usługę WinRM. Aby takową usługę uruchomić należy z wiersza poleceń PowerShell wykonać następujący cmdlet:

Enable-PsRemoting

Pamiętajmy również, że w przypadku wykonywania poleceń PowerShell w sieci opartej na tak zwanych grupach roboczych, a nie na domenach Microsoft, maszyny docelowe powinny znajdować się na liście trusted-host klienta z którego wydawane są polecenia PowerShell, a w przeciwnym przypadku polecenia nie zadziałają.

Aby dodać maszynę do listy trusted-hosts można, przykładowo, postąpić w taki oto sposób:

PS WSMan:\> set-item wsman:\localhost\Client\TrustedHosts -value 'NAZWA_KOMPUTERA' WinRM Security Configuration. This command modifies the TrustedHosts list for the WinRM client. The computers in the TrustedHosts list might not be authenticated. The client might send credential information to these computers. Are you sure that you want to modify this list? [Y] Yes [N] No [S] Suspend [?] Help (default is "Y"):

Załóżmy teraz, że chcemy się dowiedzieć więcej o dyskach podpiętych do kilku maszych Windows. Warto zautomatyzować taką procedurą. Zobaczmy jak to można przykładowo zrobić.

Pierwszym krokiem jest zapisanie poświadczeń uprawnionego użytkownika w zmiennej sesyjnej:

PS C:\WINDOWS\system32> $admin = get-Credential MOJADOMENA\Admin1

Wykonanie powyższego cmdleta powoduje wyświetlenie się okienka z monitem o hasło zapodanego użytkownika. Po wprowadzeniu prawidłowego hasła, obiekt poświadczeń zostaje zapisany w wybranej zmiennej sesyjnej, w tym przypadku jest to zmienna $admin.

Informacja o dyskach w sieci - Zapis poświadczeń w zmiennej
Informacja o dyskach w sieci - Zapis poświadczeń w zmiennej


Na tym etapie, możemy już wykonać, w sposób częściowo zautomatyzowany, polecenie get-PhysicalDisk na zdalnych maszynach, przykładowo w następujący sposób:

PS C:\> $args = "SPHINX", "THOR"; invoke-Command -ComputerName $args -Credential $admin -ScriptBlock { get-PhysicalDisk }

Jak łatwo zauważyć, parametr -ComputerName akceptuje jako argument tablicę zmiennych. Przykładowym wynikiem powyższego polecenia, w którym jasno widnieje nazwa komputera, może być:

Informacje o dyskach w sieci
Informacje o dyskach w sieci

Oczywiście, w przypadku dużych sieci i konieczności wykonywania częstej diagnostyki stanu dysków oraz ich dostępności, warto jest napisać odpowiednie funkcje PowerShell, które pozwolą zaoszczędzić na ilości wpisywanych znaków poleceń. Ten temat jednak wykracza poza zakres niniejszego artykułu.

Powodzenia! W przypadku jakichkolwiek uwag lub wątpliwości proszę o komentarze!

niedziela, 15 stycznia 2017

Wstęp do obiektów w PowerShell 5.0

Jak już miałem okazję wyjaśnić w artykule Wstęp do Windows PowerShell, Windows PowerShell 5.0 oparty jest na frameworku Microsoft .NET, co sprzyja ogromnym możliwościom programistycznym jeśli chodzi o pracę z obiektami. Dowiedzieliśmy się wówczas, między innymi, iż wynikami wykonywanych cmdletów nie są łańcuchy znaków, lecz obiekty.

Weźmy przykładowo cmdlet Get-ChildItem, który omówiłem wstępnie we wspomnianym wyżej artykule. Wywołując cmdlet Get-ChildItem, otrzymujemy listę elementów, które mogą być, w zależności od kontekstu, plikami i folderami, ale nie tylko. Te elementy są jednak zawsze obiektami, posiadającymi programistyczne właściwości i metody.

Zobaczmy, dla czystego przykładu, jakie właściwości i metody posiadają pliki zawarte w bieżącym katalogu oraz w jaki sposób można się do nich odwoływać:

PS C:\WINDOWS\system32> Get-ChildItem -File | gm -MemberType Property, Method | Format-Table Name, Membertype

W rezultacie wykonania powyższego polecenia, otrzymujemy listę obiektów, ich właściwości i metod:

Właściwości i metody obiektów w PowerShell 5.0
Właściwości i metody obiektów w PowerShell 5.0

Znając dostępne dla danego obiektu właściwości i metody, które zależne są od jego klasy, możemy z nich korzystać do konkretnych celów. Czysto przykładowo, korzystając z właściwości LastAccessTime, która jest dostępna dla obiektów klasy System.IO.FileInfo, możemy ograniczyć listę elementów zwracanych przez cmdlet Get-ChildItem do tych, których czas ostatniego dostępu jest późniejszy od daty 12/12/2016:

PS C:\Windows\system32> Get-ChildItem -File | where LastAccessTime -gt "12/12/2016"

W rezultacie wykonania powyższego polecenia, otrzymujemy:

Korzystanie z właściwości i metod obiektów w PowerShell 5.0
Korzystanie z właściwości i metod obiektów w PowerShell 5.0

Ten sam efekt można uzyskać korzystając z możliwości bezpośredniego odwoływania się do właściwości obiektów PowerShell. Jest na do sporo sposobów. Zademonstruję dwa z nich:

PS C:\WINDOWS\system32> ( gci -File ).where({$PSItem.LastAccessTime -gt "12/12/2016"});

PS C:\WINDOWS\system32> (gci).where( {!$_.psiscontainer -AND $_.LastAccessTime -gt "12/12/2016"} );

W Windows PowerShell 5.0 możemy jednak tworzyć własne obiekty i korzystać z ich specyficznych właściwości i metod. Zobaczmy teraz, prosty wstęp do pracy z własnymi obiektami:

Tworzenie obiektów w PowerShell 5.0
Tworzenie obiektów w PowerShell 5.0

Wyjaśniam zatem o co chodzi w powyższym przykładzie. Otóż utworzyłem obiekt klasy wscript.network, po czym przejrzałem jego metody i właściwości i zastosowałem jedną z nich aby zmapować przykładową lokalizację sieciową do litery dysku N:, po czym wyświetliłem zawartość dysku N:, a następnie zastosowałem odpowiednią metodę aby usunąć wcześniej utworzone mapowanie. Podobny efekt można uzyskać na wiele sposobów. Przykładowo, utworzenie obkiektu klasy wscript.network i mapowanie dysku sieciowego mogą być wykonane również w następujący sposób:
PS C:\Windows\System32> (New-Object -Com WScript.Network).MapNetworkDrive( "N:" , "\\SAMBA-SERVER1\Dom")

Innym prostym przykładem pracy z własnymi obiektami w PowerShell 5.0 może być obiekt klasy wscript.shell:

Tworzenie obiektów w PowerShell 5.0
Tworzenie obiektów w PowerShell 5.0

O co w tym chodzi? Otóż utworzyłem przykładowy obiekt klasy wscript, uzyskałem listę jego metod i właściwości, po czym zastosowałem metodę popup, co spowodowało pojawienie się okienka z uśmiechem.

Rzyczę miłej zabawy z obiektami w PowerShell 5.0 i zapraszam ponownie!

sobota, 14 stycznia 2017

Xnote Clevo P177SM – Opinie - Frustracja

Dwa lata temu stanąłem przed trudną decyzją, dotyczącą zakupu nowego laptopa, który miał mi służyć zarówno do pracy, jak i do rozrywki.

Z zawodu jestem programistą i administratorem systemów informatycznych, jednak w wolnym czasie staję się nieustraszonym gejmerem. Lubię sobie ostro pograć w niekiedy bardzo wymagające sprzętowo gry. Rozglądając się zatem w sieci za optymalnym rozwiązaniem, które zaspokoiło by moje potrzeby zarówno zawodowe, jak i czasu wolnego, natknąłem się na laptopy Xnote, które w sposób szczególny przykuły moją uwagę. Czemu tak się stało? Otóż producent zapewniał silną, jakościową, a zarazem mobilną platformę dla gracza, trwałość i łatwą rozbudowę sprzętu. Jakby zahipnotyzowany tymi pięknymi obietnicami, wyłożyłem sporą kasę, aby 2 lata temu stać się posiadaczem laptopa Xnote P177SM.



Wybrałem następującą konfigurację sprzętu:
  • kartą grafiki NVIDIA Gforce GTX-770M;
  • 16GB RAM;
  • CPU iCore 2.7Ghz;
  • HDD SSD 256GB;

Na powyższą konfigurację wydałem wówczas ponad 7000zł! Sądziłem, że będę zadowolony.

Obiecanki cacanki, a głupiemu radość


Przez krótki czas laptop XNOTE bardzo mi się podobał, ale najwidoczniej byłem początkowo zauroczony nowym nabytkiem, którzy rzeczywiście początkowo spełniał swoje zadanie. Mój zachwyt nie trwał jednak długo, ponieważ już po kilku miesiącach użytkowania sprzętu, nawaliła płyta główna i musiałem wysłać laptop do serwisu. Po około 3 tygodniach oczekiwania, sprzęt został naprawiony w ramach gwarancji. Ciekawostką jest fakt, iż specyfikacja płyty głównej, którą zamontowano w serwisie, nieco się różniła od poprzedniej.

To jednak był dopiero początek czarnej serii zdarzeń XNOTE. O dziwo, tuż po odbiorze laptopa z serwisu, bateria zaczęła nawalać, a potem zupełnie przestała się ładować. W sumie, żywotność baterii, która obecnie kosztuje prawie 500zł, wyniosła lekko ponad rok czasu. Czy to oznacza, że co roku miałbym wykładać 500zł na nową baterię, aby móc korzystać z mobilności laptopa? Lekka przesada!

W drugim roku użytkowania, wewnątrz matrycy (wyświetlacza) pojawiły się czarne plamy, jakby spowodowane jej wewnętrznym pęknięciem, jednak z zupełnie niewyjaśnionych przyczyn. Ponieważ okres gwarancyjny już wówczas minął, byłem zmuszony do wymiany matrycy na własny koszt.

Kilka tygodni później, zaczęło nawalać chłodzenie procesora. Początkowo pomogło czyszczenie układu chłodzenia i nasmarowanie osi wiatraka. Te czynności musiałem jednak powtarzać regularnie aby chłodzenie działało prawidłowo. Po jakimś czasie silnik wiatraka całkiem padł. Ponieważ okazało się, że nowe chłodzenie to wydatek około 200zł (XNOTE bardzo się ceni), wykorzystałem jako część zamienna wiatrak CPU ze starego laptopa Acer, który okazał się idealnie pasować do mojego XNOTE.

Alternatywne chłodzenie CPU
Alternatywne chłodzenie CPU - Wiatrak wzięty ze starego laptopa ACER

Następnie pojawiły się problemy z zasilaczem, które jednak udało mi się samemu rozwiązać, ustawiając odpowiednio mechanicznie poluzowane styki.

Kolejne niespodzianki i mankamenty


Półtora roku po zakupie sprzętu, zacząłem się „przymierzać” do podmiany karty grafiki na bardziej wydajny model. Jednak szybko zrezygnowałem z tego zamiaru, gdyż się okazało, że taka podmiana to koszt połowy nowego laptopa! To prawda, laptop można łatwo rozbudować, co nie oznacza, że nie będzie to drogo kosztowało. Łatwo nie oznacza bowiem tanio. Producent nie kłamał!

Jeśli chodzi o mobilność, to ten ważący około 4 kilogramów kolos, wraz ze swoim 888-gramowym zasilaczem, stanowią niezły bagaż. Na dodatek wymiary laptopa nie są małe, co sprawia dodatkowe trudności jeśli wybieramy się w dalszą podróż.

Dużym mankamentem mojego modelu XNOTE jest bardzo kiepskiej jakości obudowa, z której aluminiowej części obficie odpryskuje farba, nawet w trakcie zwyczajnego przemieszczania sprzętu.

Obudowa z odpryskującą farbą
Obudowa z odpryskującą farbą

Podświetlana klawiatura jest owszem bardzo przydatna, lecz jej klawisze odpadają wskutek ich delikatnego czyszczenia suchą ściereczką. Dwóch klawiszy nie udało mi się z powrotem przyczepić.

Wypadek podczas czyszczenia klawiatury
Wypadek podczas czyszczenia klawiatury

Głośniki praktycznie nie mają mocy, a miały zapewnić niesamowite wrażenia podczas gier!

Kolejną ciekawostką jest touchpad, którego praktycznie nie da się używać od samego początku, ze względu na drganie kursora wskutek wibracji od obydwu układów chłodzenia, szczególnie gdy procesor i karta grafiki intensywnie pracują.

Muszę też wspomnieć, iż podczas wymagających gier laptop staje się od spodu bardzo gorący, a chłodzenie jest wówczas bardzo głośne. Laptop w takim stanie, trzymany na kolanach, wręcz parzy.

Jeśli chodzi o czyszczenie obudowy, to jest ono bardzo kłopotliwe, gdyż do jej gumowatej powierzchni wszystko łatwo lgnie i tworzą się na niej trudne do usunięcia plamy.

Po takim doświadczeniu, jestem szczerze przekonany, że nigdy więcej nie kupię sprzętu firmy XNOTE.

Ponieważ właśnie przymierzam się do zakupu nowego laptopa, postanowiłem tym razem rozejrzeć się bardzo dokładnie nad różnymi możliwościami, jakie oferuje obecny rynek. Szukając w sieci opinii i porad w tym temacie, natknąłem się, całkiem przypadkowo, na ciekawą grupę dyskusyjną https://www.facebook.com/groups/laptop.nieidealny.plk, którą mogę szczerze polecić wszystkim tym, którzy nie chcą ponieść rozczarowania i klęski z nieodpowienio dopasowanym do własnych potrzeb sprzętem, podobnie jak miało to miejsce w moim przypadku. Powiązane z grupą jest również forum https://www.forum.nieidealny.pl/.

W przypadku pytań proszę o komentarze. Dziękuję za uwagę i zapraszam ponownie!

sobota, 7 stycznia 2017

Wstęp do Windows PowerShell

Czemu taki artykuł


Wielokrotnie pytano mnie, czemu na moim blogu wszystko kręci się wokół Linuxa. Otóż od kilkunastu lat moja praca polega na administrowaniu tego typu systemami oraz projektowaniu i rozwijaniu zarówno prostych aplikacji, jak i złożonych systemów informatycznych, głównie w tym właśnie środowisku. Obiecywałem jednak, że jako posiadacz tytułu Microsoft Certified Systems Engineer, zacznę pisać artykuły związane z systemami Microsoft. Niniejszy artykuł jest pierwszym z tej właśnie serii.

Czym jest PowerShell


Windows PowerShell to interpreter poleceń rodem z Microsoft, ściśle zintegrowany ze środowiskiem .NET Framework i o wiele bardziej rozbudowany niż wcześniejsze interpretery poleceń COMMAND.COM i cmd.exe, opracowane przez tą samą firmę. Windows PowerShell jest potężnym narzędziem, przeznaczonym głównie do wykonywania zadań administracyjnych, także sieciowych, za pomocą poleceń zwanych cmdletami, z ang. cmdlets. Windows PowerShell cechuje się logiką obiektową, co oznacza iż wynikiem wykonywanego polecenia cmdlet nie jest ciąg znaków, lecz obiekt, co stanowi bardzo dużą różnicę w odniesieniu do innych interpreterów poleceń zarówno Microsoft jak i Linux. Historia tego interpretera poleceń sięga roku 2002. Od czasów Windows 7 PowerShell stanowi integralną część systemu operacyjnego, natomiast obecnie system Windows 10 zawiera PowerShell w wersji 5.0.

Po co polecenia?


Wielu z Was zada sobie kluczowe pytanie: po co w ogóle korzystać z interpretera poleceń w systemach Microsoft, skoro "wszystko" da się zrobić w GUI, czyli w środowisku graficznym? Na to pytanie jest bardzo prosta odpowiedź. Stwierdzenie, że wszystko da się zrobić w środowisku graficznym, nie jest, na dzień dzisiejszy, zupełnie zgodne z rzeczywistością. Prawdą jest owszem, że tak było kiedyś, lecz obecnie, w związku ze zmianą podejścia firmy Microsoft do tej kwestii i wynikającym z tej decyzji rozwojem PowerShell'a, sytuacja jest zupełnie odwrotna! Wiele zadań administracyjnych jest praktycznie niemożliwych do wykonania w systemie Windows bez korzystania z PowerShell'a lub wyspecjalizowanej aplikacji, natomiast inne zadania można wykonywać znacznie sprawniej z wiersza poleceń. Wyobraźcie sobie przykładowo, że Waszym zadaniem jest utworzenie kilkuset kont użytkowników na zdalnych serwerach. Korzystanie z interfejsu graficznego sprawiałoby w tym przypadku spore utrudnienie, natomiast PowerShell przynosi w tym obszarze niesamowite możliwości i elastyczność działania.

PowerShell cmdlets


Polecenia PowerShell, cmdlets, to wyspecializowane klasy środowiska .NET Framework, których instancje są tworzone i wywoływane przez runtime PowerShell'a. Nazwy cmdletów zą tworzone na zasadzie Czasownik-Rzeczownik, co pozwala na precyzyjne określenie ich działania, a zarazem zwiększa wygodę korzystania z poleceń. Przykładowo, polecenie Get-ChildItem zwraca listę elementów (na przykład listę plików i katalogów) zawartych w określonym kontenerze (np. w katalogu systemu plików lub lokalizacji rajestru systemu), która domyślnie jest bieżącym kontenerem. A oto kilka innych przykładów poleceń Windows PowerShell, które wszystkie, jak widać, trzymają się tych zasad notacji:

Get-Date Get-Service Get-Command Set-Location Get-Module

W odróżnieniu od poprzednich interpreterów poleceń firmy Microsoft, PowerShell jest o wiele bardziej przyjazny dla użytkownika. Komendy są interaktywnie podświetlane w trakcie ich wpisywania, co pozwala użytkownikowi szybko orientować się czy ciąg znaków pasuje do istniejących komend, a klawiszem TAB można błyskawicznie kompletować wprowadzane polecenia (TAB completion), podobnie jak ma się to w interpreterach systemu Linux.

W dalszej części tego artykułu będę stosował określenie PowerShell w odniesieniu do wersji PowerShell 5.0, dostępnej w środowisku Windows 10.

Jak zacząć korzystać z PowerShell'a


Dostępnych jest obecnie wiele aplikacji stanowiących interfejs między interpreterem PowerShell a użytkownikiem, pozwalających korzystać z potęgi PowerShell'a. Jednym ze sposobów na rozpoczęcie korzystania z omawianego tutaj interpretera polecen jest wyszukanie aplikacji Windows PowerShell w pasku wyszukiwania Windows i uruchomienie jej z uprawnieniami Administratora, korzystając z menu opcji wyświetlanego po kliknięciu prawego przycisku myszki nad dostępną w wynikach wyszukiwania aplikacją Windows PowerShell. Alternatywnie, aby korzystać w PowerShell'a można wybrać aplikację Windows PowerShell ISE. Obecnie można znaleźć w sieci sporą ilość rozmaitych aplikacji umoliwiających korzystanie z dobrodziejstw Windows PowerShell, niekiedy bardzo rozbudowanych, tak jak przykładowo Sapien Technologies PowerShell Studio.

Windows PowerShell - uruchamianie
Przykładowy sposób uruchamiania Windows PowerShell


Pierwsze kroki w PowerShell


Po uruchomieniu wybranej przez nas aplikacji, umożliwiającej wydawanie poleceń PowerShell, możemy zacząć korzystać z potężnego interpretera poleceń Microsoft.

Dobrą wiadomością dla osób zaznajomionych z poprzednią wersją interpretera poleceń Microsoft, jest to, iż polecenia znane z cmd.exe, będą generalnie działać w środowisku PowerShell. A to już dobry początek:

PS C:\> mkdir c:\katalog1 Directory: C:\ Mode LastWriteTime Length Name ---- ------------- ------ ---- d----- 2017-01-06 15:58 katalog1 PS C:\> cd c:\katalog1 PS C:\katalog1> date > plik1.txt PS C:\katalog1> dir Directory: C:\katalog1 Mode LastWriteTime Length Name ---- ------------- ------ ---- -a---- 2017-01-06 15:58 66 plik1.txt PS C:\katalog1> type plik1.txt 6 stycznia 2017 15:58:39 PS C:\katalog1> del plik1.txt


Aliasy


Z powyższego przykładu można łatwo zauważyć, że polecenia znane nam ze starszego interpretera Microsoft wydają się bezproblemowo działać w środowisku Windows Powershell. Jednak, nie jest to do końca prawdą, a zobaczmy dokładnie o co chodzi. Przykładowo, próba wydania znanego nam z poprzednich interpreterów Microsoft polecenia DIR, wraz z jakąkolwiek opcją, na przykłąd opcją /L, w środowisku Windows PowerShell skutkuje błędem:

PS C:\katalog1> dir /L dir : Cannot find path 'C:\L' because it does not exist. At line:1 char:1 + dir /L + ~~~~~~ + CategoryInfo : ObjectNotFound: (C:\L:String) [Get-ChildItem], ItemNotFoundException + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand

Czemu tak się dzieje? Otóż dlatego, że polecenie DIR jest, w środowisku PowerShell, tylko aliasem, czyli alternatywną nazwą dla natywnego polecenia cmdlet Get-ChildItem, o którym wstępnie już wspomniałem, a nie poleceniem samym w sobie. Dlatego też, natywny cmdlet PowerShell, wywoływany przez zdefiniowany dla niego alias, nie jest w stanie przyjać przekazywanych w ten sposób dodatkowych opcji, których cmdlet w sumie nie jest w stanie interpretować. Ciekawostką jest też to, iż cmdlet Get-ChildItem może być także wywołany aliasem o nazwie ls, a więc nazwą w stylu Linuksa:

PS C:\katalog1> ls Directory: C:\katalog1 Mode LastWriteTime Length Name ---- ------------- ------ ---- -a---- 2017-01-06 16:57 66 data.txt -a---- 2017-01-06 16:57 13 data1.txt

Zobaczmy teraz, przykładowo, wszystkie aliasy zdefiniowane dla cmdleta Get-ChildItem:

PS C:\katalog1> Get-Alias -definition Get-ChildItem CommandType Name Version Source ----------- ---- ------- ------ Alias dir -> Get-ChildItem Alias gci -> Get-ChildItem Alias ls -> Get-ChildItem

Polecenia PowerShell mogą być niekiedy zapodawane z wieloma rozmaitymi parametrami. Często, w zależności od polecenia, dostępnych parametrów może być bardzo dużo. Jeśli nie pamiętamy nazwy danego parametru, wówczas nie ma się czym przejmować, ponieważ PowerShell może nam ją automatycznie podpowiedzieć. W tym celu wystarczy zapodać nazwę polecenia, a następnie znak parametru '-' oddzielony spacją od polecenia, po czym, aby wyświetlić wszystkie dostępne dla danego polecenia parametry wystarczy wciskać klawisz tabulatora. Dla przykładu, w przypadku cmdletu Get-ChildItem, parametr -Directory ogranicza listę wyświetlanych wyników do katalogów:

PS C:\WINDOWS\system32> Get-ChildItem -Directory

Z pomocą w doborze odpowiednich parametrów dla stosowanych cmdletów przychodzi nam również kombinacja klawiszy Ctrl+Spacja tuż po wpisaniu znaku minus oznaczającego parametr polecenia, co skutkuje wyświetleniem wszystkich możliwych parametrów, po których następnie możemy przechodzić strzałkami. Aby wybrać bieżący parametr klikamy ENTER:

Windows PowerShell - Dobór parametrów polecenia
Windows PowerShell - Dobór parametrów polecenia


Dodam tutaj, iż także w przypadku doboru wartości parametrów można niekiedy, w analogiczny sposób, korzystać z klawisza TAB, w zależności od wartości przyjmowanych przez dany parametr.

Popularne przykładowe cmdlety PowerShell


Oprócz wspomnianego wcześniej polecenia Get-ChildItem, jednym z najbardziej ogólnych i najbardziej przydatnych cmdletów PowerShell'a jest polecenie Get-Command, które domyślnie wyświetla listę wszystkich dostępnych w systemie cmdletów. Ponieważ ilość dostępnych cmdletów, w zależności od zainstalowanych w systemie modułów PowerShell, może być imponująca, warto jest ograniczać ilość wyświetlanych wyników wyszukiwania:

Windows PowerShell Get-Command
Windows PowerShell - Przykładowy wynik cmdleta Get-Command Get-Smb*


Kolejnym, bardzo ważnym poleceniem Windows PowerShell jest Get-Module. Wyświetla ono obecnie załadowane do pamięci moduły. Od wersji PowerShell 3.0 potrzebne moduły są automatycznie ładowane do pamięci operacyjnej w miarę potrzeby, co oznacza, iż wywołanie cmdletów wymagających konkretnych modułów, powoduje ich automatyczne załadowanie do pamięci, jeśli jeszcze ich tam nie ma.

S C:\WINDOWS\system32> Get-Module ModuleType Version Name ExportedCommands ---------- ------- ---- ---------------- Manifest 3.1.0.0 Microsoft.PowerShell.Management {Add-Computer, Add-Content, Checkpoint-Computer, Clear-Con... Manifest 3.1.0.0 Microsoft.PowerShell.Utility {Add-Member, Add-Type, Clear-Variable, Compare-Object...} Script 1.1 PSReadline {Get-PSReadlineKeyHandler, Get-PSReadlineOption, Remove-PS...

Warto tutaj także wymienić cmdlet o nazwie Get-Process, za pomocą którego możemy uzyskać informacje o procesach. Dla przykładu:

PS Env:\> get-Process boinc Handles NPM(K) PM(K) WS(K) VM(M) CPU(s) Id SI ProcessName ------- ------ ----- ----- ----- ------ -- -- ----------- 195 18 8400 14804 94 3,80 13208 2 boinc

Polecenie Get-Service wyświetla informacje o usługach. Jeśli chcemy uzyskać informacje o konkretnej usłudze, przykładowo o usłudze Bonjour, wystarczy wprowadzić polecenie z nazwą usługi:

PS Env:\> get-service 'Bonjour Service' Status Name DisplayName ------ ---- ----------- Running Bonjour Service Usługa Bonjour

Bardzo przydatnym poleceniem PowerShell, o którym również warto wpomnieć, jest cmdlet o nazwie Get-EventLog, który umożliwia nam dostęp do zawartości dzienników zdarzeń. Przykładowo, jeśli interesuje nas 5 najnowszych zdarzeń, które zostały zapisane w dzienniku aplikacji, możemy tę informację uzyskać w następujący sposób:

PS Env:\> get-eventLog -LogName Application -Newest 5 Index Time EntryType Source InstanceID Message ----- ---- --------- ------ ---------- ------- 48560 sty 07 13:09 Information Software Protecti... 1073742890 Stan zainicjowania obiektów usługi.... 48559 sty 07 13:09 Information Software Protecti... 1073742724 Usługa ochrony oprogramowania jest uruchamiana.... 48558 sty 07 13:08 0 Software Protecti... 1073742727 Usługa ochrony oprogramowania została zatrzymana.... 48557 sty 07 13:08 Information Software Protecti... 1073758208 Zaplanowano restart usługi ochrony oprogramowania o 2116-12-14T12:08:29Z. Przyczyna: RulesEngine. 48556 sty 07 13:07 0 Software Protecti... 1073742726 Usługa ochrony oprogramowania została uruchomiona....

Providery PowerShell


Providery PowerShell'a umożliwiają poruszanie się w zbiorach danych różnego rodzaju (np. systemy plików na dyskach, rejestr systemu Windows, środowisko systemowe) w sposób taki, jaki ma miejsce w przypadku prawdziwego systemu plików. Z tej właśnie przyczyny dla przykładowego, wspomnianego wcześniej cmdleta o dziwnej nazwie Get-ChildItem wybrano bardziej uniwersalną nazwę niż np. dir czy list, nazwę która nie ogranicza jego stosowania wyłącznie do prawdziwego systemu plików. To przykładowe polecenie PowerShell, jak wiele innych, dzięki providerom PowerShell okazuje się przydatne nie tylko w przypadku systemów plików, lecz także w przypadku każdego innego rodzaju danych, obsługiwanego przez providery PowerShell. Zobaczmy teraz w jaki sposób można uzyskać listę dostępnych providerów Windows PowerShell:

PS C:\WINDOWS\system32> Get-PSProvider Name Capabilities Drives ---- ------------ ------ Registry ShouldProcess, Transactions {HKLM, HKCU} Alias ShouldProcess {Alias} Environment ShouldProcess {Env} FileSystem Filter, ShouldProcess, Credentials {C, E, D} Function ShouldProcess {Function} Variable ShouldProcess {Variable}

Tak więc, dzięki providerom Windows PowerShell, możemy przykładowo przejść do rejestru HKCU, poruszać się w nim, oglądać jego zawartość, korzystając z tych samych sposóbów i narzędzi, które są dostępne w przypadku struktury systemu plików:

PS C:\WINDOWS\system32> set-location HKCU: PS HKCU:\> Get-ChildItem

A oto przykładowy wynik powyższych poleceń:

Windows PowerShell - Poruszanie się w strukturze rejestru HKCU
Windows PowerShell - Poruszanie się w strukturze rejestru HKCU

Także dzięki providerom, jak wiadać z wyników polecenia Get-PSProvider, można w podobny sposób dostać się do zmiennych środowiskowych Windows (Environment Variables). A więc, wchodzimy do zmiennych środowiskowych, niczym do systemu plików:

Windows PowerShell - Zmienne Środowiskowe Windows
Windows PowerShell - Zmienne Środowiskowe Windows

Pomocy!


Windows PowerShell cechuje się bardzo rozbudowanym systemem pomocy. Można w nim błyskawicznie uzyskać pomoc dotyczącą każdego dostępnego cmdleta. Przed rozpoczęciem korzystania z pomocy warto jednak ściągnąć z sieci aktualizację pomocy. Aby to zrobić wystarczy wydać polecenie:

PS C:\WINDOWS\system32> Update-Help

W wyniku powyższego polecenia PowerShell ściąga z serwerów Microsoft dostępne aktualizacje systemu pomocy:

Windows PowerShell - Aktualizowanie systemu pomocy
Windows PowerShell - Aktualizowanie systemu pomocy

Aby uzyskać pomoc dotyczącą konkretnej komendy wystarczy wprowadzić polecenie o nazwie Get-Help, lub jego alias w linuksowym stylu, o nazwie man, z nazwą polecenia, dla którego jest nam potrzebna pomoc. Przykładowo:

PS C:\WINDOWS\system32> Get-Help Get-RestorePoint

Jeśli nie pamiętamy dokładnej nazwy polecenia, możemy zastosować wildcardy, czyli gwiazdki. Przykładem może być:

PS C:\WINDOWS\system32> Get-Help *smb*


Windows PowerShell - Pomoc
Windows PowerShell - Pomoc


Co ciekawe, dodatkowym ułatwieniem jest fakt, iż pomoc może być wyświetlana w okienku GUI, w przypadku zapodania cmdletu Get-Help z parametrem -ShowWindow. Wówczas wyszukiwanie może stać się o wiele bardziej przyjemne:

Windows PowerShell - Pomoc w GUI
Windows PowerShell - Pomoc w GUI


Można także uzyskać dostęp do pomocy związanej z konkretnym tematem, w trybie online, czyli poprzez przeglądarkę www. W tym celu należy zastosować parametr -Online. Przykładowo:

PS C:\WINDOWS\system32> Get-Help Get-ChildItem -Online

Warto tutaj wspomnieć, iż system pomocy PowerShell może być bardzo przydatny w nauce korzystania z potencjału PowerShell'a, gdyż umożliwia on nam dostęp do pełnych treści tutoriali związanych z konkretnymi tematami. Przykładowo jeśli interesuje nas temat modułów, wówczas, aby uzyskać dostęp do tutorialu o modułach, wystarczy wydać polecenie:

PS C:\WINDOWS\system32> Get-Help about_Modules

Aby dowiedzieć się jakie tutoriale są obecnie dostępne w systemie pomocy, wystarczy wydać polecenie:

PS C:\WINDOWS\system32> Get-Help about*


Pipelining, czyli potoki


Obsługa tak zwanego pipeliningu, czyli potoków, znanych nam ze świata Linuxa, jest w pełni obecna w Windows PowerShell. Jak wcześniej wyjaśniłem, wykonywane polecenia PowerShell zwracają jako wynik nie zwykły tekst, lecz obiekty. Domyślnie obiekty te wyświetlane są na ekranie. Istnieje jednak możliwość automatycznego wywołania kolejnych cmdletów, z otrzymanymi wynikami jako argumenty wejściowe. Zobaczmy teraz jak to działa na konkretnych przykładach.

Wiemy już, że polecenie Get-Process domyślnie wyświetla listę aktywnych procesów na wybranej maszynie. Wiemy też, że polecenie to zwraca listę obiektów. Możemy zatem wykorzystać wyniki tego polecenia jako argumenty wejściowe innego polecenia, na przykład polecenia o nazwie Select-Object, które w naszym przykładzie poskutkuje wyświetleniem jedynie identyfikatorów procesów, zamiast wszystkich domyślnie pokazywanych elementów:

PS C:\WINDOWS\system32> Get-Process | Select-Object -Property Id Id -- 2448 2208 2456 8664 2480 [...]

Innym prostym przykładem potoków PowerShell, który już nieco bardziej ukazuje potencjał interpretera, może być następujący wiersz, którego wykonanie skutkuje wyświetleniem nazw pierwszych 10 elementów z listy obiektów plików i katalogów w bieżącej lokalizacji systemu plików, uporządkowanej według daty utworzenia, w kierunku od najnowszego do najstarszego elementu:

PS C:\WINDOWS\system32> Get-ChildItem | Select-Object Name | Sort-Object CreationTime -Descending | select -first 10 Name ---- iedkcs32.dll ieapfltr.dll IdListen.dll icsigd.dll IcsEntitlementHost.exe icrav03.rat icsunattend.exe ideograf.uce IdCtrls.dll icsvc.dll

Podsumowanie


W związku z coraz to bardziej złożoną strukturą wewnętrzną produktów firmy Microsoft, opracowanie interpretera poleceń nowej generacji okazało się nie tylko koniecznością, lecz ogólnie wielkim zwrotem. Jak zdążyliśmy zauważyć w trakcie czytania tego artykułu, Windows PowerShell to nie tylko rozbudowany interpreter poleceń, lecz potężne narzędzie, administracyjne i programistyczne, umożliwiające wykonywanie zadań absolutnie niewykonalnych w GUI, a na dodatek w sposób prosty, efektywny, a zarazem intuicyjny. Użytkownikami docelowymi Windows PowerShell są administratorzy systemów i programiści, którzy działają nie tylko w śwodowiskach systemowych i sieciowych Microsoft, ale taże w środowiskach sieciowych mieszanych.

Więcej informacji o Windows PowerShell, można uzyskać na stronach witryny Microsoft Developer Network.

Jeśli artykuł spodobał Ci się, proszę udostępnij go znajomym! Jeśli masz jakiekolwiek pytania, proszę o komentarze.