Babble On

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

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).
• 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.

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

Ready? It’s:

:> filename

(i.e. colon greater-than followed by the name of the file). This can also be used to create a new, empty file.

Having recently moved from the world of Windows, and even more recently picked up a 2nd Mac, and then even more recently again donated the original Mac to a relative, I hit upon the problem of both Macs having the same name. Of course the network address of each computer was different - one had a “-2″ appended to it, which I wasn’t particularly fond of.

Anyway, as usual, this turns out to be very easy to remedy:

1. Open up System Preferences
2. Under Internet & Network, click the Sharing icon
3. At this point you can simply edit the computer name
4. Use the Edit button to make changes to the network address (if still necessary)

Et voila!