The course is part of this learning path
Building and maintaining Linux graphic desktops
This course - the seventh of eleven courses covering LPIC-1 Linux certification - will explore Linux Display Managers and graphic Desktop Environments. You will learn how to:
- configure hardware peripherals for use in a GUI environment
- control graphic login sessions
- manage Display Managers like LightDM
- enable and manage Linux accessibility utilities to ensure that users with disabilities can access system resources, and
- build a graphic user interface on top of a virtual server in Amazon's AWS.
If you have thoughts or suggestions for this course, please contact Cloud Academy at email@example.com.
Build a remote graphic Linux desktop on an AWS EC2 instance
Since we've been discussing how to manage Linux graphics desktops, it might be fun to see if we can actually build one on top of a Linux server. We'll do that in a place you'd never normally expect to see anything graphic, on an Amazon web services EC2 virtual machine. Naturally, the real value of cloud based virtual machines is in their ability to launch light and serve web applications. That generally means terminal command line interfaces. However, you never know when you might have a need for a GUI Linux desktop in the cloud, so let's give it a try.
We'll first go to the EC2 dashboard and click on launch instance. We'll select a 64 bit Ubuntu 14.04 Amazon machine image, and go with the T2 micro instance type. This type, by the way, will be too small and slow for most useful purposes, but it will serve as a nice illustration. We'll accept the instance detail defaults and go onto storage, whose defaults we'll also accept. Choosing a security group to control traffic into and out of our instance will be important. We'll create a new security group, and for security purposes, first limit SSH access to my local IP address, which Amazon inserts automatically. Then, we'll add a new custom TCP rule, which will allow traffic through port 5901, which happens to be the default port for VNC - VNC stands for virtual network computing - and limit its access to my local IP. We'll review, confirm that my key pair is available, and launch the instance.
We'll head back to the EC2 dashboard where, after a minute or two, our instance's new public IP address will be displayed. Once we get that IP address, we can SSH into a terminal session, where we can set up our graphic desktop. I use -i to point to the newkey.pem key pair that's in the current directory, and then ibuntu @ the IP address I was given. Since this is obviously the first time I've logged into this instance, I'll have to acknowledge that the new authentication key will be added to my allowed list.
The first thing we will do in our brand new virtual server is create a new user who'll be the owner of the VNC hosting session. He'll need a password, too. Next, we'll add our new user to the admin group, using user mod. Now we'll use su to switch users to become our new user. There's a simple change we'll have to make to the sshd_config file to allow password based access to our system. We'll scroll down to the password authentication line, and change its no value to yes. So that this change can take effect, we'll restart SSH, using service restart.
We're now ready to install the software that Ubuntu will need to host graphic sessions. In fact, Ubuntu desktop is a very convenient metapackage, that includes the dozens or even hundreds of packages that are necessary to get the graphic desktop running. Once that's done, we'll install the VNC4 server package to permit graphic hosting sessions. Now we'll run VNC server, which will prompt us to create a VNC password. Remember the password because we'll need it later.
Since we're going to edit the VNC configuration, we'll shut down VNC server using -kill. The VNC config files can be found in a hidden directory in my user's home directory. ls -a will show all directory contents, including hidden. We'll cd to the .vnc directory, and using Nano, open the X startup file for editing. Now here, we're faced with a number of possibilities. For some people, it's enough to simply uncomment these two lines and add sh after exec. But I found that for me, that configuration hasn't been successful. So I'm going to replace the entire script with this text. Notice how the script calls Nautilus, the Linux file manager. This will start a session within Nautilus. If you would leave that line out, this session would open with a terminal window instead. That would be really nice and all but hardly useful, considering that we're already in a terminal window.
We'll exit and save the file and restart VNC server. We'll now go back to our local computer and use Remmina, a very nice little remote desktop client to open a session on our AWS server. We'll start a new connection using the VNC protocol. We'll insert our EC2 instance's public IP address, followed by a colon and the number one into the server field, and add our user name. That should be it. We'll click connect and provide our VNC password.
And we're in. It's not much, and the connection is rather slow but it's a living, breathing, GUI desktop running on the Amazon cloud.
About the Author
David taught high school for twenty years, worked as a Linux system administrator for five years, and has been writing since he could hold a crayon between his fingers. His childhood bedroom wall has since been repainted.
Having worked directly with all kinds of technology, David derives great pleasure from completing projects that draw on as many tools from his toolkit as possible.
Besides being a Linux system administrator with a strong focus on virtualization and security tools, David writes technical documentation and user guides, and creates technology training videos.
His favorite technology tool is the one that should be just about ready for release tomorrow. Or Thursday.