How our remote access service works

Tags: Faq

I realise that it’s quite possibly not clear to a lot of people how Guacamole works in our setup. This has a bearing on our ability to respond to fault reports.

So here goes…

We’ve reserved a bunch of physical machines for remote use. These offer Windows (via Microsoft RDP), Linux (via VNC) or MacOS (again via VNC). We’ve placed a small proxy service in front of these machines, whose job is to dole out physical machines to people when they connect to the proxy address.

In fact, you can access these directly by connecting

Remote desktop to windows-desktop.dcs.aber.ac.uk VNC to linux-desktop.dcs.aber.ac.uk:0 VNC to mac-desktop.dcs.aber.ac.uk:0

Guacamole is (effectively) an in-browser client for the above services - it just makes it easier for people, saving them having to install client software.

What all that means is that when you connect via Guacamole, you’re landing on a physical machine in one of our teaching rooms.

All our physical machines, both local and remote access, are cloned from the same master image. So at rollout time, they’re all identical. Problems such as missing software, if they don’t affect all machines, are down to issues (e.g. failed updates) that have happened on individual machines after rollout.

People are used to having to identify physical machines when reporting faults, but it strikes me that it’s not immediately obvious that the same applies when using remote machines.

When people encounter a fault via the Guacamole service, we’d really appreciate it if they could tell us the name of the machine they were on at the time. The easiest way of finding out (on Windows, Linux and MacOS) is to open a command prompt/terminal window and type “hostname”.