-
Leigh B Stoller authored
* 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!
99c1507e