Seit einer Weile enthält Windows das “Subsystem für Linux” (WSL). Damit kann man Linux-Code nativ unter Windows ausführen, ohne dafür erst eine VM starten zu müssen oder ähnliches. Di Installation ist super einfach:
Am besten und einfachsten geht es per PowerShell (womit auch sonst? )
In letzter Zeit beschäftige ich mich immer mal wieder mit DevOps-Themen. Eines davon ist Continuous Integration und das dafür gemachte Jenkins. Einige meiner Erfahrungen hierzu möchte ich gerne teilen.
Dieser Artikel beschäftigt sich mit PowerShell Core und Jenkins. In einem vorherigen Artikel habe ich in Kurzform erläutert, wie man Jenkins unter Debian Linux installiert. Das ist für diesen Artikel eine Art Voraussetzung.
Auch ohne PS Core kann Jenkins PowerShell-Code und –Skripte ausführen – allerdings braucht es dazu immer einen sogenannten “Build Slave” (also einen weiteren Jenkins-Knoten) mit Windows als Betriebssystem,
Mit der Verfügbarkeit von PowerShell Core für Linux ist es künftig nicht mehr zwingend nötig, einen Windows Buildslave zu verwenden, wenn man PowerShell benutzen möchte. Was leider NICHT funktioniert (zumindest mit Stand Heute), ist das PowerShell-Plugin für Jenkins. Dieses ruft den Code in einer Art und Weise auf, wie es nur unter Windows funktioniert. Selbst wenn man den dort verwendeten Aufruf “powershell.exe” mittels symbolic Link oder Alias auf pwsh mappt, wird es nicht funktionieren.
Ein möglicher Weg führt aber über den Einsatz eines Batch-Skriptes. Und das könnte so aussehen:
Mit Hilfe von Parametern kann später flexibler mit dem Build Job umgegangen werden (siehe weiter unten):
Der Einfachheit halber sollte der Parametername keine Leer- oder Sonderzeichen enthalten.
Für den eigentlichen Build (also die Aktionen, die durch den Job auszuführen sind), muss man hier nun auf “Shell ausführen” zurückgreifen. Der Menüpunkt “Windows PowerShell” wird nicht funktionieren (er steht auch nur zur Verfügung, wenn das Plugin bereits installiert ist).
Mein Aufruf für die Shell lautet hier beispielhaft:
Mit ${PARAMETER} kann man auf den oben definierten Parameter zurückgreifen.
Anschließend kann man den Buildjob über “Bauen mit Parametern” aufrufen. Dabei kann man dann den Wert des/der Parameter definieren (oder, falls man Defaultwerte definiert hat, diese einfach beibehalten):
Anschließend kann man mit einem Klick auf den kleinen Pfeil neben dem Buildjob unten bei “Build-Verlauf” die “Konsolenausgabe” aufrufen:
Dort sieht man dann entweder den/die Fehler, falls welche aufgetreten sind, oder eben die Ausgabe des Jobs:
In letzter Zeit beschäftige ich mich immer mal wieder mit DevOps-Themen. Eines davon ist Continuous Integration und das dafür gemachte Jenkins. Einige meiner Erfahrungen hierzu möchte ich gerne teilen.
In diesem Artikel möchte ich kurz beleuchten, wie man Jenkins auf Debian 9 “Stretch” installieren kann. Es gibt sicherlich einige andere Wege, aber dieser hier funktioniert sehr schnell und zuverlässig.
Als erstes braucht ihr natürlich eine Debian Maschine. Ich nutze dafür gerne Hyper-V oder Azure, aber jede andere Plattform wird ebenso funktionieren. Wichtig ist am Ende eigentlich nur, dass die Maschine Internetzugriff hat.
Als nächstes braucht man die passenden Keys und eine Quelle für APT:
Der letzte Aufruf gibt das Initialpasswort aus, welches man anschließend für die Einrichtung benötigt.
Nun kann man unter
http://HOSTNAME:8080
den frisch installierten Jenkins aufrufen und einrichten:
Hier wird nun also der vorhin ausgelesene Key benötigt.
Bei den Plugins kann man im Zweifel erstmal mit den “suggested plugins” beginnen, aber ich bevorzuge es, einige nicht benötigte Plugins gar nicht erst zu installieren und wähle daher “Select plugins to install”. Meine konkrete Auswahl kann man in Teilen unten sehen:
Nun muss man noch ein Admin-Konto anlegen und dann kann es auch schon losgehen…
Auch wenn es nicht erst seit gestern verfügbar ist, wollte ich gern auf ein cooles Feature in Azure hinweisen: Azure Cloud Shell.
Kurz gesagt handelt es sich hier um ein Zugang zu Azure und seine Funktionen über PowerShell oder Linux Bash. Diese Shell läuft in einem Container auf Azure und kann ganz einfach über den Browser verwendet werden. Dazu ruft man einfach
auf. Nach der Anmeldung muss einmalig ein Storageaccount eingerichtet werden, der dann in die Shell gemountet wird
und dort als Speicher zur Verfügung steht:
Nach der Anmeldung bei Azure muss die gewünschte Subscription ausgewählt werden:
Dann erfolgt die Auswahl der gewünschten Shell – Bash auf Linux oder PwerShell auf Windows:
Außerdem muss ein Storageaccount ausgewählt oder angelegt werden, wozu die Auswahl des gewünschten Abonnements erfolgen muss:
Das Anlegen des Storage Accounts und der erste Start der Shell dauern dann leider etwas…
Fortan steht die Shell auch etwas schneller zur Verfügung. Sie kann auch aus dem Azure Portal aufgerufen werden – dazu ist der Button in der oberen Leiste gedacht:
Es gilt, ein paar Kleinigkeiten zu beachten:
Es gibt einen 20-Minuten-Timeout in der Shell. Nach 20 Minuten Inaktivität wird die Shell recycelt.
Änderungen im Dateisystem sind nur innerhalb von $Home und clouddrive persistent
Man kann jederzeit zwischen Bash und PowerShell umschalten – aber man kann immer nur eine Shell gleichzeitig laufen haben
Der Power-Button oben startet die Shell (bzw. deren Container) neu – dabei gehen dann z.B. die Variablen und deren Werte verloren
Das Starten einer auf PowerShell basierenden Cloudshell kann ca. 60 Sekunden dauern – Bash geht deutlich schneller
Im Zuge der Weiterentwicklung von PowerShell Core und der Ausrichtung auf Linux-Systeme hat Microsoft eine neue Strategie für die Remote-Verwaltung von Systemen entwickelt. Diese beinhaltet u.a. die Verwendung von OpenSSH unter Windows. Das an sich ist nicht wirklich neu – zumindest etwas neuer ist aber die Tatsache, dass diese Technologie jetzt seit dem 1709 Build (“Fall Creators Update”) als Beta im System integriert ist. Allerdings müssen die Komponenten bei Bedarf noch aktiviert / installiert werden. Und das geht so:
Startmenü / Einstellungen (Zahnrad) / Apps / Optionale Features verwalten / Feature hinzufügen:
Dort finden sich dann die beiden OpenSSH Optionen:
Beide Optionen sollten eigentlich selbst-erklärend sein…
Alternativ kann die Installation auch über PowerShell erfolgen:
# Installieren von Server und Client Add-WindowsCapability -Online -Name OpenSSH* # Nur Server Add-WindowsCapability -Online -Name OpenSSH.Server* # Nur Client Add-WindowsCapability -Online -Name OpenSSH.Client*
Der SSH Client läuft jetzt völlig problemlos von der Kommandozeile – wenn man den vollen Pfad benutzt:
C:\Windows\System32\OpenSSH\ssh.exe
Spätestens nach dem nächsten Neustart ist dann der Pfad auch in PATH und damit von überall aus aufzurufen.
Die Konfiguration des OpenSSH-Servers ist ein kleines bisschen aufwändiger. Diesem Thema werde ich demnächst einen weiteren Blogartikel widmen. Stay tuned!
In nächster Zeit möchte ich mich mehr mit dem Thema “PowerShell Core” (also PowerShell 6.0, der Version auf Grundlage von .NET Core, die auf Linux, Unix und MacOS läuft) beschäftigen. Den Einstieg soll die Installation der PowerShell Core unter Debian Linux machen.
Zunächst brauch man eine unterstütze Linux-Version. Aktuell sind das:
Ubuntu 14.04
Ubuntu 16.04
CentOS 7
OpenSUSE 42.1
Arch Linux
RHEL 7.2/7.3
Debian 8
MacOS 10
Konkret für Debian bedeutet das, dass man “old stable” (Jessie) benutzen muss, weil Debian 9 “Stretch” noch nicht unterstützt wird.
Nach der frischen Installation von Debian 8 braucht man sinnvollerweise noch folgende Pakete:
sudo (Dazu muss man sich ggf. als root einloggen!)
SSH (damit der Zugang und das Übertragen der URLs einfacher wird)
Nun können die Vorbereitungen und die eigentliche PowerShell-Installation durchgeführt werden:
# Import der GPG Schlüssel für das MS Repository
curl https://packages.microsoft.com/keys/microsoft.asc |sudoapt-key add -
# Registrierung des Microsoft Repositories
curl https://packages.microsoft.com/config/debian/8/prod.list |sudotee/etc/apt/sources.list.d/microsoft.list
# Oder alternativ:# curl https://packages.microsoft.com/config/ubuntu/14.04/prod.list | sudo tee /etc/apt/sources.list.d/microsoft.list# Update mit apt-getsudoapt-get update# Installation von PowerShellsudoapt-get install-y powershell
# Start der PowerShell Core
powershell
# Import der GPG Schlüssel für das MS Repository
curl https://packages.microsoft.com/keys/microsoft.asc | sudo apt-key add -
# Registrierung des Microsoft Repositories
curl https://packages.microsoft.com/config/debian/8/prod.list | sudo tee /etc/apt/sources.list.d/microsoft.list
# Oder alternativ:
# curl https://packages.microsoft.com/config/ubuntu/14.04/prod.list | sudo tee /etc/apt/sources.list.d/microsoft.list
# Update mit apt-get
sudo apt-get update
# Installation von PowerShell
sudo apt-get install -y powershell
# Start der PowerShell Core
powershell
Was für uns MVPs schon etwas länger bekannt war, wurde heute durch Microsoft offiziell bekannt gegeben (und daher darf ich nun auch darüber schreiben):
Die Windows PowerShell ist seit heute OpenSource! Das Projekt ist auf GitHub zu finden:
Da ich in der letzten Zeit immer wieder gefragt wurde, wie man einen Linux-Computer zur Verwaltung von SCCM hinzufügen kann, möchte ich dies hier kurz darstellen.
Zunächst benötigt man hierzu die Installationsquellen für den Configuration-Manager-Client für Linux bzw. Unix. Diese lassen sich über den Splash-Screen der SCCM-DVD besorgen:
Über diesen Link gelangt man (je nach Sprache) auf einer Microsoft-Webseite, z.B. dieser:
Beim Klick auf “Herunterladen” steht noch die Wahl, welche Version benötigt wird:
Die heruntergeladene EXE-Datei muss nun noch mittels Doppelklick entpackt werden:
Nach dem Entpacken müssen die Dateien auf das gewünschte Linux-/Unix-System kopiert werden. Beispielhaft verwende ich dazu SSH:
Nach dem Kopieren der Dateien muss die Datei “install” noch ausführbar gemacht werden. Dies geschieht mittels
1
chmod +x install bzw. sudochmod +x install
chmod +x install bzw. sudo chmod +x install
Nach diesem Vorgang kann die Installation gestartet werden. Als Parameter sind der Name eines Management-Point-Servers, der Site-Code sowie die notwendige Linux-Version anzugeben:
Sobald die Installation komplett ist, muss der Client noch im SCCM genehmigt werden:
Nun ist der Client im SCCM registriert. Das lokale Logfile des Clients befindet sich unter
/var/opt/microsoft/scxcm.log
Dieses kann z.B. mit Hilfe des Aufrufs
1
tail-F/var/opt/microsoft/scxcm.log
tail -F /var/opt/microsoft/scxcm.log
beobachtet werden.
Will man nun z.B. einen Policy-Abruf oder einen Hardware-Inventur-Zyklus erzwingen, ist dies mit den Aufrufen
1
/opt/microsoft/configmgr/bin/ccmexec -rs policy
/opt/microsoft/configmgr/bin/ccmexec -rs policy
bzw.
1
/opt/microsoft/configmgr/bin/ccmexec -rs hinv
/opt/microsoft/configmgr/bin/ccmexec -rs hinv
möglich.
Bei Bedarf kann man sich z.B. noch eine Gerätesammlung für alle Linux-/Unix-Systeme anlegen. Als begrenzende Sammlung verwendet man sinnvollerweise “Alle Systeme”. Die Mitgliedschaft lässt sich mit der Abfrageregel auf “Systemressource / Betriebssystem-Name und –Version” realisieren:
