Again, I’m not going to argument in favor of one or the other, but just document how you can get a consistent setup for your team. This setup however is something that can’t be easily committed in the repository itself like it was done with the line ending configuration. The main reason are the scripts that need to be executed to make sure that any content is processed when checking out or into the repository.

Converting spaces to tabs

To get a good setup, use the same git attributes to process any file. In my repository, the C# code was indented with 4 spaces while the XML files where indented with 2 spaces. If you want everything to be tabs, but you want to keep consistent indentation, you set up 2 filters in .git/config, one for each file type:

[filter "tabspace4"]
    clean = cat
    smudge = unexpand -t 4 --first-only
[filter "tabspace2"]
    clean = cat
    smudge = unexpand -t 2 --first-only

Our filters are defined, now we only have to make them active by adding the following to .git/info/attributes:

*.cs     filter=tabspace4
*.xml     filter=tabspace2

Similar to the line endings, git needs to reprocess all your files. This is done by clearing the working copy and getting a new set of working copy files:

user@host:MyComponent$ git rm --cached -r .
user@host:MyComponent$ git reset --hard
user@host:MyComponent$ git add .
user@host:MyComponent$ git commit -m "Introducing space to tab conversion"

This should transform all spaces to tabs in C# and XML files and commit the tabbed files to the git database.

Platform dependency

The filter definitions use the Unix unexpand command. This setup is not portable to Windows, neither will it work on Mac OS X as the standard unexpand is not real GNU unexpand. This means that every developer needs to have a different setup based on the tools available. This is very cumbersome.

Another option is EditorConfig. EditorConfig is a tool that can be plugged into a number of different editors and IDE’s and takes over your source file formatting regarding indentation and line endings. The source file formatting definition can be committed to the source code repository. Although not all developers will probably use the same editor, with the EditorConfig plugin installed the team will nevertheless have consistent source code formatting.

• git-tfs
• TFS2GIT
• Git-TF

The latter two solutions were tried in converting from the TFS repository to a Git repository.

TFS2Git has the drawback that it is a shell wrapper around the tfs and git command line commands. It just replays the history but all git commits are timestamped with the execution time of the conversion, not the initial timestamp from the TFS repository. This was not favorable.

Git-TF is created by Microsoft to provide access to a TFS repository from non-Microsoft platforms like Linux and Mac OS X. It is a two-way bridge between a local Git checkout and a TFS server, meaning that you can work on the client with your Git toolchain, but pull and push to the central TFS server. As such, it works flawlessly with your TFS server. In a normal developer setup, you only pull the latest changes from TFS, continue working in your local git clone, and push your changes back as TFS changesets. However, performing a deep clone, even from a single branch with a bit of history, takes quite some time. Do you consider 26 hours acceptable for a history of around 2500 commits?

Besides the conversion, a bit of git post-processing was done on the converted repository before it was pushed to the new git server. Let’s get started!

Converting from TFS to Git

To convert MyComponent with full history, without tagging the git revisions with the TFS commit info, run:

user@host:~$ git tf clone --deep --no-tag http://tfs.domain.local:8080/tfs/MyCode $/MyComponent/Development/Development MyComponent

In the above example, only the Development branch was converted. The team already used a minimal gitflow like branch structure and the most granular commit info was on this branch. Given the conversion time mentioned above, converting all branches was not on option.

The intention is to execute a one-time conversion to Git and continue to work in Git. As such, we can remove the remote ref to the TFS server:

user@host:~$ cd MyComponent
user@host:MyComponent$ git branch -rd origin_tfs/tfs

Cleaning up the commit author information

After conversion, the author in every git revision refers to the respective Active Directory user account. As git users, we are used to the regular email style information. So let’s rewrite some git history. Most people seem to know the Github script for changing author info, but the script below can change multiple authors at once in a single rewrite run:

#!/bin/sh

git filter-branch -f --env-filter '

