43N79W.com

I recently discovered that a prominent web hosting company had a version of ruby installed and available to its users that had a well-publicized DDoS vulnerability. Simply put, any site using that copy of Ruby, to say run Rails, would also be vulnerable.

Rather than try to wait it out for an update, one thing I have opted to do on several other web hosts is to install my own Ruby installation along with gem eco-system.

If you're not familiar with how to do this, here are some instructions:

1. You will need access to gcc on your web host. If your web host does not allow you access to gcc, then you should first find out what operating system it does use, install that OS in a virtual machine, and carry out the following steps.
2. Get to a shell on your web host or virtual machine. Unpack the source code in a folder of your choosing, and change directory into this folder.
3. ./configure --prefix=/path/where/ruby/should/be/installed --disable-pthread
4. make
5. make install
6. Ruby is now installed. Edit your PATH variable so that the shell finds your copy of ruby before the system-installed version. You can verify this by yping: which ruby. It should return the path of the newly-installed ruby.
7. Ruby by itself isn't very useful, so you probably will want to install rubygems. Download an appropriate version, unpack it to a folder of your choosing, and inside that folder run: ruby setup.rb

Voila! You now have ruby and rubygems installed on your shared host (or in a virtual machine, in which case you can zip up the installed files and unpack them on your shared host). You can continue on to install all the versions of rails you need by doing gem install -v=VERSION_NUMBER rails --include-dependencies

I recently switched from using a cluster of Mongrels on my Rails staging server to using FastCGI on Apache 2 with mod_fcgid installed. One thing that bugged me is that my dispatch.fcgi file would trigger the infamous Application Error: Rails application failed to start properly if I did not hardcode the path to my Ruby interpreter in the shebang of the script (e.g., the first line of the file appearing like: #!/opt/local/bin/ruby). I prefer to use the env program (e.g., the first line of the file appearing like #!/usr/bin/env ruby) so that my scripts are (fairly) portable across platforms where interpreters are located in different locations.

Today, I tried to resolve the situation as it was causing wasted time while testing/deploying. I finally found the solution. But not without spending a considerable amount of time heading down numerous paths toward dead ends.

I realized very quickly that the problem was that the environment variables mod_fcgid had access to, specifically $PATH, were not set to what they needed to be. So I tried a number of ways to set the $PATH only to fail several times before stumbling on the solution that should have been obvious.

The solution lies in your Apache 2 configuration. You need to add the following line wherever you happen to configure your mod_fcgid installation (I happen to include a file called httpd-fcgi.conf but most people could get away with doing this in their httpd.conf):

DefaultInitEnv PATH your path goes here

In fact, you can set any environment variable that you want your FastCGI script to have access to by using this method. I've seen several people have this shebang issue while using Ruby or Python scripts with FastCGI and there have been several workarounds posted that involve rewriting the shebang for different deployment targets. But I'd rather not do that if I don't have to. This solution works if you can modify your Apache 2 configuration and means you don't have to worry about an annoying detail like the shebang but simply get on with actual development.

I had another flat tire today. Skip to the bottom if you just need information on the lug bolts BMW uses on the 2005 MINI Cooper. Or, read ahead to hear how difficult it was for me to find this information on the Internet! Anyways, as always, the tire pressure sensor indicator lit up before I knew anything was wrong. I carefully drove into a parking lot, took out the tire pressure gauge I carry in the trunk and measured 16 psi. Note to those of you who do not regularly check your tire pressures: the tire should measure 30 psi (when cool not after being driven) and it did not visibly look flat nor even low on air.

In any event, I put on the spare tire and drove the punctured tire to Canadian Tire to have it patched. As I was in a rush and needed my car, I told them I would leave while they repaired the wheel and come back later to put it on myself. But first I would need a torque wrench and an appropriate sized socket. I would also need to know the torque specifications for the lug bolts. I used Google to search for this information, but I guess I wasn't using the correct search queries, because I came up with nothing useful.

So here's the information (torque spec according to BMW Toronto's service advisor):