Education and the Cloud

September 7, 2016

Using Guacamole for a browser-only HTML5 Remote Desktop capability that will work with both Ubuntu and Windows servers!

Cloud in a Box (CIAB) Remote Desktop

Connect using only a Web Browser  to both Linux and Windows Servers to access and use a Remote Desktop

Aug 2016 – Brian Mullan (



CIAB Remote Desktop (CIAB – Cloud-In-A-Box) was originally envisioned around 2008 after I had the funded opportunity from my employer to spend nearly 18 months on a Fellowship with a non-profit here in North Carolina that provides the networking connectivity to all of the schools in North Carolina.

At the time, cloud computing was just beginning and Amazon’s AWS was practically the only game in town.

Having used AWS myself quite a bit by that time I tried to investigate how “cloud” could be used by K-12 schools as a possible low cost solution to the may problems almost every school faced including:

  • lack of funds often prevent hiring top tech support or buying new equipment
  • local inexperienced technical support which often-times consisted of a librarian, teacher or volunteers
  • a hodge-podge of mixed old/new computers (desktop, laptops)
  • security & viruses were a constant threat because of Windows  usage.

Besides traditional use of Desktop and Laptop computers schools today also include mixes of Chromebooks, Tablets as well.

The above circumstances and combination of problems often created a frustrating experience for teachers, students and parents.

So in 2008 I first started thinking about how to bring together a Cloud based Remote Desktop solution that while not solving every problem, would try to adhere to the 80/20 rule of trying to solve 80% of the problems.

CIAB Remote Desktop only requires a working HTML5 web browser!    This means that all of the above school computing resources (Desktop, Laptop, Chromebook, Tablet and even a Smart Phone) can be used.

The power of the local computer would no longer matter.

The amount of memory, disk drive space, operating system on the local computers was no longer relevant as the real User “desktops” are remote and the “server” they run on can be scaled in the “cloud” to as large as needed in size or number based on availability.

The school would only need decent Network connectivity in regards to speed & reliability.

For example, on AWS EC2 the largest single Virtual Machine “server” you can spin up today is an “instance” called “d2.8xlarge”:

Instance Type      # vCPU                    Memory (GiB)                   Storage (GB)                   Network Speed               Physical Processor
d2.8xlarge           36                       244GBytes                     24 x 2TByte                    10 Gigabit                 Intel Xeon E5-2676 v3

Today there are lots of great IaaS (Infrastructure as a Service) Cloud providers including AWS, Digital Ocean and others.

If you were to install CIAB Remote Desktop on such an AWS server you would pay by the hour or month but as the above stats show you would be using a very powerful server to provide remote desktops to the students.

CIAB Remote Desktop Use-Case Benefits

Since any applications or databases used by the CIAB Remote Desktop users run on the remote server it doesn’t really matter much how old or slow your local computing device is!

  1. For an Admin… to upgrade/delete/add or configure an application only requires doing so in one place not on dozens or hundreds of local computers.3. Security. Regarding Security and/or viruses the remote desktop environments all are running on Linux.
  2. Security for School orient Remote Desktops is managed in perhaps just a few Cloud based servers versus dozens or hundreds of premises based servers spread all over every School District in every County in a State.     Viruses… I’m not sure that there are any that affect Linux.  Also, CIAB Remote Desktop uses HTTPS (SSL) so the Browser connection to the remote desktop is fully encrypted between the user and the Remote server providing the Desktop Environment
  3. For a school, students can access their CIAB Remote Desktop while at School or Home just using a web Browser.   They and the Teachers could access and do homework or grading at home or at school just using only a Web Browser!




              Your remote desktop is always available to you from home or even while traveling !

              Beyond schools, CIAB Remote Desktop could be useful for many people or businesses.

              Besides the above benefits, if installed on one of your home computers you could access your Home Desktop from anywhere!





Over the past couple years I’ve gradually integrated a combination of software into a solution for CIAB that seems to work very well.

I’ve utilized the great work of the Apache Guacamole project.   Guacamole is a clientless remote desktop gateway. It supports standard protocols like VNC, RDP, and SSH.     Its called clientless because no plugins or client software are required to be installed.    Thanks to HTML5, once Guacamole is installed on a server, all you need to access your remote desktop is the web browser you or the students use already.

I integrated several other Open Source software projects with Guacamole to enhance the overall remote desktop solution including:

NGINX –  a free, open-source, high-performance HTTP server and reverse proxy

MySQL – the most popular Open Source SQL database management system

Tomcat – is an open-source web server developed by the Apache Software Foundation (ASF).

XRDP/X11RDP – these 2 components provide a fully functional Linux terminal server, capable of accepting RDP protocol connections from Linux based rdesktop & freerdp clients but also from Microsoft’s own Remote Desktop (re RDP protocol speaking) clients.    XRDP/X11RDP allow RDP Protocol speaking clients the ability to connect to a Linux Server Desktop environment and interact just as if they were logged into it directly and just like they are familiar doing with Windows Terminal Servers and their Windows Remote Desktops.

The combination of NGINX and Tomcat is implemented to support HTTPS web browsing so the end-to-end connection from the student’s web browser to the remote desktop is encrypted.


Installation should be Easy

My development of CIAB included creation of a set of Linux “bash” shell scripts that, for the most part, automatically install everything including the Ubuntu Mate Desktop Environment,  the Guacamole Web Proxy Server, Tomcat8, NGINX, MySQL, and XRDP/X11RDP software.

During execution of these scripts the installer/admin is only asked perhaps 7-8 times to input information and most of those are simply to enter Admin passwords for Guacamole, NGINX, MySQL or their own Linux/Ubuntu User Account.

I’ve created a fairly extensive README.PDF file which explains the installation process step by step and includes quite a few pictures of various entry forms/screens that the Installer will encounter.    PLEASE…. Take the time to thoroughly read & use the README.PDF file!

In that README.PDF guide I also talk about an example installation on Amazon’s AWS EC2 Cloud.     For that installation I also identify a recommended  AWS EC2 “server” identifier (called an AMI) to use if you want to experiment.

NOTE:   I have used these scripts to install this many times now on the AWS Cloud but also on Digital Ocean’s Cloud as well as on local Servers and even a local VM.

I’ve posted all of the scripts and associated files required by the scripts to install CIAB Remote Desktop on the GitHub repository site:

NOTE:   you will need ALL of those files for the scripts to successfully install the CIAB Remote Desktop on your Cloud Server, local server or VM.

Also, note on the GitHub page I include a pointer to a YouTube Video I made that shows me running through the entire CIAB Remote Desktop installation process !

That video can be found here:

Lastly,  all of the Scripts were designed to install the CIAB Remote Desktop onto an Ubuntu 16.04 Server.    If you want to install onto some other Linux distribution you will have to go through the various scripts and make appropriate changes for your Linux distro choice.

The Demonstration of the CIAB Remote Desktop only focuses on connecting to an Ubuntu MATE Desktop on the AWS Cloud.

REMEMBER…   the very same setup of Guacamole can be used to simultaneously configure Remote Desktop connections to Microsoft Windows Servers as well assuming those Windows Servers have been configured appropriately for RDP Remote Desktop connections/sessions.

If you find this useful, interesting and decide to try it out please let me know how it went.






November 20, 2013

Configure x2go remote desktop capability into LXC Containers

Filed under: LXC, Remote Desktop, ubuntu, x2go — Tags: , , , — bmullan @ 8:32 am

I’ve long used x2go for remote desktop access to Linux machines.   So far I’ve found x2go to be by far the fastest/best remote desktop application for Linux whereby a Linux, Windows or Mac user can access that Linux desktop “server”.

The following will show you how to create an LXC container and configure it to implement the x2go (see remote desktop “server” so you can access the LXC container’s desktop using any of x2go native client (windows, linux, mac) or even the x2go web browser plugin (ubuntu only at this time).

Note 1:

  • the following assumes an Ubuntu Host OS.   LXC is implemented in the Linux Kernel and should be available on ANY Distro but use may differ in some ways not documented here.

First lets create a test LXC container

$ sudo lxc-create -t ubuntu -n test

Note 2:    -t specifies “what” linux LXC “template” to use in creation of the LXC container.   In ubuntu templates exist for:

  • lxc-alpine
  • lxc-busybox
  • lxc-fedora
  • lxc-sshd
  • lxc-altlinux
  • lxc-cirros
  • lxc-opensuse
  • lxc-ubuntu
  • lxc-archlinux
  • lxc-debian
  • lxc-oracle
  • lxc-ubuntu-cloud

So although I use Ubuntu I could create an LXC container running OpenSuse, Debian, Arch Linux etc….  very cool capability.

The ONLY caveate is that all container OS’s will have to run the Host OS’s “kernel”.    This normally is not a problem for most use-cases though.

Next we have to “start” the LXC container we called “test”

$ sudo lxc-start -n test

As part of executing the above command you will be presented with a login prompt for the LXC container.   The default LoginID = ubuntu and the password = ubuntu

So login to the LXC container called “test”

Next I started adding some of the applications I would be using to do the test.

First I make sure the test container is updated

test:~$ sudo apt-get update && sudo apt-get upgrade -y

Next I install either an XFCE or LXDE desktop… Note, I use one of these because no remote desktop software I am aware of supports the 3D graphics of etiher Unity or Gnome3… including x2go. But x2go does support xfce, lxde, mate and a couple others.

So lets install xfce desktop in the container.

test:~$ sudo apt-get install xubuntu-desktop -y

In order to install x2go PPA in the container I have to get “add-apt-repository” (its not by default)

test:~$ sudo apt-get install sofware-properties-common -y

Now I can add the x2go PPA:

test:~$ sudo add-apt-repository ppa:x2go/stable

Next, install the x2goserver to which I will connect from my Host by using the x2goclient I will install there later.

test:~$ sudo apt-get install x2goserver x2goserver-xsession -y

x2goclient uses SSH to login to an x2goserver.

There are various advanced x2go configs you can do for login but to keep it simple I am going to just be using login/password combo.

However, to be able to do that the default Ubuntu /etc/ssh/sshd_config file needs 2 changes to allow logging in with login/password.

Use whatever editor you use to edit (I use nano – which you would have to also install with apt-get into the container)

test:~$ sudo nano /etc/ssh/sshd_config

Change the following from NO to YES to enable challenge-response passwords

ChallengeResponseAuthentication no

Uncomment out (re remove the #) the following to enable Password Authentication

#PasswordAuthentication yes 

Save your 2 changes and exit your editor.

Now, restart SSH so the changes take effect

 test:~$ sudo service ssh restart

At this point the x2goserver is all setup in the LXC container so you can access it with your x2goclient on your Host OS or wherever they might be assuming they can connect to your LXC container’s IP address.

You can shutdown (or reboot) the LXC container while logged into it just as you would in any Ubuntu by:

test:~$ sudo shutdown -r now  -or- $ sudo shutdown -h now

What is nice about LXC is that once you have shutdown the LXC container you can “clone” that entire container very quickly by issuing the following command on your Host OS

hostOS:~$  sudo lxc-clone -o test -n new_container

Each new LXC container will get a new IP address (default will be in the 10.x.x.x address range).

After you “start” your new cloned LXC container:

hostOS:~$  sudo lxc-start -n new_container

To access the NEW LXC container you can find out the new LXC container’s IP address using the following command after the LXC container has been started:

hostOS:~$ sudo lxc-ls –fancy

 You can then use that IP address in creating a new x2go “session profile”.

Again, remember that each container “could” be configured with a different Desktop Environment so one user could have xfce another lxde another Mate etc.

Hope this is useful and fun for you to experiment with.


Blog at