Set VNC_PORT and NO_VNC_PORT for multiple containers with host networking

[ykontekakis]

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

• NO_VNC_PORT is not being used properly. I had to perform the following change on the ubuntu-vnc-xcfe repo in order to bind the vncserver on the VNC_PORT:

diff --git a/src/startup/vnc_startup.sh b/src/startup/vnc_startup.sh
index c5e334b..9d33602 100644
--- a/src/startup/vnc_startup.sh
+++ b/src/startup/vnc_startup.sh
@@ -104,7 +104,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}"/no_vnc_startup.log

• I can then build both accetto/ubuntu-vnc-xfce and accetto/ubuntu-vnc-xfce-firefox and successfully start the first container as follows:

$ docker run -ti --rm --network host -e VNC_PORT=7901 -e NO_VNC_PORT=8901 accetto/ubuntu-vnc-xfce 
USER_ID: 1000, GROUP_ID: 1000
nss_wrapper location: /usr/lib/libnss_wrapper.so
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 :1
Connect via VNC viewer with 127.0.1.1:7901
Connect via noVNC with http://127.0.1.1:8901

but the 2nd one fails as follows:

$ docker run -ti --rm --network host -e VNC_PORT=7902 -e NO_VNC_PORT=8902 accetto/ubuntu-vnc-xfce
USER_ID: 1000, GROUP_ID: 1000
nss_wrapper location: /usr/lib/libnss_wrapper.so
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
~/tmp$ echo $?
255

If I stop the first container and then run the second command it works fine. I cannot see any port clashing and I am running out of ideas. Can you please advise on this issue ?

[accetto]

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]

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]

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]

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]

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]

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]

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]

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:

• Source code workspace management: Less git juggling to do when for example documenting stuff (on /README.md for example) performing changes on the latest sha on xubuntu-vnc-xfce and wanting to build it (and possible change and document) through an older SHA of xubuntu-vnc).
• I find it useful having a 1-1 mapping when tagging docker images with the corresponding git SHA rather than the SHA of the tip of the monorepo

(these are just personal preferences)

[accetto]

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]

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