case ${GIT_COMMITTER_NAME} in
		"DOMAIN\joe") name="Joe" ; email="joe@domain.com" ;;
		"DOMAIN\foo") name="Foo" ; email="foo@domain.com" ;;
		"DOMAIN\baz") name="Baz" ; email="baz@domain.com"
esac

export GIT_AUTHOR_NAME="$name"
export GIT_AUTHOR_EMAIL="$email"
export GIT_COMMITTER_NAME="$name"
export GIT_COMMITTER_EMAIL="$email"
'

After running this conversion script in your git repo, it is a good idea to perform some cleanup:

user@host:MyComponent$ git gc --prune=now

Your git repository should shrink considerably.

Line endings…

The never ending debate of line endings. I’m not going to enter this debate of which is better. A good article on how Git handles line endings is the one written by Tim Clem. The only thing to mention is what I wanted and how I set it up: only Line-Feed (LF) wanted in the database, and platform dependent line endings in the working copy. This means also LF on Unices but CRLF on Windows.

Add the following to a .gitattributes file in the root of your repository:

# These files are text and should be normalized (convert crlf => lf)
*.cmd        text
*.config     text
*.Config     text
*.cs         text diff=csharp
*.csproj     text
*.datasource text
*.disco      text
*.edmx       text
*.map        text
*.md         text
*.msbuild    text
*.ps1        text
*.settings   text
*.sln        text
*.svcinfo    text
*.svcmap     text
*.t4properties text
*.tt         text
*.txt        text
*.vspscc     text
*.wsdl       text
*.xaml       text
*.xsd        text

# Images should be treated as binary
# (binary is a macro for -text -diff)
*.ico        binary
*.jepg       binary
*.jpg        binary
*.sdf        binary
*.pdf        binary
*.png        binary

Add additional suffixes that you need mapped to either text or binary type. Now commit this file in your repository:

user@host:MyComponent$ git add .gitattributes
user@host:MyComponent$ git commit -m "Central repository configuration"

As you can see from the code samples, everything is executed on a Unix machine. As the content in the TFS repository contains Windows line endings, we need a single full conversion to make sure that everything is not correctly normalized:

user@host:MyComponent$ git rm --cached -r .
user@host:MyComponent$ git reset --hard
user@host:MyComponent$ git add .
user@host:MyComponent$ git commit -m "Introducing normalised line-endings"

The working copy was removed, we checked out a new working copy with our new settings active. This results in a all text files having LF only now. We add all these changed files to the staging area and commit them. The database now correctly contains LF only for text files.

Results

Our workstation now contains a Git repository with a single master branch, with correct author information and normalized line endings working on all platforms. The only thing left to do is to push this to the new Git server and let the team work on it:

user@host:MyComponent$ git remote add origin http://me@gitserver.domain.com/MyComponent.git
user@host:MyComponent$ git push origin master

That’s all folks!

If you have comments or questions, please leave them below!

The setup used in this article is an Ubuntu 12.04 host system with VirtualBox 4.1.18 installed. From disk /dev/sda the partitions 3 and 4 will be made available to a virtual machine. All virtual machines are run as user virtualbox. All console samples show clearly the user that runs the command.

On Ubuntu, raw devices have the following default access rights:

root@host:~# ls -l /dev/sda*
brw-rw---- 1 root disk 8,  0 Aug 20 15:11 /dev/sda
brw-rw---- 1 root disk 8,  1 Aug 10 17:37 /dev/sda1
brw-rw---- 1 root disk 8,  2 Aug 10 17:37 /dev/sda2
brw-rw---- 1 root disk 8,  3 Aug 21 09:43 /dev/sda3
brw-rw---- 1 root disk 8,  4 Aug 21 09:43 /dev/sda4

To give the virtualbox user proper access to the disks, the disk group will be extended:

root@host:~# usermod --groups disk -a virtualbox

Before going any further, please make sure that any processes currently running as user virtualbox are restarted! This is needed for these processes to pick up the changed permissions. Next to the VirtualBox subsystems, don’t forget to restart the active shell sessions. By adding the virtualbox user to the group disk, the change is also persisted over system reboots.

