* 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.

sliverstatus. Change CM name from keys to users.

No more 768MB limit for memory.
Use FreeBSD 9 kernel if available, it is more stable with Xen.

This reverts commit f352b4d5.

the CM; we return the entire set of logins (keys) that were included
when the sliver was created. Format looks like:

	keys => [{'urn'   => $urn.
	          'login' => $login,
		  'keys'  => [...] },
		 {'urn'   => $urn.
	          'login' => $login,
		  'keys'  => [...] }];

This is *not* integrated with the AM yet.

that list.

1. Change default slice expiration to a new site variable called
   protogeni/default_slice_lifetime, defaults to six hours.

2. Add a site variable (protogeni/warn_short_slices) to tell the
   sa_daemon if it should send email to war about short lived slices
   expiring, defaults to off.

confuses the user.