hello, hellm

After a long discussion with MediaTemple tech support, I’ve learned that the version of Ruby installed on the containers (1.8.5) is different than the version of Ruby installed on the shell machine (1.8.2) accessed via SSH. On the container (which users don’t have shell access to), they get this:

# ruby -v
ruby 1.8.5 (2006-12-04 patchlevel 2) [i386-linux]

Whereas, on the shell machines, we get this:

$ ruby -v
ruby 1.8.2 (2005-04-11) [i386-linux]

That means that some command line tools will break in newer versions of Rails (< 1.2.3?) that expect Ruby 1.8.5, for example:

$ rake db:migrate
(in /home/####/containers/rails/armstrong)
rake aborted!
undefined method `formatter' for class `Logger'

Unfortunately, there’s not a way to get around this without compiling your own Ruby 1.8.5. When I have time, I will probably get around to this. In response to my trouble ticket, MediaTemple tech support says (on 4/18/07):

“We are investigating upgrading the system version and that should happen soon. I will update this ticket when I know more.”

Sooner rather than later, I should hope.

[Updated for the dv 3.5 here]

I’m currently testing a web application on a MediaTemple “dedicated virtual server” (dv). This means I need to have Subversion installed to check the current version of the application from the repository. Unfortunately, while MediaTemple installs Subversion on their (oft-derided) “grid-server” (gs), they don’t install it on the (dv).

What to do? I put in a request with MediaTemple, but after vainly waiting 24 hours for a response, I decided to use yum to install Subversion. This seems like a better idea than working with rpms; the likelihood is that I’ll need to install other packages, after all. Yum doesn’t come with the (dv), however - for reasons unknown - so the first thing we need to do is get yum (following this post) [in a comment below, Bart has updated the location of the rpms].

$ wget http://centos.mirror.vpslink.com/centos-4/4.4/os/i386/CentOS/RPMS/yum-2.4.3-1.c4.noarch.rpm

$ wget http://centos.mirror.vpslink.com/centos-4/4.5/os/i386/CentOS/RPMS/yum-2.4.3-3.el4.centos.noarch.rpm

$ wget http://mirror.centos.org/centos/4/os/i386/CentOS/RPMS/yum-2.4.3-3.el4.centos.noarch.rpm

It has dependencies, so we need get them too.

$ rpm -ivh --nodeps http://centos.mirror.vpslink.com/centos-4/4.4/os/i386/CentOS/RPMS/libxml2-python-2.6.16-6.i386.rpm http://centos.mirror.vpslink.com/centos-4/4.4/os/i386/CentOS/RPMS/python-elementtree-1.2.6-4.2.1.i386.rpm http://centos.mirror.vpslink.com/centos-4/4.4/os/i386/CentOS/RPMS/python-sqlite-1.1.7-1.2.i386.rpm http://centos.mirror.vpslink.com/centos-4/4.4/os/i386/CentOS/RPMS/rpm-python-4.3.3-18_nonptl.i386.rpm http://centos.mirror.vpslink.com/centos-4/4.4/os/i386/CentOS/RPMS/python-urlgrabber-2.9.8-2.noarch.rpm

$ rpm -ivh –nodeps http://centos.mirror.vpslink.com/centos-4/4.5/os/i386/CentOS/RPMS/libxml2-python-2.6.16-10.i386.rpm http://centos.mirror.vpslink.com/centos-4/4.5/os/i386/CentOS/RPMS/python-elementtree-1.2.6-5.el4.centos.i386.rpm http://centos.mirror.vpslink.com/centos-4/4.5/os/i386/CentOS/RPMS/python-sqlite-1.1.7-1.2.1.i386.rpm http://centos.mirror.vpslink.com/centos-4/4.5/os/i386/CentOS/RPMS/rpm-python-4.3.3-22_nonptl.i386.rpm http://centos.mirror.vpslink.com/centos-4/4.5/os/i386/CentOS/RPMS/python-urlgrabber-2.9.8-2.noarch.rpm

$ rpm -ivh –nodeps http://mirror.centos.org/centos/4/os/i386/CentOS/RPMS/libxml2-python-2.6.16-10.i386.rpm http://mirror.centos.org/centos/4/os/i386/CentOS/RPMS/python-elementtree-1.2.6-5.el4.centos.i386.rpm http://mirror.centos.org/centos/4/os/i386/CentOS/RPMS/python-sqlite-1.1.7-1.2.1.i386.rpm http://mirror.centos.org/centos/4/os/i386/CentOS/RPMS/rpm-python-4.3.3-23_nonptl.i386.rpm http://mirror.centos.org/centos/4/os/i386/CentOS/RPMS/python-urlgrabber-2.9.8-2.noarch.rpm

Now we can install yum:

$ rpm -Uvh yum-2.4.3-3.el4.centos.noarch.rpm

Check if it’s installed:

$ rpm -q yum

With yum installed successfully, we can use it to install Subversion.
$ yum install subversion

That should do it.

-

I should add that I didn’t know at first what flavor of Linux was running on MediaTemple’s (dv). I found that we were dealing with CentOS 4.4 by running:

$ cat /etc/*release /etc/*version

I’m a fan of the Mozilla application icons, and I find the Ubuntu replacements for Firefox and Thunderbird a bit disorienting. That’s why I’ve used a script to restore the Mozilla icons. I was mildly dismayed to find it didn’t work after upgrading to Edgy - that’s because “Edgy is the first version of Ubuntu that symlinks /bin/sh to /bin/dash instead of /bin/bash” (says rama001). Like it says in the first link above, use this instead:

sudo bash restore_mozilla_icons

Or change the first line of the script to:

#! /bin/bash

I’d waited this long to upgrade to Edgy because I’d heard stories about X not working after upgrade (I’m rather partial to my graphical user interface) and I’ve spent some time wrangling with ndiswrapper and Network Manager to get my laptop’s internal Broadcom adapter working with WPA encryption, so I felt sure that would break.

Good thing I decided to try this on my laptop first. First, I had no X - despite that both xserver and ati support were installed. That meant that the fixes suggested for other users, installing or reinstalling those packages, wouldn’t work. Of course, I tried anyway, but to no avail. I decided to run the reconfigure wizard for xorg, and the conf file it created let me login to X. I haven’t looked at the files to determine the actual cause, but it’s clear that Edgy found something awry in the conf that worked with Dapper.

sudo dpkg-reconfigure xserver-xorg

And my wireless was gone. The culprit, as it so often is, is ndiswrapper. I tried a few approaches, but the one that seems to have done the trick (let me know if this doesn’t work, or if there’s a better solution):

sudo apt-get install ndiswrapper-utils-1.8
sudo apt-get remove ndiswrapper-utils-1.1

I was getting an error running modprobe ndiswrapper before this approach. Afterward, it ran successfully.

sudo modprobe ndiswrapper

However, Network Manager couldn’t see my wireless card until I restarted X (restarting the Network Manager daemon and other network services wouldn’t do it). When X came back up, so did my wireless connection.
Success!