Contest Clash is an Anagram

Setup a virtual linux server in VMware Fusion

2009-10-01T10:00:00.000-07:00

Instead of worrying about getting my environment setup exactly right in Snow Leopard, I kind of gave up and decided to try and set up a linux server as a virtual machine in VMware fusion. The first time I tried to do this, it didn't work at all - I could install the system, but as far as I could tell there were no VMware tools for linux. (Or were there?) Well there are now.

First download ubuntu 9.04 desktop 32-bit as an .img. Create a new vm in Fusion, pick linux/ubuntu/etc. Point the install to your .img file. Install and wait. Once it is running, choose "Install VMware Tools" from the menu. Stuff will start happening, all of it good. At this point, you might want to get updates. One of those updates is an updated kernel. Get 'em. Once the system restarts, all the VMware Tools are broken. No problem - choose Install VMware Tools again. It will show up as a drive on the ubuntu desktop, but you'll have to install from the .tar. Open up a terminal and follow these instructions. New stuff will compile against the new headers for the new kernel - things are happening and all of it is good.

Your linux guest networking is setup as NAT by default. Leave it like this. But to access it like another machine on the network, it would be nice if it weren't DHCP and the IP address didn't change all the time. No problem. Go to System/Preferences/Network Connections. Select "Auto eth0" and click Edit. Authenticate. Go to IPv4 Settings. Change from Automatic (DHCP) to Manual. Add an Address and enter in: Address: 192.168.177.100, Netmask: 255.255.255.0, Gateway: 192.168.177.2. For DNS Servers type in 192.168.177.2. OK. You might have to disconnect and reconnect networking on the guest. You are done. The subnet 192.168.177 looks like the default for Fusion. You can check your defaults in the file (on the Mac) /Library/Application Support/VMware Fusion/vmnet8/dhcpd.conf.

To give your new 192.168.177.100 a name, edit the /etc/hosts file on your mac. Then you can ssh into it easily from the terminal on the Mac. Make sure you install sshd in the linux guest.

For an extra bonus, you can enable "headless" mode in Fusion. In a terminal (on the host mac):

defaults write com.vmware.fusion fluxCapacitor -bool YES

The next time your run fusion, the menu item "Enter Headless" will appear in the view menu. Look here for the full details.

Building psycopg2 on Snow Leopard

2009-09-25T09:58:00.000-07:00

After installing snow leopard, my development environment seemed to continue to run without fuss - postgresql8.4, postgis, geos, proj - all built from source using the standard ./configure make sudo make install sequence. Then I decided to update postgis and rebuild. OK, now we have some problems - under snow leopard, everything is built as x86_64 instead of i386. No big deal, shouldn't be a problem - just rebuild everything, right? Sure, all is still well. But now psycopg2 doesn't work at all, even after rebuilding. The problem is this - psycopg2 builds an .so file that references libpq.dylib, the interface to postgres. That .dylib file, after rebuilding postgres in snow leopard is now an x86_64 library. You can check this using the "file" command.

$ file /usr/local/pgsql/lib/libpq.5.2.dylib
libpq.5.2.dylib: Mach-O 64-bit dynamically linked shared library x86_64

When you build psycopg2 using setup.py, that .so file is built for ppc and i386, but not for x86_64. There's a warning at the end of the build telling you that architectures don't match, but you might not notice the first time around. You'll find out when trying to run django, or just importing psycopg2 from the python prompt. You'll get a stack trace for an exception and at the end it will say:

Symbol not found: _PQbackendPID.

_PQbackendPID is most certainly there in the .dylib. No really, it is, it's just that the architectures don't match up, so loading the library failed.

I found another solution for this that used a patch to the macports Portfile to create a universal binary of postgresql, but you know what? I don't want to start mucking up my system with macports when installing from source is so easy. I wanna keep it simple.

Here's how to do it:

Go to your postgresql source directory (I'm assuming you've built it once already).

$ make clean
$ CFLAGS="-arch i386" LDFLAGS="-arch i386" ./configure
$ make

Copy the libpq dylib to some temporary location and rename it:

$ cp src/interfaces/libpq/libpq.5.2.dylib ~/libpq_i386.dylib

Now go back and make the x86_64 version again:

$ make clean
$ ./configure
$ make

Now use lipo to make a dylib that has multiple architectures:

$ lipo libpq_i386.dylib src/interfaces/libpq/libpq.5.2.dylib -create -output ~/libpq.5.2.dylib

Now check it:
$ file ~/libpq.5.2.dylib

It should say:

libpq.5.2.dylib: Mach-O universal binary with 2 architectures
libpq.5.2.dylib (for architecture i386): Mach-O dynamically linked shared library i386
libpq.5.2.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64

Now copy the file to the pgsql installation.

$ sudo cp ~/libpq.5.2.dylib /usr/local/pgsql/lib/

You are done. You can now run python and import psycopg2, or run django, or whatever. It works. And you don't have to use macports.

Snow Leopard all good so far

2009-08-29T16:08:00.000-07:00

I upgraded my MacBook Pro this morning to 10.6 "snow leopard" and so far all is well. The most important feature for me was the MS Exchange support in Mail. No, I didn't want to have to install Entourage. So finally I have all my email accounts in one place. I'd say that was worth the $29.

The other pleasant thing I noticed is that I suddenly have a lot more hard drive space. I *think* I have another 10 GB now, but it might be more, like 20. I don't know for sure because I didn't check before installing. All I know is that I have more space, and that's the opposite of what everyone has come to expect from an upgrade - I assume though that a lot of it is ejecting all the code that supported the G4/G5, etc. (Is that it?)

Not so good is the built-in VPN support, which doesn't support IPSec over UDP. Needed to reinstall the CiscoVPN Client, and everything was back to normal. VMWare Fusion is working perfectly.