Port/Display question

[rsettlage]

One more question:

Being a shared machine, we could quite possibly see lots of users on a node. I am hoping to simply bind mount /tmp:/tmp and let things happen right with picking of display using the info in /tmp/.X11-utils. This seems to work correctly EXCEPT, websockify doesn't seem to get the message and still points to localhost:5901. IF, I set the VNC_PORT manually, things seem to be ok, but that of course requires that I choose the display as one determines the other.

Where does websockify get the port for VNC from? And when for that matter.

Short of answering that, my plan is to simply choose two open ports, say, >7000 and set the VNC/noVNC/DISPLAY variables accordingly.

[accetto]

That's a good question. I didn't have a use case similar to yours yet, so I have to check.

As a quick preliminary info: I do not pass any parameters to websockify. The code starting VNC and noVNC is in docker/xfce/src/startup/vnc_startup.rc.

What would the content of /tmp/.X11-utils look like?

[rsettlage]

It includes files that look like X1, X2 etc. What I currently do is:

## get initial random display/ports
display=$(($RANDOM % 300))
vnc_port=$(($display+5900))
no_vnc_port=$((($RANDOM % 28231) + 32768))

## make sure display and vnc_port are not otherwise used
#
while ( (netstat -tln | grep -c $vnc_port)>0 && ((cd /tmp/.X11-unix && for x in X*; do echo ":${x#X}"; done) | grep -c $display)>0 ) ; do display=$(($RANDOM % 300)) && vnc_port=$(($display+5900)
) && echo $vnc_port ; done

# get noVNC port
#
while ( (netstat -tln | grep -c $no_vnc_port)>0 ) ; do no_vnc_port=$((($RANDOM % 28231) + 32768)) && echo $no_vnc_port ; done

## push into file for container
#
echo "export VNC_PORT=$vnc_port" >port.rc
echo "export NO_VNC_PORT=$no_vnc_port" >>port.rc
echo "export DISPLAY=:$display" >>port.rc
echo "export VNC_PW=${password}" >>port.rc
## set display on host
export DISPLAY=:$display

I have modified startup.sh to include sourcing of the port.rc file:

################## added for OOD
source "${_mydir}"/port.rc
################# end additional

This works fine, it would just be nice to allow more kernel control so I don't accidentally grab a reserved port or something else the kernel would know best.

[accetto]

Yes, this would work. However, it's also possible to override the variables by starting the container. For example:

docker run -it --rm \
    -e DISPLAY=":241" \
    -e VNC_PORT="6141" \
    -e NO_VNC_PORT="39954" \
    -p "25000:6141" \
    -p "25001:39954" \
    accetto/ubuntu-vnc-xfce-g3:latest --debug

The container's output will end by:

VNC server started on display ':241' and TCP port '6141' Connect via VNC viewer with 172.17.0.3:6141 noVNC started on TCP port '39954' Connect via web browser

Then navigating the web browser to localhost:25001 for checking the variables inside the container:

For this use case I would also disable the EXPOSE statements in the Dockerfile, otherwise there still would be the ports 5901 and 6901 marked as exposed in the metadata.

However, maybe I still don't follow your scenario correctly.

[rsettlage]

Right, I am using the container via Singularity, singularity build new_image.sif docker://accetto..., singularity run new_image.sif, as the normal user does not have root, I need to change the ports from inside the container at run time. So, I am looking for ports and the display prior to starting the container. I put them into the ports.rc file, bind mount that file into the container and add the sourcing of that file to the startup script which I also bind mount into the container.

Things are working and it looks great, so perhaps we will leave it at that. ;)

[accetto]

Agreed :) I never worked with Singularity, so I cannot really asses it.

[accetto]

Hello @rsettlage,

I've included the features you've missed and proposed into the upcoming release 20.03.

Would you agree to test it with Singularity before I publish the final release? I have no experience with it and I do not have it installed.

I have published the upcoming release on GitHub (next_release branch) and published the image on Docker Hub (accetto/dev-ubuntu-vnc-xfce-g3, tag next).

I would really appreciate your feedback. Thanks in advance.

Regards, accetto

[rsettlage]

Sure. I can try it tonight/tomorrow.

[accetto]

FYI

I've replaced the next_release branch by the upcoming_release one. The content is still the same, only the git history has been cleaned-up.

Please be aware that also the upcoming_release branch will be removed after publishing the final release.

[accetto]

FYI

By releasing I've encountered an unexpected problem similar to this BuildKit issue. The proposed workaround (to disable the BuilKit) will not work in my case, so I have to find-out something myself. It should not have any impact on your testing, I assume, because there is no problem by building locally, only on Docker Hub. Unfortunatelly I had to rebase the master branch to remove the latest commit.

[rsettlage]

This works so far. I will play around with it more over the next week or so!

[accetto]

I've just published the release 21.03, so there is no need for the upcoming_release branch and the next image tag any more. I'll remove them. Please use the published master branch resources and the public images for testing. Thanks once more.

[accetto]

Seems like everything is working, so I'm closing the issue.