elasticfox – Shlomo Swidler

Copying ElasticFox Tags from One Browser to Another

The ElasticFox Firefox extension allows you to tag EC2 instances, EBS volumes, EBS snapshots, Elastic IPs, and AMIs. ElasticFox’s tags are stored locally within Firefox, so if you use ElasticFox from more than one browser your tags from one browser are not visible in any other browser. In this article I demonstrate how to copy tags from one ElasticFox installation to another.

Where Are ElasticFox Tags Stored?

My article about Tagging EC2 Instances Using Security Groups shows a brief walkthrough of using ElasticFox to tag instances. Under the hood, ElasticFox stores tags in the prefs.js file within your Firefox Profile directory. But instead of poking around in there directly, take a look at Firefox’s built-in interface to these preferences. It’s the about:config screen, and you get there by typing about:config into the address bar:

Click “I’ll be careful, I promise!” Up comes the about:config screen, with all sorts of interesting-looking settings. We’re interested in the ElasticFox tags only, so type ec2ui.*tag in the Filter field, and the result looks like this:

Viola! Those are the ElasticFox tags that I’ve set up.

Copying ElasticFox Tags to Another Browser Manually

You can copy ElasticFox tags from the about:config screen, via the clipboard, into a text file. First, open the about:config screen and use the Filter as described above to see the relevant settings. Create an empty text file and copy each setting (right-click on the entry and choose “Copy”) and paste it into the text file. Add each setting you want to transfer into the text file. You can email the text file to yourself (or put it on your USB key) and then use the text file to help you change the values of these settings in the target browser’s about:config screen.

Once copied setting looks like this:

ec2ui.eiptags.MyDrifts.us-east-1;({'75.101.15.8':'mydrifts.com'})
The setting’s name is ec2ui.eiptags.MyDrifts.us-east-1 and its value is ({'75.101.15.8':'mydrifts.com'}), separated from the name by a semicolon (;). For each setting you want to transfer to the target browser, select the value (after the semicolon) from the text file and copy it to the clipboard. Then, in the target browser’s about:config screen, right-click on the corresponding setting entry and choose “Modify”, and paste in the new value.

All that selecting and copying and pasting is annoying, and you might make a mistake when entering the values in the target browser. I feel your pain. There must be a better way.

Copying ElasticFox Tags to Another Browser with OPIE

OPIE is a Firefox extension that allows you to import and export preference settings. The good thing about it is that it can be used to export only some settings – and we only want to export the ElasticFox settings. Unfortunately, it does not support ElasticFox!

Please help lobby the OPIE developer to add ElasticFox support by posting in this forum thread – OPIE support would make copying ElasticFox tags (and indeed, entire ElasticFox setups) between browsers much easier.

Copying ElasticFox Tags to Another Browser with Shell Scripts

I’ve put together two shell scripts that can be used to directly export ElasticFox settings from the Firefox prefs.js file and to directly import them back in. These scripts really export and import all your ElasticFox settings, not just tags. Read on for directions on how to use these scripts, which work on Linux, Mac OS X, and Solaris, for Firefox 3.x and above.

A word of caution before you export and import via prefs.js directly: make sure Firefox is not running when you export or import. Firefox overwrites the prefs.js file upon exiting, and reads it upon starting up. In order to make sure all your ElasticFox tags (and all other settings, too) are in the export, Firefox must be closed before exporting. Likewise, in order to make sure Firefox picks up your imported settings you need to make sure it is closed before importing.

How to Export ElasticFox Settings

Here is a handy script to export ElasticFox preferences from Firefox. You can download it, or copy it from here and save it to your local machine:

#! /bin/bash

# the base name of the extension preferences
# that are to be imported
PREF_BASE=ec2ui
# ec2ui is the extension base name of ElasticFox

# backslash-escape special characters as you
# would in a regular expression
# the following command will only escape
# periods (".") but that should suffice
# for firefox extensions
ESCAPED_PREF_BASE=$(echo $PREF_BASE | sed -e "s/\./\\\\./g")

# export desired prefs
egrep "^user_pref\(\"$ESCAPED_PREF_BASE\." prefs.js

Once you save the script locally, make it executable:

chmod +x exportFirefoxPrefs.sh
The script expects to be run in the same directory as the prefs.js file, but it’s most convenient to keep this script in your home directory and create a soft-link there to the prefs.js file. On my machine, the command to make a soft-link to the prefs.js file is this:

ln -s /Users/shlomo/Library/Application\ Support/Firefox/Profiles/f0psntn6.default/prefs.js prefs.js
You’ll need to specify the location of your Firefox profile directory (instead of mine).

Remember to exit Firefox. Now you’re ready to run the export script.

./exportFirefoxPrefs.sh > savedPrefs
This will create a file called savedPrefs containing the ElasticFox settings. Move this file to the target browser’s machine, where we will import it.

How to Import ElasticFox Settings

Here is a script to import to import ElasticFox settings into Firefox. Download it, or copy it from here and save it to your local machine:

#! /bin/bash

WORKFILE=workfile.txt
OUTFILE=newPrefs.js
XFERFILE="$1"

# the base name of the extension preferences
# that are to be imported
PREF_BASE=ec2ui
# ec2ui is the extension base name of ElasticFox

if [ -z "$1" ]
then
  echo "Please provide the filename of the file containing the prefs to import."
else
# backslash-escape any  characters as you would
# in a regular expression
# this command only handles periods
# but that should suffice for firefox extensions
ESCAPED_PREF_BASE=$(echo $PREF_BASE | sed -e "s/\./\\\\./g")

# backup the existing prefs
cp prefs.js prefs.js.old

# get the file header
egrep -v "^user_pref\(" prefs.js > $OUTFILE

# add all other prefs
egrep "^user_pref\(" prefs.js | egrep -v "^user_pref\(\"$ESCAPED_PREF_BASE\." > $WORKFILE

# add desired prefs
cat $XFERFILE >> $WORKFILE

# sort all prefs into output
sort $WORKFILE >> $OUTFILE

# clean up
rm $WORKFILE

# uncomment this when you trust this script
# to replace your prefs automatically
#cp $OUTFILE prefs.js
#rm $OUTFILE
fi

After you save the script locally, make it executable:

chmod +x importFirefoxPrefs.sh
As with the export script above, the import script expects to be run in the same directory as the Firefox prefs.js file, so make a soft-link to the prefs.js file in the same directory as the script (see above).

Once you’ve made sure that Firefox is not running, you’re ready to run the import script:

./importFirefoxPrefs.sh savedPrefs
This will create a file called newPrefs.js in the same directory. newPrefs.js will contain the imported ElasticFox settings from the savedPrefs file, merged with the other already-existing Firefox settings from prefs.js. The script will also create a backup copy of prefs.js called prefs.js.old. All you need to do is to replace your Firefox’s prefs.js with newPrefs.js, as follows:

cp newPrefs.js prefs.js rm newPrefs.js
Now, restart Firefox. It should contain the ElasticFox settings from the source browser. If anything doesn’t work, simply exit Firefox and restore the previous prefs.js:

cp prefs.js.old prefs.js
Once you are confident that the script works consistently, you can uncomment the last few lines of the script and let it automatically replace Firefox’s prefs.js file by itself – then you do not need to perform that step manually.

This method of copying ElasticFox settings using shell scripts is relatively easy, but not perfect. OPIE would be a friendlier way, and would support Windows as well (so please lobby the developer to support ElasticFox). If you’re looking for your ElasticFox tags to be available via the EC2 APIs, check out my article on using security groups as a way to tag instances (but unfortunately not Elastic IPs, EBS volumes and snapshots, or AMIs).

Tagging EC2 Instances Using Security Groups

Update September 2010: AWS has added support for tagging instances, volumes, snapshots, and many other EC2 resource types via the API and the AWS Management Console. The techniques described here are no longer necessary.

So you have a bunch of instances running in Amazon EC2 and you want to be able to tell them apart easily. The way to do this is to “tag” each instance with a descriptive tag, such as “database”, “web server”, “memcached”, etc. The easy, human-friendly way to tag your instances is to use ElasticFox, and the robust, programming-friendly way is to use Security Groups.

Tagging Instances in ElasticFox

The ElasticFox Firefox extension is a great UI for managing your EC2 resources. ElasticFox supports adding tags for instances (as well as tagging EBS volumes, AMIs, and Elastic IPs). These tags are stored in internal Firefox preferences.

Let’s tag an instance in ElasticFox:

1. Here is the ElasticFox extension. Note how it shows that I am running one EC2 instance.
Notice the “Tag” column, which is empty.

2. Right-click on the entry for the instance we want to tag:
Now, add the tag in the dialog that pops up:
And the result:

Tagging instances in ElasticFox is great if you are the only person managing EC2 instances, and if you only use ElasticFox from a single machine. Because the tags are stored in your local browser, they are only visible to you. But, if you need your tags to be visible to other people, or on multiple browsers/computers, tagging in ElasticFox will not help because the tags are not stored in the cloud, only in the local browser. Other browsers / users / computers will not see the tags that you supply using ElasticFox. And, if you need programmatic access (via the EC2 API or command-line tools) to the tags, ElasticFox tags will not help.

Update 15 July 2009: Check out my article about how to copy ElasticFox settings (including tags) between browsers.

Tagging Instances Using Security Groups

Amazon Security Groups can also be used as a tagging mechanism for EC2 instances. The basic idea is to create a custom security group named, for example, “#database” or “#web server”, and launch the instance(s) in that custom security group in addition to the other security groups you want. The custom security group is defined without any permissions so it will have no effect on any instances in the group. This works without affecting the “real” security because the effective security permissions for an instance are the union (the sum) of all the permissions on the security groups the instance belongs to, and the “tag” security group grants zero permissions: x + 0 = x.

Using security groups to tag instances is slightly more cumbersome because you must create the custom-named security group in a separate step before launching instances in it. However, tagging via security groups is a more robust solution for the following reasons:

Security groups are stored inside the cloud. When you add an instance to a security group, you do not need to “remember” anything on the client-side: you can change browsers or change computers and your assigned security groups will still be visible every time you look.
Security groups are visible via the API and the command-line tools. This mean you can write code, in bash/PHP/Java/python/etc., that reads and manipulates the instance “tags” (really security groups). In fact, if you choose a convention for naming your security groups that are really tags, you can programmatically distinguish between the “real” security group (such as “default”) and the “tag” security group. I use the prefix “# ” for naming the security groups that function as tags.

However, all this extra flexibility comes with a price: you cannot add an instance to a security group after it is running; you can only specify an instance’s security groups at launch time. If you use security groups to tag instances, your must specify all your security group tags when you launch your instance(s).

You can use ElasticFox to create tag security groups and to specify the security groups when you launch instances. There is one gotcha: when creating the tag security group, make sure you choose “I will authorize protocols for this group as needed” – this creates the group without adding any permissions.

Instead of walking through that process in ElasticFox, here is an example of using the command-line tools to manage tag security groups.

Managing Tag Security Groups from the Command-Line

To create a security group on the command-line, use the ec2-add-group command:

ec2-add-group "#web server" -d "tag web server"
Output:

GROUP #web server tag web server

This creates a security group called #web server with the description tag web server.

To launch an instance with this tag, use the ec2-run-instances command:

ec2-run-instances ami-12345678 --instance-type m1.small --key gsg-keypair --group default --group "#web server"
Output:

RESERVATION r-27e29b4e 614123456789 #web server,default INSTANCE i-031b376a ami-12345678 pending gsg-keypair 0 m1.small 2009-06-30T11:36:30+0000 us-east-1c aki-a71cf9ce ari-a51cf9cc monitoring-disabled

This launches a single instance of ami-12345678, in any availability zone in the US region (I got us-east-1c), using the gsg-keypair, and having the security groups default and #web server. In practice, you will substitute the AMI id you want to use and the name of your keypair. You may also want to add other arguments, so check out the docs or try ec2-run-instances --help for more command-line options. You can see in the output above that the security groups are default and #web server.

Once the instance starts running, you can use the ec2-describe-instances command to see all your running instances and the security groups they belong to:

ec2-describe-instances
Output:

RESERVATION r-27e29b4e 614123456789 #web server,default INSTANCE i-031b376a ami-12345678 ec2-75-101-177-214.compute-1.amazonaws.com ip-10-250-18-244.ec2.internal running gsg-keypair 0 m1.small 2009-06-30T11:36:30+0000 us-east-1c aki-a71cf9ce ari-a51cf9cc monitoring-disabled

Note the #web server security group in the output. This is the tag security group for this instance.

You can parse the output of the above command using shell utilities (awk, perl, cut, etc.) if you want to programmatically discover what instances belong to which groups.

Update 24 September 2009: AWS now supports the ability to add a long description to EBS snapshots.