1. 22 Nov, 2004 1 commit
  2. 17 Nov, 2004 1 commit
  3. 16 Nov, 2004 1 commit
  4. 15 Nov, 2004 13 commits
  5. 11 Nov, 2004 2 commits
    • Mike Hibler's avatar
    • Leigh B. Stoller's avatar
      Checkpoint the client side of ElabInElab changes in case some whacko is · a5c1e591
      Leigh B. Stoller authored
      dying to see whats going on. These changes can go into new images; it will
      be ignored in non ElabInElab experiments;
      
      rc.inelab: A terrible hack that I now regret. The whole point of this
      script to allow inner boss/ops to 1) play by the standard state machine goo
      (ISUP) for the outer emulab. That way os_setup, node_reboot, etc all work
      when dealing with setting up the inner elab. 2) Since the inner
      control can fall on any of the interfaces (as picked by assign), we
      need to still do ifc/route configuration using tmcd. At the time I did
      this, I expected that swapmod/swapin/swapout would be possible and
      that boss/ops would be coming in on different nodes using different
      interfaces for the inner control net, and that I would want to ask
      each reboot. Well, I think swapping an inner emulab is a really long
      way off, maybe so far off I'll be retired by that time.
      
      rc.mkelab: A lot of very ugly code that turns a node into an inner ops
      or boss. I won't bother to describe this code other than to say the
      operating model for this rev is to create a fully functional inner
      emulab based on the DB state provided by the outer emulab. Currently,
      the current testbed software is expected to be in the /proj tree, and
      a full boss/ops install is done, followed by all kinds of
      customizations (like building accounts for members of the project,
      etc) to make it a fully function emulab with just a single project;
      the project in which the inner emulab was created.
      a5c1e591
  6. 10 Nov, 2004 1 commit
  7. 09 Nov, 2004 2 commits
  8. 05 Nov, 2004 2 commits
  9. 03 Nov, 2004 1 commit
  10. 29 Oct, 2004 1 commit
    • Leigh B. Stoller's avatar
      dhclient changes for ElabInElab. The crux of this is that inner · 3afcab05
      Leigh B. Stoller authored
      nodes are treated specially. For inner boss/ops, ignore most of what
      DHCPD returns; we need to do the DHCP so that we know what interface,
      but for the moment stuff is hardwired into /etc/rc.conf when the inner
      boss and ops are created. I can probably fix this up later as needed,
      to be more dynamic for supporting swapout/swapin of an inner emulab,
      but swapout and restore of an inner elab has som many open issues,
      that not worrying about it now.
      
      For inner nodes, the change is simple; If no hostname provided, ignore
      the DHCPD reply completely, favoring a full reply from the inner
      control network, and returning -1 from the exit hook so that dhclient
      keeps trying in the foreground.
      
      I am committing these so they get into new images.
      3afcab05
  11. 27 Oct, 2004 4 commits
  12. 26 Oct, 2004 1 commit
  13. 25 Oct, 2004 3 commits
  14. 21 Oct, 2004 1 commit
  15. 18 Oct, 2004 1 commit
  16. 14 Oct, 2004 2 commits
  17. 08 Oct, 2004 3 commits
    • Leigh B. Stoller's avatar
      ElabInElab fix: Remove use of control_iface in iptonodeid (the initial · 320dfab4
      Leigh B. Stoller authored
      query that maps the peer IP to a node in the DB). This was primarily
      used as a safety to make sure that the node_types entry really did
      match (in case the luser picked experimental addresses that conflicted
      with real testbed addresses?), but not sure this test really
      mattered. But, just to be safe, I changed it so that we check for a
      matching IP and role='ctrl'.
      320dfab4
    • Mike Hibler's avatar
      Initial steps toward a hardware-assisted (switch VLAN) firewall implementation. · 0527441a
      Mike Hibler authored
      This checkin adds the necessary NS and client-side changes.
      
      You get such a firewall by creating a firewall object and doing:
      
      	$fw set-type ipfw2-vlan
      
      In addition to the usual firewall setup, it sets the firewall node command
      line to boot "/kernel.fw" which is an IPFW2-enabled kernel with a custom
      bridge hack.
      
      The client-side setup for firewalled nodes is easy: do nothing.
      
      The client-side setup for the firewall is more involved, using vlan devices
      and bridging and all sorts of geeky magic.
      
      Note finally that I don't yet have a decent set of default rules for anything
      other than a completely open firewall.  The rules might be slightly different
      than for the "software" firewall since they are applied at layer2 (and we want
      them just to be applied at layer2 and not multiple times)
      0527441a
    • Mike Hibler's avatar
      61a152d9