Also, add undocumented -F option to quickly fix any broken hash files
(i.e., by reading hash value from the DB and not recomputing it).

This is for geniracks or for our APT setup. Includes the -N option described
in the previous commit. Also changed the makefile to install this script
under the install-genirack target.

Not particularly useful in the case of xenbridge setup inside Emulab where
we only use it for the control network. However, I had made all the changes
to this file before I realized it was the wrong version, so what the heck!

new ajax model.

node state in sliver status. Use a web task to track create image
and return status from ImageInfo.

Setting LVM_FULLDISKONLY will effectively tell it to not use extra
space on the system disk when constructing the VG used for vnode disk
creation. This can affect performace for everybody, especially if it
uses multiple little partitions on the system disk. However, this is
turned off by default since, on our d710 nodes, most of the extra
space is on the system disk. Setting this should be plumbed through
to the user somehow so they can choose.

This will prevent the image from hanging inexplicably at boot when used
external to Emulab control in a situation like, I don't know, maybe your
machine is miles away at a datacenter and you would have to go stand
around in a noisy machine room for hours to figure out what is wrong...

then scattering around. Makes the php pages a lot cleaner, and
reduces code duplication. Its an approach, lets see how it goes.

http://stackoverflow.com/questions/5213753/build-step-progress-bar-css-and-jquery

Simple, but does not really work well enough with bootstrap, it is
going to take more work if we want to use it for more then the imaging
progress modal.

which starts an image capture in the background on behalf of a user
using the APT web interface. The webtask holds the state of the image
capture as to told to us by the aggregate manager, and conferred to
the user via ajax calls which read the state of the webtask.

descriptor updated with the progress of the image capture.

1. web_tasks: This table is to track background processes that we
   start either from the web interface or from the protogeni XMLRPC
   interface. The goal is to not have a bunch of task specific stuff
   in tables, but a more general way to start a process tied to an
   object (say, like taking an image) and record state of the process
   in the descriptor (say, the image size as it grows). A client can
   poll for info about the process; the server just looks for the task
   descriptor associated with the object and returns the (currently)
   adhoc data in JSON format to the client.

   Work in progress, still determining if this general approach is
   worth it.

2. web_sessions: Playing with real PHP sessions, using the DB to store
   the session data (instead of the default, which is data files in
   /var/run). No idea how I am going to use this one, just want to
   play with sessions.

APT profile, it will not exists on the node.