1. 19 Mar, 2012 1 commit
  2. 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
  3. 17 Aug, 2011 1 commit
  4. 27 Jul, 2011 1 commit
  5. 19 Jul, 2011 1 commit
  6. 01 Jun, 2011 3 commits
  7. 14 May, 2010 1 commit
  8. 10 May, 2010 1 commit
  9. 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
  10. 13 Nov, 2009 1 commit
  11. 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
  12. 01 Apr, 2009 1 commit
  13. 02 Feb, 2009 1 commit
  14. 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
  15. 23 May, 2008 1 commit
  16. 16 Aug, 2007 1 commit
  17. 25 May, 2007 1 commit
  18. 22 May, 2007 1 commit
  19. 08 May, 2007 1 commit
  20. 04 May, 2007 1 commit
  21. 23 Apr, 2007 1 commit
  22. 03 Apr, 2007 1 commit
  23. 22 Mar, 2007 2 commits
  24. 14 Mar, 2007 1 commit
  25. 04 Dec, 2006 1 commit
  26. 15 May, 2006 1 commit
  27. 29 Mar, 2006 1 commit
  28. 15 Nov, 2004 1 commit
  29. 04 Nov, 2004 1 commit
  30. 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
  31. 13 Oct, 2004 1 commit
  32. 30 Sep, 2004 1 commit
  33. 28 Sep, 2004 1 commit
  34. 19 Aug, 2004 1 commit
  35. 29 Jul, 2004 1 commit
  36. 10 May, 2004 1 commit