© Fotograf, 123RF

Wer auch auf der Windows-Plattform nicht auf die wichtigsten Vorteile von Linux verzichten möchte, dem bietet neuerdings das Windows-Subsystem für Linux eine weitere Arbeitsmöglichkeit. Der Artikel taucht in die Linux-Unterwelt hinab und erklärt, wie sich das Subsystem optimieren lässt.

Das neue Linux-Subsystem [1] gibt es seit dem Creators-Update von Windows 10, laut Microsoft kommt es ohne eine Ressourcen fressende VM und deren Konfiguration aus. Es soll zudem ein nativeres Linux-Feeling bieten als die bisherige Linux-Umgebung Cygwin [2]. Letztere bedient seit Jahren Linuxer auf Windows-Systemen, erfordert es aber, Linux-Programme für Windows neu zu kompilieren. Mit Linux lassen sich dann Prozesse mit Shellskripten automatisieren, etwa massenhafte Git-Checkouts.

Ein Blick in das Subsystem lohnt sich auch wegen des überraschend leichtgewichtigen, Prozess-basierten Virtualisierungskonzepts, das durchaus Schule machen könnte. Der vorliegende Artikel erklärt die Beschränkungen des Subsystems im Vergleich zu nativem Linux und zu Cygwin. Und er gibt eine Reihe von Anpassungstipps, die das Subsystem fit für den Alltagseinsatz machen.

Installation

Zumindest Nutzer von Windows 10 Professional holen das Linux-Subsystem im Handumdrehen rein. Denn es läuft gefühlt nativ auf Windows und kommt ohne eine zusätzliche virtuelle Maschine aus. Wer bei der Installation keinen Account bei Microsoft anlegen möchte, installiert Ubuntu 16.04 LTS direkt über die Windows-Powershell. Als Administrator bereitet der Befehl

Enable-WindowsOptionalFeature -O -F  Microsoft-Windows-Subsystem-Linux

Windows auf die Installation des Subsystems vor (Abbildung 1). Ein Klick auf »Einstellungen | Update und Sicherheit | Für Entwickler« aktiviert dann den »Entwicklermodus« (Abbildung 2). Die Installation erfolgt, indem der Admin »bash« in die Eingabe-Aufforderung tippt (Abbildung 1, unten). Die Bash-Shell aus Abbildung 3 startet wie alle Anwendungen unter Windows über das Startmenü und den Aufruf von »Bash.exe«.

Abbildung 1: Leicht zu verwechseln: Oben ist die Powershell, unten die Eingabe-Aufforderung zu sehen.

Dahoam is dahoam

Nach Doppelklick auf »Bash.exe« findet sich der Nutzer in einer Linux-Shell mit Ubuntu-Umgebung wieder. Selbst der Apt-Paketmanager ist einsatzbereit. Die Dateien des Subsystems speichert Windows unter »C:\Users\pa\AppData\Local\lxss«. Umgekehrt mountet Ubuntu Windows unter »/mnt/c«.

Abbildung 2: Windows-User müssen den Entwicklermodus aktivieren.

Um Tipparbeit zu sparen und redundante Datenstrukturen zu vermeiden, führt der Benutzer am besten zuerst die Homeverzeichnisse aus der Linux- und Windows-Welt zusammen. Dazu ändert er den Pfad auf sein Linux-Homeverzeichnis in der Datei »/etc/passwd« so, dass dieser auf sein Windows-Home »/mnt/c/Users/pa« verweist. Dabei hilft ihm auch unter Windows der Editor Vi, den er über »sudo vi /etc/passwd« aufruft. Nach einem Neustart der »Bash.exe« landet der Benutzer direkt im Windows-Homeverzeichnis.

Abbildung 3: Die Linux-Shell unter Windows fühlt sich zumindest nativ an.

Startup-Probleme

Der Einsatz des benutzerbezogenen Pfades »C:\Users\pa\AppData\Local\lxss« lässt die Unterschiede zu einem nativen Linux-System bereits erahnen: Die Dienste, die Ubuntu üblicherweise im Verzeichnis »/etc/init.d« verlinkt, starten nicht – wie sonst üblich – automatisch schon beim Bootvorgang. Außerdem terminieren sie mit der Shell. Zwar lässt sich der Apache-Webserver wie gewohnt konfigurieren, der Admin muss ihn jedoch jedes Mal per Hand ankurbeln. Nach dem Schließen von »Bash.exe« lässt er sich darüber hinaus überhaupt nicht mehr erreichen.

Ein Befehl zum Registrieren eines Linux-Dienstes unter Windows, beispielsweise »cygrunsrv« unter Cygwin, existiert für das neue Subsystem noch nicht. Mit dieser Einschränkung kann ein Linux-Nutzer aber noch gut leben, da er beim Arbeiten ohnehin gewohnheitsmäßig immer zuerst eine Shell öffnet.

Rechteverdreher

Es warten aber noch weitere Merkwürdigkeiten auf den Nutzer. Alle Dateien unter »/mnt/c« gehören »root«. Änderungen der Benutzerrechte mit »chmod« und »chown« bleiben wirkungslos. Dieser Malus stört die Benutzbarkeit jedoch nicht gravierend. Schließlich kann der Benutzer in seinem Subsystem uneingeschränkt Dateien und Verzeichnisse anlegen und löschen.

Will er allerdings beim Datentransfer auch die Benutzerrechte von Dateien übertragen, muss er diese beim oder nach dem Übertragen setzen. Dazu bietet Rsync eine Lösung an. In dem Beispielaufruf

rsync --perms --chmod=+wrx,go-w index.html server:/var/www

sorgt der Parameter »perms« dafür, dass das Synchronisierungstool auch die Verzeichnisrechte überträgt. Anschließend setzt »chmod« im ersten Schritt mittels »+wrx« alle Rechte für den Benutzer, die besitzende Gruppe und alle anderen.

Im zweiten Schritt entzieht der Ausdruck »go-w« der Gruppe und allen anderen das Schreibrecht wieder. Im Endeffekt erhält die übertragene Datei »index.html« auf diesem Weg die Berechtigungen »rwxr-xr-x«. Rsync unterscheidet übrigens anhand von Filtern Verzeichnisse (»D«) und Dateien (»F«). Der zusätzliche Ausdruck »F-x« als drittes Element der kommaseparierten Liste würde allen Dateien die Ausführbarkeit entziehen.

Wer lieber eigene SSH-Schlüssel verwenden möchte, greift zum Skript aus Listing 1. Es sichert SSH-Schlüssel und »config«-Dateien aus dem Homeverzeichnis im Ordner »/etc/ssh«. Verzichtet der Admin auf das Skript, wirft der Aufruf des Befehls »ssh myserver« die Fehlermeldung »Bad owner or permissions on /mnt/c/Users/pa/.ssh/config« aus.

01 #!/bin/bash
02 cd ~
03 if [ -d .ssh ]; then
04   tar cf ssh.tar .ssh
05   for keyfile in `grep -le 'BEGIN .* PRIVATE KEY' -e '^ssh-' .ssh/*`; do
06     filename=`filename $keyfile`
07     mv $keyfile /etc/ssh
08     chmod 644 /etc/ssh/$filename
09   done
10   if [ -f .ssh/config ]; then
11     cat .ssh/config >> /etc/ssh/ssh_config
12     sed -i 's|~/.ssh|/etc/ssh|g' /etc/ssh/ssh_config
13     rm -f .ssh/config
14   fi
15 fi

Am Ende sichert der Admin Listing 1 als Datei »ssh-extend.sh« und ruft sie – ebenfalls in der Shell – mit dem Befehl »sudo bash ssh-extend.sh« auf. In Zeile 2 wechselt das Skript zunächst ins Home des Benutzers. Existiert der Inhalt des Ordners »~/.ssh«, sichert Zeile 4 ihn mit Hilfe des Archivkommandos Tar. Die For-Schleife iteriert dazu über alle Dateien, die der »grep«-Ausdruck als Schlüsseldateien identifiziert.

Die Zeichenketten nach dem Kommandozeilenschalter »-e« arbeiten jeweils als reguläre Suchmuster. Zeile 7 verschiebt pro Schleifendurchlauf eine Schlüsseldatei nach »/etc/ssh«, Zeile 8 setzt passende Zugriffsrechte.

Vorausgesetzt sie ist vorhanden, überträgt das Skript die Einstellungen der Konfigurationsdatei »~/.ssh/config« in die globale Konfigurationsdatei für SSH. In Zeile 11 hängt das Skript die gefundenen Einträge mit Hilfe des »>>«-Operators ans Ende der Datei »/etc/ssh/ssh_config«. Der »sed«-Befehl ersetzt dann mit Hilfe von Suchen und Ersetzen das Pfadpräfix »~/.ssh« durch »/etc/ssh«. Weil das Linux-Subsystem im Verzeichnis des Windows-Benutzers hängt, droht beim Übertragen der Schlüsseldateien im Subsystem kein Geheimnisverrat. SSH lässt sich anschließend wie gewohnt in der Shell verwenden.

Kernspaltung

Weit größer sollten die Beschränkungen des Subsystems für Programme sein, die auf Kernelfeatures zugreifen, denn das Linux-Subsystem muss ohne Linux-Kernel auskommen. Der Clou: Linux-Prozesse laufen in einem neuen Prozesstyp namens Pico [3] im Userspace von Windows (Abbildung 4). Windows übersetzt die Kernel-Aufrufe aus dem Pico-Prozess über die Pico-Provider LXSS und LXCore in Aufrufe an den Windows-Kernel und reicht sie transparent weiter.

