All new accounts created on Gitlab now require administrator approval. If you invite any collaborators, please let Flux staff know so they can approve the accounts.

  • Mike Hibler's avatar
    Support image PUT (aka, "upload") and assorted minor changes. · 77dbad39
    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:
    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!"
243 993 Bytes