1. 27 Jul, 2016 1 commit
  2. 08 May, 2016 3 commits
  3. 22 May, 2015 1 commit
  4. 25 Nov, 2014 1 commit
  5. 25 Sep, 2014 1 commit
  6. 08 Sep, 2014 1 commit
  7. 20 Aug, 2014 1 commit
  8. 01 Jul, 2014 1 commit
  9. 16 May, 2014 1 commit
  10. 11 Feb, 2013 1 commit
  11. 19 Oct, 2012 1 commit
  12. 25 Sep, 2012 1 commit
  13. 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
  14. 13 Apr, 2012 1 commit
    • Mike Hibler's avatar
      Remove dependency on a racy state transition. · 089676f5
      Mike Hibler authored
      The recent reboot-node-if-going-from-PXEWAIT-to-SECURELOAD change to
      bootinfo was checking that the node was in PXEKERNEL/PXEBOOTING. However,
      the transition from PXEWAKEUP->PXEBOOTING may not have happened yet.
      
      However, the check for PXEBOOTING was unnecessary anyway, since bootinfo
      is the one that sends that state and it *always* does it just before calling
      query_bootinfo_db (the guy relying on the racy state change). Thus, the node
      is intended to be in PXEBOOTING even if that hasn't yet been recorded in
      the DB. So just remove the state check (we still check the op_mode).
      
      Note that this only affects nodes that are using the secure diskload MFS.
      089676f5
  15. 19 Mar, 2012 1 commit
  16. 14 Mar, 2012 2 commits
    • Mike Hibler's avatar
      Make the secure boot path work with PXEWAIT. · ceeede28
      Mike Hibler authored
      When a node with the secure boot dongle is freed, it goes into PXEWAIT in
      the context of the secure MFS. Previously we remained in "secure mode"
      (i.e., did not terminate with a TPMSIGNOFF) while a node was in this state.
      If the next use of the node, just booted from the OS that was already on
      the disk, then we never signed off properly.
      
      Now we sign off before entering PXEWAIT. I thought that this would be the
      easiest alternative to fixing the problem..HaHaHa..not! Because now we have
      to restart the secure boot path (i.e., reboot) if the result of coming out
      of PXEWAIT is a request to reload the disk (i.e., if we are continuing the
      secure disk load path).
      
      Ideally this would have required only modifications to the state machines
      for SECUREBOOT/LOAD, but as you can see by the presence of stated.in in the
      modified files, this was not the case. The change required some additional
      "finesse" to get it working. See the comments in stated.in and bootinfo_mysql.c
      if you really care.
      ceeede28
    • Mike Hibler's avatar
      Pass through bootinfo flags on tmcc "bootwhat" command. · 3ca3abf6
      Mike Hibler authored
      bootwhat will now return a FLAGS=%d value corresponding to the flags
      field in the boot_what struct.
      
      NOTE: THIS REQUIRED A TMCD VERSION BUMP. We are now at version 35.
      The issue was backward compatibility with existing CD/dongle boot images
      which are overly strict in their parsing of the returned bootwhat values.
      
      Added a new boot_what flag (the whole point of this) to signify if the
      entity being returned is part of the "secure boot" path. This is used
      by the gPXE dongle to determine whether it needs to do a trusted boot
      path "sign-off" for the MFS it downloads. We used to use the name of
      the MFS as our heuristic for this.
      
      bootinfo uses the new tbdb.os_info osfeature "ontrustedboot" to determine
      whether to set the flag.
      3ca3abf6
  17. 17 Aug, 2011 1 commit
  18. 27 Jul, 2011 1 commit
  19. 19 Jul, 2011 1 commit
  20. 01 Jun, 2011 3 commits
  21. 14 May, 2010 1 commit
  22. 10 May, 2010 1 commit
  23. 14 Apr, 2010 1 commit
    • Mike Hibler's avatar
      Changes for speeding up elabinelab server setup. · 6feda7d3
      Mike Hibler authored
      Boss/ops/fs: reboot them together after setup rather than serially.
      
      Nodes: leave them in PXEWAIT throughout the setup, until after boss has
      been rebooted.  At that point we send them the new bootinfo RESTART command
      telling pxeboot to re-DHCP and use the new info obtained (next-server) to
      contact a potentially new boss node.  This is a quick way to switch a node
      in PXEWAIT from talking to the outer boss to talking to the inner one.
      
      A significant number of rinky-dink changes were needed to do this, primarily
      adding a new state, PXELIMBO, where nodes can be sent to sit until they are
      restarted.  It turns out, just putting them in an existing state such as
      PXEWAKEUP or SHUTDOWN wouldn't work, as they tend to timeout or otherwise
      reboot.
      6feda7d3
  24. 13 Nov, 2009 1 commit
  25. 12 Oct, 2009 1 commit
    • David Johnson's avatar
      Add the ability to load images on virtnodes. For now, we just overload · c6c57bc9
      David Johnson authored
      the tb-set-node-os command with a second optional argument; if that is
      present, the first arg is the child OS and the second is the parent OS.
      We add some new features in ptopgen (OS-parentOSname-childOSname) based
      off a new table that maps which child OSes can run on which parents, and
      the right desires get added to match.  We setup the reloads in os_setup
      along with the parents.  Also needed a new opmode, RELOAD-PCVM, to handle
      all this.
      
      For now, users only have to specify that their images can run on pcvms, a
      special hack for which type the images can run on.  This makes sense in
      general since there is no point conditionalizing childOS loading on
      hardware type at the moment, but rather on parentOS.  Hopefully this stuff
      wiill mostly work on shared nodes too, although we'll have to be more
      aggressive on the client side garbage collecting old frisbee'd images for
      long-lived shared hosts.
      
      I only made these changes in libvtop, so assign_wrapper folks are left in
      the dark.
      
      Currently, the client side supports frisbee.  Only in openvz for now, and
      this probably breaks libvnode_xen.pm.  Also in here are some openvz
      improvements, like ability to sniff out which network is the public
      control net, and which is the fake virtual control net.
      c6c57bc9
  26. 01 Apr, 2009 1 commit
  27. 02 Feb, 2009 1 commit
  28. 22 Dec, 2008 1 commit
    • Mike Hibler's avatar
      Hack to support command line arguments to MFS boots: if the "path" column · 32906417
      Mike Hibler authored
      in the os_info row contains a space, everything after the space is considered
      arguments.  Note that these arguments can be overridden by those in the
      nodes table for def_boot and next_boot (but not temp_boot, which has no
      corresponding boot_path and boot_cmd_line fields--something that should be
      fixed, at the same time moving all these *_boot fields into node_attributes
      and out of nodes).
      32906417
  29. 23 May, 2008 1 commit
  30. 16 Aug, 2007 1 commit
  31. 25 May, 2007 1 commit
  32. 22 May, 2007 1 commit
  33. 08 May, 2007 1 commit
  34. 04 May, 2007 1 commit
  35. 23 Apr, 2007 1 commit