A quick post to the opscode discussion forum (actually the wrong forum but jtimberman was kind enough to help out) told us that the error was the result of the outdated rubygems package. The easy solution was to simply use rubygem’s own self-updating mechanism by running gem update --system. Easy enough, however the version installed by apt doesn’t actually permit this:
ERROR: While executing gem ... (RuntimeError) gem update --system is disabled on Debian. RubyGems can be updated using the official Debian repositories by aptitude or apt-get.
At this point we could have introduced new apt sources to see if they contained more recent versions, but we decided we really wanted rubygems to be able to update itself. Rather than reinstall rubygems from source, we found that there was a rubygem on rubygems.org for exactly this purpose “rubygems-update”. Unfortunately for some reason, perhaps an incompatibility between rubygems 1.2.0 and rubygems.org, even after adding rubygems.org as a gem source, gem complained it was unable to find the repository online. Downloading the gem and installing it locally provided the fix for that:
Problem solved. With the new version of rubygems installed, we’re now able to run gem update —system to stay up to date.
I believe rubygems was originally installed as a dependency of the chef package in the opscode apt repo, and the rubygems version in there is 1.2.0. So it appears that this problem would always occur when bootstrapping a new debian lenny machine with chef-client using only the apt packages, so I’ll be switching to bootstrapping via the chef gems rather than using apt. I’ll pose this question to the smart folks at opscode though and see if there isn’t a simple answer to the package dependency issue.