Run level, run!

17 October 2008

ec2 linux runlevels xen

Trying to debug why my init scripts weren't initing on EC2, I checked all the normal places.

The chkconfig tool reported that my services should be on at runlevel 3:

  
jboss   0:off   1:off   2:off   3:on    4:off   5:on    6:off

My /etc/inittab says I was booting to runlevel 3:

  
id:3:initdefault:

Yet the console did not show my things to be spinning. A little googling around, I found the runlevel command (I'm not a linux expert...) which explained to me I was in runlevel 4.

  
N 4

4? Really? 4? I wasn't expecting that.

Apparently this is just how EC2/Xen work. They force you up into runlevel 4.

What does 4 mean? Asking the Wikipedia, you'll see a pattern:

  • Typical linux: unused
  • Debian/Ubuntu: same as 2,3 and 5, weirdos
  • RHEL/Fedora: unused/user-definable
  • SUSE: unused/user-definable
  • Slackware/Gentoo: Same as 3, which implies graphics, even
  • Sys-V: seems to imply multi-user with graphics

I had no idea that runlevels were all over the map. I also had no idea that EC2 would disregard my inittab and make up their own ideas.

Thanks, guys. Another hour-long round of RPMing, kickstarting, and image-creation ahead of me...

Stumbling through technology

11 October 2008

ec2 java jboss puppet thincrust virtualization

It can sometimes be funny, the paths we take.

Once I'd verified that a Rails app deployed on JBoss would indeed cluster, I sat in my farmhouse, looking at my lone little Mac. Not much of a cluster to play with.

So I started looking at Amazon EC2, which is truly very nice, particularly when paired with Elasticfox.

Of course, firing up a cluster on EC2 requires a nicely-produced, ready-to-boot machine image or a lot of manual configuration on each node.

Sacha pointed me to another group within Red Hat: Thincrust.

Thincrust configures a Fedora disk image with "just enough" OS bits, and provides a way to add/update applications on it. It's a happy mixture of Kickstart, Puppet and Yum.

The goal is to make it easy to produce "appliance" images that could be flung onto machines, real or virtual. Need a Git server? Fire up the Git appliance on the cloud. Need a Drupal server? Fire one of those up. Need a JBoss server or cluster? We're working on that..

Thincrust is built upon Fedora. My Mac is not. But VMWare Fusion lets me run Fedora. So I can create Fedora-based Thincrust images. Which I'll deploy on EC2. Which is running Xen, probably on RHEL. And ultimately allowing you to run your Ruby-on-Rails applications on a Java stack.

There are times I can't remember exactly which OS, language, or virtualization environment I should be thinking in.

Elasticfox, OSX and iTerm

01 October 2008

applescript ec2 elasticfox osa osx

Elasticfox is a nice extension for managing your relationship with EC2 from within Firefox. It's XUL-based, somewhat homely and odd. But it's so much nicer than dealing with the ec2-* scripts directly and copying Amazon's wacky hash identifiers hither and thither.

But on OSX, the "ssh to this instance" button is wired up to Terminal.app. I can't stand Terminal.app. I much prefer iTerm.

So, a little AppleScript hacking, and Elasticfox now uses iTerm to connect to instances through ssh.

Instead of jamming it all into a dozen -e options on osascript, I just put it in a file, and changed my configuration.

Elasticfox configuration

And the script itself:

  
on run argv
  tell application "iTerm"
    activate
    set cmd to "ssh -i " & item 1 of argv & " " & item 2 of argv
    set myterm to the last terminal
    tell myterm
      launch session "Default Session"
      tell the last session
        write text the cmd
      end tell
    end tell
  end tell
end run