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