… a kingdom was lost.
Fortunately, I don’t have a kingdom at stake. My tale is more like the House That Jack Built. I had to spend a little time building the tools to build the code to build the language upon which I build solutions for clients. And the path was strewn with gotchas, but I persevered. Since I’ll likely need to do it again some day, I’ll record it here in hopes I can retrace my patch, er, path.
I’ve installed Fedora 19 on my main development laptop, replacing an older Mint 12 install that had gotten too old to maintain easily. I’ve spent some time updating and configuring the machine in my spare time. With FireFox already installed, Chromium was an early addition. Thanks to syncing, these browsers retain the history and passwords of the sites I spent all day on. I moved over my ssh keys and configurations and vim configurations and installed git and the basic development setup is ready to go: most of my coding occurs on remote systems. Next came Apache and PHP in order to develop locally. Finally, I started on Ruby and Rails. Here, I took a tangent from past installs and installed rbenv rather than RVM, the Ruby Versions Manager. I have seen problems with RVM and the 2.0 version is coming along slowly. In the meantime, Bundler has come along and solved a number of problems with gems, gemsets and disk clutter, but in a different and incompatible way with RVM. I thought that this was a good opportunity to inform myself of a new tool, should I run across it on a new gig. Also, I had seen a Drew Neil videocast in his VimCasts series recently where he showed some very useful tools, but rbenv was a pre-requisite. Due to the way RVM works, rbenv can’t be installed side-by-side, so I had to remove RVM. No time like the present!
However, there’s a catch. Isn’t there always? Fedora 19 uses a version of OpenSSL which is configured differently than what used to be typical. I am no crypto expert, but I understand they disallowed some form of elliptical curve (EC) encryption. Ruby, as part of its build process, tests for that specific functionality, so builds will break on Fedora 19 (and recent Red Hat, too). There is a fix in the pipeline: https://bugs.ruby-lang.org/projects/ruby-trunk/repository/revisions/41808, which changes the behavior from requiring this specific form of encryption, which wasn’t really required, just a poorly chosen hard-coded test) and instead tests to confirm that there are some algorithms for encryption by iterating through them. So. Now, I knew there was a fix, I just had to figure out how to wedge it into my system. Thank goodness for internet search engines! Here http://philippe.bourgau.net/how-to-install-a-patched-ruby-interpreter-wit/ was a similar enough situation that I could interpret the process for my system, with different version numbers, of course, and a few tweaks. After a few false starts, I had my own custom patched versions of Ruby 2.0 and 1.9 installed a ready to go.
It may not be clear why I didn’t just install the version of Ruby that comes with Fedora 19. At the moment, that version is the same (p247) as the current version, but as a developer, I don’t want to have to count on the distribution to keep their versions up to date in order to have the most recent version on my systems. Since I’ll be deploying systems into production, and therefore exposed to potential attack from the internet, I need to have the ability to build from the latest source code and to apply patches as needed. This provides the best possible security to my clients for this app. I also need to support older versions, so having worked out the recipe for 2.0, I was able to backport the same changes into Ruby 1.9.3 and install that on the system as well. At the moment, I don’t have any need for Ruby 1.8.7, but now that I’ve worked out the build routine, I’m confident I could deploy that if needed.