1. 07 Jun, 2010 1 commit
  2. 04 Jun, 2010 1 commit
  3. 17 May, 2010 1 commit
  4. 15 Apr, 2010 1 commit
  5. 24 Mar, 2010 1 commit
  6. 23 Mar, 2010 1 commit
  7. 23 Feb, 2010 4 commits
  8. 19 Feb, 2010 1 commit
    • Leigh B Stoller's avatar
      Okay, I think I have solved the problem with interoperability between · 350bc54e
      Leigh B Stoller authored
      event clients and servers that do not have the same value of
      ELVIN_COMPAT compiled in. Most of use know this as the dreaded "HMAC
      mismatch" failure that clients spit out.
      Bottom line: My tests so far have ELVIN_COMPAT and non ELVIN_COMPAT
      clients sending and receiving events to/from each other okay. Events
      work in both directions.
      More details:
      The basic problem is that non ELVIN_COMPAT clients generate the hmac
      by traversing the notification in linear order. Very simple.
      When ELVIN_COMPAT is compiled in, we want to be able to take a
      notification that started in an actual elvin client, was converted to
      a pubsub notification, and then passed along. In this case the hmac
      that was in the original elvin packet was generated using the elvin
      traversal, which is not linear but a hash function. Annoying.
      To deal with this, our ELVIN_COMPAT clients take the notification and
      compute what the hash ordering is supposed to be, and then generates
      the HMAC for comparison. Ditto for outgoing notifications, which is
      why we have the interoperability problems.
      If I had been thinking ahead, I would have put a version number into
      pubsub notifications. Oh wait, thats another story ... lets get back
      to ELVIN_COMPAT ...  Instead of computing an order, I should have just
      put them into the notification in the proper elvin order, so that all
      clients only had to traverse it in linear order to compute the hmac.
      This is essentially what my changes have done. All notifications go
      out with the hmac computed from the linear ordering. When ELVIN_COMPAT
      is on, I use a hash table to generate the proper ordering, and then
      insert them into the notification.
      By putting adding a version number into the notification (refer to
      Mike's Rule of Version Numbers), I can tell old clients from new
      clients, and so new clients know what to do with a notification from
      an old client.
  9. 09 Feb, 2010 1 commit
  10. 25 Jan, 2010 1 commit
    • Mike Hibler's avatar
      Fixes for Fedora 10. · 9e9c658b
      Mike Hibler authored
      Fix obvious typo in liblocsetup.pm which was getting perl5.10 all cranky.
      Stop statically linking a couple of proxy pieces.  In general, it is/was
      a bad idea, and Fedora 10 doesn't have a static libz anyway.
  11. 05 Jan, 2010 2 commits
  12. 18 Dec, 2009 1 commit
  13. 14 Oct, 2009 2 commits
  14. 31 Aug, 2009 1 commit
  15. 28 Aug, 2009 2 commits
  16. 20 Aug, 2009 2 commits
  17. 04 Aug, 2009 1 commit
    • Kevin Atkinson's avatar
      Implement frontend and middleend support for loading multiple images · e7871305
      Kevin Atkinson authored
      at once with Frisbee (excludes the actual MFS changes).
      Os_load now takes take a list of comma serrated image names for the
      "-i" and "-m" options.  The default OS is the OS for the last image
      specified in the list.  I also changed the "-p" option of osload to
      search both the project specified and emulab-ops for the image rather
      than just the project specified in order to simplify specifying
      multiple images (and because I personally found that behavior annoying
      when using osload).
      I modified the current_reloads table to be able to specify more than one
      image for a node by adding an "idx" column which controls the order of
      the reloads.  I also added a "prepare" column to the table (explained
      I modified tmcd to basically loop over the entries in the table and
      create a multiline LOADINFO responsive, and modified rc.frisbee to
      handle the multiline response and load each image in turn.
      I modified os_load to take a new option "-P" which will tell rc.frisbee
      to zap the superblocks even if a whole disk image is not specified.
      To do this I set the prepare entry for the first image in the
      current_reloads table to true.  Tmcd than passes this into to
      rc.frisbee in the LOADINFO line.  When rc.frisbee sees this it will
      make sure to zap the superblock before loading that image.
      To support having multiple images as the default, "default_imageid"
      can now be a comma separated list.  I implemented a hack to be able to
      set multiple imageids via editnodetype.php3.  Basically the form
      splits default_imageid into default_imageid_0, default_imageid_1, etc
      and than adds an empty default_imageid_# slot to allow adding an
      imageid.  Multiple images can be added by adding one image, than
      submitting the form, and than adding another into the empty slot.  Not
      the best, but I don't thing this will be a very common operation.
      When the form is submitted it will than combine all default_imageid_#
      into a comma separated list ignoring any that are deleted or set to
      "No ImageID" (ie 0).
      Everything will work fine with old MFSs as long as only one image is
      loaded.  If multiple images are loaded with an old MFS, an email will
      be sent to testbed-ops.  This works by having tmcd detect old MFS's by
      using the version number and setting the state to RELOADOLDMFS.  Stated
      will pick up on the and send the email to testbed-ops via a trigger.
  18. 07 Jul, 2009 1 commit
  19. 11 Jun, 2009 1 commit
  20. 01 Apr, 2009 1 commit
  21. 10 Feb, 2009 1 commit
  22. 17 Dec, 2008 1 commit
  23. 11 Dec, 2008 1 commit
  24. 20 Oct, 2008 1 commit
  25. 10 Sep, 2008 1 commit
  26. 03 Sep, 2008 1 commit
  27. 19 Aug, 2008 1 commit
  28. 28 Jul, 2008 2 commits
  29. 24 Jul, 2008 1 commit
  30. 18 Apr, 2008 1 commit
  31. 16 Apr, 2008 2 commits