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

not put in any of the req_altname stuff.

Takes old certificate, gets the private key from inside it,
generates a new serial number, and uses x509 to create a new
certificate. Good for updating expired certs.

This reverts commit 0786a006.

This is because if sites bother to obtain externally signed certificates
for their web server, they're going to use @WWWHOST@ for the name.

communication with the clearinghouse, and modifications to the
certificate format (put the URN in subjectAltName and move any
URL to a private OID under subjectInfoAccess).

are now generated for new certificates.  However, UUIDs and old HRNs
are still used, for compatibility.

its really a hugely stripped down Emulab boss install, using a very
short version of install/boss-install to get a few things into place.

I refactored a few things in both the protogeni code and the Emulab
code, and whacked a bunch of makefiles and configure stuff. The result
is that we only need to install about 10-12 files from the Emulab
code, plus the protogeni code. Quite manageable, if you don't mind
that it requires FreeBSD 6.X ... Still, I think it satisfies the
requirement that we have a packaged clearinghouse that can be run
standalone from a running Emulab site.

remote-site target.

This is a local hack for now.

Maybe by then someone will figure out the CRL stuff.

browser). This came up in elabinelab cause WWWHOST (www.myemulab.x.y.z) is
not an exported (from outer emulab) CNAME for the bossnode, so I have to
set WWWHOST equal to BOSSNODE, which causes the browser to complain.

(config files) can be localized:

	C                      = @SSLCERT_COUNTRY@
	ST                     = @SSLCERT_STATE@
	L                      = @SSLCERT_LOCALITY@
	O                      = @SSLCERT_ORGNAME@

Which are initialized locally to:

	SSLCERT_COUNTRY="US"
	SSLCERT_STATE="Utah"
	SSLCERT_LOCALITY="Salt Lake City"
	SSLCERT_ORGNAME="Utah Network Testbed"

Also added an "apache" target which will generate an initial cert/key
for the apache server. This is a self signed certificate of course, which
is fine for getting a new site off the ground. Note that the cert/key are
installed during by install/boss-install.

* SSL based server (sslxmlrpc_server.py) that wraps the existing Python
  classes (what we export via the existing ssh XMLRPC server). I also have a
  demo client that is analogous the ssh demo client (sslxmlrpc_client.py).
  This client looks for an ssl cert in the user's .ssl directory, or you can
  specify one on the command line. The demo client is installed on ops, and
  is in the downloads directory with the rest of the xmlrpc stuff we export
  to users. The server runs as root, forking a child for each connection and
  logs connections to /usr/testbed/log/sslxmlrpc.log via syslog.

* New script (mkusercert) generates SSL certs for users. Two modes of
  operation; when called from the account creation path, generates a
  unencrypted private key and certificate for use on Emulab nodes (this is
  analagous to the unencrypted SSH key we generate for users). The other mode
  of operation is used to generate an encrypted private key so that the user
  can drag a certificate to their home/desktop machine.

* New webpage (gensslcert.php3) linked in from the My Emulab page that
  allows users to create a certificate. The user is prompted for a pass
  phrase to encrypt the private key, as well as the user's current Emulab
  login password. mkusercert is called to generate the certificate, and the
  result is stored in the user's ~/.ssl directory, and spit back to the user
  as a text file that can be downloaded and placed in the users homedir on
  their local machine.

* The server needs to associate a certificate with a user so that it can
  flip to that user in the child after it forks. To do that, I have stored
  the uid of the user in the certificate. When a connection comes in, I grab
  the uid out of the certificate and check it against the DB. If there is a
  match (see below) the child does the usual setgid,setgroups,setuid to the
  user, instantiates the Emulab server class, and dispatches the method. At
  the moment, only one request per connection is dispatched. I'm not sure
  how to do a persistant connection on the SSL path, but probably not a big
  deal right now.

* New DB table user_sslcerts that stores the PEM formatted certificates and
  private keys, as well as the serial number of the certificate, for each
  user. I also mark if the private key is encrypted or not, although not
  making any use of this data. At the moment, each user is allowed to get
  one unencrypted cert/key pair and one encrypted cert/key pair. No real
  reason except that I do not want to spend too much time on this until we
  see how/if it gets used. Anyway, the serial number is used as a crude form
  of certificate revocation. When the connection is made, I suck the serial
  number and uid out of the certificate, and look for a match in the table.
  If cert serial number does not match, the connection is rejected. In other
  words, revoking a certificate just means removing its entry from the DB
  for that user. I could also compare the certificate itself, but I am not
  sure what purpose that would serve since that is what the SSL handshake is
  supposed to take of, right?

* Updated the documentation for the XMLRPC server to mention the existence
  of the SSL server and client, with a pointer into the downloads directory
  where users can pick up the client.

Also added control-install target to indicate what needs to be done
on the control-node.

captures certificate.  This is needed by the netbuild tiptunnel since
java does not have a plain SHA implementation.