David Vollbracht

Did I inherit thothle.ca?

Google “David Vollbracht”. What domain name comes up? Right now the domain is thothle.ca. In fact, you may even be viewing this page on thothle.ca. This is quite awkward, as I do NOT own thothle.ca. I’m not even Canadian. Nonetheless, I’m writing this post right now on thothle.ca, because it seemed appropriate.

whois thothle.ca

No, I won’t post all the contact info here, but suffice to say the nameservers for thothle.ca are from mydyndns.org. My conclusion: the owner of thothcle.ca was using my Amazon elastic IP and released it. He did not, however, update his dns to reflect that the IP is no longer his. Consequently his domain now points to my website, and has become the #1 page on google when searching for my name.

Conclusion

Obviously this isn’t really Amazon’s fault. They can’t exactly follow up after every IP is released and check where it is pointing now. The best I can do is contact the domain’s owner and hope he’ll change the nameserver config to not point to the IP. Funnily enough, this kind of reminds me of the poor chap who has my old cell phone number… I can empathize now.

I’m pleased to announce that ThoughtWorks is sponsoring the first Atlanta Function Programming Users Group meeting. All the info is here at our google group page. I’ll be giving a short introduction to the Haskell programming language and then we’ll open up the floor to discussion about the group’s future. If you’re in Atlanta (or can drive there) and you’re interested in Functional Programming, this is the place for you!

I’ve moved the hosting for this blog from my old VPS into Amazon EC2. My calculations indicate this should save me around $9-$10 a month when using a single reserved m1.small instance. This is a pretty good deal since an m1.small instance has over twice as much memory and about 60% more cpu horsepower. The EC2 setup isn’t very complicated, so I’ll give you an overview right here.

I’m running a single elastic ip attached to a single running m1.small instance. I started with the public Fedora Ruby on Rails Web Starter AMI (ami-22b0534b) and lightly customized it to fit my needs. That included installing a few rubygems and mucking about in init.d and chkconfig to get the services starting the way I wanted.

The most complicated part of the setup was separating out some parts of the machine to an EBS volume for persistent storage. In particular, the mysql database needs to be on persistent storage so it is safe if the instance goes down. Also, I wanted any rails apps to be on persistent storage so I don’t have to create a new ami for every single configure change, upgrade, or deployment. All this is achieved simply by putting symlinks to the normal places where these would live in the filesystem and pointing them to the mount point for the EBS volume.

With that done and working the only remaining issue was to ensure that the EBS volume gets attached and mounted. A bit of googling confirmed that creating an init.d script was the generally accepted approach for this, and I found a workable starting point here. That solution relied on the EC2 api tools, which in turn rely on Java which I didn’t relish the idea of installing. Instead I installed the very nice amazon-ec rubygem and rewrote the mountec2vol script on top of it. Voila! Now bringing up a new instance attaches the EBS, mounts it, and then starts any services that needed the volume once it is available.

If you’re interested in the init.d script, you can get it here. It’s limited currently by having the volume id specified in the script, so you have to rebuild the ami to change the volume id. I’ll probably extract that in the future, but it’s doing what I need for now. If you find it useful, let me know!