Update: Linux on Windows (WSL) für Windows 1703

Zweimal habe ich mir das Windows Subsystem for Linux (WSL), umgangssprachlich Linux on Windows schon angesehen: Das erste Mal vor knapp einem Jahr hier im Blog, ein zweites Mal im Herbst 2016 für derstandard.at. Insofern beschränke ich mich hier auf eine Zusammenfassung der Features, die sich seither geändert haben.

Alle Tests habe ich unter Windows 10, Insider Programm, Slow Ring (»verzögerte Anzeige«) durchgeführt. Der seit einigen Tagen verfügbare Build 15058 soll weitestgehend dem für April erwarteten Creator Update entsprechen.

WSL hat offiziell noch immer Beta-Status. Zur Installation müssen Sie in den Systemeinstellungen den Entwicklermodus und im Programm Windows Features das Windows Subsystem für Windows (Beta) aktivieren. Nach einem Neustart finden Sie im Startmenü die bash. Bei dessen ersten Start werden dann die Ubuntu-Pakete aus den Windows Store heruntergeladen.

Erste Experimente im bash-Fenster des »Windows Subsystem for Linux«

Licht …

Ubuntu kommt standardmäßig in der Version 16.04.1 zum Einsatz, kann aber mit apt-get unkompliziert auf die aktuelle Release 16.04.2 aktualisiert werden.

Bei der Installation der WSL muss ein Benutzer eingerichtet werden. Nach dem Start der bash sind Sie automatisch in diesem Account eingeloggt. Erst sudo mit Passwort-Angabe gibt root-Rechte.

Standardmäßig sind ca. 440 Pakete installiert. (Zum Vergleich: eine minimale Ubuntu-Server-Installation umfasst ca. 480 Pakete.)

ssh und ping funktionieren auf Anhieb, ip verrät die aktuelle Netzwerkkonfiguration, die einfach von Windows übernommen wird.

Die in den ersten WSL-Versionen beobachteten Darstellungs- und Tastaturprobleme im bash-Fenster sind behoben. Die wichtigsten von Linux bekannten Tastenkürzel funktionieren.

Es ist erlaubt, mehrere bash-Fenster gleichzeitig zu öffnen. Diese teilen sich den Prozessraum (d.h., es läuft nur eine Instanz des WSL).

Dustin Kirkland hat vor einem halben Jahr relativ umfassende Benchmark-Tests durchgeführt. Demnach läuft das WSL relativ flott. Ich habe das nicht überprüft, aber rein subjektiv verhält sich das WSL performant.

… und Schatten

WSL nutzt theoretisch Systemd als Init-System. Theoretisch deswegen, weil der Start von Hintergrundprozessen nur bedingt vorgesehen ist (alle Prozesse enden, sobald Sie das letzte bash-Fenster schließen), und weil systemctl nicht verwendbar ist (failed to connect to bus). Immerhin funktioniert das service-Kommando.

Es gibt kein Logging, kein Cron und keinen Hardware-Zugriff (die Verzeichnisse /proc, /sys und /dev sind sehr übersichtlich).

Netzwerkfunktionen stehen nur mit Einschränkungen zur Verfügung (Details siehe im MSDN-Blog).

Das WSL verwendet keinen Linux-Kernel. Insofern ist es klar, dass Kernel-nahe Kommandos wie iptables oder dmesg nicht funktionieren.

SSH-Server aktivieren

Im WSL ist standardmäßig ein SSH-Server installiert. Er läuft aber nicht, und seine Inbetriebnahme ist ein wenig umständlich. Als erstes müssen Sie die für die sichere Kommunikation erforderlichen Schlüssel manuell einrichten:

dpkg-reconfigure openssh-server

Dann müssen Sie in /etc/ssh/sshd_config eine Zeile ändern, um die Authentifizierung per Passwort zu erlauben:

# in /etc/ssh/sshd_config
... 
PasswordAuthentication yes

Zum Start des Servers verwenden Sie das service-Kommando:

service ssh start

Der SSH-Server läuft nun bis zum Schließen des letzten bash-Fensters und kann lokal getestet werden. Bevor Sie eine SSH-Verbindung von einem anderen Rechner durchführen können, müssen Sie allerdings in der Firewall noch Port 22 (TCP) freischalten. Der Port wird standardmäßig blockiert.

Ein noch ungewohntes Bild: Ein SSH-Login bei einem Windows-Rechner, hier durchgeführt von einem Fedora-Rechner im lokalen Netzwerk.

