I am going to take a slightly different angle on the [tag]AWS[/tag]/[tag]EC2[/tag] topic this month. In the last blog entry I focused on addressing specific Java Web Application related development challenges (Tomcat clustering, Terracotta etc). This month, I am going to look at how we can extend EC2 to be used in the real world by ‘normal’ users. I know, in this day and age, it is fairly difficult to classify normal users; but for me a normal user is someone who uses their PC, MAC or whatever, to browse the web, write some letters, check their email and other normal day stuff.
So far our only method of interfacing with EC2 has been via a Putty SSH session. Not what you’d call the most user friendly method in the world! For the last year or so, I have been running a copy of [tag]Ubuntu[/tag] 6.1 (Edgy), on VMPlayer, on my laptop. This is running the [tag]GNOME[/tag] Desktop Environment and I find it, in a word, great! It’s easy to use, visually pleasing and has lots and lots of nice features, like adding transparency to terminal windows.
So what did I have to do to get GNOME up and running on EC2 and access the session remotely from my laptop or desktop? To be honest it was surprisingly easy. All the information that you need is out there, but unfortunately, I couldn’t find one consolidated resource that I could refer to.
Basically, there are two core pieces of software that are required to make this work:
- The GNOME Desktop Environment distro
- Some form of remote control software
The installation of the GNOME distro is fairly straight forward. I performed the install on a [tag]Fedora[/tag] Core 4, Stentz, version of Linux. Use yum to do all the hard work for you:
yum -y groupinstall "GNOME Desktop Environment"
It took me a number of tries before I manged to get all the necessary packages downloaded, but stick with it and eventually yum will manage to download all the necessary packages. On installation you may encounter the following error:
The GPG keys listed for the "Fedora Core 4 - i386 - Base" repository are already installed but they are not correct for this package.
Check that the correct key URLs are configured for this repository.
Thanks to Tom Gleeson on the AWS forums for posting the fix for this.
Next up is to decide which remote control solution to use. I originally went with a VNC solution and it worked fine! But trust me when I say that the VNC is no where near the quality and speed of that offered by FreeNX. I have them running side by side against the same EC2 instance and there is simply no comparison between [tag]FreeNX[/tag] and VNC.
Here are some screenshots of the two desktops repainting:
FreeNX Repainting the Desktop
VNC Repainting the Desktop
One thing that is not immediately obvious from these screen shots is the fact that FreeNX can make use of the full client resolution, thereby taking up the full screen. This does not appear to be the case with VNC, and it seems to reside within its own boxed area, even after maximizing the VNC window.
FreeNX is not difficult to get up and running, but like everything else, the necessary information does not seem to be in any one location. For me there were three keys sites that had the information that I needed to get up and running:
- HOWTO Setup FreeNX on Fedora by Rick Stout
- Remote Access with FreeNX in5 Steps
- An answer to a session startup failure question on the Ubuntu forums
Follow the above links in the right order, and trust me, you will avoid a lot of head scratching.
The HOWTO guide takes you through the installation and setup of the NXServer and Client. The excellent client is provided by NoMachine. This guide also points out a potential bug in connecting to a GNOME session via the NXClient, but thankfully, it provides an easy workaround.
The second of the guides, Remote Access with FreeNX in 5 Steps, fills in the blanks left behind by the HOWTO guide i.e. creation of user accounts on the NXServer, without which, you ain’t going anywhere! Follow this guide and you shouldn’t have any problems getting authenticated against your NXServer.
The last of the guides, from the Ubuntu forums, answers a question to an issue that you may encounter after completing the steps in guide 2. I had installed, what I thought, was the latest and greatest of the NX Clients for Windows, version 2.1.0-17. After authentication against the NXServer I was getting the following error message:
NX> 1000 NXNODE - Version 1.4.0-45-SVN OS (GPL)
NX> 700 Session id: paul-ubuntu-1000-531E6551EE8E5BF9B58B669E364DAA11
NX> 705 Session display: 1000
NX> 703 Session type: unix-gnome
NX> 701 Proxy cookie: acfe24b70625000bd409026837739796
NX> 702 Proxy IP: 127.0.0.1
NX> 706 Agent cookie: 426dea9932211fbafb099051a861b9c6
NX> 704 Session cache: unix-gnome
NX> 707 SSL tunneling: 1
NX> 105 /usr/lib/nx/nxserver: line 891: 8408 Terminated ( sleep $AGENT_STARTUP_TIMEOUT; exit 1 )
NX> 504 Session startup failed.
NX> 1004 Error: nxagent failed to start with: Unrecognized option: 1
NX> 1001 Bye.
Killed by signal 15.
Thankfully, I found the answer to the issue on the Ubuntu forum. Install the 1.5.0-114 version of the NX Client instead of the 2.1.0 version. I don’t know why it worked but it did. And within 2 minutes after installing the older version of the client, I was in! FreeNX say that they offer ‘near local speed application responsiveness’ and in my opinion, they do not disappoint.
Of course, having a nice desktop running on EC2 offers more advantages than just being able to browse the web or check your email. It also offers a portal into your EC2 instances. Before, if you wanted multiple terminals running against a single instance, it was case of opening a Putty session, and then duplicating the session. Now you can start as many terminals as is necessary from with GNOME. You were also limited by the fact that you could not run any applications that were UI dependant. Well, now you can!
We have been working on putting together a Continuous Performance Management ([tag]CPM[/tag])environment on EC2. We are, I would think, about 80% of the way there. We have a fully load balanced server environment, being stressed by a distributed [tag]JMeter[/tag] setup. We also have a [tag]PerformaSure[/tag] Nexus running in EC2 that is collecting stats at the application and system level across the load balanced applications, and because we have desktop environment, we can run the PerformaSure workstation on EC2 to perform the analysis of the collected stats. The alternative is to download the stats file, which could be a couple of hundred Mb in size. Not a good idea!
I will be posting more information on the progress of the setup of this environment in the coming weeks. If anyone has any problems in getting any of the above working, I would be more than happy to help out in anyway I can.
You may also be interested in: