1. 01 Jun, 2017 1 commit
  2. 31 May, 2017 1 commit
  3. 20 Oct, 2016 1 commit
  4. 22 May, 2015 1 commit
  5. 25 Nov, 2014 1 commit
  6. 25 Sep, 2014 1 commit
  7. 01 Jul, 2014 1 commit
  8. 19 Oct, 2012 1 commit
  9. 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
  10. 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
  11. 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
  12. 17 Aug, 2011 1 commit
  13. 01 Jun, 2011 3 commits
  14. 13 Nov, 2009 1 commit
  15. 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
  16. 02 Feb, 2009 1 commit
  17. 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
  18. 23 May, 2008 1 commit
  19. 14 Mar, 2007 1 commit
  20. 15 May, 2006 1 commit
  21. 15 Nov, 2004 1 commit
  22. 29 Oct, 2004 1 commit
    • Leigh Stoller's avatar
      Such a brutal ElabinElab hack ... When trying to swapin an actual · 0749ef9c
      Leigh Stoller authored
      experiment from the web interface, I ran into another control network
      problem, this time in bootinfo. When a node is sitting free, it waits
      in pxeboot for a bootinfo packet from boss to tell it what to do (this
      is different then when the node is allocated, and bootinfo tells it
      what to do in a reply to the initial request). In the PXEWAIT case, we
      *send* it a packet, addressed to its *control network* address, which
      in the inner DB, is on the inner control network, but of course PXE is
      really using the outer control network, so packets addressed to inner
      control network are never seen by pxeboot.
      
      This is the only (known) case of this happening, and rather then try
      for some general, over engineered solution, I did something unusual,
      and put in a hack, ifdefed for ELABINELAB (meaning, its an inner
      elab). I know, you're thinking, how could he have done such a thing,
      its so unlike him!
      
      Well, it was damn easy! Anyway, this little hack checks the DB for an
      interface tagged as role='outer_ctrl' and uses that IP instead of the
      inner control network. When I create the inner DB from the outer DB, I
      was already leaving the outer control network in place so that
      bootinfo could find the proper node (again, cause the bootinfo request
      packets are coming from the outer control network, and so its IP would
      not match any nodes in the DB).
      
      I'd like to say that this is the last problem with swapin, but I see
      in my other window that the event scheduler failed to start on inner
      ops with some silly error ssh permission denied error. Whats that all
      about?
      0749ef9c
  23. 13 Oct, 2004 1 commit
  24. 21 Jan, 2004 1 commit
  25. 12 Jan, 2004 1 commit
    • Leigh Stoller's avatar
      Death to proxydhcp; one less specialized daemon. DHCP will return the · 2b2b8ca1
      Leigh Stoller authored
      filename to boot, and all local nodes will boot the same pxeboot kernel,
      which has been extended to allow for jumping directly into a specific MFS
      (in addition to the usual testbed boot into a partition or multiboot
      kernel).
      
      Bootinfo and the bootwhat protocol extended to tell the client node what
      MFS to jump into directly, without a reboot. pxe_boot_path and
      next_pxe_boot_path are now deprecated, with bootinfo used to control which
      MFS to boot. Nodes now boot a single pxeboot kernel, and bootinfo tells
      them what to do next.
      
      Bootinfo greatly simplifed. temp_boot_osid has been added to allow for
      temporary booting of different kernels (such as with ndoe_admin or
      create_image). Unlike next_boot_osid which is a one-shot boot,
      temp_boot_osid causes the node to boot that OS until told not too.
      
      next_boot_path and def_boot_path in the nodes table are now ignored.
      Bootinfo gets path info strictly from the os_info table entry for the osid
      given in one of def_boot_osid, temp_boot_osid, or next_boot_osid.  This
      makes the selection of what to do in bootinfo a lot simpler (and for
      TBBootWhat in libdb). The os_info table also modified to include an MFS
      flag so that bootinfo knows to tell the client that the path refers to an
      MFS and not a multiboot kernel.
      
      Change to boot sequence; free nodes no longer boot into the default OSID.
      Instead, they are told to wait in pxeboot until told what to do, which
      will typically be when the node is allocated and a specific OSID
      picked. If the node needs to be reloaded, then the node is told to jump
      directly into the Frisbee MFS, which saves one complete reboot cycle
      whether the node has the requested OS installed, or not.  New program
      added called "bootinfosend" that is used by node_reboot to "wake up" up
      nodes sitting in pxewait mode, so that they query bootinfo again and boot.
      
      node_reboot changed to look at the event state of a node, and use
      bootinfosend to wake up nodes, rather then power cycle, since pxeboot does
      not repsond to pings. Retry (if the UDP packet is lost) is handled by
      stated.
      
      Event support added to bootinfo, to replace the event generation that was
      in proxydhcp. I have not included the caching that Mac had in proxydhcp
      since it does not appear that bootinfo packets are lost very
      often. Cleaned up all of the event and DB queury code to use lib/libtb for
      DB access, and moved all of the event code into a separate file.  The
      event sequence when a node boots now looks like this:
      
      	'SHUTDOWN'    --> 'PXEBOOTING'  (BootInfo)
      	'PXEBOOTING', --> 'PXEBOOTING'  (BootInfo Retry)
      	'PXEBOOTING', --> 'BOOTING'     (Node Not Free)
      	'PXEBOOTING', --> 'PXEWAIT'     (Node is Free)
      	'PXEWAIT',    --> 'PXEWAKEUP'   (Node Allocated)
      	'PXEWAKEUP',  --> 'PXEWAKEUP'   (Bootinfo Retry)
      	'PXEWAKEUP',  --> 'PXEBOOTING'  (Node Woke Up)
      
      Change stated to support resending PXEWAKEUP events when node times out.
      After 3 tries, node is power cycled. Other minor cleanup in stated.
      
      Clean up and simplify os_select, while adding support for temp_next_boot
      and removing all trace of def_boot_path and next_boot_path processing.
      Remove all pxe_boot_path and next_pxe_boot_path processing.  Changed
      command line interface to support "clearing" fields. For example,
      node_admin changed to call os_select like this to have the node
      temporarily boot the FreeBSD MFS:
      
      	os_select -t FREEBSD-MFS pcXXX
      
      which sets temp_boot_osid. To turn admin mode off:
      
      	os_select -c -t pcXXX
      
      which says to clear temp_boot_osid.
      
      sql/database-fill-supplemental.sql modifed to add os_info table
      entries for the FreeBSD, Frisbee, and newnode MFS's.
      
      Be sure to change dhcpd config, restart dhcp, kill proxydhcp, restart
      bootinfo,
      2b2b8ca1
  26. 30 Jan, 2003 2 commits
  27. 18 Oct, 2002 1 commit
    • Mac Newbold's avatar
      Merge the newstated branch with the main tree. · 5c961517
      Mac Newbold authored
      Changes to watch out for:
      
      - db calls that change boot info in nodes table are now calls to os_select
      
      - whenever you want to change a node's pxe boot info, or def or next boot
      osids or paths, use os_select.
      
      - when you need to wait for a node to reach some point in the boot process
      (like ISUP), check the state in the database using the lib calls
      
      - Proxydhcp now sends a BOOTING state for each node that it talks to.
      
      - OSs that don't send ISUP will have one generated for them by stated
      either when they ping (if they support ping) or immediately after they get
      to BOOTING.
      
      - States now have timeouts. Actions aren't currently carried out, but they
      will be soon. If you notice problems here, let me know... we're still
      tuning it. (Before all timeouts were set to "none" in the db)
      
      One temporary change:
      
      - While I make our new free node manager daemon (freed), all nodes are
      forced into reloading when they're nfreed and the calls to reset the os
      are disabled (that will move into freed).
      5c961517
  28. 20 Sep, 2002 1 commit
  29. 07 Jul, 2002 1 commit
  30. 22 Jun, 2001 1 commit
  31. 06 Jun, 2001 2 commits
  32. 09 May, 2001 1 commit
  33. 03 May, 2001 1 commit
  34. 02 Jan, 2001 1 commit
  35. 14 Dec, 2000 1 commit