Ein automatischer Start des SSH-Servers beim Windows-Login ist mit etwas Konfigurationsaufwand möglich, ein automatischer Start schon beim Hochfahren aber offensichtlich nicht:

https://github.com/Microsoft/BashOnWindows/issues/612
https://wsl-forum.qztc.io/viewtopic.php?f=6&t=10

Vorsicht: Jeder SSH-Server ist ein Sicherheitsrisiko, aber im WSL gilt dies ganz besonders: Gewöhnliche Benutzer dürfen viele Dateien des Windows-Dateisystems (/mnt/c) lesen und teilweise auch verändern! Stellen Sie unbedingt sicher, dass alle im WSL eingerichteten Benutzer sichere Passwörter haben!

Konflikte mit dem Windows-eigenen SSH-Server: Windows 10 verfügt seit Build 14352 einen eigenen SSH-Server, der noch weitgehend unbekannt und in der Regel nicht aktiv ist. Wenn er aber läuft, dann kann der SSH-Server von WSL nicht gestartet werden, weil Port 22 blockiert ist. Dafür gibt es zwei Lösungen: Entweder verhindern Sie den Start des Windows-eigenen SSH-Server im Programm Dienste, oder Sie weisen dem WSL-SSH-Server in /etc/ssh/sshd_config mit Port nn einen anderen, freien Port zu (etwa 2222). Informationen zum Windows-eigenen SSH-Server finden Sie z.B. in diesem Blog-Beitrag.

LAMP-Server

Auch die Installation eine LAMP-Server verläuft problemlos. Beim Start treten zwei Warnungen auf, die Sie aber ignorieren können.

apt-get install tasksel
tasksel install lamp-server
service apache2 start}

  Starting Apache httpd web server 
  [core:warn] [pid 9124] (92)Protocol not available: AH00076: 
  Failed to enable APR_TCP_DEFER_ACCEPT

service mysql start

  Starting MySQL database server 
  mysqld: No directory, logging in with HOME=/

Wenn die Warnungen Sie stören, müssen Sie in die Apache-Konfigurationsdateien AcceptFilter http none eintragen und für den mysql-Account mit usermod -d /var/lib/mysql/ mysql das richtige Home-Verzeichnis einstellen (Quelle 1, Quelle 2).

Ansonsten gilt wie für den SSH-Server: Der Start von Apache und MySQL gelingt nur, wenn die Ports 80 bzw. 3306 frei sind und nicht durch einen anderen Web-Server (IIS) oder einen unter Windows installierten MySQL-Server blockiert sind. Die von Apache gelieferten Webseiten sind nur lokal zugänglich, es sei denn, Sie richten in der Windows-Firewall einen Ausnahmeregel für Port 80 ein. Ein automatischer Start des Web- und MySQL-Servers ist nicht vorgesehen.

Wenn Sie mit dem folgenden Kommando ein PHP-Script mit der Funktion phpinfo() einrichten, können Sie unter <localhost://testphp.php> alle Details der PHP-Konfiguration nachlesen:

echo "<?php phpinfo(); ?>" > /var/www/html/testphp.php
Testseiten eines LAMP-Systems, das im WSL läuft

Reset

Sollten Sie das Ubuntu-System innerhalb des WSL zerstört haben (z.B. durch rm -rf /etc), starten Sie cmd.exe und führen dort das folgende Kommando aus:

lxrun /uninstall /full}

Nach einer Rückfrage wird das Dateisystem für Ubuntu gelöst. Damit gehen natürlich auch alle von Ihnen durchgeführten Änderungen verloren. Anschließend starten Sie im Windows-Startmenü neuerlich bash und initiieren so eine Neuinstallation.

Wozu?

Technologisch hat mich das WSL bereits in der ersten Version fasziniert. Mittlerweile sind viele Anfangsprobleme ausgeräumt, das WSL läuft flüssig und im Rahmen seiner Möglichkeiten weitgehend problemlos.

Natürlich ist es ungemein praktisch, dass es nun mit der bash eine für Linux-Anwender vertraute Alternative zu cmd.exe bzw. zur PowerShell gibt. Der nahtlose Zugriff auf das Windows-Dateisystem, find und grep, die Möglichkeit, unkompliziert Python-Scripts auszuführen — alles toll!

Dennoch bin ich nicht überzeugt, dass diese Features für viele Entwickler ausreichen, um von virtuellen Maschinen mit einem »echtem«, uneingeschränkten Linux oder evt. auch von Docker-Containern Abschied zu nehmen.

Quellen und weitere Informationen

2 Gedanken zu „Update: Linux on Windows (WSL) für Windows 1703“

Kommentare sind geschlossen.