Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docker-for-win: --vcxsrv: X cookie authentication fails #160

Closed
mviereck opened this issue May 21, 2019 · 20 comments
Closed

docker-for-win: --vcxsrv: X cookie authentication fails #160

mviereck opened this issue May 21, 2019 · 20 comments

Comments

@mviereck
Copy link
Owner

mviereck commented May 21, 2019

Coming from #145 (comment)

@1138-4eb wrote:

When I don't use it (x11docker --verbose x11docker/check), the following error is shown:

LoadPreferences: C:\msys64\home\eine\.XWinrc not found
LoadPreferences: Loading C:\Program Files\VcXsrv\system.XWinrc
Warning: Locale not supported by X, falling back to 'C' locale.
(II) IGLX: Loaded and initialized swrast
(II) GLX: Initialized DRISWRAST GL provider for screen 0
/c/Users/eine/x11docker/cache/x11docker-check-c01f93/xinitrc: line 107: xsetroot: command not found
-rw-r--r-- 1 eine None 0 May 17 04:47 /c/Users/eine/x11docker/cache/x11docker-check-c01f93/share/Xclientcookie
Failed to retrieve trusted cookie from X server. Will bake one myself.
Ignoring locks on authority file Xclientcookie
Ignoring locks and writing authority file Xclientcookie
-rw-r--r-- 1 eine None 230 May 17 04:47 /c/Users/eine/x11docker/cache/x11docker-check-c01f93/share/Xclientcookie
C:\Program Files\VcXsrv\xauth.exe: (argv):1:  unable to read any entries from file "(stdin)"
Ignoring locks on authority file Xclientcookie

==> /c/Users/eine/x11docker/cache/x11docker-check-c01f93/message.log <==
x11docker[258.42]: Waiting since 1s for --vcxsrv to be ready.

I think that unable to read any entries from file "(stdin)" might be familiar to you.

@mviereck mviereck added the bug label May 21, 2019
@mviereck mviereck changed the title --vcxsrv: Cookie authentication failes docker-for-win: --vcxsrv: Cookie authentication failes May 21, 2019
@mviereck
Copy link
Owner Author

This is the code of interest:

        echo     "[ -s '$Xclientcookie' ] || { "
        echo     "  # still no cookie? try to create one without extension security"
        echo     "  verbose -d 'Failed to retrieve trusted cookie from X server. Will bake one myself.'"
        echo     "  echo 'Failed to retrieve trusted cookie from X server. Will bake one myself.'"
        echo     "  $Xauthexe -v -i -f Xclientcookie add :$Newdisplaynumber . $(makecookie) | rmcr"
        echo     "  ls -l $Xclientcookie"
        echo     "}"
        echo     "# create prepared cookie with localhost identification disabled by ffff, needed if X socket is shared. ffff means 'familiy wild'"
        echo     "Cookie=\$($Xauthexe -i -f Xclientcookie nlist | rmcr | sed -e 's/^/ffff/')"
        echo     "echo \"\$Cookie\" | $Xauthexe -v -i -f Xclientcookie nmerge - | rmcr"rmcr)\""

This is the line that probably fails: https://github.com/mviereck/x11docker/blob/master/x11docker#L3109

        echo     "echo \"\$Cookie\" | $Xauthexe -v -i -f Xclientcookie nmerge - | rmcr"

Can you please try:

rmcr() {                        # remove carriage return to translate DOS/Windows newlines into UNIX newlines
  # convert stdin if $1 is empty. Otherwise convert file $1.
  case "${1:-}" in
    "") sed    "s/$(printf "\r")//g" ;;
    *)  sed -i "s/$(printf "\r")//g"  "${1:-}"
  esac
}
export PATH="$PATH:/c/Program Files/VcXsrv/"
Newdisplaynumber=123
xauth.exe -v -i -f Xclientcookie add :200 . $(mcookie) | rmcr
Cookie="$(xauth.exe -i -f Xclientcookie nlist | rmcr | sed -e 's/^..../ffff/')"
echo "$Cookie" | xauth.exe -v -i -f Xclientcookie nmerge -  ### failing line?
xauth.exe -f Xclientcookie nlist

The last output line must start with ffff like in

ffff 0006 627573746572 0003 323030 0012 4d49542d4d414749432d434f4f4b49452d31 0010 621413826a2f0b9cf4026cb0e8af2e17

