As a starting point I have used a very nice post ; parts of it have become outdated (e.g. freenx installation) for which a more updated instructions are provided, in addition to several settings that I have found to be more convenient.
Launching AMI
One of the best distributions for running on EC2 is Ubuntu. You can launch an official AMI version from http://cloud.ubuntu.com/ami/ by simply clicking on the AMI-ID of the instance that you want to launch. Another option (that gives you more flexibility; e.g. using spot instances) is to launch the instance through AWS Console by clicking on Instances/Launch Instance https://console.aws.amazon.com/ec2/ search for the official ubuntu ID: 099720109477
Recommendations:
- EBS Root Device: ensures that any changes that you make will persist even if you shutdown your machine.
- 64-bit version: more fully utilizes computational resources.
- instance type:
- don’t get micro instance; will be too slow for most UI tasks
- don’t use spot instance at this point, since it can’t be stopped, and when is terminated the EBS volume will be deleted
[AWS Ref] Although Spot Instances can use Amazon EBS-backed AMIs, they don’t support Stop/Start. In other words, you can’t stop and start Spot Instances launched from an AMI with an Amazon EBS root device.
Then you just need to follow the EC2 Wizard Steps.
[MHM's post] If you do not have a keypair, then select Create a new Key Pair, name your keypair and download it. You will need to put it somewhere accessible as we will be modifying the permissions of this file later. Once you have copied the keypair information, click Continue to head to the next screen.
Then create a new security group (or select an existing ones; if you are familiar with security group settings):
Once you complete the wizard you should be able to see your instance launching & then running. Make sure to select the region in which you were launching the instance (otherwise it will not be displayed).
Instance Configuration
[MHM's post] Now that the instance is running, you will need to access it via SSH. I will assume you are usnig a Linux distribution with access to a terminal or equivalently, you can use Putty in Windows.
Attempting to use the keypair (downloaded in the previous step) while logging in will cause SSH to throw an error that the default read permissions on the file are too insecure. Therefore we need to remove the read permissions for groups and others, while retaining it for the user. Thus we change permissions from 644 to 400:
chmod 400 keypair.pem
Now we can SSH into the Amazon instance using the keypair. Remember to replace the asterisks below with your specific host (Public DNS field) which can be seen from the AWS Management Console:
ssh -i /path/to/keypair.pem ubuntu@ec2-***-***-***-***.compute-1.amazonaws.com
Now that we are logged into the Amazon instance, we need to perform some essential system maintenance, which includes updates, an upgrade and installation of some additional packages:
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install build-essential
In order to be able to use NX, we now need to create a new user with admin rights (lets call it ec2usr).
sudo adduser ec2usr
sudo adduser ec2usr admin
We also need to allow SSH to use a password login:
sudo vi /etc/ssh/sshd_config
[MHM's post] Set PasswordAuthentication to “yes” where it says “no”, then save and exit. You will have to restart the SSH daemon for this to take effect:
sudo /etc/init.d/ssh restart
UI (Desktop) Installation
[MHM's post] The next step is to install the Ubuntu Desktop functionality. This essentially means install the X window system and the window manager. Bear in mind that the last command will take around 15-20 minutes:
export DEBIAN_FRONTEND=noninteractive
sudo -E apt-get update
sudo -E apt-get install -y ubuntu-desktop
Restart to complete upgrades.
You now have an Ubuntu Desktop living in the cloud! Although, we can’t do much with it yet as we can’t connect to it via a GUI remote connection.
Installing NX Sever
FreeNX is a traditional NX Sever; however the support for it has been lacking lately (does not work well on latest ubuntu releases). Therefore we go with the NX Free Edition for Linux from NoMachine (which has a limit of 2 sessions per server). These packages are not in the software repository so need to be downloaded (for the latest version see NX Free Edition for Linux DEB amd64):
wget http://64.34.161.181/download/3.5.0/Linux/nxclient_3.5.0-7_amd64.deb
wget http://64.34.161.181/download/3.5.0/Linux/nxnode_3.5.0-7_amd64.deb
wget http://64.34.161.181/download/3.5.0/Linux/FE/nxserver_3.5.0-9_amd64.deb
and then installed:
sudo dpkg -i nxclient_3.5.0-7_amd64.deb
sudo dpkg -i nxnode_3.5.0-7_amd64.deb
sudo dpkg -i nxserver_3.5.0-9_amd64.deb
Installer will automatically launch the NX server. But just do double check you can check it’s status by:
sudo /usr/NX/bin/nxserver --status
Other command options (in case you need them) are: |–start|–stop|–restart
NX Client Installation
Now you need to install NX client on your local machine. Download the latest NX client from NoMachine. One option to download the latest stable version, or the beta (could be unstable), right now that is NX 4 Beta/Preview (NX Player: Windows, Linux, Mac OS X ).
OSX update: NX 4 Preview seems to be quite unstable on OSX (but is the only option if you have OSX >= 10.7; the stable 3.5 version seems to work better).
For some reason running System Monitor made NX client quite slugish.
Launch NX Player (Warning: UI is not very intuitive); and “create new connection” by filling in “host” field; and click X to go back to the main menu.
To connect to your server click on the leftmost icon (make sure to use NX login):
Enter username ec2usr and corresponding password.
Click on “Create a new session” and select “Create a new GNOME virtual Desktop”.
You will now see the ubuntu gui that is running in the cloud 
Troubleshooting NX
Due to some glitch in NX; you may start getting the following error:
NX is unable to connect. Authentication failed for user XXX …
Thanks to this post (with minor modifcations) this issued could be resolved as follows:
sudo cp /usr/NX/home/nx/.ssh/known_hosts /usr/NX/home/nx/.ssh/known_hosts.bak
sudo rm /usr/NX/home/nx/.ssh/known_hosts
sudo touch /usr/NX/home/nx/.ssh/known_hosts
sudo /usr/NX/bin/nxserver --restart
The NoMachine service is not available on host
If you are connecting from NoMachine Player to NX server 3.5.0, be sure you select “Use the NoMachine login” rather than “Use the system login” in the Connect GUI and re-try to run the session [ref-post].
Very slow Response UI; large latency
Seem to get fixed by changing display setting on the NX client: low quality and disabling optimization options.
Making EBS/AMI Image
Before you stop your instance; go to the instances in AWS console; select yours and click on “Create Image (EBS AMI)” this way you can save it, and launch it later. This will create an AMI under AMI section; as well as a snapshot called something like “Created by CreateImage(i-fb2xxxx) for ami-683xxxx from vol-132cxxx”
Starting/Stopping Your machine in the cloud
Assuming that you have followed instructions carefully and selected an instance with EBS root store, you can now shutdown and start you cloud machine at will. To do this just go to the https://console.aws.amazon.com/ec2/ (make sure you select the right region in the left upper corner; in my case it is Tokyo (Gigabit speeds in Japan are sweeeet)). Then right-click on instance and select start or stop depending on your intentions (note if you click terminate, the ebs volume will be detached and renamed, and then when you start AMI the original volume will be launch (so you will not see the data from the last session); if stop is greyed out it may indicate that you are running a spot instance).
update: some of the above procedures may not be needed if you are running a regular instance (non-spot one).
Note: every time that you start/stop your instance it’s address will change; so you will need to update it accordingly in NX Player (unless you set up static ip).
You may also want to install Dropbox for easy and relatively pain free way of sharing files with your cloud machine; could be easily installed from “Software Center” of Ubuntu.
Tips
Resizing EBS Volume
http://www.steinpalmer.com/blog/?p=39 provides a nice description of how this could be done by using AWS GUI Console
- [If the volume is already attached to an EC2 instance] Detach it from the instance (Right-click on the instance and select the detach option)
- Take a snapshot of the EBS Volume
- Go to your snapshots listing and right-click on the newly created snapshot. select the option to create a new volume from the snapshot
- Enter the new size of the volume and fill out the other fields as desired.
- Voila, you have now successfully re-sized your volume. you can now attach it to your instances. <Neil> you should attach it as /dev/sda1 (unless you have other volumes)
Once the system starts up; you need to reconfigure it so that it knows of a new size:
sudo resize2fs /dev/xvda1
to make sure that it worked properly:
df -h
Saving Money by Running Spot Instances
You can save significant amount of money by running a spot instance. Of course this comes at a price (your instances might be terminated if your minimum price is not met). Moreover, spot instances could not be manually stopped (only terminated); when you terminate an instance your EBS volume is detached and is renamed; so if you launch your AMI it will be pointing to the old EBS volume. There are several optins of coping with this.
* Create a new AMI from the detached-renamed EBS volume. Useful if you want to launch multiple instances.
* Create an additional EBS volume, and attach it to the instance. The drawback of this approach: volume can be attached only to a single instance, so if you want to launch multiple instances you would need to make copies and they will get out of sync.
Click on the volume that you want to attach (make sure it is in the same availability zone as your instance);
specify the device, e.g.: /dev/sdb
although it will be mounted as /dev/xvdb [ref]
make sure that it is visible: sudo fdisk -l
format it: sudo mkfs -t ext4 /dev/xvdb
edit /etc/fstab and add this :
/dev/xvdb /var auto defaults,nobootwait,noatime 0 0
reboot from AWS Console
[ref]
Choosing Availability Region/Zone
If you do a lot of UI interactions you may want to optimize your network latency. The following website is quite handy: http://www.cloudping.info/
Although I’ve used US-East (since it tends to have the cheapest spot prices) with 300 ms delay; without too much trouble.
Luckily I am based in Japan; so for a bit of extra money I can get EC2 instances in the same region (Japan) with gigabit bandwidth and 20 ms latency; now I can do a lot of heavy lifting computationally wise from my mac air while seeping some green tea 
Migrating/Copy AMI between Regions
It used to be quite troublesome to move AMI’s between regions; Amazon has finally addressed this issue: http://aws.typepad.com/aws/2012/12/ebs-snapshot-copy.html
[Deprecated]
@see above
Oddly, AWS does not provide any straightforward ways of doing it. Luckily this nifty script makes it quite easy and convenient.
You can install the above script locally, or on one of your EC2 instances. Bellow are the instructions:
First, you need to set the EC2_ACCESS_KEY and EC2_SECRET_KEY environment variables. You can get your keys from: https://portal.aws.amazon.com/gp/aws/securityCredentials
export EC2_ACCESS_KEY="YOUR_EC2_ACCESS_KEY"
export EC2_SECRET_KEY="YOUR_EC2_SECRET_KEY"
Then install the script:
sudo perl -MCPAN -e 'install VM::EC2'
During the installation the script may ask for your keys again; you may paste them (although sometimes that does not seem to work well; in which case you can just hit enter to omit it). If you get some errors make sure to read what they say. There is a high chance that you may be missing some libraries; in my case I had to install the following:
sudo apt-get install libwww-perl libcrypt-ssleay-perl libxml-libxml-perl
Once the script is installed you can invoke the migration by:
migrate-ebs-image.pl --from us-east-1 --to ap-northeast-1 ami-NNNN
Note: ec2-migrate-image does not work with EBS AMIs
Notes
Nice post that describes differences between AMI, EBS, etc. http://serverfault.com/questions/268719/amazon-ec2-terminology-ami-vs-ebs-vs-snapshot-vs-volume
Keywords: ubuntu linux Ubuntu 11.10 (Oneiric Ocelot) mint remote desktop ui gui graphical gnome kde amazon aws ec2 cloud gnome kde ami nx freenx neatx NoMachine vnc ssh mac os x osx lion aws ec2 zones countries ping latency
For Indexing & Reference purpose I am including my web search history bellow:
|
|
abill - google.com |
3:48pm |
Yesterday
‘build-essential’ is not needed to install NX. You can also restart ssh by doing ‘sudo restart ssh’.
Thanks.
Finally a decent step by step article without the rubbish… FreeNX was driving me insane error after error!
Great work – Thanks
Hi
Really nice step by step, but I cannot get the final steps to work. When connecting with NX player 4, preview 6 to ubuntu 12.04 I get the “Authentication failed for user” no matter what I try. Also after trying the “fix” several times.
I don’t know if there is a difference because it the newer Ubuntu 12, and your step guide is for U11.
Any idea for getting that step to work is very welcome, because I’m going crazy
I’m new in ubuntu, so nothing is intuitive to me
Best regards
I’ve recently done an install on 12.04 and it seemed to work fine.
Have you selected “Use the NX login” on the NX Player?
I had the same problem before; and running the following (by connecting to your machine through ssh) seemed to have fixed it:
sudo cp /usr/NX/home/nx/.ssh/known_hosts /usr/NX/home/nx/.ssh/known_hosts.bak
sudo rm /usr/NX/home/nx/.ssh/known_hosts
sudo touch /usr/NX/home/nx/.ssh/known_hosts
sudo /usr/NX/bin/nxserver –restart
You may want to reboot machine if it still does not work. Reinstalling the NX server might help as well.
Hope it works.
Very nice! It worked flawlessly. Thanks.
Thanks for your kind comment. I am very glad that it was helpful.
Thank you! Very well-written.
The first time through I had problems on the very last step. The symptom of the problem was that the Ubuntu desktop background image would appear in the NX Client for Windows, but nothing else. No status bar across the top; no shortcut icons on the left; just a empty desktop. I had used the the Ubuntu Server 12.10 AMI.
I started over a second time and used the Ubuntu Server 12.04.1 LTS AMI. It worked perfectly on this attempt.
At the time of this comment, No Machine 4 was still in preview. I did not try that. I used No Machine 3.5 on both of my attempts.
Thank you for your comments.
> The symptom of the problem was that the Ubuntu desktop background image would appear in the NX Client for Windows, but nothing else. No status bar across the top; no shortcut icons on the left; just a empty desktop.
I think I have ran into similar issue before. In my case it seem to have been cause by NX client (or ubuntu) having a wrong resolution; rebooting an instance and/or changing resolution settings of NX client has worked in my case.