With the proper access in place, we first create the VMDK file pointing to the raw device:

virtualbox@host:~$ VBoxManage internalcommands createrawvmdk -filename /home/virtualbox/virtualmachines/machine1/machine1-sda.vmdk -rawdisk /dev/sda -partitions 3,4 -relative
RAW host disk access VMDK file /home/virtualbox/virtualmachines/machine1/machine1-sda.vmdk created successfully.

Assuming that the VM machine1 is already created and contains a storage controller, the raw disk is now attached to the virtual machine:

virtualbox@host:~$ VBoxManage storageattach machine1 --storagectl "SATA Controller" --port 0 --type hdd --medium /home/virtualbox/virtualmachines/machine1/machine1-sda.vmdk

On successful completion, this command returns no output. If you want to validate that the disk is attached correctly, print the virtual machine information:

virtualbox@host:~$ VBoxManage showvminfo machine1
...
SATA Controller (0, 0): /home/virtualbox/virtualmachines/machine1/machine1-sda.vmdk (UUID: afc0a...)
...

That’s it!

Please report typos and/or improvements to this article in the comments!

backportpackage fetches a package from one distribution release or from a specified .dsc path or URL and creates a no-change backport of that package to one or more Ubuntu releases release, optionally doing a test build of the package and/or uploading the resulting backport for testing.

This tool comes with the ubuntu-dev-tools package.

I needed to backport the ocaml source package from precise (12.04) to all earlier releases up to lucid (10.04). For the backport to oneiric, here is the command:

$ backportpackage -s precise -d oneiric -u amplidata-2.5 -r ocaml

amplidata-2.5 is the identifier to the PPA as defined in my dput.cnf file. I also configured the file ~/.devscripts with the keys DEBEMAIL, DEBFULLNAME and DEBSIGN_KEYID.

I manage multiple Unix users on Dreamhost, a plethora of Linux virtual machines at work, running Jenkins builders and two additional machines at home. With ssh-keygen, you can generate multiple different public/private keypairs (aka an identity). The section “Selecting Keys” of the above mentioned article describes how you can select a specific identity for connecting to a specific host. The example below shows how to connect to one of my DreamHost user accounts in a passwordless manner:

$ ssh -i ~/.ssh/dh-user1 user1@boba.dreamhost.com

If you have a long list of accounts, it would definitely be easy to use shortcuts for every combination of user@host and link that up to a specific SSH identity. Well, this is possible with the use of an SSH config file. I found out about this file here and then read more about it in the man page.

When you have user1 and user2 as accounts on your remote machine, in my case boba.dreamhost.com, and having different SSH identities for each user (dh-user1[.pub] and dh-user2[.pub]), how do you link everything together to be able to just type one of the following:

$ ssh dh-user1
$ ssh dh-user2

Actually, this is quite easy. Here is the ~/.ssh/config file in my local account (the account I’m making SSH connections from):

Host dh-user1
User user1
HostName boba.dreamhost.com
IdentityFile ~/.ssh/dh-user1

Host dh-user2
User user2
HostName boba.dreamhost.com
IdentityFile ~/.ssh/dh-user2

Every section in this file starts with Host ConnectionName followed by a number of connection parameters that are fully described in the man page. In my case, I specify the real host name, the username on the remote machine, and the identity file I want to link to that account.

Done!

Creating the Snapshot

First we look at the available volumes:

$ ec2-describe-volumes
VOLUME	vol-4001e429	1		us-east-1c	available	2008-09-25T09:51:48+0000

Then we make the snapshot:

$ ec2-create-snapshot vol-4001e429
SNAPSHOT	snap-cb7493a2	vol-4001e429	pending	2008-09-26T11:48:30+0000

It is “pending”. We check the status until it the snapshot creation has “completed”:

$ ec2-describe-snapshots snap-cb7493a2
SNAPSHOT	snap-cb7493a2	vol-4001e429	completed	2008-09-26T11:48:30+0000	100%

Creating a Volume from the Snapshot

Now that the snapshot is ready, we can create a new volume from it. Note that we create it in a different availability zone. The orginal volume resides in “us-east-1c”. The new volume will reside in “us-east-1a”.

$ ec2-create-volume --snapshot snap-cb7493a2 -z us-east-1a
VOLUME	vol-9f00e5f6	1	snap-cb7493a2	us-east-1a	creating	2008-09-26T11:52:37+0000

We wait until the volume is “available”:

$ ec2-describe-volumes
VOLUME	vol-9f00e5f6	1	snap-cb7493a2	us-east-1a	available	2008-09-26T11:52:37+0000
VOLUME	vol-4001e429	1		us-east-1c	available	2008-09-25T09:51:48+0000

Now we have two available volumes.

Mounting the New Volume in an Instance

Let’s launch an image so that we can verify that the newly created volume can be mounted and has the same contents as the original volume. Note that the instance is launched in the availability zone where the newly created volume resides.

$ ec2-run-instances ami-0757b26e -k gettingstarted-keypair -z us-east-1a

The AMI we use here is a public Ubuntu Desktop image.

$ ec2-describe-instances
RESERVATION	r-ff4d9e96	190912652296	default
INSTANCE	i-0fcf6c66	ami-0757b26e	ec2-67-202-35-79.compute-1.amazonaws.com	domU-12-31-38-00-6C-F6.compute-1.internal	running	gettingstarted-keypair	0		m1.small	2008-09-26T11:55:16+0000	us-east-1a	aki-a71cf9ce	ari-a51cf9cc

The instance is ready to be used. In another terminal we connect to the image and start the “user-setup” script. The GUI interaction to set up the user is not shown here.

$ ssh -i id_rsa-gettingstarted-keypair root@ec2-67-202-35-79.compute-1.amazonaws.com
The authenticity of host 'ec2-67-202-35-79.compute-1.amazonaws.com (67.202.35.79)' can't be established.
RSA key fingerprint is ab:df:4e:78:b7:4d:59:3e:ae:6c:81:32:80:eb:bd:78.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'ec2-67-202-35-79.compute-1.amazonaws.com,67.202.35.79' (RSA) to the list of known hosts.
Linux domU-12-31-38-00-6C-F6 2.6.21.7-2.fc8xen #1 SMP Fri Feb 15 12:39:36 EST 2008 i686

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

Amazon EC2 Ubuntu 7.10 gutsy base install AMI built by
Eric Hammond
For more information: http://ec2gutsy-desktop.notlong.com

root@domU-12-31-38-00-6C-F6:~# user-setup
Shadow passwords are now on.
Using `/usr/share/libgksu/debian/gconf-defaults.libgksu-sudo' to provide `libgksu-gconf-defaults'.

Time to attach the volume (in the orginal terminal):

$ ec2-attach-volume vol-9f00e5f6 -i i-0fcf6c66 -d /dev/sdh
ATTACHMENT	vol-9f00e5f6	i-0fcf6c66	/dev/sdh	attaching	2008-09-26T12:01:15+0000
$ ec2-describe-volumes
VOLUME	vol-9f00e5f6	1	snap-cb7493a2	us-east-1a	in-use	2008-09-26T11:52:37+0000
ATTACHMENT	vol-9f00e5f6	i-0fcf6c66	/dev/sdh	attached	2008-09-26T12:01:15+0000
VOLUME	vol-4001e429	1		us-east-1c	available	2008-09-25T09:51:48+0000

Let’s see whether it is available. Connect to the desktop as described in Preparing for Amazon AWS Usage.

In the terminal connected to the instance, we can mount the volume now:

root@domU-12-31-38-00-6C-F6:~# mkdir /mnt/my-volume
root@domU-12-31-38-00-6C-F6:~# mount /dev/sdh /mnt/my-volume

Now the volume should be mounted as “my-volume” and accessible. Let’s verify that by opening a file browser on that volume.

Indeed, the “readme” file that was on the original volume is also on the new volume created from the snapshot.

I followed the instructions given in the Elastic Block Storage Feature Guide.

Starting an Instance

Let’s see which AMIs are available:

$ ec2-describe-images -o self
IMAGE	ami-c6c622af	dehonk-gettingstarted/image.manifest.xml	190912652296	available	private		i386	machine

I launch ami-c6c622af with Elasticfox. Let’s check the status of the instance with the command line tools:

$ ec2-describe-instances
RESERVATION	r-9f3deef6	190912652296	default
INSTANCE	i-520faf3b	ami-c6c622af			pending	gettingstarted-keypair	0		m1.small	2008-09-25T09:50:01+0000	us-east-1c

Important to note for later is the availability zone in which the instance is running, because volumes can ony be attached to instances when they live in the same availability zone.

Create the Volume

Create a volume of 1 GB in the same availability zone in which the instance resides:

$ ec2-create-volume --size 1 -z us-east-1c
VOLUME	vol-4001e429	1		us-east-1c	creating	2008-09-25T09:51:48+0000

Check the status of the volume:

$ ec2-describe-volumes vol-4001e429
VOLUME	vol-4001e429	1		us-east-1c	available	2008-09-25T09:51:48+0000

The volume is available now. Time to use it!

Attaching the Volume

Attach the newly created volume as device /dev/sdh to the running instance:

$ ec2-attach-volume vol-4001e429 -i i-520faf3b -d /dev/sdh
ATTACHMENT	vol-4001e429	i-520faf3b	/dev/sdh	attaching	2008-09-25T09:59:14+0000

The command returns saying that the volume is attaching. Let’s check the status:

$ ec2-describe-volumes VOLUME	vol-4001e429	1		us-east-1c	in-use	2008-09-25T09:51:48+0000 ATTACHMENT	vol-4001e429	i-520faf3b	/dev/sdh	attached	2008-09-25T09:59:14+0000

While the volume was “available” and “attaching” before, now it is “in-use” and “attached”.

Formatting the Volume

Open another termnal. Connect to the instance via ssh:

$ ssh -i id_rsa-gettingstarted-keypair root@ec2-75-101-254-227.compute-1.amazonaws.com

Looking at the contents of /dev reveals that the volume is available as device “sdh”:

# ls /dev
MAKEDEV   port   ptyc1  ptye6  ptyqb  ptyt0  ptyv5  ptyxa  ptyzf    ttya2  ttyc7  ttyec  ttyr1  ttyt6  ttyvb  ttyy0
--- cut here for brevity ---
loop7     ptyb3  ptyd8  ptypd  ptys2  ptyu7  ptywc  ptyz1  <strong>sdh</strong>      ttyb9  ttyde  ttyq3  ttys8  ttyud  ttyx2  ttyz7
--- cut here for brevity ---

Since a new volume is not formatted, we do that first:

# yes | mkfs -t ext3 /dev/sdh
mke2fs 1.38 (30-Jun-2005)
/dev/sdh is entire device, not just one partition!
Proceed anyway? (y,n) Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
131072 inodes, 262144 blocks
13107 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=268435456
8 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
	32768, 98304, 163840, 229376

Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 20 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

Mounting the Volume

Finally, the volume is ready to be mounted in the instance:

# mkdir /mnt/data-store
# mount /dev/sdh /mnt/data-store

Let’s check whether everything is as expected:

# ls /mnt
data-store  lost+found
# ls /mnt/data-store/
lost+found

That looks okay.

Put a file on the volume

Using vi, I created a file named “readme” with this contents:

This is an example file to show that a file persists on an EBS volume after unmounting and detaching.

Unmounting the Volume

Before we stop the instance, we have to unmount the volume. From the Elastic Block Storage Feature Guide: A volume must be unmounted inside the instance before being detached. Failure to do so will result in damage to the file system or the data it contains.

# umount /mnt/data-store

Remember to cd out of the volume, otherwise you will get an error message “umount: /mnt/data-store: device is busy”

Detach the Volume

From the Feature Guide: An Amazon EBS volume can be detached from an instance by either explicitly detaching the volume or terminating the instance. Let’s do it by explicitly detaching it:

$ ec2-detach-volume vol-4001e429 -i i-520faf3b -d /dev/sdh
ATTACHMENT	vol-4001e429	i-520faf3b	/dev/sdh	detaching	2008-09-25T09:59:14+0000

Soon the status of the volume changes form “detaching” to “available”:

$ ec2-describe-volumes
VOLUME	vol-4001e429	1		us-east-1c	available	2008-09-25T09:51:48+0000

Mounting the Volume in Another Instance

Now do all the steps over again to start a new image and mount the volume. Because the volume resides in availability zone “us-east-1c” and instances and volumes have to live in the same availability zone, we have to launch the instance in “us-east-1c”.

$ ec2-run-instances ami-c6c622af -k gettingstarted-keypair -z us-east-1c RESERVATION	r-eb22f182	190912652296	default INSTANCE	i-5a12b233	ami-c6c622af			pending	gettingstarted-keypair	0		m1.small	2008-09-25T11:23:01+0000	us-east-1c $ ec2-describe-instances RESERVATION	r-eb22f182	190912652296	default INSTANCE	i-5a12b233	ami-c6c622af	ec2-72-44-53-70.compute-1.amazonaws.com	domU-12-31-39-01-5C-76.compute-1.internal	running	gettingstarted-keypair	0		m1.small	2008-09-25T11:23:01+0000	us-east-1c $ ec2-describe-volumes VOLUME	vol-4001e429	1		us-east-1c	available	2008-09-25T09:51:48+0000 $ ec2-attach-volume vol-4001e429 -i i-5a12b233 -d /dev/sdh ATTACHMENT	vol-4001e429	i-5a12b233	/dev/sdh	attaching	2008-09-25T11:25:46+0000 $ ec2-describe-volumes VOLUME	vol-4001e429	1		us-east-1c	in-use	2008-09-25T09:51:48+0000 ATTACHMENT	vol-4001e429	i-5a12b233	/dev/sdh	attached	2008-09-25T11:25:46+0000

Now start anoher terminal to connect to the instance:

