-
Mike Hibler authored
1. Support for PUT. The big change is support for uploading via the master server, based heavily on the prototype that Grant did. Currently only host-based (IP-based) authentication is done as is the case with download. Grant's SSL-based authentication code is "integrated" but has not even been compiled in. The PUT protocol allows for assorted gewgaws, like specifying a maximum size, setting a timeout value, returning size and signature info, etc. There is a new, awkwardly-named client utility "frisupload" which, like the download client, takes an "image ID" as an argument and requests to upload (PUT) that image via the master server. As with download, the image ID can be either of the form "<pid>/<emulab-image-name>", to upload/update an actual Emulab image or it can start with a "/" in which case it is considered to be a pathname on the server. On the server side, the master server takes PUT requests, verifies permission to upload the image, fires up a separate instance of an upload daemon (with the even catchier moniker "frisuploadd"), and returns the unicast addr/port info to the client which then begins the upload. The master server also acts as a traffic cop to make sure that downloads and uploads (or uploads and uploads) don't overlap. This has been integrated into the Emulab "create image" process in a backward-compatible way (i.e., so old admin MFSes will continue to work). Boy, was that fun. One not-so-desirable effect of this integration is that images now traverse our network twice, once to upload from node to boss and once for boss to write out the image file across NFS to ops. This is not really something that should be "fixed" in frisbee, it is only "undesirable" because we have a crappy NFS server. What has NOT been done includes: support of hierarchical PUT operations (we don't need it for either the elabinelab or subboss case), support for uploading standard images stored on boss (we really want something better than host-based authentication here), and the aforementioned support of SSL-based authentication. 2. Other tidbits that got mixed in with PUT support: Added two new site variables: images/frisbee/maxrate_std images/frisbee/maxrate_usr which replace the hardwired (in mfrisbeed and frisbeelauncher before that) bandwidth limits for image download. mfrisbeed reads these (and the images/create/* variables) when it starts up or receives a HUP signal. These could be read from the DB on every GET/PUT, but they really don't change much and I needed something to test the reread-the-config-on-a-HUP code! Fixed avoidance of "problematic multicast addresses" so it would actually work as intended. Lots of internal "refactoring" to make up for things I did wrong the first time and to give the general impression that "Wow, Mike did a LOT!"
77dbad39