Technical stuff, mostly to remind myself when I forget in a couple of months' time.

Tuesday, 5 July 2011

Powering on Squeezebox Server remotely

Some time ago I wrote about using the Squeezebox Server remotely.  A minor detail, surprisingly overlooked in the post, was the fact that, if you want to do this, the server must be on.  This is all very well if you can leave the server on permanently.

Unfortunately, I can't.  It's a big old PC that makes a lot of noise and the associated disks (where the music is stored) have very bright lights.  And this all sits in our bedroom - unfortunately, the only room in the house left for such things now that the kids need their own rooms.

So what do I do if I have - once again - forgotten to switch it on before I left the house?  My options:

  • Send a text message to a remote device requesting boot up.  The remote device in this case is otherwise known as "C's mobile phone" and depended on her a) having it on; b) being in the house and c) being bothered.
  • Set the server to power on at set times.  I believe the BIOS supports this but I didn't look at it seriously because I wanted more manual control - and I didn't want it waking us up on the weekends (in the unlikely event that the kids hadn't already done so).
  • Use wake-on-LAN (WOL) to cause the server to boot up.
WOL it woz then!

The server's BIOS supports it, but this isn't the only configuration needed.  The OS needs to send some configuration to the network card (NIC) to put it into the right state.  This guide for Ubuntu explains what to do.  Once all set up, a simple command from another computer on the LAN sends a "magic packet" to the server's MAC address and - hey presto! - the server boots.  This was easily verified on the home LAN using the "wakeonlan" command in Ubuntu (and there are various other programs available for other OSs).

The tricky bit was doing this from a remote location.  What I want to be able to do is connect to the internet wherever I am, send a command to my home IP address (conveniently addressed via dynamic DNS) and have it just work.  However, it doesn't seem to be possible.  There's some suggestion that if you configure your router to route traffic on a nominated port (which one doesn't matter) to the LAN's broadcast address (e.g. 192.168.1.255) then this should work.  However, my router won't allow the LAN's broadcast address to be used like this.

There are also a couple of open-source router firmware packages that have built in WOL clients (DD-WRT and Tomato) but these didn't support my router and anyway I didn't fancy replacing the firmware on mine and possibly ending up with a bricked router.

So the only other possibility is to have another device in the house that is already on, ssh into that and send the WOL command from that.  It would have to be:

  • always on - since if I can't remember to switch the server on, I'm not going to remember to switch something else on;
  • no noise
  • capable of supporting ssh
  • capable of sending WOL magic packets
I don't have much hardware lying around and was at a loss as to what might fit the bill.  And then I realised - the Squeezebox Controller was just the thing!  It's the remote control for the SB Receiver (the pair being the SB Duet that I bought a couple of years ago) but it's not just a typical infrared, line of sight type device.  It's a capable device in its own right.  It runs embedded Linux (busybox), connects to the wireless network and can control multiple SB devices.  It's capable to waking up the server, it's small and silent - and it supports ssh as standard (using dropbear).  It wouldn't be a problem leaving this on - as long as it's in its cradle it stays on (when it's out it suspends after a couple of minutes).

My only concern was security.  My main server listens on a non-standard port instead of 22 and only allows public key authentication.  I followed this guide to enabling public key authentication on the Controller but try as I might I couldn't work out how to change the port or disable standard password based authentication.  So in the end I generated a very long complex password and used that (and saved it somewhere safe) because I'll never have to enter it because I'm using keys.

I set up my router to direct traffic on port 22 to the Controller, so now I can ssh in from a remote location.  And, after a bit of searching, I figured out the command to send a WOL packet - it's ether-wake.  I wrote a quick shell script on the Controller so that I didn't have to remember the server's MAC address - and we're done!

So now the server is off, just waiting for me to power it on remotely.  It's silent and dark.

Oh - and as for the dazzling blinkenlights on the USB disk drive, I discovered that the second hard disk (which acts as a backup for the first) has slightly more sophisticated power management - if the machine to which it is attached is off, it switches itself off, even though it has a separate power supply.  So I switched them round.

Of course, the right answer for this is to have a server I can leave on all the time - and I might have an answer for this soon ...


No comments:

Post a Comment

Your Host

Husband, father, pop music anorak, guitarist