Tuesday, May 1, 2018

Cobalt Qube 2 / RaQ 2 Notes

I've had an old Cobalt Qube 2 in my possession since at least 2003 and I got my hands on an old Cobalt RaQ 2 sometime in 2007. These are cute ("qute"?) MIPS machines that (used to) work great as targets for my Compilers and Interpreters course. Sadly both boxes have been "out of commission" for a few years, but I recently decided that I want to run them again, the RaQ in particular. In the process I noticed that a few important pieces of Cobalt information are hard to find online these days, so this post is mostly a collection of notes for myself.

First here are two basic shots of the RaQ 2 in pretty much the state I received it in over 10 years ago. First note the lack of a cover for the power supply! You'll need to be somewhat careful working in here if you're worried about a capacitor zapping you.

Cobalt RaQ 2 Front

There is also a spot for a fan but apparently the power supply never gets hot enough because (as you can see in the next shot) that grate is actually covered by the Cobalt logo.

Cobalt RaQ 2 Back

The installed fan is incredibly tiny and in my RaQ 2 it doesn't sound particularly healthy anymore. I have not double-checked yet, but supposedly Cobalt used this SUNON fan for the RaQ 2. Sourcing an exact replacement fan has turned out to be difficult, but I've also found some ancient posts that claim that these machines don't really get hot enough to require a fan in the first place. I am leaving mine in for now, hoping that even if it fails it won't bring down the box with it.

Next topic: Failed battery. There's a CR2032 located on the main board next to the power supply. Sadly the thing has one of those dreaded sockets with an excessively tight retaining clip on top. You're supposed to "lift the clip" and then slide out the battery, but of course in the process of doing that the entire thing just "ripped off" the mainboard. To add insult to injury, a solder pad came off as well, complete with the attached copper track of course.

Socket and copper track, yikes!

Witness the complete destruction on the mainboard:

Battery connector destroyed.

The lesson here is either that I am incapable of treating a piece of history with the required tenderness or that one should just leave good enough alone. Good enough? Well it turns out that the machine works perfectly fine with an empty battery. Better yet, it works perfectly fine even with a ripped out battery. So luckily I did not actually destroy the entire machine with this horrible mistake. If I ever decide to give my Qube 2 the "same" treatment, I'll desolder the entire battery socket instead and replace it with a less insane one.

To be continued... :-)

Saturday, January 27, 2018

Unlock LUKS Remotely on Ubuntu 16.04 LTS

I reinstalled my little server at work. It had been running the same Gentoo setup since 2008 (!) but in December 2017 the Gentoo folks finally managed to produce a convoluted enough update to completely hose the darn thing. Well, not "hose" as in "disaster" of course: I got all the data off safely and I could even leave it running over the holidays while I was away in Germany. But in preparation for the Spring 2018 semester it was necessary to "start from scratch" as it were.

Upset enough with Gentoo I decided to go completely the other way and do a minimal Ubuntu 16.04 LTS install. I also used this opportunity to finally add full-disk LUKS encryption to my setup. Not that it makes much sense (the server runs 24/7 so it's basically always decrypted) but what the heck, this is how you're supposed to set up your server, right? And instead of going for ZFS or btrfs (which is what I used on my new home machine), I went "retro" one last time:

  1. Partition the disks into one "small" boot partition and one "large" data partition.
  2. Use mdadm to create a RAID-1 boot and a RAID-10 data array.
  3. Use cryptsetup to LUKS-encrypt the "huge" data RAID array.
  4. Use LVM to create swap, root, and various home volumes in the encrypted RAID.

Great! But now I had a problem. You see, every now and then we actually have a power outage. (I know it's weird, but since we're not the hospital we apparently don't get to have a redundant power grid.) I might not be around to reboot the machine manually, but students want to submit their homework assignments. And I don't like giving extensions. So what to do?

Enter the recent dropbear-initramfs package! This thing is supposed to integrate a tiny dropbear SSH server into the early root filesystem, enabling "remote unlocking" of the encrypted RAID array. And it almost works. First the easy parts:

  1. apt install dropbear-initramfs (and ignore the error message)
  2. mkdir -p /etc/initramfs-tools/root/.ssh/
  3. Put your SSH keys into /etc/initramfs-tools/root/.ssh/authorized_keys
  4. update-initramfs -u

Now when the machine boots up, it'll still ask for a passphrase on the console, but it will also start the dropbear SSH server. In theory you can ssh in as root at that point and run the unlock script, but that didn't work for me. What did work, however, is to echo the passphrase directly to the FIFO created by cryptsetup:

  1. ssh root@server
  2. echo -n passphrase >/lib/cryptsetup/passfifo
  3. exit

At this point the encrypted RAID will come up and the boot process will continue, just as if you had typed the passphrase at the console. I am positive that they'll eventually fix the scripts, but for now I am just happy that I was able to make it work.

Note that it's convenient to run dropbear SSH and the regular OpenSSH on different ports to avoid getting loads of useless warnings when connecting. It's also just good sane practice if you want to keep the number of script kiddies trying to get into your server down to a minimum. Yes, security through obscurity is bad, but it's only really bad if it's your only approach. Happy remote booting!