Posts für Suchanfrage wsl werden nach Relevanz sortiert angezeigt. Nach Datum sortieren Alle Posts anzeigen
Posts für Suchanfrage wsl werden nach Relevanz sortiert angezeigt. Nach Datum sortieren Alle Posts anzeigen

Sonntag, 22. November 2020

WSL - Windows Linux - wie macht man das?

Ich habe mich etwas mit Windows Subsystem Linux beschäftigt und versucht einen produktiven Ablauf für Setup und Verwendung zu finden. 

Als Ergebnis gibt es auf meiner GitHub Seite ein Powershell Script, welches den automatischen Start von WSL und einer Applikation darin bewerkstelligt. Ich werde dieses Script sicher aktualisieren und erweitern, eine kurze Anleitung zur Verwendung findet sich am Ende des Artikels.

Dieser Artikel ist die Mitschrift der Installation und Einrichtung von WSL und meiner ersten Versuche. Der Code ist eher prinzipiell und nicht unbedingt fehlertolerant.

Grundeinrichtung

Update 4.8.2021

Wenn man das Update KB5004296 installiert hat, kann man im aktuellen Windows 10 wohl einfach so in der Powershell Konsole installieren - dies war bisher nur mit der Insider Preview möglich:

wsl --install

Mit dem Befehl „--install“ werden die folgenden Aktionen ausgeführt (Quelle):

  • Die optionalen Komponenten von WSL und Plattform für virtuelle Computer werden aktiviert.
  • Der aktuelle Linux-Kernel wird heruntergeladen und installiert.
  • WSL 2 wird als Standard festgelegt.
  • Eine Linux-Verteilung wird heruntergeladen und installiert (möglicherweise ist ein Neustart erforderlich) .
  • Standardmäßig ist die installierte Linux-Verteilung Ubuntu. Dies kann mit wsl --install -d <Distribution Name> geändert werden.

Unter Windows 10 kann man das Feature WSL entweder per GUI oder per Powershell installieren. Zwei optionale Feature müssen aktiviert werden:

Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform,Microsoft-Windows-Subsystem-Linux

Danach ist ein Neustart fällig.

Das Admin-Tool für Windows Subsystem Linux ist wsl.exe. Damit kann man auch testen ob die Installation erfolgreiche war und aktive Distributionen und deren Status auflisten:

wsl -l -v

Es ist jetzt noch ein Kernelupdate fällig (auch bei 20H2)! 

Bevor man eine Distribution installiert sollte man die default WSL Version 2 setzen. 

wsl --set-default-version 2

Danach installiert man über den Windows Store eine Linux Distribution (debian). Die Installation ist immer zweistufig: download des appx Packetes und anschließend automatische Installation beim ersten Start. Beide Schritte entweder über suchen und zwei Klicks im Store direkt oder über zwei Powershell Befehle. Scheinbar sind die MS Store Versionen neuer als die auf der Download Seite!

Der Windows Store verhielt sich bei mir manchmal zickig: Es passiert beim Button drücken passiert nichts!? Es gibt zahlreiche Beiträge und einen extra Link in den Windows Einstellungen "Fehlerbehebung bei Microsoft Store Apps". Es gibt das cmd Programm wsreset.exe.

Die finale Installationroutine startet das Subsystem sofort und fragt Linux User und Passwort ab. 

Jeder weitere Aufruf von wsl.exe öffnet ein "Terminalfenster", der Erste startet das Subsystem.

wsl -d debian

Die Grundlage ist geschaffen und WSL wartet auf ein praktisches Beispiel: 

Anwendung (FHEM) in WSL installieren und starten

Für die FHEM Installation braucht man vorher noch (kann sich offenbar täglich ändern)

sudo apt install wget gnupg

danach funktioniert der debian easy way, allerdings wird FHEM am Ende nicht gestartet. 

Hinweis 2024: Die wsl ubuntu Distribution arbeitet mit systemd, fhem wird wie gewohnt gestartet wenn man wsl startet. Die folgende Fehlerbehebung ist in ubuntu nicht notwendig.

Es gibt eine Fehlermeldung am Ende, der Grund: Die debian Distribution enthält kein aktives init System (Systemd). Unschön ist, dass diese Fehlermeldung im dpkg status gespeichert bleibt und fortan jeder Befehl mit dpkg oder apt diesen Fehler anzeigen wird. 

Deswegen sollte man diesen Fehler unbedingt korrigieren:

sudo sed -i '/^Package: fhem/n;s/Status: install ok half-configured/Status: hold ok installed/' /var/lib/dpkg/status

Den Erfolg kann man leicht testen, der Fehler sollte verschwunden sein.

sudo apt install -f

Der sed Befehl 

  • patched die Datei direkt, 
  • er sucht die Zeile "Package: fhem" und 
  • ersetzt in der nächsten Zeile den Fehler. 

Der Start von FHEM benötigt zwei Befehlszeilen, mir ist das nur über einen Script Datei gelungen. Es ist wichtig diese Datei Linux konform zu erstellen. Die Windows Taste + cmd oder Powershell öffnet die Sitzung im Userpfad. Ein anschließendes wsl öffnet die Linux Sitzung im Userpfad. Jetzt einfach mit nano start.sh die Datei mit diesem Inhalt erstellen:

cd /opt/fhem
perl fhem.pl fhem.cfg

Das Script als Startbefehl übergeben und die Linux Distribution mit dem User fhem starten.

wsl -u fhem -d debian -e bash start.sh

Zugriff auf Ports innerhalb WSL

Um auf das Netzwerk in WSL zuzugreifen, kann man vom Host einfach auf localhost(127.0.0.1) zugreifen. Die Ports von WSL werden an diese Hostadresse geleitet (WSL 1 und 2).

http://localhost:8083

Will man aus dem restlichen Netzwerk auf FHEM (den WSL 2 Service) zugreifen, muss man einen PortProxy einrichten und die Ports in der Firewall freigeben. Dafür braucht man erhöhte Rechte, also Powershell im Administratormodus starten.

Anmerkung: Ich bin nicht sicher ob ich die Sache mit dem Portproxy und den Adressen richtig verstanden habe. Aber auf die Art wie ich es gelöst habe, funktioniert es zuverlässig. Im nächsten Beitrag habe ich noch meine Versuche und Erkenntnisse dokumentiert.

Da sich die IP Adresse bei jedem Neustart von WSL 2 ändert, muss man dieses Script bei jedem Start ausführen! Ich habe verschiedene Varianten zur Ermittlung der IP gefunden.

#$cAddr=(wsl -- ip addr show eth0 `| grep 'inet ') -match '\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}'
#$cAddr=(bash.exe -c "ip addr show eth0 | grep 'inet '") -match '\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}'
#$cAddr=$matches[0]
$cAddr=(wsl hostname -I).Trim()    # entferne Leerzeichen am Ende
$ports=8083,1883                   # Array mit allen Ports
if (netsh interface portproxy show all){netsh interface portproxy reset}
Foreach ($port in $ports){
   netsh interface portproxy add v4tov4 listenport=$port connectport=$port connectaddress=$cAddr
}

Die Firewall Rules braucht man nicht bei jedem Start neu machen

New-NetFireWallRule -DisplayName 'WSL Firewall Unlock' -Direction Outbound -LocalPort $ports -Action Allow -Protocol TCP
New-NetFireWallRule -DisplayName 'WSL Firewall Unlock' -Direction Inbound -LocalPort $ports -Action Allow -Protocol TCP

Sind die Regeln einmal vorhanden, kann man sie mit einem Befehl bez. der Ports modifizieren.

Set-NetFirewallRule -DisplayName 'WSL Firewall Unlock' -LocalPort $ports

Automatischer Start beim Windows Start

Ich habe ein Powershell Script erstellt, welches das komplette Setup erledigt. Nach dem Download in Zeile 3 kann man das Script natürlich noch anpassen.

Zur Vorbereitung braucht man vier Zeilen:

