I wanted to use RVM for some testing with Ubuntu 10.10 last night. Not one set of instructions I found around the web would work. At the end of the day it was actually something rather simple; a path issue.

As the documentation clearly points out, you need to make a couple of modifications to your .bashrc script for things to work properly.

Here is what all the instructions say to past at the end:

[[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm" # This loads RVM into a shell session.

Here is what you really have to paste at the end:

[[ -s "$HOME/.rvm/src/rvm/scripts/rvm" ]] && . "$HOME/.rvm/src/rvm/scripts/rvm"

^^^^^ ^^^^^

Notice the path differences. I have no idea why this is the case but it is. I had the same issue on previous Ubuntu version as well though. Well, this cost me a little bit of time but once I made that change along with the other documented changes everything has been just peachy.

root@mavrvm:~# rvm --default 1.8.7

root@mavrvm:~# ruby -v

ruby 1.8.7 (2010-08-16 patchlevel 302) [x86_64-linux]

root@mavrvm:~# rvm --default 1.9.2

root@mavrvm:~# ruby -v

ruby 1.9.2p0 (2010-08-18 revision 29036) [x86_64-linux]

root@mavrvm:~#

root@mavrvm:~# rvm --default 1.8.7root@mavrvm:~# ruby -vruby 1.8.7 (2010-08-16 patchlevel 302) [x86_64-linux]root@mavrvm:~# rvm --default 1.9.2root@mavrvm:~# ruby -vruby 1.9.2p0 (2010-08-18 revision 29036) [x86_64-linux]root@mavrvm:~#

Update on 2010-10-22 16:03 by Kent Langley

Thank Wayne for catching my error and posting the info here in the comments. The reason I was having issues w/ my RVM installation on Ubuntu 10.10 is that when you install AS ROOT the path for the .bashrc is going to look like this:

[[ -s "/usr/local/rvm/scripts/rvm" ]] && . "/usr/local/rvm/scripts/rvm"

I posted the entire .bashrc contents to a github gist file if you'd like to see the whole thing. The only modifications are to fix it up for RVM.

For some time now I’ve been thinking about and reading about tools like Chef and Puppet. A couple of years ago a got a couple of small projects off the ground with Puppet for a job I was working as well. But, with the way the cloud is developing and my general belief that if you are really deploying a cloud computing application but then you find yourself logging into a server command prompt for some reason during normal operations then something has either gone wrong or you are doing something wrong.

The issue of scripted server build and configuration management is hardly new. There are numerous other resources I’m sure you can search to learn the history of configuration management tools both commercial and open source. For my part, I’ve been doing a number of experiments and have chosen to work with the Opscode Chef platform. What follows in this article are a few of the things I’ve learned along the way.

Knowing some ruby helps a LOT! Opscode chef is going to be challenging to get the hang of if you do not know the first thing about the ruby programming language. If you are in that camp, you might just want to invest a bit of time w/ a good basic ruby programming language tutorial first. A great deal of the flexibility and power of the chef tools is about being able to use ruby effectively. This is not a major barrier because you do not need to be a l33t hax0r by any means. But, it will help a great deal if you know how variables work, how to do a loop, case statements, and other basic constructs of the language.

I have been used to building and deploying things with push methods a lot in the past. With a tool like chef things are kind of turned around the other way. You need to put yourself the the shoes of the server you are trying to configure and think more about pulling data to yourself. This is essentially what happens after you bootstrap a chef configured server. It pulls a lot of data to it after it registers itself with a chef server somewhere. It then uses this data(recipes and roles) to turn itself into the server it is told it should be more or less.

Why would I bother with all this you might be thinking!? Well, assuming I have set up my environment properly, defined my roles, created the proper recipes assigned to that role, then with a command that looks a bit like the following:

knife rackspace server create 'role[serverrole]' --server-name myawesomeserver --image 49 --flavor 1

NOTE: This example uses the knife tools to interact w/ chef. Knife is a command-line utility used to interact with a Chef server directly through the RESTful API.

I can start a server (a node) running the software I want running on the rackspace cloud with the code I want on it in about 4-5 minutes. That’s 4-5 minutes from the time I hit the <enter> key on my keyboard! Race ya!

Now, if I’m building one server, this might not seem very worthwhile. But, if I am building 100 or 1000... or if I’m going to be building them and tearing them down constantly by the dozens or hundreds per day then yes, this makes ALL THE SENSE IN THE WORLD! But WAIT! It gets better.

With this command I can launch THE SAME server on a different cloud in 4-5 minutes (AWS US-East-1c in this case)

knife ec2 server create -G WebServers,default --flavor m1.small -i ami-2d4aa444 -I /Users/me/Downloads/mykey.pem -S servername -x ubuntu 'role[serverrole]' -Z us-east-1c

Just think about this for a moment. From my laptop (macbookpro in this case) I can launch a server that is exactly the same on two different cloud computing providers in well under 10 minutes without ever touching a cloud GUI like the AWS console or the Rackspace Cloud console (which would only slow me down).

Now, it wasn’t exactly trivial to set all this up so that it works. But, the fact is, it wasn’t that bad either and I learned a TON along the way.

So, this was just a little intro article. There are LOADS of great resources about chef out there. I will warn you about one other thing I learned. It’s a bit hard to search for information about this software because it’s called “chef” and it has “recipes” which means a lot of the time you’ll end up with search results from FoodTV network. I like food so I don’t mind sometimes but it can be annoying.

I've worked with Puppet in the past, love it. I'm working with Chef now, love it. I'll almost certainly be using both for projects where they are best appropriate in the future.

Have good configurating and I'm sure I'll be writing more about this in the near future.