1. 07 Jun, 2016 1 commit
  2. 13 Apr, 2016 1 commit
  3. 22 Mar, 2016 1 commit
  4. 14 Mar, 2016 2 commits
  5. 15 Dec, 2015 2 commits
  6. 30 Nov, 2015 1 commit
  7. 12 Nov, 2015 1 commit
  8. 29 Oct, 2015 1 commit
  9. 23 Oct, 2015 1 commit
  10. 01 Sep, 2015 1 commit
  11. 14 Aug, 2015 1 commit
  12. 11 Aug, 2015 2 commits
  13. 17 Jun, 2015 1 commit
  14. 27 Apr, 2015 1 commit
  15. 24 Apr, 2015 2 commits
  16. 12 Mar, 2015 1 commit
  17. 02 Mar, 2015 1 commit
  18. 26 Jan, 2015 1 commit
  19. 22 Dec, 2014 1 commit
    • Leigh B Stoller's avatar
      Add slots to apt_instances and apt_instance_history, to store the params · 1ffbbcfd
      Leigh B Stoller authored
      and rspec that are used. This is to support Parameterized Profiles, where
      the rspec is generated from a geni-lib script and user defined parameters.
      
      Add manifest to apt_instance_history; I was not storing the manifest cause
      I figured we could just ask the backend cluster for it. Well, that is kinda
      silly, so lets store it locally. I'll have to go back and grab the
      manifests for the current history entries.
      
      Add isaptkey to user_pubkeys so that we can mark the key that comes in from
      the instantiate page. This lets us keep the Emulab keys for a user
      independent of the APT key, so that APT users only deal with a single key
      on that path, without messing up their Emulab keys.
      1ffbbcfd
  20. 05 Dec, 2014 1 commit
  21. 05 Nov, 2014 1 commit
  22. 03 Nov, 2014 1 commit
  23. 02 Oct, 2014 1 commit
  24. 25 Sep, 2014 1 commit
  25. 01 Jul, 2014 1 commit
  26. 09 Jun, 2014 1 commit
  27. 06 May, 2014 1 commit
    • Mike Hibler's avatar
      Add "relocatable" flag to images table to indicate that an image can be moved. · 65de520b
      Mike Hibler authored
      Hopefully, my last schema change related to images. If relocatable is not
      set then an image must be loaded at the lba_low offset. If set, then the
      image can be loaded at other offsets. Currently, all FBSD images are
      relocatable courtesy of the relocation mechanism in imagezip (which can
      fix up otherwise absolute offsets in an image). Sadly, Linux images are
      not relocatable due to absolute block numbers in the grub partition
      bootblock that we require. Ryan "taught" imagezip to relocate these, but
      I need to find his changes.
      65de520b
  28. 05 May, 2014 1 commit
  29. 02 May, 2014 1 commit
    • Mike Hibler's avatar
      Add low/high sector numbers to the images table. · c345f7cf
      Mike Hibler authored
      These are computed by imagedump for .ndz images. The plan is to
      pass this info on to clients via tmcc so they can know the max disk
      size required.
      
      There will shortly be a utility to automatically update these values
      when an image is created or updated. Stay tuned.
      c345f7cf
  30. 25 Mar, 2014 1 commit
    • Leigh B Stoller's avatar
      Server side of firewall support for XEN containers. · 2faea2f3
      Leigh B Stoller authored
      This differs from the current firewall support, which assumes a single
      firewall for an entire experiment, hosted on a dedicated physical
      node. At some point, it would be better to host the dedicated firewall
      inside a XEN container, but that is a project for another day (year).
      
      Instead, I added two sets of firewall rules to the default_firewall_rules
      table, one for dom0 and another for domU. These follow the current
      style setup of open,basic,closed, while elabinelab is ignored since it
      does not make sense for this yet.
      
      These two rules sets are independent, the dom0 rules can be applied to
      the physical host, and domU rules can be applied to specific
      containers.
      
      My goal is that all shared nodes will get the dom0 closed rules (ssh
      from local boss only) to avoid the ssh attacks that all of the racks
      are seeing.
      
      DomU rules can be applied on a per-container (node) basis. As
      mentioned above this is quite different, and needed minor additions to
      the virt_nodes table to allow it.
      2faea2f3
  31. 17 Mar, 2014 1 commit
    • Kirk Webb's avatar
      Add taint state tracking for OSes and Nodes. · 1de4e516
      Kirk Webb authored
      Emulab can now propagate OS taint traits on to nodes that load these OSes.
      The primary reason for doing this is for loading images which
      require special treatment of the node.  For example, an OS that has
      proprietary software, and which will be used as an appliance (blackbox)
      can be marked (tainted) as such.  Code that manages user accounts on such
      OSes, along with other side channel providers (console, node admin, image
      creation) can key off of these taint states to prevent or alter access.
      
      Taint states are defined as SQL sets in the 'os_info' and 'nodes' tables,
      kept in the 'taint_states' column in both.  Currently these sets are comprised
      of the following entries:
      
      * usermode: OS/node should only allow user level access (not root)
      * blackbox: OS/node should allow no direct interaction via shell, console, etc.
      * dangerous: OS image may contain malicious software.
      
      Taint states are inherited by a node from OSes it loads during the OS load
      process.  Similarly, they are cleared from nodes as these OSes are removed.
      Any taint state applied to a node will currently enforce disk zeroing.
      
      No other tools/subsystems consider the taint states currently, but that will
      change soon.
      
      Setting taint states for an OS has to be done via SQL presently.
      1de4e516
  32. 10 Mar, 2014 1 commit
    • Mike Hibler's avatar
      Support "no NFS mount" experiments. · 5446760e
      Mike Hibler authored
      We have had the mechanism implemented in the client for some time and
      available at the site-level or, in special cases, at the node level.
      New NS command:
      
          tb-set-nonfs 1
      
      will ensure that no nodes in the experiment attempt to mount shared
      filesystems from ops (aka, "fs"). In this case, a minimal homdir is
      created on each node with basic dotfiles and your .ssh keys. There will
      also be empty /proj, /share, etc. directories created.
      
      One additional mechanism that we have now is that we do not export filesystems
      from ops to those nodes. Previously, it was all client-side and you could
      mount the shared FSes if you wanted to. By prohibiting the export of these
      filesystems, the mechanism is more suitable for "security" experiments.
      5446760e
  33. 27 Feb, 2014 1 commit
  34. 07 Feb, 2014 1 commit
  35. 29 Jan, 2014 1 commit
  36. 25 Nov, 2013 1 commit