Wake On LAN Project

This is the final report for devproj.inf project number 213.

The Problem

The project's aim was to give users a way of waking their machines remotely, should the machines be sleeping. Both the School and the University have for some years made efforts to encourage computers to go into a sleep state when idle. A sleeping computer can easily be woken by a touch on its keyboard or power button, but if the user is not in the same physical location as the computer a remote solution is needed: Wake On LAN.

Information Services was quick to set up a Wake On LAN system for the University, My Wake List (PDF). This works well for machines managed by IS. For machines on school-managed networks it has a couple of drawbacks:

  • It needs access to inventory data, which for school-managed machines it doesn't have.
  • Its functioning depends on the network routers being able to route the "Magic Packets" used for Wake On LAN. The IS network can do this but Linux-managed School networks, including our Informatics network, cannot.

Initial Thoughts

The first choice for this project was whether to seek to solve both of these problems, thus giving our users and computers access to My Wake List, or whether to implement a separate system. The authors of My Wake List, Kenneth MacDonald and James Jarvis, very helpfully gave me access to much of its software.

This is what seemed necessary for us:

  • A web page which allows someone to identify a particular computer and ask for it to be woken up.
  • The web page should be accessible from anywhere on the internet. (People will want to access their machines remotely from home or while travelling.)
  • The web page should be usable only by people with Informatics computer accounts. (We don't want random internet users waking our machines for fun or profit.)
  • There should be some kind of authorisation check to control whether or not a particular user should or shouldn't be allowed to wake a particular machine. Wise and mature as Informatics people generally are, this nevertheless seemed prudent. We already have that sort of control over who can['t] login to a machine.

When assessing our possible use of My Wake List, a couple of technical problems became evident:

  • Getting our computer inventory data to IS and keeping their copy of our data reliably up to date would probably depend on some arbitrary bolted-on mechanism which would in time be liable to be forgotten about and/or fail.
  • Persuading our computer network to route magic packets would not be straightforward.

In addition, several features of My Wake List seemed unnecessary for us. Being a smaller and more homogenous unit than the University as a whole, Informatics could get away with a simpler solution to that employed by IS, in several ways:

  • We could dispense with My Wake List's user-driven features such as adding or deleting arbitrary computers from the wake list, instead populating it with LCFG based on our inventory's people/machine data.
  • We could do without an indication of whether a computer was currently sleeping or not. The machine's would-be user could presumably find that out very quickly for herself.
  • Given the smaller size of our network we could manage without any clever packet routing to the correct subnet, and instead simply send magic packets to every relevant Informatics subnet simultaneously.
  • Integration with MyEd isn't a common feature of our web facilities and didn't seem necessary in this case either.
  • My Wake List sends a Magic Packet then carefully tries to detect whether the machine has woken, and if not, sends another packet, carrying on in this way for a while before giving up and printing a failure message for the user. Given our comparatively small and homogenously managed network, we could get away with a much simpler system which just sent one Magic Packet then exited, without making any effort to detect a resulting wake-up.

The Solution

We already had these:

  • Our desktop machines, both DICE and self-managed, already have their MAC addresses and hostnames recorded in our LCFG system.
  • Machine allocation data could be used to seed the "who can wake which machine" data.
  • There are network infrastructure machines which are already on every network subnet on which a machine might ever be sleeping.
  • IS (Kenny and James) could provide us with a handy pair of LCFG components (wolclient and wolconf) from the My Wake List project. These components gather the necessary inventory and authorisation data from each participating machine and pass it all via a spanning map to one machine which can use it in serving our simple wake-up web page.
  • We already had similar CGI scripts.
  • The solution would involve communication between the machine serving the web page, and the network infrastructure machines which would send out the magic packets; we already had scripts which do such communication using remctl.
  • We could use our existing Cosign authentication infrastructure to safely serve the web page on the wider internet with DICE authentication.

It was then straightforward to:

  • install wolclient into each machine's profile to populate the "wol" spanning map
  • create a virtual machine on which to run the wake.inf.ed.ac.uk web page
  • install wolconf on that machine, gathering together the data from each participating machine
  • adapt a CGI script to serve wake.inf and communicate with the network infrastructure machines using remctl
  • identify the most suitable network infrastructure machines to use
  • write a backend script for the network infrastructure machines to receive wake instructions from the wake.inf server and send out the magic packets.

Review & Rewrite

The placing of a new CGI script outside our firewall made it necessary to have a security review. Stephen Quinney performed this and came up with one main recommendation: when calling system from a perl script, the desired command line should be passed to it as a series of separate arguments, rather than as one combined string. The latter has to be parsed by a shell whereas the former can just be executed directly by perl. Since the shell command arguments can be added to by adding items to a CGI script's URL, it makes sense to avoid use of the shell wherever possible.

He also demonstrated ways in which the CGI script could be made much clearer using templates in several ways.

Another suggestion was to add profile.group data to each machine's wolclient data, and pass this through to the CGI, so that machines could be sorted by profile group. This would make the page far easier to use for those people authorised to wake many machines. Patches to add this to wolclient and wolconf were fed back to Kenneth MacDonald (LCFG bugs 511 and 512) who produced new versions of both.

Use So Far

The apache logs show just one or two uses per day, and only 33 unique users so far, so perhaps there's a need for more promotion of the Wake On LAN facility! Either that, or possibly not that many machines are routinely sleeping yet. I suggest digging for data to find out what the problem is, so we know the next step in the sleep campaign.

Time Taken

The project took in total about four weeks of effort. This was a little more than had been expected by some but seems fine to me given the amount I learned during the project (e.g. CGI programming, perl templating, remctl).

A service catalogue entry has been created.

Some Lessons Learned

  • When hunting for appropriate LCFG components for a task, remember to look outside of Informatics. Look on svn.lcfg.org or ask in the lcfg chatroom.
  • Keep it simple. Dump complication where you can.
  • Don't be afraid to re-use things we already have.
  • Use templates to massively simplify the processing of data for web pages.
  • When using the perl system call, pass separate arguments to it wherever possible.

-- ChrisCooke - 24 Jan 2012

Topic revision: r3 - 25 Jan 2012 - 16:32:00 - ChrisCooke
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies