Since the apps require a linux environment, docker does not run natively in Mac and PC. Rather, it sets up a linux virtual machine and runs docker engine inside that. Before version 1.12, docker on Mac required installation of virtualbox and docker-machine to manage this linux virtual machine inside which the containers are run. However, latest version of docker for mac uses hypervisor to run operating system as a service and thus has more native feel. Lets install it using Homebrew:

brew cask install docker

Run the app from the launcher and it will go through the initial setup process. We can now interact with the docker daemon through the shell.

Next, we will pull a debian image and install gimp and inkscape in it. Open a terminal and create a Dockerfile inside a folder called apps.

FROM debian:jessie
RUN apt-get update
RUN DEBIAN_FRONTEND=noninteractive \
  apt-get install -y -q gimp inkscape \
  ttf-dejavu --no-install-recommends
RUN rm -rf /var/lib/apt/lists/*
CMD "gimp"

Next, build the docker image called apps:

docker build -t apps .

docker commands

To run graphics inside docker containers, we will need X11 running on Mac. At the time of this writing the stable version of XQuartz (2.7.9) has a bug which prevents graphics forwarding. However, 2.7.10_beta2 works.

brew cask install xquartz-beta

The stable version of xquartz may work if it is higher than 2.7.10. Check the version in home-brew by: brew cask info quartz.

Start XQuartz and allow connections from network clients in preferences > security. Now the following commands should get gimp running:

ip=$(ifconfig | grep "inet " | grep -v 127.0.0.1 | awk '{print $2}')
xhost + $ip
docker run --rm -it -e DISPLAY=$ip:0 -v $HOME/Downloads:/root/Downloads apps

This will also share the ~/Downloads folder with the container. To run inkscape:

docker run --rm -it -e DISPLAY=$ip:0 -v $HOME/Downloads:/root/Downloads apps inkscape

Any changes made to gimp itself will be lost when the app is closed. Any additional plugins or customizations should be included in the Dockerfile to make them permanent.

The Unity desktop in Ubuntu is very slow over VNC for some reason. So, the first step is to switch to Xfce or xubuntu desktop. Also installed x11vnc while at it.

sudo apt-get install xubuntu-desktop x11vnc

For security, it better not to run VNC server all the time, but rather start it when needed. This can be accomplished by the following command at the terminal from the home computer (Macbook):

ssh -t -L 5900:localhost:5900 remote-host 'x11vnc -localhost -display :0

Where remote-host is the work PC. The above command starts x11vnc in the work PC and forwards the port to the home machine. One can now connect to it by typing in another terminal,

open vnc://localhost

It is advisable to create a VNC password for the server in the remote-host for added security. Refer to x11vnc web or man page for instructions. The above command will stop the server once the client exists, or -forever can be used to keep it alive. Then it will need to be stopped by CTRL-c.

Unfortunately, this method works only if the remote-host is logged in. When at the lock-screen in Ubuntu, the virtual terminal runs at display :1 (rather than at :0), so the x11vnc will have to be started with arguments -auth /var/run/lightdm/root/:1. But after unlocking the session, the VT falls back to :0, so x11vnc needs to be restarted with default VT. To work around this problem, I wrote the following script:

#!/bin/bash
vncpa=$HOME/.vnc/passwd
vtpath=/var/run/lightdm/root
vtuser=:0
vtlock=:1
while [ -e "$vtpath/$vtlock" ]; do
   echo "screen locked"
   x11vnc -localhost -rfbauth $vncpa -display $vtlock -auth $vtpath/$vtlock
   sleep 2
done
echo "screen unlocked"
x11vnc -localhost -rfbauth $vncpa -nevershared -forever -display $vtuser -auth $vtpath/$vtuser

Saved it as ~/bin/x11run and made it executable. Note that, access to the folder /var/run/lighdtm requires root privileges, so this script has to be run with sudo. So, to establish the tunnel, start the server and client in a single script, I use the ever-useful expect with ssh.

#!/bin/bash
echo -n "ID: "; read paD
sleep 5 && open vnc://localhost &
/usr/bin/expect << EOF
set timeout 120
spawn ssh -L 5900:localhost:5900 remote-host

expect "remote-host:~$ "
send "sudo ~/bin/x11run\r"

expect "*for user: "
send "$paD\r"

expect eof
interact
EOF

With appropriate modifications to those marked in red, it should work!