Skip to Content

IT nieuczesane.
category

Category: DevOps/Scripting

skrypty, programy, command line i inne

konQrs WGUiSW

zgodnie z zapowiedziami – po 3ciej części mini-serii dotyczącej PowerShell na WGUiSW rozpoczyna się konqrs, w którym do wygrania będzie na szczurach pędzona woda ognista (12to letni chivas). zasady konkursu są proste:

  • celem jest napisanie funkcji efektów dla silnika PowerPresentation czyli:
    • trochę zabawy nad niekonieczną rzeczą
    • dobry powód do nadrobienia zaległości z PS albo pouczenia się trochę
  • oceniane będą:
    • poprawność – czy funkcja napisana jest poprawnie, czyli ma odpowiednie deklaracje, opisy itd
    • fajność – czyli czy efekt robi wrażenie
    • kompatybilność – będzie wymagał możliwie mało zmian w kodzie głównym *[dalej napiszę o co cho]
  • oceniał będę ja, czyli nExoR, na podstawie subiektywnej oceny.
  • kod PP wraz z prezentacjami WGUiSW jako przykłady można zassać stąd.
  • efekty należy tworzyć jako oddzielne pliki zawierające funkcje efektów z podwójnym rozszerzeniem – .ppe.ps1 . takie pliki są automatycznie dot-soursowane przez PP
  • kod można przesyłać na mój adres nexorek[at]gmail.com do końca maja
  • wyniki zostaną podane na kolejnym WGUiSW – o3.o6.2o14

PowerPresentation to skrypt, który wyświetla prezentacje w hoście PS – ci, którzy uczestniczyli we WGUiSWach mieli okazję go zobaczyć w działaniu. na napisanie go nie poświęciłem jakoś specjalnie dużo czasu – chodzi o zabawę, więc proszę się nie czepiać kodu. nie pisałem modułu, ponieważ wymagało by to instalacji czy innych wynalazków a chodzi o to, żeby prezentację można było łatwo uruchomić na dowolnym kompie z PS np. z pendrive’a.

PP wykorzystuje prosty plik XML jako wsad prezentacyjny. opis podstawowych tagów znajduje się helpie do funkcji – są to tak nieskomplikowane rzeczy, że nie chce mi się tego opisywać w szczegółach. w razie co zawsze można napisać do mnie maila do wyjaśnię.

domyślam się, że ze względu na prymitywizm kodu niektóre pomysły mogą być nierealizowalne lub wymagałyby potwornej akrobatyki. dla tego dozwolona jest modyfikacja kodu PP ale:

  • zmiany powinny być możliwie niewielkie
  • cała reszta musi działać nawet po zmianach – czyli albo nie mogą one wpłynąć na działanie standardowych funkcji albo trzeba je również poprawić.