mkdir c:\scripts -force
cd c:\scripts
wget -O c:\scripts\SetupStartWsl.ps1 https://raw.githubusercontent.com/heinz-otto/Powershell/master/SetupStartWsl.ps1
Set-ExecutionPolicy RemoteSigned
.\SetupStartWsl.ps1

Das Setup Script erledigt 4 Schritte:

  1. Erzeugung des Shell Scripts für den Start innerhalb WSL. 
  2. Erzeugung des Powershell Scripts für den Taskscheduler, 
    • welches das Script aus 1. mit wsl startet, 
    • den Portproxy einrichtet und 
    • die FirewallRegeln anpasst.
  3. Firewall Regel als Grundlage erstellen.
  4. Registrierung der Aufgabe (Taskscheduler) beim Systemstart mit erhöhten Rechten das Script aus 2. auszuführen.

Man könnte noch folgendes einbauen:

  • die verwendeten Ports beim Start des wsl auslesen
  • eventuell eine Startverzögerung berücksichtigen 

Doku zu den Powershell cmdlets: Task mit Powershell


Montag, 10. Oktober 2022

WSL und Docker Desktop - Neuigkeiten

Mit Windows 11 Build 22000 habe ich mal die Neuigkeiten bei der Installation von Windows-Subsystem für Linux und die Installation von Docker Desktop getestet. Die sind am Ende relativ umfangreich - gemessen an meinen früheren Versuchen.

Montag, 30. November 2020

WSL - ein paar Notizen zur Verwendung

Es gibt eine Menge im Netz zum WSL, aber vieles ist nicht klar mit Versionshinweisen beschrieben. Ich habe etwas mit WSL herum gespielt und hier meine Notizen dazu.

Versionen

Windows Server 2019: unterstützt nur V1, Tools: wsl.exe, wslconfig.exe, keine Store - nur manuelle Installation der (älteren) Distributionen.

Windows 10: unterstützt V1 und V2, Tools: wsl.exe mit erweitertem Umfang

Version 1: keine virtuelle Netzwerkkarte, verwendet direkt das Hostnetzwerk

Version 2: eine virtuelle Netzwerkkarte (bei jedem Neustart neue IP Adresse, Bereich 172.x.x.x) für alle Distributionen, besserer Kernel

Hier der offizielle Vergleich von MS.

Zugriff mit der virtuellen Maschine

wsl.exe öffnet quasi das "Terminal" ssh braucht man für die "Bedienung" nicht. 

Im Zusammenhang mit dem Thema "Kommandozeile" lohnt sich ein Blick auf Windows Terminal, dies ist seit kurzem über Windows Store installierbar.

Alle Datenträger vom Host sind direkt erreichbar (/mnt/c/...)

Die Ports aus der virtuellen Maschine werden an den Host durchgereicht, man kann über localhost:port oder 127.0.0.1:port zugreifen. Will man aus dem Netzwerk über den Host auf Ports in der virtuellen Maschine zugreifen, ist das Vorgehen bei V1 und V2 unterschiedlich. Die virtuelle IP ist aus dem Netzwerk nicht direkt erreichbar (NAT). 

Die Ports kann man mit ss -lntu innerhalb WSL V2 anzeigen, netstat und lsof sind nicht installiert (und funktionieren wohl nicht?). In WSL V1 habe ich keine Port Ausgabe hinbekommen, die Meldung klingt so, als ob im Kernel V1 etwas nicht implementiert ist.

Interessant: 

  • Aus dem ubuntu Subsystem heraus kann man direkt Windows Programme starten.
  • Mit einer kleinen Vorbereitung geht das auch umgekehrt, siehe diese Beschreibung.
  • In Windows kann man mit bash -c "Kommando" auch direkt Linux Befehle ausführen.

Die Distributionen (Ubuntu, debian) in WSL haben offenbar generell kein init System (wie systemd) aber eventuell kann man darauf auch verzichten. Mann kann den WSL und Prozesse darin direkt über die Windows Aufgabenplanung (Taskscheduler) starten.

Eine Kommando in Windows mit wsl.exe an WSL übergeben liefert die Ausgabe an Windows zurück. Die Ermittlung der IP Adresse gibt uns dafür ein paar Beispiele.  

