search

accetto / ubuntu-vnc-xfce-firefox

Retired and merged into 'accetto/ubuntu-vnc-xfce' (Generation 1).
Apache License 2.0
24 stars 9 forks source link

Set VNC_PORT and NO_VNC_PORT for multiple containers with host networking #4

Closed ykontekakis closed 4 years ago

ykontekakis commented 4 years ago

I need to use multiple containers with host networking but I am facing two issues:

accetto commented 4 years ago

Thank you for reporting this issue. Before I'll check it, could you try also the newer images from the repository accetto/xubuntu-vnc-novnc please?

ykontekakis commented 4 years ago

So, docker run -ti --rm --network host -e VNC_PORT=6109 -e NO_VNC_PORT=7109 accetto/xubuntu-vnc-novnc-firefox has the same issue of not binding vncserver to VNC_PORT. With the following patch:

diff --git a/docker/xubuntu-vnc-novnc/src/startup/vnc_startup.sh b/docker/xubuntu-vnc-novnc/src/startup/vnc_startup.sh
index cc632b0..5c9d25f 100644
--- a/docker/xubuntu-vnc-novnc/src/startup/vnc_startup.sh
+++ b/docker/xubuntu-vnc-novnc/src/startup/vnc_startup.sh
@@ -120,7 +120,7 @@ vncserver -kill "${DISPLAY}" &> "${STARTUPDIR}/vnc_startup.log" \

 echo "... VNC params: VNC_COL_DEPTH=${VNC_COL_DEPTH}, VNC_RESOLUTION=${VNC_RESOLUTION}"
 echo "... VNC params: VNC_BLACKLIST_TIMEOUT=${VNC_BLACKLIST_TIMEOUT}, VNC_BLACKLIST_THRESHOLD=${VNC_BLACKLIST_THRESHOLD}"
-vncserver "${DISPLAY}" -depth "${VNC_COL_DEPTH}" -geometry "${VNC_RESOLUTION}" \
+vncserver "${DISPLAY}" -rfbport "${VNC_PORT}" -depth "${VNC_COL_DEPTH}" -geometry "${VNC_RESOLUTION}" \
     -BlacklistTimeout "${VNC_BLACKLIST_TIMEOUT}" \
     -BlacklistThreshold "${VNC_BLACKLIST_THRESHOLD}" &> "${STARTUPDIR}/vnc_startup.log"

and by building both accetto/xubuntu-vnc-novnc and accetto/xubuntu-vnc-novnc-firefox (with docker build -t accetto/xubuntu-vnc-novnc-firefox -f Dockerfile.firefox .) I can start the first container (docker run -ti --rm --network host -e VNC_PORT=6109 -e NO_VNC_PORT=7109 accetto/xubuntu-vnc-novnc-firefox) and connect successfully.

When I start the second one (docker run -ti --rm --network host -e VNC_PORT=6110 -e NO_VNC_PORT=7110 accetto/xubuntu-vnc-novnc-firefox) it fails with:

$ docker run -ti --rm --network host -e VNC_PORT=6110 -e NO_VNC_PORT=7110 accetto/xubuntu-vnc-novnc-firefox
Script: /dockerstartup/vnc_startup.sh
uid=1001(headless) gid=0(root) groups=0(root),27(sudo)

Preparing VNC server configuration files ...
xauth:  file /home/headless/.Xauthority does not exist
Could not start Xvnc.

_XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed
_XSERVTransMakeAllCOTSServerListeners: server already running
(EE) 
Fatal server error:
(EE) Cannot establish any listening sockets - Make sure an X server isn't already running(EE)
ykontekakis commented 4 years ago

Both containers work fine if I run the second one as:

$ docker run -ti --rm --network host -e VNC_PORT=6110 -e NO_VNC_PORT=7110 -e DISPLAY=:2 accetto/xubuntu-vnc-novnc-firefox
Script: /dockerstartup/vnc_startup.sh
uid=1001(headless) gid=0(root) groups=0(root),27(sudo)

Preparing VNC server configuration files ...
xauth:  file /home/headless/.Xauthority does not exist

New 'laptop:2 ()' desktop is laptop:2

