Archiv für den Monat: Januar 2017

Die DSC-Script-Ressource etwas flexibler einsetzen

Zu den knapp ein Dutzend DSC-Ressourcen, die bei der PowerShell 5.0 von Anfang an dabei sind, gehört auch die Script-Ressource. Mit ihrer Hilfe ist es möglich, auf einem Node bei der Anwendung der Ressource durch den LCM beliebige Skriptbefehle auszuführen. Das hört sich zunächst einmal gut an, etwas kniffliger ist es die Ressource so einzusetzen, dass sie wirklich etwas bringt. Das bedeutet konkret, Parameterwerte, die Teil der Konfigurationsdaten sind, in die per SetScript ausgeführten Befehle einzubauen.

Die Script-Ressource umfasst drei Eigenschaften: TestScript, GetScript und SetScript. Alle drei Eigenschaften sind vom Typ String, ihnen kann aber auch ein ScriptBlock zugewiesen werden was im Allgemeinen die etwas flexiblere Variante ist. TestScript enthält einen Befehl/Befehlsfolge, die einen $true/$false-Wert zurückgeben muss. Nur wenn der Wert $false ist, wird der Befehl ausgeführt, der über SetScript festgelegt wird. GetScript erfüllt keine echte Funktion. Die Befehlsfolge muss eine Hashtable mit einer Result-Eigenschaft zurückgeben, die einen beliebigen Wert besitzen kann.

Soweit, so gut. In der Regel sollen die per SetScript auszuführenden Befehle Werte verarbeiten, die Teil der Konfigurationsdaten sind. Dazu muss die Variable Node in die Befehlskette eingebaut werden. Am einfachsten geschieht dies, in dem der Node-Variablen ein „using:“ vorangestellt wird. Per Using kann auch eine Variable angesprochen werden, die außerhalb der Konfiguration definiert ist.

Im folgenden Beispiel soll eine Datei über das Web herunterladen und in einem lokalen Verzeichnis abgelegt werden. Die Url ist Teil der Konfigurationsdaten und wird daher über die Node-Variable angesprochen.

Der folgende Aufruf setzt die Konfiguration um.

Der folgende Aufruf überträgt die Konfiguration auf den über die Konfigurationsdaten festgelegten Computer (in diesem Beispiel ist es der lokale Computer).

StarWars Episode IV via Telnet als ASCII-Film

Auch wenn der Star Wars-Film im ASCII-Format vermutlich nichts Neues mehr ist, bin ich erst vor kurzem per Zufall darauf gestoßen und finde das Ganze einfach nur genial.

Einfach Telnet in PowerShell oder Cmd starten (der Telnet-Client gegebenenfalls noch als Feature hinzugefügt werden) und „telnet towel.blinkenlights.nl“ eingeben. Und schon geht es los.

Großes Kompliment an die Macher (ich möchte nicht wissen, wieviel Zeit, die man mit sinnvolleren Dingen hätte verbringen können, dafür geopfert werden musste – aber auf der anderen Seite, damit haben sie sich im Hacker- und Geek-Universum verewigt). Auf alle Fälle ist es ein gelungenes Beispiel dafür, wie Hacker die Welt ein klein wenig besser machen können, in dem sie etwas schaffen, dass einfach Freude macht und das zeigt was mit Bits, Programmierung und einer großen Portion Kreativität alles machbar ist. Der „Film“ ist erstaunlich „kompakt“ und macht schon Spaß alleine, um noch einmal die ganzen Zitate aus Episode IV mitlesen zu können („this are not the droids you are looking for“). Leider, und das ist ein großes Leider, ist der Film noch nicht fertig, sondern hört irgendwann im letzten Drittel einfach auf. Die Zerstörung des Todessterns, soviel verrate ich bereits, ist leider noch nicht umgesetzt. Ich denke, dass dies aufgrund der besonderen perspektivischen Darstellung auch eine echte Herausforderung sein dürfte. Der Autor Simon Jansen hat auf seiner Wbeseite aber in Aussicht gestellt, dass er sein Projekt irgendwann fertigstellen wird.

Die ersten Schritte mit den AWS-Cmdlets (inkl. Problemlösung)

Amazon stellt für die Nutzung ihrer inzwischen sehr umfangreichen Amazon Webservices (AWS) ein sehr umfangreiches Modul (über 2.500 Cmdlets!) zur Verfügung. Die AWS Tools for Windows PowerShell stehen u.a. über die PowerShell Gallery zur Verfügung.

Eine ausführliche Übersicht gibt es unter der folgenden Adresse: https://aws.amazon.com/de/powershell/. Dort gibt es auch einen Button für den direkten Download einer Msi-Datei, über die das .NET SDK und die Cmdlets installiert werden.

Die Dokumentation ist, typisch für AWS, vorbildlich mit ein paar kleineren Abstrichen.

Das Modul muss direkt per Import-Module geladen werden.

Ein kleiner „Trick“ zählt die Anzahl der Cmdlets, in dem die Verbose-Ausgabe auf den Standardausgabekanal umgeleitet und damit in die Pipeline gelegt wird.

Die Authentifizierung erfolgt über einen Access Key und einen Secret Key, die man zuvor in der AWS-Konsole im Browser anlegen muss. Der Secret Key wird nur einmalig beim Anlegen eines neuen Key angezeigt und kann als Csv-Datei heruntergeladen werden.

Mit den beiden Zutaten wird per Set-AWSCredentials ein Profil angelegt.

Hier kam es bei mir zu einer Fehlermeldung, die besagte, dass der Pfad %userprofile%\.asws\credentials nicht gefunden werden konnte. Dieser Fehler muss wohl mit der Version der AWS-Tools (3.3.45.0) und anderen Faktoren zu tun haben. Der Fehler trat nicht mehr auf, nachdem ich im Benutzerprofil ein Verzeichnis mit dem Namen .aws angelegt hatte.

Interessant ist, dass die Keys aber nicht in diesem Verzeichnis, sondern als Json-Datei RegisteredAccounts.json unter %userprofile%\AppData\Local\AWSToolkit abgelegt werden.

Anschließend wurde das Profil per Get-AWSCredentials -ListStoredCredentials aufgelistet. Per Clear-AWSCredentials kann ein Profil wieder gelöscht werden.

Die weitere Vorgehensweise ist dann sehr einfach. Bei allen Cmdlets wie z.B. Get-S3Bucket erfolgt die Authentizierung über das Profil, das per ProfileName-Parameter angegeben wird.

WMF 5.1 offiziell verfügbar

Seit Mitte Januar 2017 gibt es offiziell die Version 5.1 der Powershell und des Windows Management Framework (WMF) für alle windows-versionen ab Windows Server 2008 R2 und Windows 7.

Die Download-Adresse ist:

http://www.microsoft.com/en-us/download/details.aspx?id=54616

Viele Neuerungen sind es natürlich nicht, aber es gibt Neuerungen. Eine davon sind signierte Module. Eine andere ein Satz an Cmdlets für die Verwaltung lokaler Benutzer und Gruppen.

Die immer lesenswerten Release-Notes gibt es hier:

https://msdn.microsoft.com/en-us/powershell/wmf/5.1/release-notes

Bericht vom 1. Treffen der PowerShell User Group Stuttgart – und ein paar Tipps zum Umgang mit Hashtables

Am 12.1.2017 fand das erste Treffen der PowerShell User Group Stuttgart statt. Gastgeber waren die Firma Microsoft, die uns einen Raum in ihren schönen Firmenbüro in Vaihingen bei Stuttgart zur Verfügung stellte. Wenn ich mich nicht verzählt habe, waren wir insgesamt zu neunt, so dass die magische Grenze von 10 knapp verfehlt wurde. Aber für das erste Treffen, dessen Termin zudem so kurzfristig angesetzt wurde, war das bereits ein guter Anfang.

Nachdem Friedrich anhand eines von ihm entwickelten „Frameworks“ für die Rechnerkonfiguration, das er in seiner Firma einsetzt, einige recht spezielle Techniken vorgestellt hatte, unter anderem eine auf eigenen Attributen basierende Parametertyp-Konvertierung, gab ich einen Überblick über das Thema Hashtable, das in meinen Schulungen in der Regel eine gewisse Verständnishürde darstellt – inzwischen war es bereits 21 Uhr 20, so dass das ganze Treffen etwas länger ging als geplant. Kurz nach 22 Uhr war dann Schluss.

Noch ein Nachtrag zu einem meiner Beispiele, in der ich eine Hashtable mit einigen Tausend Datensätzen so ansprechen wollte, dass der Datensatz über eine Zahl ausgewählt wird, die die Rolle der Id des Datensatzes spielt.

Der folgende Befehl hat leider nicht funktioniert:

8000 ist der Wert eines Schlüssels. Der Befehl gab, sooft ich es auch probierte, einfach nichts zurück. Da es bereits etwas später war (und die Raumtemperatur für meinen Geschmack deutlich zu hoch eingestellt war) gab ich es dann auf. Die naheliegende Lösung $Liste[8000].Nachname war mir etwas zu trivial, da es auch anders gehen sollte.

Heute habe ich mich noch einmal auf die Suche nach einer Lösung gemacht und bin hier fündig geworden: http://blog.danskingdom.com/accessing-powershell-variables-with-periods-in-their-name.

Die Lösung besteht darin, den Index in runde Klammern zu setzen:

Und da wir gerade dabei sind: Einträge zu eine Hashtable per += hinzufügen ist deutlich langsamer als per Add-Methode.

Das erste Treffen der neuen PowerShell User Group Stuttgart fand in den Räumen von Microsoft in Vaihingen statt

Runspace-Debugging in 5 Minuten

Mit der Version 5.0 der PowerShell wurde das Debuggen eines Runspaces ermöglicht. In der Praxis wird man diese Technik vermutlich eher selten benötigen. Wer sich dennoch aus welchen Gründen auch immer für das Thema interessieren sollte, der Umgang mit Runspaces ist relativ einfach (ein Runspace ist der „Bereich“, in dem ein PowerShell-Befehl ausgeführt wird – jede Sitzung/Session enthält mindestens einen Runspace – es lassen sich beliebig viele weitere Runspaces anlegen, in denen beliebige Befehle ausgeführt werden – interessant ist diese Option immer dann, wenn die Befehle asynchron ausgeführt werden).

Das folgende kleine Beispiel führt einen Scriptblock in einem weiteren Runspace aus. Per Wait-Debugger wird der Debuggmodus aktiviert. Anschließend kann man sich per Debug-Runspace mti dem Runspace verbinden und die Befehle des Scriptblocks debuggen. Die Id des Runspace erhält man per Get-Runspace-Cmdlet.

Im nächsten Schritt muss man sich per Get-Runspace die Id des neuen Runspace holen. Danach kann man diesen Runspace mit dem Debug-Runspace-Cmdlet debuggen und die einzelnen Befehle über die Debug-Kommandos (s, v, l usw.) ausführen.