Amazon EC2 as a Reseller Web Hosting Platform – Part 2 – Initial Server Setup
Now that you have all the prerequisites together from the previous article, it’s time to set up the target instance that will be used for the rest of these articles.
Starting the base AMI
For managing our server instances, EBS volumes, and Elastic IPs, we will be using the Amazon AWS Management console, which provides a nice web-based front-end to all of the necessary functions.
The first step is to choose the AMIs menu item on the left of the console window. An AMI is a base image that can be booted into an EC2 instance. Think of it as a backup of a running system that can be restored to another system in the event of a failure. This link will bring up a selection list of available AMIs, which will be used to create our default instance.
The initial list of available AMIs you are shown covers all public AMI images. Any one of these can be booted into an instance. We are going to filter this list so we see only the types of images we want. To do so, click the dropdown arrow next to the ‘All Platforms’ item, and choose ‘Ubuntu’. This will filter the list for only Ubuntu-based AMIs. Then, in the filter box, type ‘intrepid’. This will further filter the list so that we only see the most recent fully-released version of Ubuntu, titled ‘Intrepid Ibex’. Check the box next to the AMI with the ID ‘ami-255bbc4c’.
To start an instance based off of this AMI, check the box and click the ‘Launch’ button at the top of the display window.
NOTE: Using Amazon EC2 is NOT FREE. When you launch an instance, you will start the clock, which will run at $.40/hour in the US (other zones vary) in the case of this configuration. While not initially expensive, if you forget to stop an instance, the cost can add up quickly.
When you launch the instance based off of the chosen AMI, you will be presented with a menu. Since we’re launching an x86_64 instance, your choice is a ‘Large’ or ‘Extra Large’ configuration. In rough terms, the ‘Extra Large’ instance is twice as powerful as the ‘Large’ instance. It also carries twice the cost, so beware. If you feel you’ll be able to utilize the additional horsepower and memory, feel free to use the ‘Extra Large’ instance, as it does not affect the configuration steps.
You will also be asked to choose or create a keypair, which will allow you to do the initial connections via SSH. In the example configuration, we will not be using (and will actually be removing the requirement) a keypair, but we need it initially to access the instance after it has been started. Once you create a keypair, you need to download your personal certificate, which will allow you to access your running instance. If you lose this file, there is no way to retrieve it, and you will need to create a new pair.
You also have the option of creating and using Security Groups, which allow you to segment your EC2 virtual network for security and operational customization. For the purpose of this tutorial, we are only using one server, and therefore do not have a need for custom Security Groups.
After launching your instance, you will be presented with your Instance status window. The rotating icon on the left indicates that the status window will update automatically. If you change to a different view, and then come back to the instance status window, that icon will switch to a checkbox, and the status will not update automatically. At this point, you can update manually by clicking the ‘refresh’ button in the upper right of the instances window.
When your instance is started, you will see a status of ‘Running’, and an entry in the ‘Public DNS’ field.
Customizing the instance – Pass 1
To access your newly started instance, use your favorite SSH program (I personally use Putty). You will need to utilize your downloaded key file. Upon login, use the id ‘ubuntu’. You will not be prompted for a password, as the key file acts as the pass.
The first thing we’re going to do is remove the passkey portion from the SSH configuration. Since we’re going to be configuring this server for multiple client use, we want them to use passwords. To change this, edit the file /etc/ssh/sshd_config file using the command ’sudo vi /etc/ssh/sshd_config’. This will open the file in the vi editor with root authority, allowing you to make changes. To enable password authentication, change the line that reads ‘PasswordAuthentication no’ to ‘PasswordAuthentication yes’.
Before restarting the ssh daemon, which implements the change, we want to set a password for the Ubuntu user so we don’t lose our ability to connect. To do so, use the command ’sudo passwd ubuntu’. This will allow you to set a new password for the ‘ubuntu’ user.
Once the password is changed, restart the sshd daemon using the following command ’sudo /etc/init.d/ssh restart’. Before closing the existing connection, be sure to connect via a new session, using your new password for the ‘ubuntu’ user. Once you are confident you can connect reliably, feel free to close the initial window that used the keypair for authentication.
The next thing we want to do is update the system to the latest patch levels. Since the AMI was built when Intrepid Ibex was released, we want to make sure any existing security issues have been repaired. To check for new updates, use the command ’sudo apt-get update’. When the command completes (should only take a few seconds at the most), use the command ’sudo apt-get upgrade’, which will start the upgrade process. The system will check against the updated package list, and build a list of packages to be updated. When it is ready, it will ask you if you wish to update. Type ‘Y’ to confirm.
NOTE: EC2 instances are not static. If you shut down your running instance without following the next steps to save your configuration, you will need to go through the beginning of this article again.
Finally, to prep the system for the LVM (Logical Volume Management) setup we’ll be using for user data, LVM packages must be installed. To install LVM, simply execute the command ’sudo apt-get install lvm2′
Archiving the instance – Pass 1
Once the updates are complete, it is time to do the first ‘backup’ of the running instance into a usable AMI in your personal S3 storage location.
If you do not already have one, you will need to create an x.509 certificate keypair, which will allow you to upload your image to S3 and keep it for storage.
EC2 creates what is referred to as an ‘ephemeral’ storage location which allows you to store temporary data, which is ideal for creating our AMI. The storage is mounted by default at /mnt. We will be using this storage as our default location for the next several steps. To access it, simply type ‘cd /mnt’.
Next, we want to create an image of the running instance in an archive format that is understood by EC2 and can be registered as an AMI that can further be launched as a new instance.
To enable the bundling of an image and registering as an AMI, we need to make sure the appropriate x.509 keypair exists on the system. Upload the two files you should have downloaded when you created your certificate to the /mnt folder on the instance. If you bundle the image with incorrect keypair information, you will be unable to unbundle and register an AMI.
The default location for bundling is in the /tmp directory, which unfortunately exists under / in the default EC2 configuration. This is not a big problem, necessarily, but it necessitates us choosing a different default location as more information is added to the running system. Since the ephemeral storage mounted in /mnt is about 400GB, that’s plenty of space for our needs. To keep things separated during the bundling process, create a folder called ‘bundle’ under the /mnt directory using the command ’sudo mkdir /mnt/bundle’.
To bundle the running image for upload to S3, you will issue the command ’sudo ec2-bundle-vol -k /mnt/pk-<your private key string>.pem -c /mnt/cert-<your cert string>.pem -d /mnt/bundle -s 1000 -u <your account number>’. The account number is your Amazon AWS account number without the dashes. When you hit enter, confirm that you are creating an x86_64 instance, and the program will chug along, creating an image of instance, and placing the files in /mnt/bundle.
With this nice powerful instance, the bundling process takes about two minutes. When it completes, you will see a list of image.part.x files in the /mnt/bundle folder, along with a file called ‘image.manifest.xml’. This is the file you will use for uploading your image to S3 for storage.
To upload the files to an S3 bucket, issue the command ’sudo ec2-upload-bundle -b my-bucket -m image.manifest -a my-aws-access-key-id -s my-secret-key-id’ from the /mnt/bundle folder. The bucket must be an existing bucket within your S3 store. The access key and secret key for your S3 account can be found on your AWS account page.
When complete, you should be able to see the image.part files and your image.manifest.xml in your previously-mentioned S3 bucket.
To register your newly bundled AMI, return to your AWS EC2 console, and click the AMIs entry again in the left. At the top of the AMI display window, you will see a button labeled ‘Register New AMI’. The popup starts the URL for your manifest file. All you need to do is fill in the name of the bucket and the filename. The resulting URL should look like ‘http://s3.amazonaws.com:80/my-bucket/image.manifest.xml’. The registration process should be almost instantaneous. If you receive any errors, go back over the previous steps and make sure your keypairs and other identifying information match appropriately.
Before shutting down the previous instance, we need to boot the new instance and make sure that our configuration and updates have been carried over. In the AMI window of your console, you should already be set to view ‘Owned By Me’, which should show you your new AMI. If not, click the dropdown and select ‘Owned By Me’.
Testing the new custom instance
Launch the AMI into a new instance using no keypair and wait until you see a public DNS entry in your console window.
If you can access your new instance appropriately (using ‘ubuntu’ and the password you created), and you see that the instance has it’s updates (’sudo apt-get update’ shows no available updates), you can safely shut down both instances by checking their boxes and selecting the ‘Terminate Instance’ option in the instance display window.
Next time, we’ll look at configuring EBS volumes and Elastic IPs.