$ ssh -i id_rsa-gettingstarted-keypair root@ec2-72-44-53-70.compute-1.amazonaws.com
Last login: Tue Sep  9 14:48:20 2008 from 213.49.236.209

	 __|  __|_  )  Rev: 2
	 _|  (     /
	___|\___|___|

 Welcome to an EC2 Public Image
                        

    Getting Started

    __ c __ /etc/ec2/release-notes.txt

[root@domU-12-31-39-01-5C-76 ~]# mkdir /mnt/data-store
[root@domU-12-31-39-01-5C-76 ~]# mount /dev/sdh /mnt/data-store
[root@domU-12-31-39-01-5C-76 ~]# cd /mnt/data-store
[root@domU-12-31-39-01-5C-76 data-store]# ls
lost+found  readme
[root@domU-12-31-39-01-5C-76 data-store]# cat readme
This is an example file to show that a file persists on an EBS volume after unmounting and detaching.
[root@domU-12-31-39-01-5C-76 ~]# umount /mnt/data-store
[root@domU-12-31-39-01-5C-76 ~]# exit

The file we created earlier was on the volume and we could read it. This proves that we can share volumes among instances.

To clean up:

$ ec2-detach-volume vol-4001e429 -i i-5a12b233
ATTACHMENT	vol-4001e429	i-5a12b233	/dev/sdh	detaching	2008-09-25T11:25:46+0000
$ ec2-describe-volumes
VOLUME	vol-4001e429	1		us-east-1c	available	2008-09-25T09:51:48+0000
$ ec2-terminate-instances i-5a12b233
INSTANCE	i-5a12b233	running	shutting-down
$ ec2-describe-instances
RESERVATION	r-eb22f182	190912652296	default
INSTANCE	i-5a12b233	ami-c6c622af	ec2-72-44-53-70.compute-1.amazonaws.com	domU-12-31-39-01-5C-76.compute-1.internal	shutting-down	gettingstarted-keypair	0		m1.small	2008-09-25T11:23:01+0000	us-east-1c
$ ec2-describe-instances
RESERVATION	r-eb22f182	190912652296	default
INSTANCE	i-5a12b233	ami-c6c622af			terminated	gettingstarted-keypair	0		m1.small	2008-09-25T11:23:01+0000

Of course, you do not want to set the environment variables every time you want to use the EC2 tools. I added the lines below to ~/.bash_login on my Mac, so that the environment variables are set everytime I open a terminal. I installed the tools in ~/AWS/ec2-api-tools-1.3-24159 and the private access key file and the certificate file reside in ~/.ec2.

export EC2_PRIVATE_KEY=~/.ec2/pk-<some id here>.pem
export EC2_CERT=~/.ec2/cert-<some id here>.pem
export EC2_HOME=~/AWS/ec2-api-tools-1.3-24159
export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Home
export PATH=$PATH:$EC2_HOME/bin

Setting Up an AWS Account and the EC2 Tools

I filled in the registration form to request a new AWS account. Then I followed the excellent Getting Started Guide. It explains how to set up an account, how to install the EC2 tools, how to run an instance, and how to create your own image starting from an existing one. I immediately felt the power to EC2.

The AWS Service Health Dashboard shows the status of AWS. It even shows the status history of about 1 month.

The account activity (you need an AWS account to see this page) shows the costs involved with AWS usage.

Installing Useful FireFox Plug-Ins

Although the EC2 tools provide everything you need to manage images, instances, and other EC2 resources, it is easier to have a nice management GUI.

Elasticfox is a FireFox plug-in for interacting with EC2, the Elasic Compute Cloud. When installed, it is available from the Tools menu. The plug-in opens in a web page and shows the avalaible machne images (AMIs) and your instances. Running an instance is as simle as selecting an AMI and pressing the “Launch Instance(s)” button. The list of public images is long. Elasticfox allows to filter the list.

The running instances show up in the “Your Instances” list. For each running instance, the public DNS name is shown, so that you can use that to connect to the instance through SSH, HTTP or other means. In the “Your Instances” list you can terminate instances when they are no longer necessary. Terminated instances are kept in the list until about one hour after termination.

S3Fox Organizer for Amazon enables access to Amazon S3 (Simple Storage Service). It shows the contents of your buckets on S3 and you can download and upload files. Simply entering you account ID, the access key and the secret key, and you are ready to roll.

Installing Desktop Access to Instances

When you want to use a desktop image, so that you can use a GUI to manage your instances, you need software to access the desktop of the instances.

First you need a desktop image. I chose an Ubuntu GutsyDesktop AMI, which is also available as a public AMI and listed in Elasticfox. I use a Mac, so I downloaded the NX Client for Mac OSX (you can download NX Client for other operating systems from the same location). In no time, I was able to manage the instance through a GUI.

I selected “ami-0757b26e” from the list in Elasticfox and pressed the “Launch Instance(s)” button. In the dialog window that appeared, I entered my key pair and pressed the “Launch” button. When the instance was running, I opened a terminal and entered:

$ ssh -i /Users/Koen/ec2-keys/id_gettingstarted-keypair root@ec2-75-101-241-111.compute-1.amazonaws.com

Using the provided information, user “root” logs in automatically. Then I entered:

$ user-setup

and followed the instructions to enter a user name (I chose “koen”) and a password.

Then I started NX Client and configured it as follows:

After pressing “Login” and waiting for the connection to be setup, this was the result (I already opened the home folder before making the screen shot): the Ubuntu desktop in X11.

Cool.