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.

  1. 05 Jun, 2015 3 commits
  2. 04 Jun, 2015 1 commit
  3. 03 Jun, 2015 1 commit
  4. 02 Jun, 2015 5 commits
  5. 01 Jun, 2015 4 commits
  6. 29 May, 2015 5 commits
  7. 28 May, 2015 10 commits
  8. 27 May, 2015 8 commits
    • Mike Hibler's avatar
      d564150c
    • Mike Hibler's avatar
    • Mike Hibler's avatar
      Avoid (as best we can) port collisions on the frisbee client/server/uploader. · 0a7fd856
      Mike Hibler authored
      Two different fixes here.
      
      The first affects frisbeed ("the server") and frisuploadd ("the uploader").
      In both, the master server was choosing the port to use as an obscure function
      of the current value of emulab_indicies frisbee_index without regard to whether
      the port was already in use by someone else.
      
      To fix this, the "-p <port>" option of both programs has been changed to
      allow a value of 0 to indicate that the program (rather, the kernel) should
      choose the first available port. It will also take a port range (e.g.,
      "-p 50000-50100") which says to find the first available port in that range.
      To communicate The Chosen Port back to the master server, there is a new
      option to frisbeed and frisuploadd, "-A <file>", which says to write the
      address info into the indicated file in the <IP-addr>:<port> format.
      Note that we don't care about the <IP-addr> part since that is just the
      multicast address (frisbeed) or our unicast address (frisuploadd) that we
      pass in to the program. The "Emulab configuration" of the master server uses
      the defs file FRISEBEEMCASTPORT and FRISEBEENUMPORTS vars to determine what
      to pass via the "-p" option. See the comment in defs-example. The "null
      configuration" (aka, on a subboss) just passes "-p 0" to frisbeed.
      
      The second fix was an attempt to avoid port conflicts on the client side
      (frisbee). There is only so much we can do since all clients of a multicast
      frisbee session have to use the same port, but we can avoid conflicts with
      other UDP apps that bind to INADDR_ANY:<port>.
      
      We make use of the REUSEADDR socket option and bind specifically to
      <mcaddr>:<port>. This also requires that the server multicast the JOIN
      reply that was previously unicast. Note that use of REUSEADDR will also
      allow multiple frisbee clients on the same host to be in the same session
      (not that we ever do that).
      
      Since the server is typically updated whenever the Emulab software is, but
      the client is embedded in images and MFSes, there can be pretty much any
      combo of {old,new} server and {old,new} client in the field. So backward
      compatibility was essential and there are a variety of implementation details
      related to that. See the comment in network.c::ClientNetInit().
      0a7fd856
    • Leigh B Stoller's avatar
    • Leigh B Stoller's avatar
      Minor code formatting changes. · e5585e8e
      Leigh B Stoller authored
      e5585e8e
    • Leigh B Stoller's avatar
      Bug fix to default profile handling. · a755a2f4
      Leigh B Stoller authored
      a755a2f4
    • Leigh B Stoller's avatar
      6ebe080c
    • Leigh B Stoller's avatar
      Fix edit modal widths. · ca702b79
      Leigh B Stoller authored
      ca702b79
  9. 26 May, 2015 3 commits