1. 13 Dec, 2010 1 commit
    • Mike Hibler's avatar
      Aerformed. If the mserver receiving the request allows the caller to be a · c5b7cceb
      Mike Hibler authored
      proxy, then it will perform its checks against the hostIP provided rather
      than the IP of the message sender.  For the Emulab subboss case, subboss
      nodes (as determined from the DB) are allowed to explicitly specify hosts
      that are under their control.  The master server on real boss will run with
      proxying enabled.
      
      Also, in a fit of madness, I added a version number to the master server
      protocol.  This way, if at some distant point in the future (say next week)
      I realize I screwed up the protocol, I can fix it without resorting to creative
      retrofitting of a version number (see imagezip) or the more Orwellian
      eradication and denial of past versions (what I am doing now). Furthermore,
      using an ill-thought-out insight, I made the version number be an ASCII string
      in case I decide to change to an all-text protocol at some equally distant
      point in the future.
      c5b7cceb
  2. 07 Dec, 2010 2 commits
  3. 06 Dec, 2010 5 commits
  4. 03 Dec, 2010 1 commit
    • Mike Hibler's avatar
      Hierarchical downloading is now implemented. · 21b01bbb
      Mike Hibler authored
      The master server can be started with a "parent" mserver that it can call
      if it doesn't have an image.  The master server will return an EAGAIN type
      error to any clients that contact it while it is downloading an image from
      its parent.  The client now has a "-B N" option to tell it to try again
      every N seconds as long as it gets back that error.  This is the "store and
      forward" mode.  The mserver also has a "cut through" style where it will
      return to clients the mcast info it got from its parent so they can download
      directly from the parent until the local mserver has it.
      21b01bbb
  5. 02 Dec, 2010 5 commits
  6. 01 Dec, 2010 1 commit
  7. 30 Nov, 2010 2 commits
  8. 29 Nov, 2010 7 commits
  9. 26 Nov, 2010 1 commit
  10. 24 Nov, 2010 1 commit
    • 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
      project/group.
      
      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.
      a2a896ab
  11. 23 Nov, 2010 1 commit
  12. 22 Nov, 2010 4 commits
  13. 20 Nov, 2010 1 commit
    • Ryan Jackson's avatar
      Fixed segfault in event/new_sched · 15fc15b7
      Ryan Jackson authored
      Fixed a segfault in the new event scheduler
      
      Cleaned up some code that dealt with converting
      xmlrpc_c::value_strings to C string constants to avoid further memory
      corruption issues.
      
      Also converted AddAgent(), AddGroup(), AddUserEnv() to take 'const
      char *' pointers instead of 'char *'s to silence GCC's warnings about
      invalid conversions from 'const char *' to 'char *'.
      15fc15b7
  14. 18 Nov, 2010 2 commits
  15. 17 Nov, 2010 5 commits
  16. 16 Nov, 2010 1 commit
    • Kevin Atkinson's avatar
      Add support for all node "tb-set-tarfiles". · a0d0c95e
      Kevin Atkinson authored
      "tb-set-tarfiles" is like "tb-set-node-tarfiles" except that it
      distributes the tarfile to all nodes rather than just one and that it
      uses frisbee to distribute the file.
      
      These changes involved 1) refactoring frisbee info from images table
      into a new table, frisbee_blobs, 2) a new experiment_blobs table, and
      3) a new tmcd command so the node knows how to get the files from the
      server.
      
      The changes where designed to be general purpose enough to eventually
      support:
        1) Distributing arbitrary files (not just tarfiles) to nodes
        2) Perform arbitrary actions on those files
        3) Use arbitrary methods to get the files
      
      As such the tmcd line is as follows:
        URL=* ACTION=*
      
      where URL is currently:
        frisbee.mcast://<ADDR>/<FILE>
      for example
        frisbee.mcast://234.16.184.192:18092/users/kevina/home-dir.tar.gz
      and when we get around to using a master Frisbee server it could be
        frisbee://*
      or it could be a file://, http://, etc.
      
      and ACTION is currently:
        unpack:<LOCATION>
      for example
        unpackt:/users
      with future syntax to be determined.
      a0d0c95e