Die einfachste Variante, funktioniert in CMD und Powershell - hat allerdings ein Leerzeichen am Ende. Dies kann man in PS einfach abschneiden (Befehl liefert String).trim()
wsl hostname -I

Ich habe die anderen Varianten mal zur Dokumentation und als Beispiel stehen lassen:

cmd Variante (fragt die wsl Umgebung ab, funktioniert aber nicht in powershell. Anmerkung: ^ ist ein Escape Zeichen der batch Umgebung)

WSL -d debian -- ip addr show eth0 ^| grep -oP '(?^<=inet\s)\d+(\.\d+){3}'

Powershell Variante Anmerkung: ` ist das Escape Zeichen in Powershell. Der Code braucht eine zweite Zeile!

(wsl -- ip addr show eth0 `| grep 'inet ') -match '\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}'
$matches[0]


Installation und Konfiguration

Das Root Dateisystem jeder Linux Distribution wird in einer dynamischen 256GB VHDX Datei installiert. Den Speicherort kann man sich in Powershell so ausgeben lassen:

& cmd "/c dir %LOCALAPPDATA%\Packages\$((Get-AppxPackage -Name "*debian*").PackageFamilyName)\LocalState"

Statt über die interaktive Installation über den Store kann man die Pakete auch manuell herunterladen. Achtung: Das praktische Ergebnis (November 2020) ist anders, als die über den MS Store. Die Versionen sind viel älter!

Und offenbar teilweise sogar unvollständig:

  • In einer Variante fehlte wget und gnupg 
  • Die öffentlichen Zertifikaten waren alt oder nicht vorhanden! Ein apt install ca-certificates behebt das Problem.

Mit der kurzen url von dieser Seite geht das auch mit Powershell. 

Get-AppxPackage *Ubuntu*|Remove-AppxPackage
Get-AppxPackage *debian*|Remove-AppxPackage
Invoke-WebRequest -Uri https://aka.ms/wsl-debian-gnulinux -OutFile Debian.appx -UseBasicParsing
Add-AppxPackage .\Debian.appx

Man kann in WSL V2 auch komplette Distributionen exportieren (einpacken) und wieder importieren.

Der Windows Server hat keinen Store, die Installation funktioniert nur so wie hier beschrieben

Der Server 2019 Version kennt anstatt Enable-WindowsOptionalFeature.

Install-WindowsFeature -Name Microsoft-Windows-Subsystem-Linux

Die Hyper-V Umgebung

Ob Hyper-V schon aktiv ist kann man mit diesem Powershell Einzeiler testen:

(gcim Win32_ComputerSystem).HypervisorPresent

Ob die Hardware Hyper-V und damit auch WSL unterstützt kann man mit einem Powershell Einzeiler testen:

$list=@('Name', 'SecondLevelAddressTranslationExtensions', 'VirtualizationFirmwareEnabled', 'VMMonitorModeExtensions');Get-CimInstance -ClassName win32_processor -Property $list|Format-List $list

Ich habe diesen Test in einer virtuellen Maschine (Hyper-V) durchgeführt. Hier muss man auf dem Hyper-V Host die Virtualisierung an die Maschine "weiterreichen":

$vm=Get-Vm -Name <MaschineName>
Stop-Vm $vm
Set-VMProcessor $vm -ExposeVirtualizationExtensions $true
Start-Vm $vm


Die Ports

Achtung: Das Verhalten der Portweiterleitung ist unmittelbar nach der Einrichtung und nach einem Neustart unter Umständen komplett anders! 

Irgendwie gelingt es relativ leicht, dass man sich das Portmapping aus WSL heraus auf 127.0.0.1 zerschießt - ein netsh interface portproxy reset bewirkt dies zuverlässig. 

Hat man einmal einen Portproxy eingerichtet, funktioniert das Ganze nach einem Neustart nicht mehr. Man muss alles löschen und neu einrichten. Will man portproxy Einträge wieder löschen, kann man dies auch einzeln mit delete v4tov4 listenport=8083 tun! Dabei bleibt offenbar das (nicht sichtbare?) default Mapping erhalten. Löscht man den Eintrag für portproxy, stellt ein Neustart die ursprüngliche Funktion wieder her. 

