• Mike Hibler's avatar
    First crack at a frisbee "master server" for handling GET (download) requests. · a2a896ab
    Mike Hibler authored
    There are a couple of new packet types in the frisbee protocol which are
    exchanged via TCP with the master server: GETREQUEST and GETREPLY.  The
    client passes to the master server an opaque imageid and a couple of options
    and gets back the addr/port to use to actually download the image.  The
    implementation of the master server is fragile and is more of a test
    framework, Grant is working on a more robust master server.  I am mostly
    doing a backend that communicates with the Emulab DB to do its authentication
    and making the client changes.
    The client now uses the -S option to specify the IP address of the master
    server and the -F option to specify an imageid.  If no error is returned,
    the image is downloaded using the returned addr/port.  If -Q is used in place
    of -F, then the client makes a "status only" call getting back info about
    whether the named image is accessible to the client and whether a server is
    currently running.
    On the server side, the new master server (mserver.c) has an Emulab
    configuration "backend" that supports host-based authentication.
    The IP address of the caller is mapped to a node_id/pid/gid/eid combo
    that is used to determine access.  On a request, the specified imageid is
    treated either as a pathname (if it starts with '/') or an image identifier
    of the form "<pid>/<imagename>".  If it is a pathname, we check to make
    sure that pathname (after running through "realpath") is contained in one
    of the directories accessible to that node in its current experiment context;
    i.e., /share, /proj/<pid>, /groups/<pid>/<gid>, or /users/<swapper-uid>.
    If it is an image identifier, the DB is queried to ensure that access is
    allowed to that image; i.e., it must be "global" or in the appropriate
    The master server forks a frisbeed for each valid request, if one is not
    already running.  The multicast address selection is still based on the
    emulab_indicies.frisbee_index field, but the address/port/server info is no
    longer stored in the frisbee_blobs table (frisbee_pid, load_address,
    load_busy are not set).
    Note that this is not yet integrated in the os_load path.  Further work is
    required to replace frisbeelauncher.
Last commit
Last update
dijkstra Loading commit data...
frisbee.redux Loading commit data...
genhostsfile Loading commit data...
growdisk Loading commit data...
imagezip Loading commit data...
shd Loading commit data...
syncd Loading commit data...
zapdisk Loading commit data...
GNUmakefile.in Loading commit data...
create-image Loading commit data...
create-swapimage Loading commit data...
install-rpm Loading commit data...
install-tarfile Loading commit data...
install-tarfile.1 Loading commit data...
split-image.sh.in Loading commit data...
template_record Loading commit data...