Supporting Multiple Versions of Ruby on OSX 10.6.7

April 25, 2011

I wanted a clean way of upgrading the default ruby 1.8.7 installation on my new Mac OSX 10.6.7 host, and couldn’t locate a decent explanation. As a result I’ve spent surprisingly little time unpicking the dependencies and getting my shiny new ruby 1.9.x installation sorted. Here’s how I achieved that. (Please note you need to have XCode installed if you plan to build the ruby installation from source.)

Firstly it’s important to understand the landscape when considering this upgrade. Firstly, the existing 1.8.x ruby installation exists in the /System/Library/Frameworks/Ruby.framework location. Beneath that root folder is a Versions folder. Versions contained another folder called 1.8 (referring to the version of ruby contained therein) and a symlink by the name of Current, which pointed to that 1.8 folder.

Decision 1: Seemed like a good idea to place all my future versions of ruby in version-aware subfolders in this …/Ruby.framework/Versions folder.

Next thing to understand is that all of the key commands relating to using the ruby framework (e.g. ruby, gem, irb, erb, …) live in the /usr/bin folder. Each of these commands are symlinks to executable files within the current ruby framework subtree. The convention here can be seen in this example:

/usr/bin/ruby -> /System/Library/Frameworks/Ruby.framework/Versions/Current/usr/bin/ruby

Next thing to understand is that all of the key commands relating to using the ruby framework (e.g. ruby, gem, irb, erb, …) live in the /usr/bin folder. Each of these commands are symlinks to executable files within the

Decision 2: If I correctly install all my subsequent versions of ruby into this same location then it should be possible for me to simply modify the Current symlink in the …/Ruby.framework/Versions folder to set the active ruby version I wish to use. All /usr/bin dependencies can simply resolve to the correct subfolder beneath the frameworks root.

Next I downloaded the latest source distribution from somewhere, in my case I used the 1.9.2 source from here (http://www.ruby-lang.org/en/news/2010/12/25/ruby-1-9-2-p136-is-released/). After downloading and unpacking into a temporary folder, I then executed the following commands from the root of the ruby source folder structure:

  1. sudo mkdir /System/Frameworks/Library/Ruby.framework/Versions/1.9.2/usr to create the new version subtree root.
  2. ./configure –prefix=/System/Frameworks/Library/Ruby.framework/Versions/1.9.2/usr to instruct the make utility to use my new installation folder for the deployment of the newly compiled binaries.
  3. sudo make && make install to create my new subtree and binaries beneath my newly created target.
When all that is done, assuming it goes OK, you will have all the necessary ruby executables in the subfolders beneath …/1.9.2/usr location but your system will still be set to use the ‘Current’ version which in my case was the pre-installed 1.8.7 version.
Final thing to do is to re-link the …/Ruby.framework/Versions/Current link to the 1.9.2 folder. I simply executed the following from the …/Ruby.framework/Versions folder:
  1. sudo unlink Current
  2. sudo ln -s 1.9.2 Current
When I now run my ruby commands – they report the correct version of 1.9.2. When and if I decide to revert to another version I can simply modify this Current link, and that can be made even easier with some alias’s and other bash helpers.
Advertisements

VMWare Fusion XP VM Losing DNS !

October 25, 2008

I’ve been running OSX Vmware Fusion 1.x and XP SP2 & SP3 for over a year and it’s been ROCK SOLID ! I run a web-connected OSX host, and a XP VM VPN’d into a corporate network all day, every day and I have not had a single problem. Until this week…when my calm seas were interrupted…

Out of the blue I notice witin the XP SP3 VM was failing to resolve DNS queries. OK. Why? I basically ran a number of diagonstics, checked driver versions and everything checked out in terms of VM integrity.No idea. The worst kind of problem…

I checked out the net and located numerous threads deliberating over the XP “Unable to flush DNS cache” type of errors, with long and elaborate threads falling into the detail of comparing router firmware versions and other such infinate variables. Eject..Eject…

It was only when I ran the VMWare packet sniffer on the OSX host I could see that the XP VM was requesting DNS, and the resoponses from the OSX host were being dispatched. From my understanding of low level IP it appeared that all was performing as expected. However I then started thinking about reasons why UDP packets were being neglected by the XP VM’s IP stack….BINGO !

I then checked out the Windows XP Event Viewer under the Security event list, and there I see all my DNS responses (from the OS X host) arriving back at my XP VM as UDP packets, all being summarily discarded by my failed/corrupted firewall. Couple of minutes later, having run the ‘support’ utility from the firewall supplier, the flood-gates openend and UDP/DNS was back in business.

Symptoms I encountered in XP:

  1. DNS resolution (i.e. ping http://www.xyz.com) within XP VM failing but direct direct addressing worked ok (i.e. ping 123.123.123.123)
  2. nslookup in the console returned ‘no response from server’ errors in response to queries.
  3. Right-clicking on the network connection icon in XP, and executing Repair proceeded through all steps apart from the final DNS cache at which point Unable to repair connection was returned.
  4. ipconfig /registerdns failed with a non-specific error

In hindsight the symptoms all point to UDP return-path and firewall but verifying the request path with the OSX VMWare vmnet-sniffer utility (located in /Library/Application Support/VMWare Fusion folder) made this a whole lot simpler.


VMWare Fusion, OS-X and Large Files

August 19, 2008

I’ve been using VMWare Fusion running an XP Virtual Machine on my Macbook Pro for 9 months now, and it’s been rock solid. There are reasons (corporate) why I need to have a specific XP build for accessing certain business support systems hence why I’ve not made the OS-X conversion all the way. I’ve been trying to replicate my XP VM onto another external drive. The image is 40GB. Computers says NOOOOOO !

I was receiving an unhelpful Error 0 from the drag-n-drop copier in the OS-X Finder, and when I dropped to a terminal window it was copying around 4 gigabytes before complaining the file was too large….yeah…it made me wait before telling me that ! So how do I move a large file?

I checked out VMWare forums who recommended using vdisk-manager (and it’s many complicated parameters) to chunk the image into 2GB files. There was also chatter of using the VMWare Fusion advanced applications settings to set the flag to ‘break image into 2GB files’ but it turns out that option is only relevant to newly created image files.

To cut a long and painful story short, after trying many weird and wonderful options, I used the following command:

# split -b 2048m /Users/Name/Documents/Virtuals/source.vmdk /Volumes/USB Drive Name/dest

This successfully broke up my 40GB source file into a file-set, using a aa..nn suffix, in my destination like:

# ls /Volumes/USD Drive Name =>

destaa, destab, destac, destad .. destat

I was then able to move my VM onto another host and reconsitute the backup with a neat bit of ruby scripting (as an alternative to a long-winded command-line). Something along the lines of:

cmdline=’cat ‘

for suff in ‘aa’..’at’ do

cmdline << “dest#{suff} “

end

cmdline << “> source.vmdk”

system(cmdline)

This a long-running yet simple solution to something I’d been struggling with for a couple of hours, and there was no need for any external tools or complexities.

The copied VM works perfectly too…but I accept no resposibility for anyone who fluffs this approach !

Powered by Qumana