I recently aquired a new desktop for work which came with a 17″ Philips LCD screen. Given that I work from home and I already owned a 17″ LCD the scene was set for a nice dual-head setup, or so I thought. Having two LCD monitors side by side, I wanted them both to be running on DVI. This was not to prove an easy task.

The first hurdle was finding a video card with Dual-DVI output for a reasonable price. This was made even harder by the fact that I was originally looking for a AGP card to avoid having to upgrade the entire motherboard. Eventually we gave up on this option and I ended up getting an HP dc7600 mini tower with a PCI-e slot to use for my desktop. We also ordered a Power Color card based on the Radeon X1300 chipset to satisfy the Dual-DVI requirement.

Unfortunately when the machine arrived (around the end of March) I discovered that the X1300 was not yet supported by the open source X.org drivers and, even worse, there was no support for it in the latest fglrx release from ATI either! This was sloppy checking on my part really. I’ve become so used to hardware “just working” thanks to Ubuntu that I didn’t even consider that the card might not be supported. I filed a support request with ATI asking when support for the X1300 was expected and received the standard “Linux isn’t supported, not aware of any upcoming revisions, we’ll support it when we get around to it” style response. Eventually we found an Radeon X850 based Dual-DVI PCI-e card for around twice the price of the X1300 and ordered that. I limped along with a single screen using the VESA driver until the card arrived.

Initial impressions with the X850 card were not promising. Although it is supported by the radeon driver in X.org 7.0 there seems to be a bug that prevents it from working correctly in Dual-head mode. There are numerous tickets in the X.org bugzilla and the problem appears to be solved if you use DVI+VGA, but its still broken for DVI+DVI unfortunately. Next step was to try the fglrx drivers to see if I could get Dual-head working with them. More problems! fglrx doesn’t play nicely with Xen (I run my desktop in a Xen dom0 with other testing domains (for sid, etc) in domU’s). After reverting back to the standard Ubuntu kernel (eg. no Xen) I’ve managed to get a nice Dual-DVI Dual-Head setup working with the X850.

However, in the process of installing the fglrx drivers I discovered that there had been a new release made on the 12th of April that among other changes added support for the X1300 chipset!!! Needless to say I’m not particularly impressed with the response from ATI’s helpdesk, given that only one week prior, they had disclaimed any knowledge of when support for the X1300 chipset would be available. As it turns out, its a bit of a non-issue anyway as I couldn’t make the X1300 work properly in a Dual-DVI setup. The secondary screen suffered all sorts of corruption and ghosting that I couldn’t work out how to remove. Running the second screen in VGA mode (via a DVI-VGA adaptor) was fine, but with a drop in quality due to the VGA connection.

So after several months of waiting, almost a day of configuration twiddling and the loss of Xen. I finally have a Dual-head, DVI based desktop setup. Its very nice, but the cost is certainly high. I can’t believe that Dual-DVI doesn’t seem to be widely used, am I really that fussy about my monitors?

Now that I’ve had to give up Xen, I’m trying to get VMware setup to do the job, but I’m already running in to problems there. VMware refuses to use LVM devices for raw disk access and the LD_PRELOAD solution provided by vmware-bdwrapper is not playing nicely with dapper’s multiarch setup at the moment. Hopefully with another days worth of twiddling I can get it working!

Back in January I talked about setting up some scripts to automatically load ssh/gpg keys into the appropriate agents when you plugged in a UBS key. I had quite a number of people ask me for my scripts, but they just weren’t quite ready.

I’m still not entirely happy with the solution that I’ve come up with, but I figure its working well enough to get some feedback now.

It’s based very heavily on the usb-storage script originally written by Sean Finney, so I think that means I owe him Pizza now. However while its based on the usb-storage script it has changed in a few major ways:

• Use udev rather than hotplug
• Support GPG as well as SSH keys
• Script no longer responsible for mounting partition

The mounting of the partition is the key change and I’m still tossing up whether the way I’m doing it is best or whether I should return to having it handled by the script. The primary reason for changing it was to allow the partition to be mounted in a stable location (as opposed to a random directory under /var/tmp) so that I could symlink from appropriate places in my home directory to the partition on the key.

The symlinking is needed to keep GPG happy as the gpg-agent seems to store only the passphrase and requires access to the private key whenever you need to sign/encrypt something. The way ssh-agent works is much nicer in this respect, in that once you’ve loaded a key into the agent it doesn’t need to refer to it on disk again.

Currently I’m using autofs to mount the partition as needed and this seems to be working well. It’s probably possible to go back to mounting the partition at a stable location from within the script without too much hassle.

You can grab the script from http://www.mattb.net.nz/debian/misc/manage-keys

The remaining details for my configuration are below:

First, setup udev to rename the key partitions to a static name and then fire the script at the appropriate times
/etc/udev/rules.d/usbkey.rules

ACTION=="add", KERNEL=="sd?2", SYSFS{serial}="A0494386139B005B", NAME="%k", SYMLINK="usbkeys", RUN+="/usr/local/bin/manage-keys"
ACTION=="remove", KERNEL=="sd?2", RUN+="/usr/local/bin/manage-keys"


Then setup autofs to mount the partition on demand
/etc/auto.master

/media/usb /etc/auto.usbkey --timeout=10

/etc/auto.usbkey

keys -fstype=ext3,ro,noatime,nosuid,nodev :/dev/usbkeys


I keep only id_dsa and secring.gpg on the key and symlink from the appropriate places in my homedir to /media/usb/keys/

matt@argon:~$ ls -l .ssh/
total 76
-rw------- 1 matt matt 612 2006-04-12 22:45 authorized_keys
-rw-r--r-- 1 matt matt 2694 2006-04-12 22:46 config
lrwxrwxrwx 1 matt matt 22 2006-04-13 01:08 id_dsa -> /media/usb/keys/id_dsa
-rw-r--r-- 1 matt matt 612 2006-04-12 22:46 id_dsa.pub
-rw-r--r-- 1 matt matt 58851 2006-04-12 23:10 known_hosts
matt@argon:~$ ls -l .gnupg/
total 2336
-rw-r--r-- 1 matt matt 126 2006-04-12 22:56 gpg.conf
drwx------ 2 matt matt 4096 2006-04-12 23:07 private-keys-v1.d
-rw------- 1 matt matt 1175737 2006-04-12 23:29 pubring.gpg
-rw------- 1 matt matt 600 2006-04-13 01:51 random_seed
lrwxrwxrwx 1 matt matt 27 2006-04-13 01:08 secring.gpg -> /media/usb/keys/secring.gpg
-rw------- 1 matt matt 10560 2006-04-12 23:27 trustdb.gpg


And that’s basically it. The script takes care of the rest.

The main problem I’m having with the script at the moment is that it doesn’t autolock the screen when you remove the key because gnome-screensaver-command is lacking the necessary environment variables to find the DBUS socket it needs to talk to its backend. Need to read up on DBUS/gnome-screensaver and sort out how to fix that tommorrow.

Update: Updated example udev config so it doesn’t run a script out of /home

I’ve set myself the task of porting libtrace to Windows, so that Perry and I can use it in an upcoming project that we’ve been scheming for a long time. It’s going to be a reasonably large job I think!

For a start its going to involve relearning all the MSVC oddities that I knew back when I last wrote code for Windows (over 4 years ago) and then there is all the stupid compatibility issues between various header files and type definitions to work out.

I haven’t been able to find a good document that lists all the common problems that you run into porting a GNU library to Windows which surprised me somewhat. There are plenty of documents about how to port code from Windows to Linux however. If anyone knows of some handy resources I would love to hear about them.

Cygwin/Mingw32 etc are not suitable for this project.

I think I finally have broadband Internet at home that I’m reasonably satisified with!

This afternoon, thanks to the excellent team at WorldXChange my DSL line was upgraded to 2M/512k. Despite the fact that we always want more than we can have I think this combination will actually be very useful and worthwhile for me. 2Mbps is more than adequate for the amount of downloading I do and increasing the upstream to 512k means that I can have an outgoing file transfer running without my SSH sessions locking up every few seconds. There is still a 10G international traffic cap, but I don’t do more than about 6-7GB of International traffic a month so that doesn’t bother me, and I’m really pleased that WorldXChange offer free national traffic.

There is no question that the threat of regulation has done wonders for the state of broadband in New Zealand over the last 18 months. It’s still a pretty tough market for the ISPs and Telecom’s wholesale bitstream product (UBS) is nowhere near the equivalent to unbundling that they promised it would be, however for the average consumer things are certainly a lot better they were. Which is good, because I think whatever the Government decides to do in June (assuming its not nothing) is going to set the Industry back a fair bit as everybody readjusts to the new landscape and works out where they fit. Having a semi-decent set of plans to tide us through that period is going to be great.

If you’re looking for a DSL provider I highly recommend that you use WorldXChange. I’ve not yet found an aspect of their product or service that is below par. They answer the phone on the first ring, the customer service reps are friendly, helpful and always know what they’re doing and best of all they give you free national internet traffic! So don’t delay, swap today to WorldXChange and put mkbrown down as your reference so that I get some credits on my account.