1. 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
      Most Utah-copyrighted files related to ProtoGENI are distributed under
      the terms of the GENI Public License, which is a BSD-like open-source
      Some Utah-copyrighted files in the Emulab source tree are distributed
      under the terms of the GNU Lesser General Public License, version 2.1
  2. 19 Jul, 2011 1 commit
  3. 25 Oct, 2010 1 commit
  4. 14 Aug, 2006 1 commit
  5. 14 Jun, 2006 1 commit
    • Mike Hibler's avatar
      Pulled another fix from the anal repository... · 97066a92
      Mike Hibler authored
      No idea why rpc exchanges started failing after updating boss/ops to
      FreeBSD 6.1 or, for that matter, why this really fixes the problem.
      Monitoring the exchanges between client and the RPC serial line didn't
      show any rhyme or reason why some exchanges elicited "Input error" and
      others didn't.  But I noticed that every \r we send to the RPC gets
      echoed back as \r\r\n (and no, it isn't the serial line CR<->NL mapping).
      So I reduced the number of \r (actually \n) we send it and things got better.
      This "fix" has been running every 5 minutes for the last hour without
      failure, so I declare it: An Improvement.
  6. 09 Jun, 2006 1 commit
  7. 28 Mar, 2006 1 commit
    • Mike Hibler's avatar
      Attempt to make firewall experiment swapout more robust by addressing a · 69b90e79
      Mike Hibler authored
      couple of MFS booting problems:
       * in the RPC power controller, make sure that an "on" command succeeds
         by checking the status, retrying if it failed (we already did this for
       * if nodes fail to boot up the MFS after a power on, try again with a
         power cycle.  I have seen "power on" leave pc600s hung, and a power
         cycle seems to cure it.
  8. 19 Dec, 2005 1 commit
  9. 12 Dec, 2005 1 commit
  10. 01 Sep, 2005 1 commit
    • Mike Hibler's avatar
      Revamped the RPC syncandsend code yet again. · 931a8a5e
      Mike Hibler authored
      Now we keep reading after we send the command, til we get the next prompt.
      That way we will catch any "Input error" messages and can try again.
      The downside is that, for reboots, we wait through the whole 10 second
      countdown before returning to the caller.  Previously we would return
      immediately after issuing the command.
  11. 13 Aug, 2005 1 commit
  12. 12 Aug, 2005 1 commit
    • Mike Hibler's avatar
      Ugh! When reading a line, go ahead and return if the string we have · c1c24bfa
      Mike Hibler authored
      read matches the prompt, i.e., don't wait to get a newline.  With the
      new power controller on the rocketport muxes on a pc1500 tipserver,
      even though we send two newlines, we just get back a single prompt
      with no newline.  This would cause us to hang forever waiting for the
      Note that it did not do this on the same RPCs with the same muxes on
      our ops node (a pc3000).  This could be a bad sign for things to come...
  13. 01 Jul, 2005 1 commit
    • Mike Hibler's avatar
      Add "status" command that can be applied to power controllers · c946abb8
      Mike Hibler authored
      (eg. "power status rpc14-1" or "power status all").
      In rpc module, add a "status" function that is called to collect,
      well..status.  This is used by the generic power code, but more importantly,
      by the new "powermon" script (which could have just called "power status",
      but no point in parsing output twice).
  14. 04 Apr, 2005 1 commit
  15. 15 Mar, 2005 1 commit
  16. 07 Jul, 2002 1 commit
  17. 21 May, 2002 1 commit
    • Robert Ricci's avatar
      Fix for a problem that Mike discovered. The RPC input buffer is · 5a3d2cee
      Robert Ricci authored
      limited to 31 characters, so we can't give commands with more than 8
      outlets. So, we split up the outlets into groups of 8, and issue
      multiple commands, if we are passed too many outlets.
      Took some minor re-structuring, since we now may need to sync up with
      the RPC prompt more than once.
  18. 26 Nov, 2001 1 commit
    • Robert Ricci's avatar
      In order to improve experiment startup times, power now sorts nodes by · ebaac553
      Robert Ricci authored
      power controller, and controls all nodes on the same controller at
      once. This is particularly helpful when rebooting nodes connected to
      the RPCs, as you now longer have to wait through the RPCs 'rebooting'
      junk for each node.
      power_rpc27.pm and snmpit_apc.pm received some minor changes to
      support passing multiple outlets to one function call.
  19. 13 Sep, 2001 1 commit
    • Leigh Stoller's avatar
      Be more forgiving of failed syswrite/sysread to the TIP socket during · 44ad0041
      Leigh Stoller authored
      the connection handshake. If the capture is active, it is going to
      write status and close the socket on its end, which may or may not be
      propogated back to the client side before/after/during the
      sysread/syswrite. I guess that a miserable way of saying there is a
      lot of asynchrony involved.
  20. 29 Aug, 2001 1 commit
    • Leigh Stoller's avatar
      Fixup capture/tip/power_rpc27 so that capture returns a positive · ed55f418
      Leigh Stoller authored
      ack/nak for a connection so that the connecting process knows what the
      hell is going on. Turned out to be necessary for power control since
      we do that in parallel, and because it stays busy for 10 seconds on
      each power control. I think we will end up revisiting this at some
      point, adding blocking connections instead of connect/fail status.
  21. 27 Aug, 2001 2 commits
    • Leigh Stoller's avatar
      Ug, forgot to turn off debug mode! · 966d8fa1
      Leigh Stoller authored
    • Leigh Stoller's avatar
      Changes to sync protocol. The RPC27 spits out a bunch of silly status · e335015b
      Leigh Stoller authored
      goo whenever it goes inactive for more than a couple of minutes. Also,
      require that we sync up so that we know for sure that the power
      control failed. Previously, I was blindly spitting out the command
      without being sure we had a command prompt.
      Note, that we still have a problem with an active tip session messing
      up power control since only one connection can be active at a time.
      At present, there is no positive way to know that the connection was
      refused since capture accepts the connection and then closes it if
      there is an active tip session. I need to change the little handshake
      so that there is a response Yes/Know response to the secret key
  22. 14 Aug, 2001 2 commits
  23. 09 Aug, 2001 1 commit