1. 14 Feb, 2005 1 commit
  2. 10 Feb, 2005 1 commit
  3. 08 Feb, 2005 1 commit
    • Leigh B. Stoller's avatar
      Remove testbed source and object trees from inner ops once the node is · ad39ab3a
      Leigh B. Stoller authored
      constructed. This is avoid the emulab source code leaking out too
      easily.
      
      We leave it on boss, since at the moment mere users do not get shells
      on inner boss, so getting the source code that way is a bit harder
      (although not that hard of course). Besides, for development its much
      nicer to have that source left on boss.
      ad39ab3a
  4. 02 Feb, 2005 1 commit
  5. 31 Jan, 2005 1 commit
  6. 28 Jan, 2005 3 commits
    • Mike Hibler's avatar
      0afe9c54
    • Leigh B. Stoller's avatar
      8d1bce8a
    • Leigh B. Stoller's avatar
      Changes to elabinelab setup. The source code for inner boss/ops no · 03cf92cb
      Leigh B. Stoller authored
      longer comes from the project directory (really, my source directory
      in the various projects). Instead, the source code comes from one of
      two places:
      
      * Using fetch on the inner ops and boss, make a special request to the
        outer webserver to return a tarball, currently stored in
        /usr/testbed/src, and created by toplevel makefile target "elabinelab".
        So, in your object tree (preferably one that is pure, without any of your
        own hacks) run "make elabinelab" and it will create the tarfile for you.
        The tarball is returned only to elabinelab experiments providing the
        experiment secret key (a variant of the existing spewrpmtar file stuff).
      
      * Using the standard tarfile install command, albiet indrectly cause of how
        we hide all of the elabinelab NS goo. So, in your NS file you can do:
      
      	tb-elab-in-elab 1
      	set ::TBCOMPAT::elabinelab_source_tarfile \
      			"/proj/testbed/tarfiles/emulab-src.tar.gz"
      
        Which will arrange for this tarfile to be installed in /usr/src, and then
        copied to the approriate place later when inner boss and inner ops are
        setup. The tarfile should be created in the top of your testbed source
        tree. This is given preference over method 1 above.
      
      XXX Currently the tarfile is unpacked in /usr/src cause install-tarfile
      does not create the target directory. As soon as we have new images, I'll
      move this unpacking to a more suitable place.
      03cf92cb
  7. 27 Jan, 2005 2 commits
  8. 26 Jan, 2005 1 commit
  9. 25 Jan, 2005 1 commit
  10. 24 Jan, 2005 1 commit
  11. 20 Jan, 2005 1 commit
  12. 14 Jan, 2005 1 commit
    • Russ Fish's avatar
      Work over the accounts and mounts part of the CygWinXP port. · 8c98fc4b
      Russ Fish authored
      Use cygrunsrv -i on sshd to "allow the service to interact with the desktop."
      Now that the sshd daemon has a desktop session context that is inherited by
      the client shell, remote home directories can work.  They start with a blank
      Windows mount context, but once a single Samba connection is made during
      login, it enables all UNC //machine/path mounts to work.  Hence the home
      directories are now CygWin mount points (no longer symlinks) to UNC paths, set
      up by rc.mounts and then shared through CygWin to all of the user logins.
      
      Get rid of the previous horrible (and fragile) hack to set up an auto-login by
      the swapin user which then automatically started a user sshd on port 2222.
      
      tmcd.c - Arrange for tmcd to provide the public key data when a special argument is
      given as "tmcc accounts pubkeys".
      
      rc.accounts - Due to permissions problems with remote-mounted authorized_keys
      files, sshd_config now uses "AuthorizedKeysFile /sshkeys/%u/authorized_keys",
      which is where rc.accounts puts the public key data.
      
      Since root, Administrator, and even SYSTEM can be locked out by permissions on
      NT, WINDOWS() variant logic to set ownership and modes on authorized_keys
      files had to be added to rc.accounts.  There is also a bug in the sshd
      "privilege separation" setreuid() dance that requires the authorized_keys
      files to be owned by SYSTEM (or be mode 644, which is slightly worse.)
      
      cygwinxp/liblocsetup.pm - Pay attention to the users' shell preferences in
      generating /etc/passwd.  Make warnings more uniform.
      8c98fc4b
  13. 11 Jan, 2005 1 commit
  14. 07 Jan, 2005 1 commit
  15. 21 Dec, 2004 1 commit
  16. 07 Dec, 2004 5 commits
  17. 02 Dec, 2004 1 commit
  18. 22 Nov, 2004 1 commit
  19. 16 Nov, 2004 1 commit
  20. 11 Nov, 2004 1 commit
    • 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
  21. 27 Oct, 2004 1 commit
  22. 26 Oct, 2004 1 commit
  23. 25 Oct, 2004 1 commit
  24. 18 Oct, 2004 1 commit
  25. 08 Oct, 2004 1 commit
    • 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
  26. 24 Sep, 2004 1 commit
  27. 25 Aug, 2004 1 commit
    • Mike Hibler's avatar
      Firewall support part III: client scripts. · b21e6942
      Mike Hibler authored
      Overview of simply firewall setup.
      
      Experimentor specifies in their ns file:
      
           set fw [new Firewall $ns]
           $fw style <open|closed|basic>
      
      to set up an "open" ("allow any"), "closed" ("deny any"), or "basic"
      (allow ICMP and ssh) firewall.  "basic is the default.  Additional rules
      can be added with:
      
           $fw add-rule <IPFW format rule>
           $fw add-numbered-rule <1-50000> <IPFW format rule>
      
      where the former implicitly numbers rules such that the firewall processes
      them in the order given in the NS file.  The latter allows explicit
      specification of the numbering.  Currently the rules are fixed strings,
      there is no variable substitution.  There is also no syntax checking done
      on the rules at parse time.
      
      We allocate an extra node to the experiment to serve as a firewall.
      Currently that node runs FreeBSD and uses IPFW.  In the initial configuration,
      all other nodes in the experiment will just be setup with a default route
      that points to the firewall node.  So all outbound traffic will pass through
      it.  Inbound traffic will still travel straight to the node.  This should
      prevent nodes from accidentally initiating attacks on the outside world.
      Long term we will of course enforce the firewall on all traffic, that should
      not have any effect on the NS syntax above.
      
      When a node boots, there will be an rc.firewall script that checks to see
      if there is a firewall for the experiment and if so, which node it is.
      This is done with the TMCD "firewallinfo" command which returns:
      
            TYPE=none
      
            TYPE=remote FWIP=N.N.N.N
      
            TYPE=<fwtype> STYLE=<fwstyle> IN_IF=<macaddr> OUT_IF=<macaddr>
            RULENO=<num> RULE="<ipfw command string>"
            RULENO=...
            ...
      
      In the case of no firewall we get back TYPE=none, and we continue as normal.
      Otherwise, there are two types of replies, one for a node that is being
      firewalled (TYPE=remote) and one for a node that is a firewall
      (TYPE=<fwtype> + RULES).
      
      In the TYPE=remote case, the firewall node indicated by FWIP.  This is
      the address we use for the default route.
      
      For TYPE=<fwtype>, we are the firewall, and we get STYLE and IN_IF/OUT_IF
      info.  Here TYPE indicates whether we should use ipfw or whatever.
      For now it is always ipfw.  IN_IF and OUT_IF may someday indicate the
      interfaces to use for the internal and external connections, right now
      both will indicate the control net interface.  So, after ensuring that
      the ipfw modules is loaded, we grab the provided RULE info, which includes
      both per-experiment and default rules, and setup ipfw.
      
      Issues to resolve:
             - synchronization: how to ensure firewall comes up first
             - how to better implement the firewalling
               (i.e., without the cooperation of the nodes)
             - support the equiv of linkdelays (on-node firewalling)?
             - allow firewalls within experiments?
               (ie., on experimental interfaces)
             - dynamic changing of firewall rules via events?
             - how to show firewall state in various web pages
      b21e6942
  28. 11 Aug, 2004 1 commit
  29. 13 Jul, 2004 1 commit
  30. 29 Jun, 2004 1 commit
  31. 25 Jun, 2004 1 commit
  32. 22 Jun, 2004 1 commit
  33. 16 Jun, 2004 1 commit