A docker container spawned utilising scripts/run.sh with no additional arguments will expose VNC service on host's port 5050 without authentication.
A VNC client of preference can then be used to initiate a remote session to the spawned container. For instance, the following command initiate a remote session without frame compression using TurboVNC.
vncviewer --nojpeg --compresslevel 0 localhost:5050The xworkspace executable located at /usr/local/sbin facilitates ease administration of the VNC Server.
The default behaviour of xworkspace can be altered by providing Xvnc4 compatible arguments. For instance, the following command overrides the resolution (default 1024x768) and the VNC service port (default 5050).
xworkspace -rfbport 8080 -geometry 1366x768The above behaviour of xworkspace can be utilised in conjoin with scripts/run.sh's custom command feature to spawn a customised container. For example, the following command attempts to expose the VNC service with authentication.
./run.sh xworkspace -SecurityTypes VncAuthThe option -m or --mount can be used to bind mount a host directory to a new container either using a relative or an absolute path. It will be binded at ~/workspace on the created container.
For instance, to bind current directory run ./run.sh --m . or ./run.sh --mount ..
Similarly, to bind a directory like C:\foo\bar using an absolute path on a Windows* system to container's ~/workspace run ./run.sh -m C:\foo\bar.
Additional volumes can be binded using multiple -v or --volume followed by respective source and destination path in standard docker format.
For instance, to bind mount directory C:\foo\bar at /mnt/foo/bar with read-only permissions run ./run.sh -v C:\foo\bar:/mnt/foo/bar:ro.
The present of flag --git will bind ~/.gitconfig on host to ~/.gitconfig on the container with read-only access.
The present of flag --ssh will bind ~/.ssh on host to ~/.ssh on container with read-only access.
The default working directory of the container is set to ~/workspace. It can be overridden to suit the need by using either -w or --workdir followed by the absolute path of the desired directory.
For instance, to set /usr/share/workspace as the container working directory run ./run.sh -w /usr/share/workspace.
The default behaviour of run.sh is to only publish container's exposed port 5050 to host's 5050 which serves as the VNC entrypoint.
The utilisation of the flag -p or --publish publishes the container's additionally exposed ports 8080, 8081, and 8082 to to the host's 8080, 8081, and 8082 respectively.
The run.sh can be used to run any docker image that is intended to be run as an executable. By default, it will attempt to use ashenm/xworkspace:latest as the image unless specified.
The default image can be overridden by simply specifying the desired image name followed by the parameter --image. If multiple images are specified the last most image name will be used.
For instance, the following command attempts to compose a gzip tarball from the current directory content utilising the alpine:latest image conjoining scripts/run.sh's custom command feature.
./run.sh --image alpine --mount . tar czf archive.tgz .By default, run.sh will attempt to execute command xworkspace. The default behaviour can altered by specifying a custom command as the last most argument to run.sh.
For example, the following command attempts to executes the python's built-in http simple server in a newly spawned container serving files in the current directory at http://<DOCKER_HOST>:8080.
./run.sh --publish --mount . python3 -m http.server 8080Given that Docker is installed, the facilitator scripts provided can be used with any shell that is is Bourne SHell compatible.
For Microsoft Windows use a POSIX-compliant run-time environment such as MSYS or Cygwin with WinPTY or Microsoft's own Windows Subsystem for Linux.