Futurechimp

I’m not much of a photographer but I couldn’t resist a snap of this situation, which we strolled past yesterday during a walk-and-talk session discussing some development issues:

As part of a series of experiments with the Rails 3 beta, I’ve started gemifying a pile of plugin code we’re using. Rails Engines in Rails 3 are completely integrated into the framework (every Rails app is now a Rails::Engine!) so there are going to be some exciting times ahead as we start building modular apps which can be distributed with versioned gem dependencies. Part of the fun will be turning plugins into gems wherever possible, so that library code can be cleanly integrated into the modular apps, and everything is quick to set up at the start of a project.

The first fruit of this is the UploadColumn gem, which is just the venerable UploadColumn Plugin wrapped up and packaged as a rubygem. It works in the same way it always has, except that you can include it in your project by doing a:

sudo gem install uploadcolumn

and then a:

config.gem 'uploadcolumn', :lib => 'upload_column'

The code is forked out on Github, dive in and start hacking on it if you are an upload_column user. The tests must be for an earlier version of RSpec (they no longer run even in the canonical JNicklas repo), we’ll have to do some cleanup work when we get a chance.

Recent changes to the email infrastructure around here have meant that those of us on Linux still have some troubles. The Exchange 2007 MAPI connector seems to work pretty well for Mac users, but Evolution’s MAPI provider plugin in Ubuntu 9.10 doesn’t work particularly well at present. It screws up calendars and inserts some strange entities (”=20”) on line breaks in emails, making us seem even geekier than we actually are.

On the upside, Evolution doesn’t freak out very often, as it did with the Exchange 2003 connector. So what happens if we try and compile the MAPI connector from source?

#!/bin/sh

#Shut down all running evolution processes
evolution --force-shutdown

# Make somewhere for the source code to live
mkdir ~/evolution
cd ~/evolution

#Download source code from gnome-evolution project page
wget http://download.gnome.org/sources/evolution-mapi/0.28/evolution-mapi-0.28.3.tar.bz2
wget http://download.gnome.org/sources/gtkhtml/3.28/gtkhtml-3.28.3.tar.bz2

#Remove evolution-MAPI package
sudo apt-get remove evolution-mapi

#Install needed dependencies for compilation
sudo apt-get install libdb-dev libnspr4-dev libnss3-dev libical-dev libsqlite3-dev
sudo apt-get install bison intltool gnome-core-devel evolution-data-server-dev 
sudo apt-get install libcanberra-gtk-dev
sudo apt-get install libgtkhtml3.8-dev network-manager-dev libunique-dev libhal-dev
sudo apt-get install libgtkimageview-dev libpst-dev libnotify-dev
sudo apt-get install libmapi-dev samba4-dev libglib2.0-dev
sudo apt-get install libebackend1.2-dev libecal1.2-dev libedataserver1.2-dev
sudo apt-get install  libedata-cal1.2-dev  libebook1.2-dev libedata-book1.2-dev
sudo apt-get install libcamel1.2-dev evolution-dev libedataserverui1.2-dev

# Compile gtkhtml
tar fxj gtkhtml-3.28.3.tar.bz2
cd gtkhtml-3.28.3
./configure && make && sudo make install
cd ..

# Compile the mapi plugin
tar fxj evolution-mapi-0.28.3.tar.bz2
cd evolution-mapi-0.28.3
./configure && make && sudo make install
cd ..

# Now you can just start evolution normally and enjoy some improvements!

Calendar invites still screw up and disappear randomly, but at least emails don’t have weird entities strewn all through them, making me feel a little better about things. Hopefully this package will get some love in the forthcoming Ubuntu 10.04! Thanks to the Ubuntu Forums people for providing partial instructions for how to compile these packages (I’ve turned that forum post into a shell script that should hopefully work for most people).

Important Note: this process only works if you’ve already got your Exchange MAPI account set up and properly configured. Installing the evolution-mapi-0.28.3 plugin breaks the UI which is used to enter your account details right at the start of the Evolution setup process, making it impossible to set up any kind of account. This somewhat sucks but I guess if you’ve already got your account set up, it won’t make much difference to you.

The shell script, ready to go, is here. If it eats your dog or provokes an existential crisis, you can back out of the changes it makes like so:

evolution --force-shutdown
cd ~/.evolution
cd evolution-mapi-0.28.3 && sudo make uninstall && cd ..  
cd gtkhtml-3.28.3  && sudo make uninstall && cd .. 
sudo apt-get install exchange-mapi

So we just got a new server machine into the office, and it’s got some major stonk so that we can move towards virtualised services in a big way. The machine is called gort, and it dominates:

As a result, we’ve got a few new file servers for specific purposes, and they’re running samba on Linux on top of Virtualbox rather than SMB on Windows. Some of them have sensitive data, which we want to protect in case of theft, so I’ve encrypted the crap out of everything using dm-crypt.

I was initially stumped as to how to make this whole setup work properly. A dm-crypt disk volume needs its encryption passphrase entered before it even begins to boot. However, the Virtualbox machine image needs to run using VBoxHeadless, without any kind of graphical interface, because we want to be able to boot the whole setup remotely via a console if a machine image goes down for some reason. It seemed like there was going to be a problem – either we could run the setup headless and not have to come into the office if a machine crashed, or have dm-crypt encryption as an anti-theft strategy, but not both.

The solution turned out to be remarkably simple.

Any Virtualbox VM image started using a command like

VBoxHeadless -startvm "FooBox"

automatically gets its own display server running something called “VRDP” (which I assume is maybe “Virtualbox Remote Desktop Protocol”). The first VM listens on port 3689 of the host server, and you need to explicitly tell any further VMs to listen on a different port, perhaps like so:

VBoxHeadless --startvm "Some Machine Image" -v on -vrdpport 5000 &

This will tell Virtualbox to start the VM called “Some Machine Image” and turn on the VRDP server on port 5000 (and the relinquish control of the terminal back to stdin due to the ampersand). Assuming that the host server has a hostname of “foo.bar.blah” on your network, you can then use your regular Remote Desktop Protocol (RDP) client to connect to the host server on port 5000. You’ll be shown the current state of the guest VM right from the moment it initially boots, allowing you to type your encryption passphrase in.

So the process basically looks like this:

dave@gort:$ VBoxHeadless --startvm "Some Machine Image" -v on -vrdpport 5000 &
[1] 8905
dave@gort:$ Sun VirtualBox Headless Interface 3.1.4
(C) 2008-2010 Sun Microsystems, Inc.
All rights reserved.

Listening on port 5000.

dave@gort:~$

At that point, the VM image has fired up and is running, but it isn’t booting, because it needs its passphrase before it can access its system files and start to boot.

So, we can connect to the host machine (don’t bother trying to connect to the guest machine yet). One very important thing to note is that VRDP only worked for me using RDPv5:

This gets us right on to the VM image’s grub screen, and then to the dm-crypt passphrase entry.

Entering the passphrase allows boot to continue normally. I’ve got to say, I’ve been pleasantly surprised by easy Virtualbox has made everything. The admin tools are first-rate and convenient to use, networking has been easy to set up, and the learning curve has been low. Now I can take all the time I’ve saved and use it to mess with kvm.