Die Lösung für meine beobachteten Probleme liegt darin, den portproxy nicht auf localhost einzurichten (obwohl dies zunächst funktioniert) sondern auf die WSL eth0 Adresse. Hier ein Beispiele, die ich im Weiteren auch verwendet habe: 

  1. Artikel WSL Port forwarding 
  2. Artikel auf superuser

Mit tasklist | findstr wslhost kann man nachschauen auf welcher PID wsl arbeitet, mit netstat -aon | findstr <Suchstring> kann man den Prozess oder das Port darstellen. Die Prozesse innerhalb von wsl werden aber separat geführt. Mir ist es noch nicht die gesamte Prozesskette darzustellen.

Die wsl Kommanozeile

Es gibt einen Unterschied in der Verarbeitung zwischen dem Parameter -e und -- 

  • Bei -- kann man mehrere Befehle übergeben, getrennt mit Semikolon Befehl1;Befehl2,
  • das funktioniert offenbar bei -e nicht!
  • Gibt man den Linux Account mit:  -u username - funktioniert die Übergabe mehrere Befehle aber nicht mehr.

Empfehlung: Einfach eine Scriptdatei machen, das funktioniert viel einfacher als sich mit escapen und Variablenauflösung herumzuschlagen. Das Konstrukt wsl -e bash Script.sh funktioniert in gleicher Art in CMD, Powershell.


Dienstag, 2. April 2024

USB Geräte in Windows WSL nutzen - oder Virtualisierung tief verschachtelt

 Da hab ich ein "neues" Projekt gefunden (gibt es offenbar schon 2 Jahre) womit es nun möglich ist USB Geräte in WSL 2 zu verwenden. Ich probiere solche Dinge gerne in einer virtuellen Maschine - damit geht die Odyssee der Stolpersteine los ...

Manchmal entdeckt man dabei Dinge die man schon immer wissen wollte, die habe ich jetzt einfach mit aufgeschrieben. Das Ergebnis diese Artikels ist ein WSL/Linux auf einem Windows/Hyper-V welches auf Linux/KVM auf einer physischen CPU läuft! In dem WSL könnte man noch Docker installieren!

Mittwoch, 30. Juni 2021

Docker - ein kleiner Schnellstart Workshop

Die Docker Dokumentation finde ich so umfangreich, ich weiß nicht wo ich anfangen soll. Deswegen habe ich mal einen kleinen Einstieg mit ein paar nützlichen Kommandos aufgeschrieben. Es ist meine Sicht der Dinge und soll keinesfalls ein: "wie mach ich es richtig" Dokument sein.

Ich habe diesen Workshop auf einem Raspberry Pi 3+ und auf einem Windows PC mit Docker Desktop ausprobiert. Selbstverständlich kann man auch ein vorhandes Linux System oder eine virtuelle Maschine verwenden.

Dienstag, 12. Januar 2021

Container Schiff

Schon oft gelesen und dann immer wieder abgestorben - so lief das Thema Docker für mich bisher. Dabei bin ich ja schon seit der ersten vmware Version ein großer Fan von Virtualisierung!

Aber jetzt - ein kleiner Vortrag über FHEM im Container hat mich bewogen es zu versuchen, wie so oft schreib ich hier mal mit, damit ich später weiß was ich gemacht habe.

Ich habe als Ergebnis des Artikels ein Setup Script auf Github abgelegt. Dieses Script

  • installiert docker und docker-compose
  • bringt den aktuellen user in die Gruppe docker
  • richtet portainer als ersten Container ein
Die Entwicklung von docker und docker-compose schreitet voran, es können sich jeden Tag Änderungen ergeben. So wie heute (18.12.2021) gestern ging die hier beschriebene Installation mit pip noch, heute funktioniert es nicht mehr. Ich versuche den Artikel immer wieder zu aktualisieren.