My server must be up 100% and cannot tolerate downtime, so I can compare the projected cost to reserved instance cost. Historically, the spot price has been pretty stable (so stable that one commentator called the market a flop) and almost equal to the reserved instance hourly price, without the overhead of the reserved instance one time fee. However, spot prices have been fluctuating greatly in the last few months (Q3 2011) so it is now more efficient to buy a reserved instance (especially since Heavy Utilization instances became available).

If we project the cost of running a micro spot instance in us-east-1b for an entire year, we would have to pay $621.20/yr for CPU time. Compare the Heavy Utilization reserved micro instances in the same region, which would cost $100/33 + 365*24*$0.005 = $77.13 (3 year term). Yeah. I know which one I’ll be getting.

The obvious thing to do is to go into General Settings (/wp-admin/options-general.php) and modify the “WordPress address” to add the new subdomain. For example, mine originally read https://dustin.li/word/, but now reads https://secure.dustin.li/word/. After clearing caches, the Log In link on the blog now correctly directs to the secure subdomain for login, and I am able to see the administration dashboard on the subdomain. There is a problem, however: the public site does not reflect that you are logged in! This means that your users will not be able to use any features of being logged in, and you will not see the administrative features on the public site.

There is an easy fix for this, though. In your wp-config.php file, add a line like this:

define(‘COOKIE_DOMAIN’, ‘.dustin.li’);

This tells WordPress that your cookie should be set and read in the “.dustin.li” domain, which any of the subdomains in dustin.li (including secure.dustin.li and dustin.li itself) can read. Problem solved! Huzzah!

We get a pretty good deal as US expats. In addition to controlling the world’s reserve currency (making it way cheaper for us to borrow money), many countries, including the UAE, have pegged their currency to the US dollar. This may not always be good for business, but it’s great for expats who don’t have to worry about currency fluctuations and the resulting loss from the currency spreads.

I’ve obtained some of the exchange rates of banks and money changers around here and tabulated them below. I included all the fees charged to obtain a “bottom line”: how much money do you loose on a transaction of sizes $100, $1000, $10000, and $100000. I included several methods of exporting money including wire transfers, demand drafts, and straight up cash exchange (i.e. carry your cash to the US… but don’t forget to declare it!). Note that there are two types of wire transfers offered: SHA (“shared fees”), where the intermediary banks take a random cut of the money, and OUR (“our fees”), where the receiving bank receives all the money you originally wired. OUR carries a premium of 100 AED. It is not clear to me how much intermediary banks take, but I’ve heard numbers of 50 USD, plus the possibility of a percentage taken which can be a big deal. I think OUR is the way to go if you must do a wire transfer.

The numbers indicate that the best way to go is to exchange money for cash at a good rate here in the UAE and carry it to the US, unless you’re sending amounts of well over $100k. The SHA wires appear to have comparable fees as higher quantities are transferred, but they belie the previously discussed hidden intermediary bank fees. Shop around for a good exchange rate by calling the exchanges up. Here’s a list of them in Abu Dhabi.

Happy transferring!

Update: I am now using RAKBANK’s Evantage account, which gives you 1 free international transfer each month. For OUR transfers, they charge a 30 AED fee. I have verified that all the money makes it to the destination account for OUR transfers. For SHA transfers a $25 fee was taken out at the destination by the intermediary bank (Citibank), which is much greater 30 AED. The maximum transfer amount is 100,000 AED per day. The OUR transfers are still not as inexpensive as carrying cash over, but for security and convenience I prefer wiring.

• NeoRouter 1.5.0 Client
• NeoRouter 1.5.1 Client

P.S. TUN/TAP is causing more kernel panics than it ought to (once every few days).

My Google Mail account is over 8 GB in size (thanks, attachment whores!), and includes over 70,000 conversations in my Inbox (ignoring the Archives). Unfortunately, this means that most search queries normally take 5-10 seconds, and this sucks, especially when you’re searching your email for that crucial information and your co-worker is looking at your personal email over your shoulder. I thought Mail.app or Thunderbird would be a solution to this with a local, SSD-backed index, but those programs search even more aggravatingly slowly (guys, can we fix this please?).

Enter CloudMagic, an extension for Chrome and Firefox that downloads and indexes your mail your for you. It will also index your Google Docs, Spreadsheets, and has plenty of other shiny features, but I’ll let you watch their demo video with the disturbingly generic narrator yourself. But can we trust this small company from Bangalore with our username and password? Will they misuse our data? Let’s take a look…

All Chrome extensions are distributed as .crx files, which are really just glorified .zip files with a little bit of Googley information tacked on. This lets us peruse some of the code of the extension, including the javascript and markup used to manage the extension’s basic functions. Poking around, the only interesting bit is where an innocuous-looking javascript file is downloaded from https://www.cloudmagic.com/res/2_71_Beta/php/initapp.php and used to inject a script into Gmail, Google Docs, and Google Calendar to provide a custom search box on those pages. There’s a good reason for this – if Google’s web interface changes, the company needs to be able to quickly update the script to prevent things from breaking, even if the Chrome Extension hasn’t been updated yet. Unfortunately, this is also a weakness – if the CloudMagic server ever gets compromised, replacing the script would allow an attacker to gain access our data as well. The question then becomes how much you trust CloudMagic to keep their server secure. Considering how big a target it is (thousands of Google accounts) and how small of a company it is, I’d rather play it safe and prevent the extension from loading any javascript remotely. A similar situation exists for the autoupdate mechanism, which allows the extension to update itself without any user intervention (and also passes a unique identifier to their website).

Another problem: you are required to enter your Google Account credentials into the extension preference page. This provides the extension with unlimited access to your account, and how much do you trust them with the password? Fortunately, this password appears to be stored locally only and is transmitted only over secure channels. A better alternative would be to use OAuth, wherein you give your password directly to Google, whose servers in turn provide an authentication token to the extension. The authentication token would only provide access limited to what is required by the extension.

Finally, there’s all the hidden code that’s compiled specifically for each platform via the NPAPI plugins. The Google Chrome developer page says it best:

NPAPI is a really big hammer that should only be used when no other approach will work.
Code running in an NPAPI plugin has the full permissions of the current user and is not sandboxed or shielded from malicious input by Google Chrome in any way. You should be especially cautious when processing input from untrusted sources, such as when working with content scripts or XMLHttpRequest.

There’s not much to find out or do here without the source code. However, we can look at the behavior of the extension with Little Snitch and Charles. The result: the traffic between the extension and its website appears innocuous (just the aforementioned update queries and script requests). It seems that the NPAPI plugin is doing its business entirely locally.

I should acknowledge that Chrome and all other Chrome extensions also use an autoupdate mechanism, so many of the issues pointed out here also apply to that software. However, in many cases those plugins are completely open source and reviewable, have a larger user base, have less access to my data, or I simply trust the vendors more.

Let’s recap the potential security issues:

• Remote Javascript injection
• Autoupdates
• No OAuth
• “Public” NPAPI plugins

I’ve modified the plugin to solve some of these issues, but it’s no Panacea.

Check it out: http://uaeclimbing.dustin.li/.

Hardware: MacMini4,1 (Mid-2010)
Software: Ubuntu 11.04 64-bit (Natty Narwhal)

The problem: booting with the CD gives bad graphics or a blank screen.

The solution: when booting, hold down alt. Select the “Windows” CD, not the “EFI” CD. This will get you to a blankish purple screen with a fuzzy icon of a keyboard on the bottom. Press F6 (NB: this will not work with an Apple Wireless keyboard. Use a wired keyboard). Pick a language. Press the down key to select “Install Ubuntu“. Now press F6 again, and select nomodeset by using the arrow keys and the space bar. Press escape, and the menu should close. Towards the bottom of the screen there’s a boot line and a cursor… use the arrow keys to scroll left until you’re just left of “quiet” and “splash” (actually, you can delete those words). Type “nomodeset xforcevesa“. Press enter to boot. Wait. Keep waiting. Nothing’s happening? Keep waiting. It took about 5 minutes for my Mac Mini to move on, upon which it started whirring and clicking. Hurray!

Post-install: your system won’t boot, unless you edit the boot commands at grub. Add nomodeset xforcevesa again (press ‘e’ when you’re at grub to edit a boot command). Once it boots, install the NVIDIA proprietary drivers. Edit /etc/default/grub to add nomodeset noacpi reboot=acpi in the appropriate place. Save the file, then run update-grub. Reboot. Your graphics may still suck. Run nvidia-xconfig and reboot. Are we there yet?

For a few months now I’ve been cheering on Amazon as I’ve dived further into its cloud services. It has had excellent performance, little downtime, and is extremely affordable. But on the road to work today, I was listening to my Marketplace podcast, and a discussion of the reliability of cloud services took place, specifically pointing to Amazon’s recently massive outage which hit massive sites like Reddit and FourSquare. Wait, what? There was an outage?

I have my cloud services set up to be monitored by external websites to alert me to exactly these kinds of problems. I double checked my inbox… nope, no alerts. Nothing in the RSS feeds either. Hmm… I logged into mon.itor.us, but after battling with the pretty awful user interface for half an hour, found out that history was capped at 24 hours. The event occurred 4 days ago. Great.

Then I checked Yottaa, and it showed me this:

Well that’s no good! My website was offline between 04/21/2011 03:00 and 04/22/2011 15:00; 37 hours. Oddly, it didn’t even register as an outage in Yottaa’s dashboard, nor did I get any alerts (apparently that’s not even an option)… well, Yotta’s got a beta label on their front page, so maybe it will get better. Ironically, the CSS wasn’t loading when I was using Yottaa’s site today. I seem to recall that Yottaa is hosted on Amazon’s servers…

I have a third monitoring service – Amazon CloudWatch. The last time I had an issue was when the server stopped responding due to a hardware failure. CloudWatch sent me an email that let me know with 10 minutes that the server was down, and I switched the site to a different server within an hour. Alas, no such email came for this incident… the server itself wasn’t suffering from a CPU or network fault, at least from the CloudWatch server’s perspective. In fact, it still isn’t clear what exactly went wrong… Amazon’s Service Health Dashboard has noted that it was a problem with their storage backend, but CloudWatch shows successful disk I/O on my instance throughout the incident.

This outage could have been avoided if I had any redundancy for this website (the outage only badly affected one of the four data zones located in Virginia, where my stuff happens to be; if I had had another server on Amazon’s cloud in Japan or California or Ireland I would have been fine)). But I don’t, because I’m a cheap bastard and don’t care about the Internet’s feelings.

So despite Amazon’s first major outage, I’m sticking with them. They were sufficiently transparent during the process via their status updates and will hopefully produce an interesting post-mortem. I expect that they’ll learn a lot from their mistakes, and that websites that rely on Amazon will learn to implement some redundancy (though most of the impacted sites are startups that are as frugal as I am, so maybe not).