Creating default startup script /home/headless/.vnc/xstartup
Creating default config /home/headless/.vnc/config
Starting applications specified in /home/headless/.vnc/xstartup
Log file is /home/headless/.vnc/laptop:2.log

Killing Xvnc process ID 23
Saving default startup script as /home/headless/.vnc/xstartup.old
Replacing default startup script /home/headless/.vnc/xstartup
Starting noVNC
Starting VNC server ...
... remove old VNC locks to be a reattachable container
... VNC params: VNC_COL_DEPTH=24, VNC_RESOLUTION=1360x768
... VNC params: VNC_BLACKLIST_TIMEOUT=0, VNC_BLACKLIST_THRESHOLD=20
... VNC server started on display :2
Connect via VNC viewer with 127.0.1.1:6110
Connect via noVNC with http://127.0.1.1:7110

I don't see why I need to specify a different DISPLAY however tbh, but it's a good workaround for me atm

ykontekakis commented 4 years ago

I suppose this has to do with unix sockets being on the same network namespace (--network host) and clashing when the same DISPLAY is set. In that case it would be nice to check if variable DISPLAY is set and if not (and clashes with an existing one) to dynamically set it to the next available.

accetto commented 4 years ago

So I've tested it and I can confirm your observations. I think, that you've found the best solutions for this particular special scenario. The problem is really related to running the containers on the host's network (--network host). It has not been the original intention, because there are some serious issues on Linux (s. for example Docker run reference) and under Windows it doesn't practically work at all.

You do not mention, why do you need to use the host's network, but if it's really not avoidable, then I find your proposal reasonable. Unfortunatelly, I'll not be able to implement it for these older containers any time soon, because I'm currently concentrating on the next generation of headless containers. They will be based on Ubuntu 20.04 LTS and they will use the newest version of TigerVNC server, which by the way, uses completely different startup procedure.

For the case, that you would have time to test your proposal, you can check, for example, this question on stackoverflow.

I really appreciate that you've tested this special scenario and that you've shared your solution.

ykontekakis commented 4 years ago

This is indeed an edge case. I am building a custom image on top of yours containing software it's protocol only works with host networking. I think vncserver's port should be updated just for consistency's sake and just close this this issue since there is a workaround if someone else needs it.

Your images are great. Can't wait using the new versions

accetto commented 4 years ago

Thank you.

You've probably already noticed it yourself, but for the case just as tips:

You can start containers also with --debug and/or --skip switches (use --help for the full list). It can help by development and debugging.

You can also bind the startup directory to avoid building the image after each change in the vnc_startup.sh script. Something like this:

docker run -it --rm --name foo --network host \
    -v $PWD/src/startup:/dockerstartup \
    accetto/ubuntu-vnc-xfce-firefox --skip bash

Then you can start the startup script manually like /dockerstartup/vnc_startup.sh --debug, then stop it using CTRL-C, modify it and start it again.

If you wish, we can add your alternative solution to the repository. Feel free to send a pull request any time.

By the way, what do you think about merging the ubuntu-vnc-xfce repositories together? It has been like that in the beginning, until I've split them. The hope is, that it'll be easier to maintain and also to use.

ykontekakis commented 4 years ago

You are already using all vncserver related variables so setting the port looks like the right choice and yes mounting part of or all the source is a useful way to move fast while developing.

If by merging together you refer to something similar with what you've done on xubuntu-vnc repo, the only downsides I see (compared to the separate repo structure approach which I am used to and mostly prefer because of that) are:

(these are just personal preferences)

accetto commented 4 years ago

Thank you for your feedback. These are exactly the points that led me to the splitting some time ago. However, after adding the third generation of images it could become confusing, so I'm considering merging each generation to one GitHub repository.

accetto commented 3 years ago

Hello @ykontekakis,

I've just released a new generation of containers based on Ubuntu 20.04 LTS. You can find it on GitHub and in the following three repositories on Docker Hub - accetto/ubuntu-vnc-xfce-g3, accetto/ubuntu-vnc-xfce-chromium-g3 and accetto/ubuntu-vnc-xfce-firefox-g3.

Unfortunatelly I had no time to test your particular scenario, but maybe you'll find it useful anyhow. So have a look and let me know if it works for you.

Regards, @accetto