wszystkie działające efekty zostaną opublikowane (:

zapis sesji WGUiSW dostępny jest na http://wiki.wguisw.org/ w ramach spotkań 59-61.

DOBREJ ZABAWY! =^.^’=

eN.

 

WTF is OFS?

takie drobne ciekawostki w PowerShell… weźmy prosty operator join:

okazuje się, że można prościej:

druga ciekawostka, to tajemnicza zmienna $ofs:

ciekawe, co? ofs to Output Field Separator – globalna zmienna, która definiuje znak stosowany właśnie przy konwersjach tablicy do stringa. zmienna jest trwała dla całej sesji, czyli każda następna zmiana będzie z niej korzystać.

eN.

migracja, FSP i ogólnie bałagan

przejąłem projekt migracji – konsolidacja struktury domen do nowej, pojedynczej domeny. „wszystko już praktycznie zrobione, będziesz się nudził” – z taką optymistyczną informacją zaczynałem pracę nad zadaniem. z bardzo wielu krzaków, które wyszły, sqpię się nad jedną ciekawostką.

po przejrzeniu zmigrowanych grup okazało się, że część kont jest pokazywana jako konta external. listing członkostwa w grupie ujawniał wpisy typu:

CN=S-1-5-21-2096504233-xxxxxxxxx-944726268-2633,CN=ForeignSecurityPrincipals,DC=target,DC=domain

CN=S-1-5-21-2096504233-xxxxxxxxx-944726268-3498,CN=ForeignSecurityPrincipals,DC=target,DC=domain

Tak są właśnie przechowywane referencje do kont z lasów ztrustowanych. zacząłem więc szukać co to za domena. sprawa prosta, ponieważ zasada jest taka sama jak przy zwykłych SIDach – pierwsza część SID to domainSID. sprawdziłem więc ID wszystkich domen źródłowych [zwykły (Get-ADDomain).domainsid.value] … i okazało się, że takiej domeny nie ma /:

śledztwo. „taaaaakk…hmmm… była kiedyś migracja parę lat temu, tej domeny już nie ma”. tia. ostatnim etapem migracji jest cleanup SIDhistory, którego ktoś nie zrobił. sprawdzam grupy w domenie źródłowej – sweet, tam też członkowie pododawani są przez SIDHistory.

po dalszym przeglądzie okazało się, że w grupach były również konta z domen połączonych trustem nieprzechodnim z domeną źródłową, czyli nierozwiązywalne – kolejna grupa dziwnych FSP. tych niestety nie da się w żaden sposób przenieść chyba, że utworzy się trust z tymi externalami. poznajdywały się również konta CNF [w nowej domenie!] i inne wynalazki. i tak to właśnie się nudziłem…

po pierwsze wniosek/porada: migrację zaczyna się od czyszczenia. nawet jak klient mówi „przenosimy 1:1” – trzeba zweryfikować jak bardzo jest naśmiecone i poczyścić.

po drugie – skrypt, czyszczący FSP

z ciekawostek: do usunięcia usera z grupy korzystając z CN, musiałem użyć ADSI – nie potrafiłem zmusić koszernych cmdletów do obsłużenia CNa.

eN.

repozytorium artów o PowerShell

wpisów ostatnio brak, ponieważ idą w eter. WDI już za nami – sesje niby mają być dostępne online. streamy będą chyba dostępne na PJWSTKTV – jest już dzień drugi, ale nie moja ścieżka. ciąg dalszy zmagań z PowerShell na WGUISW – to będzie poważny prima aprilis q:

w ramach przygotowań do wszystkich sesji zebrało mi się całkiem pokaźne repozytorium mniej lub bardziej przydatnych linków dot. PS. miłej lektury.

sporo fajnej wiedzy, która pokazuje, że PS to nie jest tylko głupi shell ale na prawdę potężne narzędzie – opanowanie wszystkich technik programowania to niemal developerka – ale korzyści będą nieocenione ^^

eN.

jak rozpoznać kartę WiFi?

scenariusz: trzeba napisać skrypt, który będzie wyłączał rejestrację DNS dla interfejsów LANowych. służy do tego metoda SetDynamicDNSRegistration klasy Win32_NetworkAdapterConfiguration. pozostaje problem – jak znaleźć owe interfejsy LANowe, bo zwykłe wylistowanie interfejsów pokaże ich multum… są dwa warunki, które trzeba sprawdzić – odfiltrować te, które nie są IPEnabled oraz te, które nie są Wired. i tu się zaczynają schody – IPEnabled to parametr klasy Win32_NetworkAdapterConfiguration a typ interfejsu pokazuje atrybut AdapterTypeID klasy Win32_NetworkAdapter.

sprawdzenie obu tych warunków byłoby niemożliwe [mega-złożone] gdyby nie klasy asocjacyjne – w tym przypadku Win32_NetworkAdapterSetting, która łączy obie wcześniej wymienione. klasy asocjacyjne pobierają atrybuty dla obu klas dla danego urządzenia i publikują je w dwóch gałęziach – element oraz setting. skrypt finalnie wygląda tak:

proste, nie? a teraz ciekawostka na koniec. na MSDN wyraźnie i jasno opisane są ‚adaptertype’ oraz ‚adaptertypeid’.. a oto jak przedstawia się moja karta WiFi /:

PS C:\_ScriptZ> .\setDynDNSReg.ps1
[debug] adapter type: Ethernet 802.3
[debug] zmieniam parametr dla: [00000000] Karta Intel(R) Centrino(R) Wireless-N 1000

eN.

przenoszenie uprawnień między domenami

jakiś czas temu pisałem o fajnym narzędziu do sprawdzenia uprawnień w AD – AD ACL Scanner. chciałem użyć go do przeniesienia uprawnień między domenami… i okazało się, że nie jest to wcale takie proste:

  • plik csv, który jest generowany jako raport, nie zawiera nagłówka – a więc nie wiadomo co oznaczają poszczególne wartości
  • wartości w raporcie HTML mają nagłówki… ale nie wszystkie i nie takie same
  • no i nawet jeśli znam nagłówek – to jak to przenieść?

oto szkic skryptu, który potrafi zaciągnąć plik z ADADCLscan i przenieść do innej domeny. to, co trzeba zrobić przed jego użyciem to:

  • zmienić w pliku raportu nazwę domeny źródłowej na docelową we wszystkich rekordach
  • wyciąć przedrostki z nazw grup [np. DOMAIN\mygroup -> mygroup]

skrypt jest bardzo prymitywny – np. zakłada, że uprawnienia są tylko dla grup a nie dla użytkowników czy komputerów, nie ma obsługi błędów, etc – niemniej pokazuje kilka ważnych elementów: jak wygląda pełny nagłówek, w jaki sposób korzysta się z cmdletów ACL.

eN.

 

Alternate Data Stream

o ADS już kiedyś pisałem – oj dawno. dziś tylko małe uzupełnienie dot. PowerShell:

do tej pory jedynym sensownym sposobem usunięcia ADS było zassanie streams.exe z sysinternalsów. ale lepiej znać narzędzia które w systemie są od razy – czyli PS. scenariusz: zassany skrypcik z netu na jednym z kompów ciągle jest klasyfikowany jako ‚zone.identifier 3’ czyli z Internetu. i choćbym klikał na ‚unblock’ 1ooo razy – ni huhu. z jakiegoś powodu nie kasuje tej informacji. z PS proste jak drut:

 

et voila!

eN.

obsługa błędów w PS

w ramach ciekawostek – żeby ładnie obsłużyć błędy korzysta się z try-catch-finally… ALE. jak zwykle jest jakieś ale. pisząc skrypty do AD straciłem sporo czasu nie rozumiejąc o co c’mon, ponieważ polecenia get-ad* inaczej zachowują się, jeśli korzysta się z ‚-identity’ a inaczej jeśli ‚-filter’. w sumie jest to całkiem logiczne – ponieważ identity oczeqje istniejącej nazwy więc zwraca błąd jeśli jej nie ma. filter to prostu filtr, więc jeśli takiej nazwy nie ma, to po prostu zwraca $null. a więc trzeba uważać ‚co jest błędem’ …

 

eN.

skrypt audytujący

zadanie – jak zaudytować komputery poza domeną tak, aby stwierdzić jakie są na nich aplikacje i jakie licencje? prostym zapytaniem WMI można dowiedzieć się, że wersja systemu to np. WinXP pro – ale OEM czy VLK?

nie udało mi się dotrzeć do samych linków na MSDN ale udało mi się zebrać te informacje. kilka ogólnych:

  • MAP toola nie da się użyć często ze względu na niedostępność komputerów a czasem credentiali. niestety takie środowiska są i to wcale nie tak rzadkie jakby się mogło wydawać…
  • wersję licencji OEM/VLK/MAK można wyciągnąć np. przy pomocy slmgr.vbs … ale tego nie ma na XP. poza tym lepiej mieć to we własnym skrypcie. kluczem jest „HKLM\SYSTEM\Setup\Pid”. w skrypcie poniżej pokazuję konkretne wartości.
  • można nawet dowiedzieć się jaka to wersja na podstawie innego klucza – ale pełnej listy nie mam.
  • korzystanie z metody Win32_product nie jest wskazane ponieważ każde takie odpytanie automatycznie uruchamia proces weryfikacji. trwa długo i może doprowadzić do dziwnych komunikatów – ogólnie wysypać się. dodatkowo – klasa PRODUCT nie jest standardowo instalowana na wersji XP /: trzeba ją oddzielnie dodać. lepiej skorzystać z zapytania do rejestru.
  • odpytując rejestr na 64 bitowej maszynie musimy zrobić dwa zapytania, zmieniając providera – inaczej dostaniemy tylko małą część aplikacji zainstalowanych.
  • do bardziej skomplikowanych operacji oraz bardziej wymyślny skrypt -> open audit

a poniżej kod. oczywiście w VBS ponieważ to jedyny ‚standard’ który zadziała na każdej wersji od w2k aż po dzisiejsze w8.1

eN.

wyszukiwanie ciągów znaków

kilka słów o jednej z najczęściej wykonywanej czynności – wyszukiwanie ciągów znaków. przydatne w każdym aspekcie – debugowanie wyników, przeglądanie logów lub po prostu zawężanie outputu. w Linuxie jest stary, dobry grep. a co jest w PS?

w pierwszej kolejności jest Select-String. narzędzie potężne – i jak to często w przypadq PS, zdradliwe. największą zdradą jest fakt, że sls [automatyczny alias od PS3.o] nie jest zwykłym grep’em textowym – jest narzędziem obiektowym. praktycznie wszystko w PS jest obiektem, więc również listingi nimi są.

zależnie od wersji PS – 1.o, …4.o – dostaniemy inne wyniki. w wersji 3.o i mniejszej, przy standardowej ‚tabelce’, dostaniemy wyłącznie wynik pojedynczej kolumny:

PS C:\> Get-Process | Select-String power

System.Diagnostics.Process (powershell)

w PS4.o wyniki najpierw są parsowane do stringa, więc wynik jest bardziej tym, czego można się spodziewać (ALLELUJA!):

PS C:\> Get-Process|sls power
512      25    72944      82868   611     4,05   3528 powershell

jak zatem radzić sobie z Select-String w PS3.o-? IMHO najprostszym sposobem jest wykorzystanie ‚starego, dobrego’ findstr. dość drastyczne różnice w wersjach PS to jedna z największych bolączek – wszystko idzie w dobrym kierunq, ale niespójność konsoli i narzędzi na poszczególnych serwerach jest WIELKIM PROBLEMEM. kiedyś o tym już pisałem obszerniej. dodatkowo, na dzień dzisiejszy, wersja 4.o [dostępna w win8.1/12] jest dostępna wyłącznie ‚preview’.

a jak ktoś się uprze, żeby jednak koszernie używać Select-String w PS3.o- oto jak to powinno wyglądać:

PS C:\> (Get-Process | Out-String ) -split "`n" | Select-String power
645      30   140712     157660   647    11.69   7728 powershell

masakra, co? nie dość, że trzeba najpierw skonwertować wynik na string, to jeszcze trzeba powstawiać line-feedy. jest jednak jedna cecha Select-String, która powoduje, że czasem warto się przemęczyć – parametr ‚context’. głupi findstr Ci tego nie da (; context powoduje wyświetlenie X linii przed i po wystąpieniu danego ciągu. jest to niezwykle przydatne np. przy filtrowaniu [grepowaniu (; ] netstat. odpowiedź na pytanie ‚jaka aplikacja bloqje port 53500?’:

PS C:\> netstat -anb |sls 53500 -Context 1
[lync.exe]
>   TCP    192.168.7.77:53500     157.55.236.69:443      ESTABLISHED
[Explorer.EXE]

przy prostym findstr dostaniemy wyłącznie pojedynczą linię – co nie odpowie na pytanie…

dość fajnym dodatkiem jest narzędzie outgridview, które przy przeglądaniu wyników może również wiele dobrego wnieść [dostępne po zainstalowaniu PS ISE]. daje możliwość graficznego przeglądania wyników i dynamicznego filtrowania:

PS C:|>Get-Process | Out-GridView

eN.

 

%d bloggers like this: