Vagrant and chef-solo are a great pair of tools for automating your cloud deployments. provides several Ubuntu images which come pre-baked with Ruby + Chef, and they can save you even more time. However, Vagrant images won’t help you when it comes time to deploy onto a cloud provider such as AWS or DigitalOcean. I am a curious fellow, so instead I chose to go with a bare version of the OS and a bootstrapping script.

Now, I haven’t migrated all of my legacy projects to Ruby 2.x yet, so I begin by installing Ruby 1.9.3. And Ruby versioning is what the rvm toolkit is all about.

Ruby Built from Source

With the rvm toolkit in place, installing your Ruby is as easy as:

% rvm install ruby-1.9.3 --autolibs=enable --auto-dotfiles

Hooray! The only drawback – is that it compiles from source.

If this is your intention, I highly recommend the two --auto* flags above; rvm does all the hard dependency work for you. But let’s say that after your Nth from-scratch deployment, you get sick of waiting for Ruby to compile. And, like me, you are as equally stubborn as you are curious, and you choose to make your bootstrap efficient (instead of going with a pre-baked Chef image).

Wouldn’t it be nice to install a pre-built binary version? Joy of joys, rvm can do that! In my case, Ubuntu consistently comes back with a uname -m of “i686”, and I couldn’t find any ready-to-use binaries via rvm list remote, etc. So I exported my own built-from-source binary by following these helpful directions.

I’ve provided some ENV vars below which are convenient for a shell script like mine which can either

  • install from source and then export the binary
  • install the binary after MD5 and SHA-512 checksum validation

What I have omitted are

  • the target directory for the exported binary ($YOUR_BINARY_DIR)
  • the checksums from exported binary ($YOUR_MD5, $YOUR_SHA512)
  • your S3 Bucket name ($YOUR_BUCKET)
  • manual steps like; updating the shell script with the latest checksums, uploading the binary to S3, etc.

Ruby Installed from Binary

With these ENV vars in place,

# convenience ENV vars

The build-from-source steps go like this

# build from source
% rvm install ruby-1.9.3 --autolibs=enable --auto-dotfiles

# export $RUBY_STAMP.tar.bz2
% pushd .
% rvm prepare $RUBY_STAMP
% md5sum $RUBY_STAMP.tar.bz2 > $RUBY_STAMP.checksums
% sha512sum $RUBY_STAMP.tar.bz2 >> $RUBY_STAMP.checksums
% popd

And the install-from-binary steps go like this

# allow rvm to validate your checksum
% test "`grep "$RUBY_STAMP" $RUBY_MD5`" == "" && \
  echo "$RUBY_BINARY=$YOUR_MD5" >> $RUBY_MD5
% test "`grep "$RUBY_STAMP" $RUBY_SHA512`" == "" && \
  echo "$RUBY_BINARY=$YOUR_SHA512" >> $RUBY_SHA512

# download it from S3
% rvm mount -r $RUBY_BINARY --verify-downloads 1

Voila! So the next step in my bootstrap script is to install Chef in its own rvm gemset.

And if the following hadn’t happened, I’m not sure I could have justified a blog post on the subject:

Building native extensions.  This could take a while...
ERROR:  Error installing ffi:
ERROR: Failed to build gem native extension.

You see, when we don’t install Ruby from source, we end up missing the dev dependency packages, as posts like this one will happily remind you. Therein lies the magic of --autolibs=enable; and you must now provide your own magic.

As a side note, rvm can also download the Ruby source for you – without the build step – via rvm fetch $RUBY_STAMP. But that isn’t the real problem here.

Filling in the Gaps

Fortunately, you can do all the --autolibs steps manually – once you identify everything it does for you.

By watching the rvm install output, you can identify the package dependencies:

# install dependencies, by hand
% apt-get -y install build-essential
% apt-get -y install libreadline6-dev zlib1g-dev libssl-dev libyaml-dev # ... and plenty more

Or – even better – you can offer up thanks to the maintainers of rvm and simply run

# install dependencies, per rvm
% rvm requirements

Tremendous! So now everything’s unicorns and rainbows now, right?

Well, apparently not. There’s one more thing that --autolibs did for you; it specified the ENV variables for your C++ compiler(s). If those vars aren’t available, you’ll get a failed command execution that looks something like this:

-E -I. -I/usr/lib64/ruby/1.8/i686-linux -I. # ... and a lot more

“What the hell is this ‘-E’ thing my box is trying to run?”, you ask yourself, loudly, as you pull out your hair in ever-increasing clumps. That, my friends, is the result of a missing ENV var. I’ll spare you all the madness of delving into ruby extconf.rb & mkmf.rb & Makefile. Here’s how simple the fix is:

# compiler vars
export CC=gcc
export CXX=g++

Excelsior! Once those vars are in place, you’re off to the races.

And here’s hoping that you don’t run into additional roadblocks of your own. Because technical obstacles can be some of the most soul-sucking time-sinks in the world.