One thing I forgot to mention in my post about newthe is that I had a play with SATA hotswap while testing it.
I'd ordered the second drive separately, as it worked out a lot
cheaper. The main machine arrived first so I configured it up and when
the new drive arrived I pulled a spare drive caddy, screwed the drive
into it and slotted the drive into the machine. And then wondered how to
get it detected (I've memories of rescan-scsi-bus for SCSI drives). I
didn't find anything conclusive, so I had a prod around. And eventually
realised that it had Just Worked without any action on my part - the
/dev/sdb device node had been created and I could setup the new
drive and add it to the RAID array. Nice. Pulling the drive also got
detected fine - on a reinsertion it became
sdc but that's not an
issue as I have MD and LVM sitting on top so raw device nodes don't
matter so much.
This is with the
ahci driver on an Intel ICH7 chipset FWIW. And the
decision for software RAID was a conscious one; I've seen drives fail
more than once under RAID1/MD and get correctly kicked out of the array
while the machine continues running. There are too many different
interfaces to hardware RAID from what I've seen, such that you don't get
the same level of control and information reporting.
I'm worried that my Debian Planet credentials are a bit weak, so have a technical post rather than one discussing the fact I'm unemployed in 3 days, or that I'm going back to NI for a week after that to try and get the new house sorted. Oh. Wait. Ooops.
Anyway. While I still have easy datacentre access to my colo box (the.earth.li) I thought it might be a good time to think about upgrading it. The most limited resource has been disk space; it was a Dell 2550, so dual PIII-1GHz + 2GB RAM which is nice, but SCSI hotswap drive bays. So nice disk, but anything large is expensive. I think SATA has come along nicely, so was happy to change over to using that instead. As it turned out the old machine was over 5 years old (doesn't time fly!) so there's been a disk performance boost anyway from using new technology.
I ended up buying the new machine from Sentral - their website isn't great, but they're very helpful by email and Black Cat had bought machines from them in the past with no problems. It's a Core2Duo E6600 with 4GB RAM and 2 * 750GB Seagate ES SATA II drives in hot swap bays. I pondered a quad core chip and an extra drive (there are 4 bays total), but decided I didn't really need them at present and keeping power consumption down was a good idea.
Last time I upgraded the I just did a straight copy of the data over to the new disks. This time there were a couple of things that meant I didn't want to do this.
Firstly, I decided to go 64 bit. The chip can do it, I have 4GB RAM, it
seemed like a good idea. That meant a
dpkg --get-selections on the
old box followed by a
dpkg --set-selections on the new one, followed
apt-get dselect-upgrade. Is there a way I could have kept my
aptitude knowledge about auto installed packages? I did have a look,
but didn't see anything obvious.
That gave me the same packages. I also installed
ia32-libs to ease
the transition for my users who had self compiled bits. Then I had to
copy the rest of the data over.
/home was easy enough, plus a few
other filesystems that didn't have packaged data on them. I manually
reviewed changes in
/etc but there wasn't anything non obvious
/var was trickier. I was pleased to discover that
Mailman config appears to cross
archs quite happily. A
pg_dumpall did the trick for
PostgreSQL. Rebuilding the overview
inn took all night. Maybe I should move away from
tradspool. There were a few other things to fix up (I hate Berkeley DB),
but by and large it wasn't as bad as it could have been.
Oh, except that copying that much data across takes a long time. And
rsync isn't that much help when the data includes lots of mail
folders, some of which are over 1G big (and receiving mail, so
constantly changing). I'd started out with a 100M link between the old
and new machines, as I hit the e1000
Tx Unit Hang
bug. Disabling the power management solved that, giving a 1G link. Still
The second major change with the new box is I've decided to go Xen. That
should let me hand out machine slices to users who want to do weird
stuff, without me really having to support them. And allow me to throw
up test machines when I need to. This was actually really easy to
install. I did a basic etch install onto a 2G partition, installed
xen-linux-system-2.6.18-4-xen-amd64 and then rebooted and had a dom0
up and running. I gave the main VDS (ie replacement the) a 600G
partition, access to both processor cores and 2G of RAM - ie still quite
a few more resources than it used to have. Then it got a bit tricky. I
wanted lvm to be available within the VDS. So I did all the VG creation
and a base install (using debootstrap) from the dom0, then added a
/etc/lvm/lvm.conf to exclude
/dev/md2 (the 600G
partition). And tried to boot the domU. Which was fine, until it tried
to mount the root fs at which point the initramfs complained it couldn't
/ and bombed out to a shell. The confusing bit was that doing
vgcreate -a y found and brought up the lvm partitions fine, at which
point the rest of the boot process would complete. Very odd. Much
digging eventually led me to discover that the LVM initramfs script only
gets run if the specified root partition has a
- in it. Argh! I
prefer the format
/dev/<vgname>/<lvname>, but once I
/dev/mapper/<vgname>-<lvname> it all worked fine.
The new machine has been in service for the past week and so far it all seems fine. I don't notice the fact it's a Xen instance and it still feels quite nippy. Plus the extra disk space is great as I don't have to worry so much about things getting full. Yet. I haven't noticed a change with the 64 bit side either, but I think on a server that's going to be much more the case - I haven't moved my desktop to 64 bit primarily due to the lack of Flash and Java plugins (I don't see the point of a chroot as there's not really a pressing reason to go 64 bit if it's going to be hassle). I threw up another domU instance to test out some bits and that went smoothly too (I'm using an LVM VG on the dom0 to share out to the other domUs, which will all have a less complicated setup than the main one). So all in all I'm pleased with both the hardware, and the software - I hadn't expected setting it up to be so easy. My last Xen experience was under sarge where it hadn't all been integrated in the same way as it is under etch.
Oh, one other thing I did; I rebuilt the AMD64 netinst Etch CD to output
to the serial console for both
isolinux and the actual installer. And
then did the install over the serial console, even though the machine
was beside me. The CD is still in the machine which means that I have a
fallback if it all falls over horribly - I can access the BIOS, tell the
machine to boot from CD and then hopefully prod and see what the issue
is. Or even do a complete reinstall if necessary. It was surprising easy
to modify - I just had to edit
isolinux/isolinux.cfg and add
SERIAL 0 9600 at the start and then
console=ttyS0,9600 cdrom-detect/eject=false to the
for kernel parameters. Definitely worth considering if you have a colo
box properly serial consoled up.
Following many months of faff, today Katherine and I completed on a house in Castlerock. I say Katherine and I, but really I did very little. She started looking after she’d started at UU, before we knew Black Cat was going to be sold. My sole involvement was to be dragged round a few places (including this one) when I was back in April.
The initial plan was that Norwich would remain our “home” and this would be somewhere that Katherine would be able to live during term time, that I could also work from now and then. Given recent events it’ll no doubt become “home” and we’ll leave Norwich. To that end I’ve been looking at the job market back in NI. I’ve found (and applied for) a few things in Belfast, all software development roles. I may even have an interview; had a phone call today that felt very much like a phone interview and ended with talk of getting a formal interview sorted for when I’m next over.
All scary stuff. Belfast is a bit far for a commute, so I may end up living there during the week. Or I might not get anything in NI and have to look further afield. Anyone know anything going in Derry? That may be a more managable daily journey.
Further prodding with my Logik IR100 has revealed that not only does it
already have (afaict undocumented) Ogg support, it also has IPv6 support
enabled, meaning that when I plug it into my normal wireless segment it
suddenly gains a real IPv6 address, thanks to
radvd. Of course, this
is absolutely useless at present, but it's pretty cool.
The Ogg support is more useful; I've now installed samba on my music holding machine and the Logik quite happily scans the share and plays the tunes in the kitchen. Now to see if it passes the Katherine usability test...
For a while now I've wanted a standalone internet radio; something that only required power and had wifi and would then stream audio from my desktop machine. A bit like the Slim Squeezebox but without the need to plug it into a HiFi setup. I'd found the range of devices based on the Reciva Barracuda module, but they all seemed a bit too expensive to impulse buy. Currys are now doing the Logik IR100, which uses this module, for Â£49.99, at which point I decided it was worth a look.
I'd already done some investigation about the module. It runs Linux, Reciva do the Right Thing and make their code available, and it can have its firmware upgraded. There used to be a wiki of info, but it's disappeared recently. Richard Kalton has a blog of his progress - he's got a shell, but doesn't seem to have found any serial console pinouts and seems to have gained the info required to get a shell (which he doesn't disclose) from reading the flash off the board itself. 'bill888' also has a general Logik IR100 page.
The radio itself seems quite consumer friendly. You plug it in, press the on button and tell it to search for networks. It then shows a list of ESSIDs which you can select from. It'll let you enter a WEP/WPA key if necessary, but I setup an unencrypted wireless network for testing. It then downloads a station list and you can chose what you want to listen to. Seems to do exactly what it says on the box.
It doesn't support Oggs though. And all my music is Ogged. So I want in. As a first approach I'm trying not to take it apart - it doesn't seem like anyone's got serial access, or confirmed JTAG as working, so there doesn't seem to be anything to be gained by opening it up yet. So I decided to watch network traffic, in particular what it does when you ask it to check for new firmware.
The initial request is for:
http://copper.reciva.com/cgi-bin/service-pack.pl?serial=<serialno>;sp=<current service pack>&hw=<hardware id>&sv=<serial firmware>&check=1
This then sends a redirect to:
reciva:// is an encrypted custom protocol it seems, that passes
the serial number to the server, which then returns a challenge, which
the device then hashes up and generates a session key, passes back to
the server and asks for the file. You can see this in
the curl tarball on the Reciva GPL site. Unfortunately there are bits
missing - several files (
sernum.c) and it appears to want to talk to some sort of sernum
daemon. As such I haven't been able to get a copy of the firmware
upgrade tarball. :(
However, if I could get one and have a look to see the format (is it a
full file system image, or just changed files? Is it relative or
absolute paths?) then I think it should be possible to build a new
firmware image, hijack the connections to copper.reciva.com on my local
network, and redirect to a
http:// URL rather than a
URL, thus avoiding having to do the encryption stuff. Assuming, of
course, that the upgrade isn't itself signed or encrypted. More prodding
subscribe via RSS