1. 12 Jul, 2014 1 commit
    • Mike Hibler's avatar
      Add config function to canonicalize the image name passed in. · a60cc3f7
      Mike Hibler authored
      This is strictly for the benefit of the Emulab config where you can
      request an image name by either ID or path, e.g. "testbed/FOO" or
      "/proj/testbed/images/FOO.ndz". Previously, simultaneous requests
      under both names would start up two different servers because we didn't
      know they were the same image. Not really a problem for downloads,
      but really not a good thing for uploads!
      a60cc3f7
  2. 09 Jul, 2014 1 commit
    • Mike Hibler's avatar
      Robustness work on the image upload side. · ca73f315
      Mike Hibler authored
      Implement idle ("lack of progress") timeout on the server.
      
      Timeout work on the client-side too. Implement idle timeouts (not for
      SSL connections yet), fixup handling of over-all timeout. In particular,
      if we are reading from a pipe ('-') don't start timeout til we get some
      input from the pipe.
      
      Add option to put out progress dots on the client (cuz we are all about
      dots in imagezip/frisbee).
      ca73f315
  3. 02 Jul, 2014 1 commit
  4. 12 Feb, 2014 1 commit
    • Mike Hibler's avatar
      Add frisbee master server mechanisms for turning on dynamic rate tuning. · d9ee4a67
      Mike Hibler authored
      For the Emulab configuration, we add the new site variable
      "images/frisbee/maxrate_dyn" which should be set non-zero to enable
      dynamic adjustment. If maxrate_dyn is enabled, then the maxrate_{std,usr}
      values are used as both the initial and maximum values for the BW of any
      instance. Really, if maxrate_dyn is on, then both of those should be set
      to the same value so that all servers are operating the same and the value
      should be just above the link BW.
      
      For the "null" configuration (aka, the subboss configuration),
      this is set by adding command line options:
          -O dynamicbw=1,bandwidth=1100000000
      which would enable it and start/cap the BW at 1.1Gb/sec.
      d9ee4a67
  5. 10 Feb, 2014 1 commit
  6. 22 Oct, 2013 1 commit
    • Mike Hibler's avatar
      Attempt to un-rot the eventsys code in frisbee. · 2197ba80
      Mike Hibler authored
      Back in the day, when the paper was written, I had an eventsys interface
      to the client to provide a syncronized interface to multiple running
      instances. I rejuvenated the bits, so the eventsys control works again,
      however some logic in the client has changed such that a second attempt
      to run within the same client hangs. More work needed.
      2197ba80
  7. 18 May, 2013 1 commit
    • Mike Hibler's avatar
      Command line option to set the socket buffer size, fix some trace logic. · 2b5587df
      Mike Hibler authored
      The "-k" option (hey, it was the best available letter!) takes a size
      in MB with which the frisbee client and server will first try to size their
      UDP socket buffers. They may still wind up with a smaller size, depending
      on what the OS supports.
      
      Fixed the burst logging logic so that we correctly trace overrun conditions.
      2b5587df
  8. 24 Jan, 2013 1 commit
  9. 14 Jan, 2013 1 commit
  10. 16 Nov, 2012 1 commit
  11. 24 Sep, 2012 1 commit
    • Eric Eide's avatar
      Replace license symbols with {{{ }}}-enclosed license blocks. · 6df609a9
      Eric Eide authored
      This commit is intended to makes the license status of Emulab and
      ProtoGENI source files more clear.  It replaces license symbols like
      "EMULAB-COPYRIGHT" and "GENIPUBLIC-COPYRIGHT" with {{{ }}}-delimited
      blocks that contain actual license statements.
      
      This change was driven by the fact that today, most people acquire and
      track Emulab and ProtoGENI sources via git.
      
      Before the Emulab source code was kept in git, the Flux Research Group
      at the University of Utah would roll distributions by making tar
      files.  As part of that process, the Flux Group would replace the
      license symbols in the source files with actual license statements.
      
      When the Flux Group moved to git, people outside of the group started
      to see the source files with the "unexpanded" symbols.  This meant
      that people acquired source files without actual license statements in
      them.  All the relevant files had Utah *copyright* statements in them,
      but without the expanded *license* statements, the licensing status of
      the source files was unclear.
      
      This commit is intended to clear up that confusion.
      
      Most Utah-copyrighted files in the Emulab source tree are distributed
      under the terms of the Affero GNU General Public License, version 3
      (AGPLv3).
      
      Most Utah-copyrighted files related to ProtoGENI are distributed under
      the terms of the GENI Public License, which is a BSD-like open-source
      license.
      
      Some Utah-copyrighted files in the Emulab source tree are distributed
      under the terms of the GNU Lesser General Public License, version 2.1
      (LGPL).
      6df609a9
  12. 19 Sep, 2012 1 commit
  13. 19 Jun, 2012 1 commit
    • Mike Hibler's avatar
      Make frisbee more directly IGMP (v2) aware. · 66e07584
      Mike Hibler authored
      Add "-Q <interval>" option to the master server to allow it to act as an
      IGMP V2 querier in environment where there is otherwise not one. It does
      essentially what the perl-based querier (code.google.com/p/perl-igmp-querier/)
      does, sending out a v2 membership query at the specified interval.
      
      This eliminates the need to run mrouted in some environments (e.g., elabinelab)
      just to issue IGMP queries. As a result, all the boss-install and elabinelab
      setup related to using mrouted to perform this function has been removed.
      The elabinelab CONFIG_MROUTED option has been changed to CONFIG_QUERIER
      (the former is still recognized and mapped to the latter). The undocumented
      defs-* variable NEEDMROUTED has been changed to NEEDMCQUERIER (the former
      still exists in install/installvars.pm.in but is always set to 0) to more
      accurately reflect the variable's purpose. If NEEDMCQUERIER is set, then
      the mfrisbeed startup script is modified to add the "-Q 30" option.
      
      The implementation of the client and server "-K <interval>" keep-alive option
      has been changed to directly send IGMP v2 membership reports containing the
      associated MC address.
      
      Note that the -K options have always been a hack to work-around assorted
      IGMP-related misconfigurations and incompatibilities, and really should
      only be used as a last resort. As implemented, they could cause the host
      machine to be pruned out of other MC groups at the nearest switch since
      they only report membership in the frisbee MC group. With the master server
      acting as an IGMP querier, instances of the frisbee server on that host
      should no longer need to do keep alives. We still have one case where it
      is needed on the client-side: a FreeBSD 8.x or later host connected to an
      IGMPv2-only switch. It appears that the IGMPv3 implementation added in
      FreeBSD 8.x always sends v3 reports, even when the default is configured
      (via sysctl or even recompiling the kernel) as v2.
      66e07584
  14. 26 Apr, 2012 1 commit
    • Mike Hibler's avatar
      Make broadcast mode work with master server. · 270bcda4
      Mike Hibler authored
      I had never completed this. Two things to note:
      
      1. Distribution via broadcast is still disabled by default in the master
         server. To enable it, see the comment added in 3.mfrisbeed.sh.in.
         To use broadcast by default in the client, see the comment in rc.frisbee.
      
      2. If you specify broadcast (-b) in either the client or server, then you
         should use "-m 255.255.255.255". However, this will broadcast to ALL
         interfaces on the client/server. To limit to a specific interface, also
         include "-i <interface-IP>". This will tell the client/server to look up
         that interface and use the subnet broadcast address in place of
         255.255.255.255. Since the master server always starts up frisbeed
         instances with -i, broadcast will always be directed on the server.
         Since our rc.frisbee script also fires up the client with -i, it will
         likewise be directed.
      270bcda4
  15. 20 Mar, 2012 1 commit
  16. 30 Jun, 2011 1 commit
    • Mike Hibler's avatar
      Make sure upload/download server run with proper group list. · bf97b597
      Mike Hibler authored
      Attempts to load an image from a subgroup of a project didn't work because
      I was only setting the primary group ID based on the node's experiment's
      project. Now we use setgroups() to establish all groups that the swapper
      of the experiment belongs to.
      bf97b597
  17. 29 Jun, 2011 1 commit
  18. 27 May, 2011 1 commit
  19. 18 May, 2011 1 commit
    • 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:
          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
  20. 04 Apr, 2011 1 commit
    • Mike Hibler's avatar
      Bug fix: ensure we run any spawned frisbeed as "the appropriate user." · 7f775c7d
      Mike Hibler authored
      Previously, frisbeed's were always running as the uid/gid of the master server
      which generally meant root. This was not a security issue, as we did not rely
      on file permissions to enforce accessibility.
      
      For the Emulab config, "appropriate user" means the uid of the experiment
      swapper and the gid of the experiment. For the null (default) config, it
      still means the uid/gid of the master server--if you don't want them running
      as root, don't run the master server as root.
      
      For now, and frisbee clients spawned (e.g., to fetch an image from a parent)
      are still run with the uid/gid of the master server. This can easily be
      changed if necessary.
      7f775c7d
  21. 10 Feb, 2011 1 commit
  22. 03 Feb, 2011 1 commit
    • Mike Hibler's avatar
      Put the frisbeed timeout back at the pre-mserver level (1800 seconds). · 6bb4e215
      Mike Hibler authored
      In the short run, we leave this at pre-master-server levels
      for compatibility (we still support advance startup of servers
      via the localhost proxy).
      
      We also need this at Utah while we work out some MC problems on
      our control net; sometimes nodes can take minutes before they
      actually hook up with the server, even with the mserver.
      6bb4e215
  23. 02 Feb, 2011 1 commit
    • Mike Hibler's avatar
      Various changes related to the port mfrisbeed listens on. · d77c33b7
      Mike Hibler authored
      1. Add -i option to tie mfrisbeed to a particular interface and use that
         option for a multi-homed boss node (only listen on inside interface).
      
      2. Make that option play nice with the localhost proxying features of a
         previous commit: we also listen on localhost in this case.  The localhost
         proxying feature now has the compile time option USE_LOCALHOST_PROXY
         rather than mixing it up with the USE_EMULAB_CONFIG option (even though
         it probably will only ever be used in the Emulab config).
      
      3. Both of those were really to fix one bug: if we got a request from
         localhost to start up a frisbeed daemon, we were starting it up bound
         to the localhost interface.  Now we will make sure the server gets
         started up using the "other" interface, i.e., the one specified with -i.
      d77c33b7
  24. 01 Feb, 2011 1 commit
    • Mike Hibler's avatar
      Implement limited backward compatibility with the old frisbee setup. · 1017ccce
      Mike Hibler authored
      The big backward compatibility issue is that we no longer store running
      frisbeed info in the DB.  This means that loadinfo could not return
      address:port info to clients and thus old frisbee MFSes could no longer
      work.  While not a show stopper to require people to update their MFS first,
      I made a token effort to implement backward compat as follows.
      
      When an old frisbee MFS does "tmcc loadinfo" (as identified by a tmcd
      version < 33), tmcd will invoke "frisbeehelper" to startup a daemon.
      Sound like frisbeelauncher?  Well sorta, but vastly simplified and I only
      want this to be temporary.  The helper just uses the frisbee client to make
      a "proxy" request to the localhost master server.  The Emulab configuration
      of the master server now allows requests from localhost to proxy for another
      node.
      
      frisbeehelper is also used by webfrisbeekiller to kill a running daemon
      (yes, just like frisbeelauncher).  It makes a proxy status request on
      localhost and uses the returned info to identify the particular instance
      and kill it.
      1017ccce
  25. 18 Jan, 2011 1 commit
  26. 15 Jan, 2011 1 commit
    • Mike Hibler's avatar
      Working download path: inner-node <-> inner-boss <-> sub-boss <-> real-boss · f1016e75
      Mike Hibler authored
      Who says Mike can't do N-level hierarchy for N > 2!
      
      The different levels are configured like:
      
      1. Running the master server on real-boss.  Just use the Emulab config (-C),
         which will authenticate by caller IP using info from the DB:
            mfrisbeed -C emulab
      
      2. Running the master server on sub-boss.  Use the default (null) config
         (authentication allows GETs only from within the default image cache
         directory), tell it where to cache images (-I), name real boss as the
         parent server (-S), pass calling client's context (IP) to parent for
         authentication (-A) (since the subboss itself has no experiment context
         and must serve all experiments), run in "mirror mode" (-M) where we are
         strictly a read-only cache for images from our parent, and allow
         redirection of sub-boss clients to the real-boss when sub-boss is itself
         downloading the image for the first time (-R):
            mfrisbeed -S boss.emulab.net -I /z/image_cache -A -M -R
      
      3. Running the master server on an inner-boss.  Use the Emulab config (-C),
         use sub-boss as our parent server (-S):
            mfrisbeed -C emulab -S pc404.emulab.net
      
      An inner elab node would make a request from the inner-boss (-S) to download
      an image with the given ID imageid (-F), trying again every 30 seconds (-B)
      if the server reports "try again" (i.e., it is downloading the image from
      its parent):
         frisbee -S boss -B 30 -F emulab-ops/FEDORA10-STD /dev/da0
      
      Note the differences between the sub-boss config (2) and the inner-boss
      config (3); both are proxying, but in different ways:
      
       * Authentication: inner-boss can use its own identity when downloading
         images on behalf of its nodes since the inner-boss is in the same
         experiment as those nodes and has the same privileges as seen by the
         outer elab. Sub-boss is in a more privileged position where its clients
         may be in mulitple experiments, hence it must pass on the client's
         authentication info (IP) to its parent.
      
       * Caching: sub-boss is just a read-only copy of the images on real
         boss; the state of these images should always match what is on boss.
         Hence it always checks in with boss to make sure that an image, even
         if cached locally, is up to date. Inner-boss is more of a COW image
         repository, since inner nodes can create new images and modify existing
         ones independent of the real Emulab; images are only downloaded if they
         don't exist locally and do exist in the outer elab.
      
       * Redirection: one optimization Ryan did in the current sub-boss setup
         was to allow clients of the sub-boss frisbee to be redirected to the
         real boss when the sub-boss itself is downloading an image for the
         first time. Hence, while sub-boss is downloading an image, its clients
         will download at the same time from the same multicast stream.  Once
         sub-boss has the image, clients will just download from it as usual.
         Conceptual this could work for inner-boss, but since we do NAT for all
         inner nodes using inner-boss as the gateway, it would be a convoluted
         setup if it could even be made to work (e.g., do we even pass MC traffic?
         can we do it without rewriting the port used by the client?)
      f1016e75
  27. 14 Jan, 2011 1 commit
  28. 13 Jan, 2011 1 commit
  29. 11 Jan, 2011 1 commit
    • Mike Hibler's avatar
      More work toward getting this working on subboss. · 8d80301e
      Mike Hibler authored
      More work on the hierarchical configuration for subboss. When doing host-based
      authentication, allow client to pass an explicit host (IP) to the mserver.
      If the mserver is configured to allow it, that IP is used for authenticating
      the request instead of the caller's IP. Add a default ("null") configuration
      so the mserver can operate out-of-the-box with no config file. The goal of
      these two changes is for an mserver instance with the default config and a
      proxy option to serve the needs of a subboss node (i.e., so no explicit
      configuration will be needed).
      8d80301e
  30. 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
  31. 07 Dec, 2010 1 commit
    • Mike Hibler's avatar
      Deal with port conflicts in the server. · f0f723ea
      Mike Hibler authored
      The frisbee server (and client) return a special exit code if they cannot
      bind to the given port.  Arrange for server startup to be retried if this
      happens.
      f0f723ea
  32. 06 Dec, 2010 1 commit
    • Mike Hibler's avatar
      Make unicast transfers work. · 66b0ae44
      Mike Hibler authored
      There are some hacks involved here right now since a unicast frisbee server
      currently can only support a single client.  So for now, we only allow a
      single unicast server for any image (i.e., because the right way to do this
      is to fix the server to support multiple clients, not to start up multiple
      single-client servers).
      66b0ae44
  33. 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
  34. 02 Dec, 2010 1 commit
    • Mike Hibler's avatar
      Inching toward recursive use, ala what is needed for elabinelab or subbosses. · 2ead2a68
      Mike Hibler authored
      Add the ability of the master server to have a "parent" from which it can
      download an image if it doesn't have it or if the image is out of date.
      Had to add some more goo to the GET reply, notably a hash so that we can
      check for up-to-dateness.
      
      The actual part where we upcall to the parent isn't done yet, that is why
      this is "inching toward" and not "leaping and bounding toward"...
      
      Also redid the child process management to not use SIGCHLD, no need for that.
      2ead2a68
  35. 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