Living in a virtual world

I have been extremely happy running Fedroa 8 on my ThinkPad T61. Dual screen works when I'm docked; wireless works around the house; all Linux, all the time. There are, unfortunately, a couple of minor hiccups.

The IT department at work is very Windows centric. The wireless is WPA2, using MSCHAP/PEAP for authentication. This should work with F8, but I can't quite get the config right. Then there's the VPN - it's this Windows only CheckPoint client. I think this is standard IPSec/IKE, so I should be able to divine out the config necessary to setup OpenSWAN. But I've yet to be successful figuring it out.

I've kept the Windows partition around for those few apps that I use that are Windows only. When I need wifi at the office, or VPN on the road, I just boot into Windows and I get it. But there's all of this Linux-y goodness on my laptop that's inaccessible; potential waiting to be tapped. And since I used LVM, not even tools that allow reading ext3 partitions work.

So what's a guy to do? I finally decided to try booting my Linux partition within VMWare, with Windows as the host OS. Things worked out much better than I expected.

For those adventurous enough to try this themselves, let me cover a few of the highlights.

Take ample backups before you begin. It's entirely possible that you could trash your Windows partition, your Linux partition, or even both. A small USB/Firewire drive and an hour or two to run the backups are all you'll need for the peace of mind that you can recover from such a dangerous undertaking.

Be sure your system boots into Linux by default. Windows is the VMware host, and with this setup, you could boot the very same partition under the VMware guest. This would wreak untold havoc, and is best avoided. Even if you configure the bootloader to prompt forever asking you to make a choice, make sure that the default choice is not the VMWare host. Besides, you only run Windows when you have to; right :-)

Be prepared to tweak your X settings. X configuration is probably the last bit of voodoo/black magic/unholy art within the usual operation of a Linux server that I know almost nothing about. (Well, that and Sendmail. Oh, yeah, and Bind. Maybe I'm not as smart as I thought...) But, as soon as you boot into VMware, X will fail to startup and you'll be staring at X's debug messages, thinking that a world of 80x24 really couldn't be all that bad. I was able to get to a not-quite-miserable place, where I can get displays to work for both native and VMware boots, with only a single line change to a config file when needed. (And a special thanks to the Gentoo guys who already did this sort of thing).

• move /etc/X11/xorg.conf to xorg.conf.bak
• restart X (init 4; init 5)
• login; run system-config-display
• configure the display as you like it, this will generate a new xorg.conf

How you proceed from here is up to you. You can have xorg.conf.vmware and xorg.conf.normal, and copy files and restart X when you switch between native boot and VMware boot. I decided to merge the files into one xorg.conf, and use a DefaultServerLayout option that I uncomment for those rare days that I boot under VMware.

Use a NAT network interface instead of a bridge. Normally, in VMware, you want your guest NIC to be bridged. However, on a laptop this is less than ideal. I'm not sure the virtual NIC will adjust as the real network adjusts. And I'm certain that it would not have access to the VPN, which is the main point of this exercise. So go with a NAT interface. You won't be able to access the virtual guest from anywhere but the VMware host, and you will have trouble with non-NAT friendly protocols. But I'm willing to bet that's less trouble than the alternative.

Disable snapshots. While the VMware snapshot facility sounds nice, it doesn't work so well when you boot directly into the virtual guest. Go ahead and turn it off in the virtual machine settings; you won't miss it.

Add a sound device. With this and fullscreen mode, you'll be asking yourself "Is it live, or is it VMware?"

I was surprise that I didn't have any more trouble than I did. I have the Windows partition mounted within Linux, but it recognized that it wasn't cleanly unmounted and refused to mount. The VMWare NIC shows up as eth1. I didn't even have to install VMware Tools for the mouse to auto-transition to and from the VMware console.

Subversion+Kerberos, without the realm!

We're using Subversion with Kerberos authentication here at work. I love having one-password-to-rule-them-all, but having the @REALM show up in the Subversion log is a bit of a pain. Today I came up with a solution.

It's very simple. I use a post-commit script to change the author revprop. The change in post-commit is quite trivial:

#
# strip Kerberos realm from svn:author
#
OLD_AUTHOR=$(svn pget svn:author file://$REPOS --revprop -r $REV)
NEW_AUTHOR=$(echo "$OLD_AUTHOR" | sed "s/$REALM//")

svn pset svn:author "$NEW_AUTHOR" file://$REPOS --revprop -r $REV

What's not so trivial is the change to pre-revprop-change. I wanted to ensure that only the change from user@REALM to just plain user was allowed.

NEW_VALUE=$(cat)

# ...

#
# Stripping Kerberos realm is allowed
#
if test "$ACTION" = M -a "$PROPNAME" = svn:author; then 
  OLD_AUTHOR=$(svnlook pget "$REPOS" svn:author --revprop -r $REV)
  echo "NEW: $NEW_VALUE"
  echo "OLD: $OLD_AUTHOR"
  ALLOWED_NEW_AUTHOR=$(echo "$OLD_AUTHOR" | sed "s/$REALM//")
  if test "$NEW_VALUE" = "$ALLOWED_NEW_AUTHOR"; then
    # allowed author change
    exit 0
  fi
  echo "svn:author $OLD_AUTHOR may only be changed to $ALLOWED_NEW_AUTHOR" >&2
  exit 1
fi