Add a datetime form to the shownodehistory we page so that a testbed
admin can plug in a specific date, and find out what that node was
doing at the time. Changes in the backend (node_history script) to
support this. Note that the table is hard to seach for such a case,
and so need to let node_history do its thing and then port process the
records list. Unfortunately, the timestamps are unsigned ints, but
perl does not handle those properly, so had to pull in Math::BigInt to
deal with it.

On the output page, include a link to the genihistory page if a node
was part of a slice.

On the genihistory page, add a new argument, slice_uuid, to look for
the records for a specific slice.

'lifetime' structure still ambiguous.

in which it will later run. Now setting up and protogeni during the
install.

elabinelab so that it has the proper network/domain and a defs that
matches where the VMs are going.

can move them elsewhere.

	capturevm.pl pcvmxxx-yy boss

will create a directory called boss and take imagezips of all the lvms
into that directory. A slightly modified xen config is written to the
directory. The XEN VM should not be running of course, and the easiest
way to stop it (without losing the disks) is:

	/usr/local/etc/emulab/vnodesetup -jh pcvmxxx-yy

Copy the directory someplace, and then run:

	restorevm.pl boss /path/to/above/stuff

which create new LVMs and then imageunzip the contents into them. A
slightly modified xen config file is then written to /var/tmp, which
can started with "xm create /var/tmp/boss.conf".

No rocket science here, but this was the easiest way to get all the
disks we create for XEN elabinelab, and since they can pretty big, we
want to use imagezip.

Finally tracked this down to a piece of code I have looked at a thousand
times. We were allocating space for a pointer to a struct instead of for
the struct itself, so when we wrote to the second word of the struct, we
were off in the weeds somewhere.

Ideally, the kernel would be extracted from the image itself, but we live
in an imperfect world.

* Split all of the certificate stuff out of initsite into initcerts so
  that it can be run independently, and when updating the IP/domain of
  a site.

* Redo initsite in terms of libinstall. Fully automated now, no user
  intervention needed.

* Regarding above statement, the new site no longer has to email the
  new CA certificate to us; a new web page is exported from the
  clearing house website that allows a new CA to be "provisionally"
  accepted; the new CA will be allowed to register their new protogeni
  certificates, but otherwise will have no access to anything else
  until someone at the ClearingHouse moves them from the unapproved to
  the approved column. 

* New script called "cacontrol" that should be used from now on to
  manage the CA certificates. Also called from the web interface to
  provisionally install a new CA certificate into an "unapproved"
  bundle that is not distributed to other protogeni sites. Otherwise,
  cacontrol should be used as follows:

	boss$ perl cacontrol -h
	Usage: cacontrol [-a] [-n] [-d] <certfile>
	       cacontrol [-n] [-d] -c <commonname>
	       cacontrol [-n] [-d] -r <commonname>
	Options
	  -n     - Impotent mode; do not do anything for real
	  -d     - Turn on debugging.
	  -a     - Add certificate to approved list instead.
	  -c     - Move certificate (commonname) to approved list.
	  -r     - Remove certificate with given commonname.

  In the first form, add a new CA certificate to the unapproved list
  (this is the entrypoint used by the web page mentioned above). If
  you add the -a option, it goes right into the approved bundle
  (approved means it goes into the xmlsec directory and is exported to
  other sites).

  The second form is used to move a CA from the unapproved column to
  the approved colum.

  The third form is used to delete a CA certificate.

  NO MORE HAND EDITING OF THE FILES!

* Split up boss/ops/fs install into indvidual modules; generally, what
  was a toplevel phase in the original files is not a file. This
  allowed for better code/variable reuse. No longer monolithic, which
  makes it easy to test and rerun parts.

* Incorporate "update" into the install process. Certain phase file
  can be used in update mode, as when the IP/subnet/domain changes.

* Moved the MFS setup from rc.mkelab into the normal install process.
  Users no longer have to do this themselves. Good thing.

* installvars.pm is a new library that has the merged set of the
  zillion variables that were at the top of boss/fs/ops install.

automatically record a new CA certificate. Hand the certificate off
to cacontrol, which will provisionally accept the certificate so that
the caller can then register their other certificates.

have been approved. Only used by the Clearinghouse to control who gets
a credential to access the Clearinghouse. This is part of the changes
to fully automate the installation of new ProtoGENI sites.

geni_cas table. If the issuer (CA) is not in the table, this is a new
registration and the credential is given the specific privilege
'register_authority' which allows the new site to do only one thing;
register their new certificates at the clearing house.