Abbildung 4: Pico-Prozesse gehen einen anderen Weg für Kernelaufrufe als native Windows-Prozesse.

Wie gut das funktioniert, lässt sich an der Containerlösung Docker überprüfen. Das Creators-Update ermöglicht es ähnlich wie Cygwin, ».exe«-Dateien über die Shell aufzurufen. Installiert der Admin Docker unter Windows und fügt anschließend der ».bashrc« im Homeverzeichnis den Bash-Code aus Listing 2 hinzu, lassen sich die Docker-Befehle nach dem Neustart der Shell wie unter Linux verwenden. Die For-Schleife befreit dabei alle ».exe«-Dateien von ihren Datei-Endungen und schließt sie über einen Alias an die Linux-Welt an.

01 DOCKER_BIN='/mnt/c/Program Files/Docker/Docker/resources/bin'
02 for f in "$DOCKER_BIN"/*; do
03   alias "$(basename "$f" | sed 's/.exe$//')" '="'"$f"'"'
04 done

Lediglich der interaktive Terminalmodus (Option »-t« wie in dem Befehl »docker run -it debian bash«) scheitert, da die Bash das Terminalprotokoll von Windows nicht interpretieren kann. Auch das Anlegen eines geeigneten Pseudoterminals über »sudo /sbin/MAKEDV -v pty« misslang im Test. Unter Cygwin verhilft der Befehl »winpty« zum gewünschten Ergebnis [4].

Schade: Pfade

Windows und Linux nutzen unterschiedliche Pfad-Schemata, um Ressourcen innerhalb ihres Verzeichnisbaums zu adressieren. Mit Subversion checkt der Benutzer zum Beispiel eine Arbeitskopie des Repository-Dokuments über den Windows-Pfad »file:///C/Users/pa/svn/documents« aus.

Der anschließende Versuch, die Arbeitskopie über die Bash mit dem Befehl »svn update« zu aktualisieren, scheitert aber, denn Linux kommt nicht mit dem Quellpfad zurecht.

Diese Klasse von Problemen behebt bisweilen ein Ausweichen in die Netzwelt, denn Linux und Windows werten URLs auf die gleiche Weise aus. Unter Subversion registriert der mit Administratorrechten eingegebene Befehl

sc create svnserve binpath= "\"C:\Program Files\TortoiseSVN\bin\svnserve.exe\" --service -r C:\User\pa\svn" displayname= "Subversion Server" depend= Tcpip start= auto

den internen Server »svnserve« zunächst als Windows-Dienst. Das Kommando »sc start svnserve« startet den Dienst. Eine Arbeitskopie checkt der Admin dann per URL über »svn checkout svn://localhost/documents« aus. Diesmal arbeitet Subversion in beiden Welten.

Ein Hinweis sollte hier allerdings nicht fehlen: Um Daten schreiben zu können, muss er der Datei »conf/svnserve.conf« im Wurzelverzeichnis des Repository »C:\User\pa\svn« die Zeile »anon-access = write« hinzufügen.

Domain Sockets

Das Implementieren von Domain Sockets scheint laut einem Blogeintrag [5] bisher nur partiell zu klappen. Der Versuch, mit »sudo nc -U /var/tmp/sockted« einen solchen Socket anzulegen, scheitert (»nc: unix connect failed: No such file or directory«).

Wie beim Pfadproblem ist auch hier die Lösung, dass der Admin die Interprozess-Kommunikation wie im Falle des Dbus-Systems über TCP/IP abwickeln lässt. Wer den Aufwand nicht scheut, findet zu diesem Thema einen weiteren Blogeintrag unter [6]. Zusammengefasst installiert der Admin einen X-Server wie »vcxrc« oder Xming, ergänzt den Eintrag »export DISPLAY=:0.0« in der ».bashrc« und veranlasst Dbus mit dem Befehl

sudo sed -i 's$.*$tcp:host=localhost,port=0$' /etc/dbus-1/session.conf

dazu, die Kommunikation über TCP/IP abzuwickeln. Dann starten Firefox und angeblich auch der Ubuntu-Desktop.

Fazit

Das Windows-Subsystem für Linux zeigt einen leichtgewichtigen, Container-basierten Virtualisierungsansatz, der über eine eigene Prozessklasse funktioniert. In der Praxis bleibt Nachbesserungsbedarf, will der User wie gewohnt mit Linux arbeiten oder zumindest den Cygwin-Reifegrad erreichen. Ein Paar Handgriffe helfen aber, ein arbeitstaugliches System herzustellen und es mit dem Windows-Überbau zu harmonisieren. Bleibt zu hoffen, das der Hersteller auch bereit ist, sein Subsystem zu vollenden.