Babble On

I’ve got 10 Dropbox beta invites up for grabs - let me know if you want one!

For those that aren’t in the know, Dropbox is the much talked about file storage/sharing/syncing solution backed by Amazon S3.  I’ve only had an account for a couple of hours, but so far it’s looking very promising…

The following will generate a dummy 500 MB file named ‘outputdata’ in no time whatsoever:

dd if=/dev/zero of=outputdata bs=500M count=1

Until Amazon release a Fedora 9 AMI for EC2, you have three choices as far as getting a Fedora 9 instance goes:

1. Build yourself one from scratch
2. Fine one that somebody else has built and made available to the public
3. Upgrade one of the existing Amazon Fedora 8 images

Maybe building an AMI from scratch is a bit more effort than you were hoping to expend today? And perhaps using an untrusted 3rd party AMI will leave you feeling a little uneasy about your security?

Assuming you trust Amazon to some extent (and if you don’t, perhaps EC2 isn’t your best bet), how do you go about upgrading a Fedora 8 image?

Thankfully, the answer is fairly simple. First, boot a suitable Fedora 8 image, then follow the instructions kindly provided by Carson McDonald on ioncannon.net - which, incidentally, is an invaluable resource for Fedora upgrades of all kinds. Before you know it, you’ll be up-and-running with Fedora 9 on EC2!

Update: the above works fine with a 32-bit AMI. If working with a 64-bit AMI, you’ll need to run the following before using rpm to install the new release:

rpm -e --nodeps curl.x86_64 curl.i386

Babble On is now running on a single Amazon EC2 ’small’ instance, along with all my other websites. It’s taken a couple of weeks to get it right, but it’s been very interesting working out how to get the best from EC2.

Since EC2 was originally launched, there have been several obstacles in the way of using it for traditional web hosting and as a replacement for a shared server or virtual private server (VPS). For my purposes, there were always three main issues putting me off getting up and moving from my comfy VPS:

• Lack of static IP address
• Lack of persistent file system storage
• Uncertainty as to whether emails sent from the server will be flagged as spam

Elastic IPs, which have now been around for a few months, completely solve the problem of not having a static IP address. Having been an avid follower of the latest AWS developments, it was the announcement of Elastic IPs in particular that started me thinking about moving my hosting to EC2.

For my purposes, I don’t really see persistence as an issue. As long as you can live with a minor amount of data loss (which I can as none of my sites are critical) then regular backups to S3 are painless and cheap and go a long way to mitigating any problems. If it really bothers you then hang on a few months for Amazon’s new persistent storage volumes, which are probably exactly what you are looking for.

Emails I have discussed previously. For now, I will observe with keen interest.

On the whole the move has been a very positive and interesting experience. I now get 1.7 GB RAM as opposed to 512 MB for only 2/3 the price. And the persistence ‘issue’ really forced me to get my backup/restore solution working as well as it could. Backups are kicked-off automatically by cron and dumped on S3 - and my restore script provides a fully automated means of transforming any instance of my AMI into a running clone of the original machine - right down to the point where the services get switched on and started up.

The best thing about EC2 is that upgrading my web server becomes trivial, risk-free and inexpensive. I just fire up another AMI instance, run my restore script and within ten minutes I have an identical server to work on - without any danger of bringing down my live sites or interfering with my live environment at all. Should I then want to replace the original server, it’s just a case of re-assigning the Elastic IP and within two minutes the new system is live. Who said that EC2 wasn’t suitable for traditional web hosting? Perhaps it’s time to stop thinking about things the traditional way.

Mac OS X 10.5.3 is now available on auto update. I am about to reboot and install, but before I do will cross my fingers and hope that between this and the recent Office 2008 service pack, the annoying issue with Spaces and Office is now resolved.  Let’s find out…

…

…

…that’ll be a resounding NO then. It just doesn’t work - especially if you have multiple Office windows open (for example, Word in addition to its Formatting Pane). As you move from Space to Space, windows jump around all over the place, either apparently following you or running away from you, resulting in a pretty dismal experience.

Also, Spaces in general doesn’t seem particularly polished to me. When I leave one Space for another, do a bit of work and then head back to my original Space, I want it laid out exactly as it was when I left it. This is quite often not the case, however: if, say, I have Finder windows open on multiple Spaces, clicking any of them will bring them all to the foreground - even those on the other Spaces. I also encountered other minor niggles whereby certain dialog boxes (if that’s what they’re called in the Mac world) would vanish behind other windows after a simple flick between Spaces with no other interaction with the OS.

So it seems that Spaces still cause more problems than they solve for Office 2008 users, and perhaps have a few issues that need ironing out in any case, which is why I am leaving them disabled until a glorious future date.

A quick search of the web reveals that Amazon’s EC2 is perhaps not a great choice for a host when it comes to sending emails. Workarounds exist - using a 3rd party forwarding service, for example (see Paul Dowman’s blog for a good discussion) - but what do you do if you have to send emails from your EC2 instances? What can you do to give your email the best chance of getting delivered?

Here are some ideas that should help things a little:

• Make use of Elastic IPs: assign a static IP address to your instance.
• Check that your IP address is not blacklisted (a quick Google search reveals several tools).
• Point a DNS ‘A’ record at your static IP address, or a ‘CNAME’ record at your instance’s external DNS name (Amazon recommend the latter).
• Assign a hostname to the server that matches an actual DNS record that’s pointing at it. The default EC2 hostnames have embedded IP addresses that spam-prevention systems may be wary of. Actually, it’s probably worth adding the hostname to /etc/hosts too (use the private IP for this), and on Fedora at least, you probably want to set the hostname in /etc/sysconfig/network so that it persists across reboots.
• Make sure you are sending emails with a From: address matching the domain in question, or any domain that actually has records pointing at the machine if you are hosting multiple.
• Create an SPF record for your domain that authorizes your EC2 instance to send email.
• If necessary, be sure to tell your MTA to trust the applications you are using to send email - e.g. mongrel and apache. With sendmail you can do this by adding the users that these applications run as to the file /etc/mail/trusted-users and restarting the service. Not doing this can result in the MTA leaving warnings in your mail headers.
• Finally, use some decent content in the email - the less your email looks like spam, the more chance there is of it getting past (say) a Bayesian filter.

Please respond if you have any feedback or further tips when it comes to emailing from EC2.

Here’s a simple example showing how to export the results of a MySQL query to a CSV file on disk:

SELECT some,fields,to,export
INTO OUTFILE '/tmp/sqlresult.csv' FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\n'
FROM some_table WHERE some_other_field=123;

Hopefully that’s reasonably self-explanatory. Obviously you’ll edit the SQL accordingly and replace /tmp/sqlresult.csv with the path to the file you want to create.

Having been a long time advocate of the Apache/Mongrel Rails ever since Coda Hale blessed us with it some time ago, I’ve not since paid a huge amount of attention to the alternative Rails deployment options that have come and gone. Not, that is, until the arrival of Passenger (aka mod_rails).

In my humblest of opinions, the deployment of Rails is not as straightforward as it could be. It’s always been something of a chore, and more recently has become a little overwhelming in terms of the number of software configurations available to do the job, each setup apparently faster and more scalable than the last.

PHP developers have enjoyed mod_php for many years now, and whilst not without its issue, it certainly makes for straightforward deployment of PHP applications. If Passenger lives up to its promise, Rails developers can now enjoy the same blissful roll-out of their own applications.

In the ever-useful Ruby Inside blog, Peter Cooper provides a useful collection of passenger resources that will surely help with the adoption of this upcoming technology. I’m still running Apache, Mongrel et al at the moment, but am very keen to see if Passenger can make my life easier. I’m also considering a move from VPS hosting to Amazon EC2 in the very near future, so perhaps I can kill two birds with one stone…

In order to use svn+ssh:// URLs on a port other than 22, you need to edit your subversion configuration and define a tunnel.

Open up ~/.subversion/config in your preferred editor and head to the [tunnels] section. In here you can add something along the lines of the following:

myscheme = ssh -p 12345


This will enable you to work with URLs like: svn+myscheme:// and connect to Subversion on SSH port 12345.

Of course, there are also other SSH arguments you can include, such as the username to connect with, whether to use compression, and so on.

To find the mac address of your MacBook’s wireless interface:

1. Open up Network Preferences
2. Select AirPort and click the Advanced… button
3. The mac address will then be listed as AirPort ID