@mviereck mviereck changed the title docker-for-win: --vcxsrv: Cookie authentication failes docker-for-win: --vcxsrv: Cookie authentication fails May 21, 2019
@mviereck mviereck changed the title docker-for-win: --vcxsrv: Cookie authentication fails docker-for-win: --vcxsrv: X cookie authentication fails May 21, 2019
@eine
Copy link
Contributor

eine commented May 22, 2019

I am not sure about what to try. I copied the code block to a test.sh file and I tried to execute it:

# ./test.sh
C:\Program Files\VcXsrv\xauth.exe:  file Xclientcookie does not exist
Ignoring locks on authority file Xclientcookie
Ignoring locks and writing authority file Xclientcookie
C:\Program Files\VcXsrv\xauth.exe: (argv):1:  unable to read any entries from file "(stdin)"
Ignoring locks on authority file Xclientcookie

Then, I tried touch Xclientcookie and executed test.sh again:

# ./test.sh
Ignoring locks on authority file Xclientcookie
Ignoring locks and writing authority file Xclientcookie
C:\Program Files\VcXsrv\xauth.exe: (argv):1:  unable to read any entries from file "(stdin)"
Ignoring locks on authority file Xclientcookie

# cat Xclientcookie
▒▒▒`▒ᗜ
200MIT-MAGIC-COOKIE-1ﶵ}▒*+▒▒▒l▒P▒d▒▒▒▒d▒[▒▒|▒200MIT-MAGIC-COOKIE-1ﶵ}▒*+▒▒▒l▒P▒d▒
K200MIT-MAGIC-COOKIE-1ﶵ}▒*+▒▒▒l▒P▒d▒▒▒▒200MIT-MAGIC-COOKIE-1ﶵ}▒*+▒▒▒l▒P▒d▒

EDIT

In the following snippet, nlist produces no output:

rmcr() {                        # remove carriage return to translate DOS/Windows newlines into UNIX newlines
  # convert stdin if $1 is empty. Otherwise convert file $1.
  case "${1:-}" in
    "") sed    "s/$(printf "\r")//g" ;;
    *)  sed -i "s/$(printf "\r")//g"  "${1:-}"
  esac
}
export PATH="$PATH:/c/Program Files/VcXsrv/"
Newdisplaynumber=123

xauth.exe -v -i -f Xclientcookie add :200 . $(mcookie) | rmcr
xauth.exe -i -f Xclientcookie nlist
# ./test.sh
Ignoring locks on authority file Xclientcookie
Ignoring locks and writing authority file Xclientcookie

@mviereck
Copy link
Owner Author

mviereck commented May 22, 2019

I am not sure about what to try.

And I am a bit confused from your results. :-)
A new attempt: Please execute this script in MSYS2:

#! /bin/bash
rmcr() {
  case "${1:-}" in
    "") sed    "s/$(printf "\r")//g" ;;
    *)  sed -i "s/$(printf "\r")//g"  "${1:-}"
  esac
}
set -x
rm Xclientcookie
export PATH="$PATH:/c/Program Files/VcXsrv/"
xauth.exe -v -i -f Xclientcookie add :200 . $(mcookie) | rmcr
Cookie="$(xauth.exe -i -f Xclientcookie nlist | rmcr | sed -e 's/^..../ffff/g')"
echo "$Cookie" | xauth.exe -v -i -f Xclientcookie nmerge -
xauth.exe -f Xclientcookie nlist

I get the following output and a valid cookie in MSYS2:

+ rm Xclientcookie
+ export 'PATH=/usr/local/bin:/usr/bin:/bin:/opt/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/c/Program Files/VcXsrv/:/c/Program Files/VcXsrv/'
+ PATH='/usr/local/bin:/usr/bin:/bin:/opt/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/c/Program Files/VcXsrv/:/c/Program Files/VcXsrv/'
+ rmcr
++ mcookie
+ case "${1:-}" in
++ printf '\r'
+ xauth.exe -v -i -f Xclientcookie add :200 . b560b0d7a8efdfedbd7a67e3aea9e2ce
+ sed $'s/\r//g'
C:\Program Files\VcXsrv\xauth.exe:  file Xclientcookie does not exist
Ignoring locks on authority file Xclientcookie
Ignoring locks and writing authority file Xclientcookie
++ xauth.exe -i -f Xclientcookie nlist
++ rmcr
++ case "${1:-}" in
++ sed -e 's/^..../ffff/g'
+++ printf '\r'
++ sed $'s/\r//g'
+ Cookie='ffff 0010 fe80000000000000e5729ef17ad1c078 0003 323030 0012 4d49542d4d414749432d434f4f4b49452d31 0010 b560b0d7a8efdfedbd7a67e3aea9e2ce
ffff 0010 fe80000000000000255916b63d0fc3e2 0003 323030 0012 4d49542d4d414749432d434f4f4b49452d31 0010 b560b0d7a8efdfedbd7a67e3aea9e2ce
ffff 0010 fe80000000000000c06f04b17b91986e 0003 323030 0012 4d49542d4d414749432d434f4f4b49452d31 0010 b560b0d7a8efdfedbd7a67e3aea9e2ce
ffff 0010 fe80000000000000ec345300f99215ef 0003 323030 0012 4d49542d4d414749432d434f4f4b49452d31 0010 b560b0d7a8efdfedbd7a67e3aea9e2ce
ffff 0004 c0a83801 0003 323030 0012 4d49542d4d414749432d434f4f4b49452d31 0010 b560b0d7a8efdfedbd7a67e3aea9e2ce'
+ echo 'ffff 0010 fe80000000000000e5729ef17ad1c078 0003 323030 0012 4d49542d4d414749432d434f4f4b49452d31 0010 b560b0d7a8efdfedbd7a67e3aea9e2ce
ffff 0010 fe80000000000000255916b63d0fc3e2 0003 323030 0012 4d49542d4d414749432d434f4f4b49452d31 0010 b560b0d7a8efdfedbd7a67e3aea9e2ce
ffff 0010 fe80000000000000c06f04b17b91986e 0003 323030 0012 4d49542d4d414749432d434f4f4b49452d31 0010 b560b0d7a8efdfedbd7a67e3aea9e2ce
ffff 0010 fe80000000000000ec345300f99215ef 0003 323030 0012 4d49542d4d414749432d434f4f4b49452d31 0010 b560b0d7a8efdfedbd7a67e3aea9e2ce
ffff 0004 c0a83801 0003 323030 0012 4d49542d4d414749432d434f4f4b49452d31 0010 b560b0d7a8efdfedbd7a67e3aea9e2ce'
+ xauth.exe -v -i -f Xclientcookie nmerge -
Ignoring locks on authority file Xclientcookie
5 entries read in:  0 new, 5 replacements
Ignoring locks and writing authority file Xclientcookie
+ xauth.exe -f Xclientcookie nlist
ffff 0004 c0a83801 0003 323030 0012 4d49542d4d414749432d434f4f4b49452d31 0010 b560b0d7a8efdfedbd7a67e3aea9e2ce
0006 0010 fe80000000000000255916b63d0fc3e2 0003 323030 0012 4d49542d4d414749432d434f4f4b49452d31 0010 b560b0d7a8efdfedbd7a67e3aea9e2ce
0006 0010 fe80000000000000c06f04b17b91986e 0003 323030 0012 4d49542d4d414749432d434f4f4b49452d31 0010 b560b0d7a8efdfedbd7a67e3aea9e2ce
0006 0010 fe80000000000000ec345300f99215ef 0003 323030 0012 4d49542d4d414749432d434f4f4b49452d31 0010 b560b0d7a8efdfedbd7a67e3aea9e2ce
0000 0004 c0a83801 0003 323030 0012 4d49542d4d414749432d434f4f4b49452d31 0010 b560b0d7a8efdfedbd7a67e3aea9e2ce

Edit: Looking at my output, I see that only one cookie in nlist starts with ffff. It seems the script has to iterate over the lines.

@eine
Copy link
Contributor

eine commented May 22, 2019

I get an empty output: Cookie is empty, because xauth.exe -i -f Xclientcookie nlist produces no output:

# ./test.sh
+ rm Xclientcookie
+ export 'PATH=/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/c/Program Files/Docker/Docker/resources/bin:/c/Program Files/VcXsrv/'
+ PATH='/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/c/Program Files/Docker/Docker/resources/bin:/c/Program Files/VcXsrv/'
+ rmcr
+ case "${1:-}" in
++ mcookie
++ printf '\r'
+ xauth.exe -v -i -f Xclientcookie add :200 . 5c8c22d5aa7be4e3ad10f72c6459db64
+ sed $'s/\r//g'
C:\Program Files\VcXsrv\xauth.exe:  file Xclientcookie does not exist
Ignoring locks on authority file Xclientcookie
Ignoring locks and writing authority file Xclientcookie
++ xauth.exe -i -f Xclientcookie nlist
++ rmcr
++ case "${1:-}" in
++ sed -e 's/^..../ffff/g'
+++ printf '\r'
++ sed $'s/\r//g'
+ Cookie=
+ echo ''
+ xauth.exe -v -i -f Xclientcookie nmerge -
C:\Program Files\VcXsrv\xauth.exe: (argv):1:  unable to read any entries from file "(stdin)"
Ignoring locks on authority file Xclientcookie
+ xauth.exe -f Xclientcookie nlist

This is the hexdump of Xclientcookie, in case it helps:

# hexdump Xclientcookie
0000000 0600 1000 80fe 0000 0000 0000 60fc b213
0000010 97e1 0d9c 000a 3203 3030 1200 494d 2d54
0000020 414d 4947 2d43 4f43 4b4f 4549 312d 1000
0000030 8c5c d522 7baa e3e4 10ad 2cf7 5964 64db
0000040 0600 1000 80fe 0000 0000 0000 64a4 5bf0
0000050 9ca6 ff7c 0300 3032 0030 4d12 5449 4d2d
0000060 4741 4349 432d 4f4f 494b 2d45 0031 5c10
0000070 228c aad5 e47b ade3 f710 642c db59 0064
0000080 0000 0d04 000a 014b 0300 3032 0030 4d12
0000090 5449 4d2d 4741 4349 432d 4f4f 494b 2d45
00000a0 0031 5c10 228c aad5 e47b ade3 f710 642c
00000b0 db59 0064 0000 c004 01a8 0080 3203 3030
00000c0 1200 494d 2d54 414d 4947 2d43 4f43 4b4f
00000d0 4549 312d 1000 8c5c d522 7baa e3e4 10ad
00000e0 2cf7 5964 64db
00000e6

@mviereck
Copy link
Owner Author

I get an empty output: Cookie is empty, because xauth.exe -i -f Xclientcookie nlist produces no output

I am completly out of ideas. It just works here.
Do you have any idea how to debug this command?

@eine
Copy link
Contributor

eine commented May 22, 2019

I get an empty output: Cookie is empty, because xauth.exe -i -f Xclientcookie nlist produces no output

I am completly out of ideas. It just works here.
Do you have any idea how to debug this command?

I just started a Debian container and installed xauth there. nlist does not print anything. Therefore, I think that the problem is that the cookie is not valid.

I then tried creating the cookie inside the container (xauth.exe -v -i -f Xclientcookie add :200 . $(mcookie)). With this one, nlist works both inside and outside of the container.

So, an ugly, but possible workaround is to use xauth inside the container to create the cookie.

EDIT

Note the difference of size between a cookie created inside the container and the one created outside:

# hexdump.exe Xclientcookie
0000000 0001 0c00 3666 6536 6466 6536 3237 3232
0000010 0300 3032 0030 4d12 5449 4d2d 4741 4349
0000020 432d 4f4f 494b 2d45 0031 8310 c98f c677
0000030 824f 236b 2bb0 114f 93f2 0044
000003b

@mviereck
Copy link
Owner Author

mviereck commented May 24, 2019

So, an ugly, but possible workaround is to use xauth inside the container to create the cookie.

That is not a way to go. I'd rather drop --vcxsrv.
A possible workaround could be to depend on Cygwin/X and using its xauth.exe.

Note the difference of size between a cookie created inside the container and the one created outside:

Normally xauth should create only one cookie. Your hexdump shows a single cookie.
The cookie file created by your VcXsrv-xauth.exe contains more than one cookie and is somehow broken.
It contains multiple cookies here, too, but it works.

@mviereck
Copy link
Owner Author

--vcxsrv now depends on xauth.exe in Cygwin/X. Please try out.

I'll try to support --xwin for MSYS2 and WSL, too, and drop --vcxsrv at all.

@eine
Copy link
Contributor

eine commented May 24, 2019

So, an ugly, but possible workaround is to use xauth inside the container to create the cookie.

That is not a way to go. I'd rather drop --vcxsrv.
A possible workaround could be to depend on Cygwin/X and using its xauth.exe.

From a user perspective, I think that it is equivalent (or even better) to use a container as a workaround, instead of requiring Cygwin/X. All the users of x11docker have docker installed. Many users do have MSYS2 or Git Bash. With WSL2, even more users will be able to GNU/Linux apps in the Terminal. So, the advantage of VcXsrv is that the user requires a single additional dependency; a very specific tool: an X server.

Conversely, by requiring Cygwin/X, users are forced to installing a full new term (Cygwin), which duplicates the functionality already available through MSYS or WSL. Moreover, Cygwin does not have any package manager, so it requires multiple packages to be looked for and selected manually. Unless it is possible to provide a kind of config file to Cygwin in order to automate the installation on multiple dependencies, I think that users which are looking for the most painless solution will prefer VcXsrv with --no-auth. This is my use case, since I don't need neither audio nor GPU support and many of the sources I work with are open source.

Nonetheless, I think that the underlying issue might be that xauth in VcXsrv is broken/buggy. It seems that it is a not very used feature, considering that paths where supported quite naively until you asked about it last summer: https://sourceforge.net/p/vcxsrv/bugs/79/.

Therefore, I believe that the way to go is to just add a warning, letting users know that authorization might not work with VcXsrv. Overall, we should suggest Cygwin/X, because of this and because of GPU support. But I would not drop VcXsrv. The code is already written, the 'knowledge' is part of the script, I use it every day, and it works ok until some external update broke it.

Note the difference of size between a cookie created inside the container and the one created outside:

Normally xauth should create only one cookie. Your hexdump shows a single cookie.
The cookie file created by your VcXsrv-xauth.exe contains more than one cookie and is somehow broken.
It contains multiple cookies here, too, but it works.

Might it be that xauth depends on some other 'sytem tools', which might be different? I have not changed VcXsrv in the last 6 months or so, and it has been working seamlessly until some weeks ago. Apart from Win10 being updated, I recently executed pacman -Syu in MSYS2. If you didn't do that, this might be the difference. I'm currently using msys2-runtime-3.0.7-2.

EDIT

--vcxsrv now depends on xauth.exe in Cygwin/X. Please try out.

It works.

@mviereck
Copy link
Owner Author

So, the advantage of VcXsrv is that the user requires a single additional dependency; a very specific tool: an X server.
Conversely, by requiring Cygwin/X, users are forced to installing a full new term (Cygwin), which duplicates the functionality already available through MSYS or WSL.

You are right. That was the reason why I preferred --vcxsrv at the first time and added --xwin only in Cygwin itself because it was easy to implement.

Now I have two bugs with VcXsrv: broken --gpu support and broken cookie authentication.
Both VcXsrv and Xwin are accessed over TCP. Without an authentication this opens a severe security leak.

I think that users which are looking for the most painless solution will prefer VcXsrv with --no-auth.

I am aware that many users won't care and will just use --no-auth. But I won't support this without a working authenticated default. One demand of x11docker is to provide a secure setup by default. If that is not possible, I'll drop it.

From a user perspective, I think that it is equivalent (or even better) to use a container as a workaround,

From the developer's perspective:
That adds some more complexity and one more workaround.
I'd rather like to simplify the Windows code part than to expand it.
Issues on Windows are hard to debug, and I'll rather look for a stable working base than to support multiple unstable options that cost a lot of time in maintenance.

I see two ways to simplify the Windows code:
Either: Using Cygwin/X as a stable base. Advantage: Stable Xwin + X tools, can be used in MSYS and WSL, too.
Or: Using WSL as a modern (hopefully stable) base without supporting MSYS or Cygwin, requiring some X tools in WSL as a dependency, and using VcXsrv (with limited --gpu support, and without --pulseaudio).

WSL is trendy and hip. From a popularity point of view, this would be the best choice.
WSL2 claims to support docker natively. That is an important point, too.
I am thinking about this. Probably the best way is to wait for WSL2 and to support only that one in future.

@eine
Copy link
Contributor

eine commented May 24, 2019

I am aware that many users won't care and will just use --no-auth. But I won't support this without a working authenticated default. One demand of x11docker is to provide a secure setup by default. If that is not possible, I'll drop it.

Although I do not agree, I understand your point of view.

From a user perspective, I think that it is equivalent (or even better) to use a container as a workaround,

From the developer's perspective:
That adds some more complexity and one more workaround.
I'd rather like to simplify the Windows code part than to expand it.
Issues on Windows are hard to debug, and I'll rather look for a stable working base than to support multiple unstable options that cost a lot of time in maintenance.

I don't know if I am missing anything, but generating a cookie in a container would require jsut aliasing a command. I do not feel it to be 'complex'. But I agree that it adds some additional small bit, and you prefer to go the other way.

I see two ways to simplify the Windows code:
Either: Using Cygwin/X as a stable base. Advantage: Stable Xwin + X tools, can be used in MSYS and WSL, too.
Or: Using WSL as a modern (hopefully stable) base without supporting MSYS or Cygwin, requiring some X tools in WSL as a dependency, and using VcXsrv (with limited --gpu support, and without --pulseaudio).

This sounds slightly contradictory to me. You have stated before that you'd rather drop VcXsrv support instead of providing an unsecure default. However, you are suggesting to use VcXsrv here. Does this mean that xauth works in WSL without requiring Cygwin/X?

WSL is trendy and hip. From a popularity point of view, this would be the best choice.

Although I am not a big fan of WSL, I agree. It seems that WSL2 will provide most of the features of MSYS2.

WSL2 claims to support docker natively. That is an important point, too.

I am not sure about this. I have seen that it will be possible to run the docker daemon in a WSL2 machine/container, which is somehow equivalent to Docker in Docker (dind). I don't know for sure whether it'll be possible to run the daemon on the underlying VM (the one running the linux kernel, where all the containers are executed). If this later approach is possible, docker-for-win itself might not make much sense. Otherwise, I do not think that it will make any difference.

I am thinking about this. Probably the best way is to wait for WSL2 and to support only that one in future.

I believe that, at some point, Microsoft will provide a built-in X server, just as they are providing a VM with a Linux kernel and rewriting part of MSYS. At that point, neither VcXsrv nor Cygwin/X will be required. However, I found no reference about this yet.

@mviereck
Copy link
Owner Author

This sounds slightly contradictory to me. You have stated before that you'd rather drop VcXsrv support instead of providing an unsecure default. However, you are suggesting to use VcXsrv here. Does this mean that xauth works in WSL without requiring Cygwin/X?

Yes. Tools like xauth or xwininfo can be installed in WSL with e.g. apt-get install xauth. x11docker could declare this as a dependency like on a regular Linux system and can use them directly without cmd.exe workarounds or path conversions and carriage return issues. It also provides a better mkfifo support than Cygwin and MSYS, an issue we had in the early x11docker-on-Windows days and is currently fixed with an ugly and time+CPU consuming workaround.

Things would also become easier if x11docker supports Cygwin/X only, but I assume WSL(2) will supersede it in future.

I don't know for sure whether it'll be possible to run the daemon on the underlying VM (the one running the linux kernel, where all the containers are executed). If this later approach is possible, docker-for-win itself might not make much sense.

AFAIK docker will run directly on the WSL2-Linux-Kernel. It is not possible in WSL1 due to missing kernel features (cgroups). There will be no need for the current Docker-VM setup. That might also fix odd bugs like #104.

I believe that, at some point, Microsoft will provide a built-in X server, just as they are providing a VM with a Linux kernel and rewriting part of MSYS. At that point, neither VcXsrv nor Cygwin/X will be required. However, I found no reference about this yet.

There has been some requests in the WSL Github tracker, e.g. microsoft/WSL#2356.
It seems to be out of scope currently, but who knows. Either way, if with VcXsrv or a built-in X, x11docker will be able to provide it to container applications.

@eine
Copy link
Contributor

eine commented May 24, 2019

I don't know for sure whether it'll be possible to run the daemon on the underlying VM (the one running the linux kernel, where all the containers are executed). If this later approach is possible, docker-for-win itself might not make much sense.

AFAIK docker will run directly on the WSL2-Linux-Kernel. It is not possible in WSL1 due to missing kernel features (cgroups). There will be no need for the current Docker-VM setup. That might also fix odd bugs like #104.

I hope you are correct, but that is not what I understood while watching: https://www.youtube.com/watch?v=lwhMThePdIo. Please see the diagram at min 41:20 and the demo at min 13:00. The docker daemon in the demo is started in 'Ubuntu' which is a container, not the VM.

So, there will be no need for the current Docker-VM setup. But the alternative will not be technically equivalent at all.

There has been some requests in the WSL Github tracker, e.g. microsoft/WSL#2356.

Thanks for the reference.

@mviereck
Copy link
Owner Author

I've looked into the video, but found it a bit confusing.
I better understand this text: https://devblogs.microsoft.com/commandline/announcing-wsl-2/
It also shows the demo of min 13:00.

Other than WSL1, WSL2 runs a real Linux kernel. This kernel runs in a VM.

The docker daemon in the demo is started in 'Ubuntu' which is a container, not the VM.

Ubuntu runs directly on the Linux kernel. It is not a container, it is a VM. Docker is started in Ubuntu. There is no docker-in-docker setup.

So, there will be no need for the current Docker-VM setup.

This is still a sort of VM setup. But x11docker and docker will run in the same WSL2-VM. Currently, the MobyVM only runs docker.

But the alternative will not be technically equivalent at all.

I don't see disadvantages. Probably the current MobyVM will be dropped, but it will still be possible to run docker.exe in Windows. I assume they'll keep the frontend and change the backend.

For x11docker I see the advantage to have docker and commands like xauth in the same environment as x11docker and to have a full qualified mkfifo. Only the X server / VcXsrv has to be called elsewhere.

However, maybe WSL2 won't run nested in a Windows VM. I already did not get MobyVM to work.

@eine
Copy link
Contributor

eine commented May 25, 2019

Ubuntu runs directly on the Linux kernel. It is not a container, it is a VM. Docker is started in Ubuntu. There is no docker-in-docker setup.

I do not think that 'Ubuntu runs directly on the Linux kernel'. When you say 'Ubuntu' I think you mean the shortcut that is shown in the screencast. That is a shortcut to what they call a
'WSL distro', which is a kind of synonym for 'Docker container' or 'OCI container'. Hence, you could start 'Debian' or 'Alpine' instead, and the setup would be equivalent.

Right now, there is no explicit VM behind WSL1, so you cannot interact with it. They say that:

To summarize: while WSL 2 does use a VM, it will be managed and run behind the scenes leaving you with the same user experience as WSL 1.

Which leads me to think that the VM will be a black box, just as the Moby-WM. The difference is that docker is automatically started in Moby-VM, which I don't know if it will be possible in Microsoft's VM.

However, WSL2 distros are not OCI containers, because the target of Microsoft is to be able to execute GNU/Linux tools seamlessly, so they break almost every isolation possible. Hence, it might make sense to execute the docker daemon in a WSL2 distro, provided that the isolation between the distro and the VM is nearly inexistent.

AFAIK, Microsoft is doing this in partnership with Docker, not on their own. Therefore, if they decided to go this way, it must be because there is no relevant performance issue. Furthermore, it is interesting, since it allows to start different docker daemons in several WSL2 distros. And this is precisely the context that I wanted to bring. This is not possible with docker-for-win/WSL1 but I think that it will be an option with WSL2.

This is still a sort of VM setup. But x11docker and docker will run in the same WSL2-VM. Currently, the MobyVM only runs docker.

This is what I am not sure about. I think that x11docker and docker will run in the same WSL2 distro, which will be executed on a VM. But neither x11docker nor docker will run on the VM directly. There seems that there is no explicit mechanism to get a shell in the VM.

I don't see disadvantages. Probably the current MobyVM will be dropped, but it will still be possible to run docker.exe in Windows. I assume they'll keep the frontend and change the backend.

I'm quite sure about it. How will it work, tho? If a single docker daemon is started on a WSL2 distro, it might be possible that it is listening on a default port, which is automatically bind to the VM, and the host (Windows). Any other daemon started in a different WSL2 distro will likely conflict.

Overall, I find it great to let the user configure the docker daemon as in a GNU/Linux environment, instead of being constrained by the configuration of the daemon in the Moby-WM. However, with great power comes great responsibility.

For x11docker I see the advantage to have docker and commands like xauth in the same environment as x11docker and to have a full qualified mkfifo. Only the X server / VcXsrv has to be called elsewhere.

Yes, I think that the codebase will be simplified a lot with WSL2. Support for MSYS2 could be dropped right away. I am not sure about Cygwin/X, tho. GPU support is an interesting feature to have.

However, maybe WSL2 won't run nested in a Windows VM. I already did not get MobyVM to work.

I agree. WSL2 will require Hyper-V. That's why they will keep WSL1: for users without Hyper-V.

@mviereck
Copy link
Owner Author

Whatever the technical details will be indeed - I am currently thinking about some sort of political dimension.

I've been curious already why there was and is no X suppot for WSL. It is an easy task to provide e.g. VcXsrv in WSL. Microsoft could just do it with almost no effort. There has been several user requests, but they all has been refused.

Maybe Microsoft just dont want it. It would allow the "common GUI user" some Linux experience. Currently only Linux nerds will use WSL. But with a WSL GUI environment many less geeky Windows users could try and like Linux. They could say, Linux is cool, let us use Linux natively and drop Windows at all.

Speaking from me, I am not really happy to support Microsoft. They did a bad lobbywork in Germany a few years ago and killed the Limux project. The city Munich/München switched from Windows to Linux several years ago. After some struggling it got stable and was a famous prestige project.
Suddenly and for no obvious reason, the project was dropped and the city migrated back to Windows. Shortly after that Microsoft built a new big headquarter in Munich.

I am angry. I think of:

  • Dropping x11docker on Windows at all to not support Microsoft.
  • Supporting x11docker on good old Cygwin, but not supporting the hype WSL to not support Windows development.
  • Supporting X on WSL (with and without docker) to make Linux GUIs on Windows available, thus making Linux famous. (However, a much shorter but well done script could suit this better.)

These thoughts are not technical at all, though. I would like to hear your thoughts about this.

@eine
Copy link
Contributor

eine commented May 26, 2019

These thoughts are not technical at all, though. I would like to hear your thoughts about this.

I must agree with you on almost everything. They also did bad lobbywork around here for several years, and they are still doing it, specially targeting education. I am aware about the case of Munich too. It was such a sad new.

Supporting x11docker on good old Cygwin, but not supporting the hype WSL to not support Windows development.

I think that this might be incoherent. Although I would prefer having Cygwin support rather than not having support at all, I think that it is not consistent to support Cygwin and not WSL. Both are solutions to use GNU/Linux tools on Microsoft's Windows. Both of them rely on some free, other open, and other closed source pieces of software. The difference between them is mostly technological. I.e., if someone was to write a HyperV-based Cygwin today, the architecture would probably look quite similar to WSL.

Moreover, both installing and using Cygwin is harder than either WSL or GNU/Linux. A common GUI user which needs to start using terminal apps might be confused about WSL being much easier, and it might lead to thinking that Microsoft's Linux is easier than a regular GNU/Linux. I think that, from a strategic point of view, it is better to let new users mix windows and linux binaries almost seamlessly. Hopefully, at one point they will be using all linux binaries without even realizing about it.

Supporting X on WSL (with and without docker) to make Linux GUIs on Windows available, thus making Linux famous. (However, a much shorter but well done script could suit this better.)

I think that x11docker can signifficantly help in this sense. According to the demos, it will be possible to launch a windows GUI app from WSL. So, users might feel that Linux is not for regular apps, because GUIs only work on windows. A simple script (which calls x11docker, or an independent one) sourced in .bashrc can solve this, as you say. A very interesting user group that might benefit from this are developers of apps with GUIs (including videogames) which use frameworks with multi-platform support.


I also think that the Windows part of the codebase is getting too complex, so I agree with you when you point out that in a few months a single and straighforward solution should be kept.

At the same time, the main reason for me to switch from my own script to x11docker was Windows support. On GNU/Linux, it is straighforward to share the X server on the host with any docker container. Hence, it is easy to set up, even by hand. However, on Windows it is not so easy. Therefore, if Windows support was dropped, I would probably need to stick with the current version. For me, it is prioritary to have a common syntax on both platforms, because it allows me to write all the scripts and development assets once. I could wrap x11docker with my own 'entrypoint', which I did in the past; but this would imply that I would not use any x11docker feature which I am not able to replicate on Windows on my own.

In the end, it is going to be mostly your time and effort, so I completely understand if you do not want to support Microsoft at all, be it because you are angry or because of any other reason.

@mviereck
Copy link
Owner Author

mviereck commented May 28, 2019

Thank you for your thoughts. You have said some important points to consider.

As a start, I have published runx v0.1.
It allows to provide VcXsrv in WSL. It can be sourced in ~/.bashrc or directly run e.g. runx xterm.
I might extend it for MSYS2 and Cygwin, too.

It can also be used for x11docker in future. This will allow me to drop some Windows code from x11docker.

I want to support x11docker in at least WSL. runx might make it easier to keep support for Cygwin and MSYS2, too.

@eine
Copy link
Contributor

eine commented May 28, 2019

Thanks to you for making an open dicussion about it ;). I find your solution very sensible.

I tried runx in WSL and I can confirm that it works. Awesome! Just two minor issues:

  • In line 335 -v|--verbose), I had to add ;;.
  • todo() is line 433 is empty. This is not allowed. I added : in line 434, just before the first comment.

@mviereck
Copy link
Owner Author

mviereck commented Jun 7, 2019

Thanks to you for making an open dicussion about it ;). I find your solution very sensible.

Thanks. :-)

Let's continue this in #165.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants