1. 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
  2. 17 Aug, 2011 1 commit
  3. 01 Jun, 2011 3 commits
  4. 13 Nov, 2009 1 commit
  5. 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
  6. 02 Feb, 2009 1 commit
  7. 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
  8. 23 May, 2008 1 commit
  9. 14 Mar, 2007 1 commit
  10. 15 May, 2006 1 commit
  11. 15 Nov, 2004 1 commit
  12. 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
  13. 13 Oct, 2004 1 commit
  14. 21 Jan, 2004 1 commit
  15. 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
  16. 30 Jan, 2003 2 commits
  17. 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
  18. 20 Sep, 2002 1 commit
  19. 07 Jul, 2002 1 commit
  20. 22 Jun, 2001 1 commit
  21. 06 Jun, 2001 2 commits
  22. 09 May, 2001 1 commit
  23. 03 May, 2001 1 commit
  24. 02 Jan, 2001 1 commit
  25. 14 Dec, 2000 1 commit
  26. 13 Dec, 2000 1 commit
  27. 12 Dec, 2000 1 commit
  28. 20 Oct, 2000 1 commit
  29. 03 Oct, 2000 1 commit
  30. 22 Sep, 2000 1 commit