1. 17 Nov, 2004 1 commit
  2. 05 Nov, 2004 1 commit
  3. 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
  4. 25 Oct, 2004 1 commit
  5. 28 Sep, 2004 1 commit
  6. 23 Sep, 2004 1 commit
    • Mike Hibler's avatar
      Add a "kernel rename" script for Linux which reruns LILO if the · 97f3da16
      Mike Hibler authored
      file /var/emulab/boot/runlilo exists.  This is used for post-diskload
      configuration.  The rc.frisbee script modifies the lilo.conf file if
      necessary (for disk types other than IDE) and touches the runlilo file.
      So next time Linux boots, it will re-run lilo and get everything in synch.
      
      So how do we boot Linux the first time before lilo has been rerun?
      I'm glad you asked!  rc.frisbee also runs the magic groklilo program which
      knows how to set the one-time command line in LILO.  We use this to set
      "root=802" or whatever to make it boot that first time.
      97f3da16
  7. 11 Sep, 2004 1 commit
  8. 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
  9. 21 Aug, 2004 1 commit
  10. 19 Aug, 2004 1 commit
  11. 11 Aug, 2004 1 commit
  12. 29 Jul, 2004 1 commit
  13. 21 Jul, 2004 1 commit
  14. 14 Jul, 2004 2 commits
    • Mike Hibler's avatar
      1. Better control net detection. · ff2335dd
      Mike Hibler authored
         No longer rely on looking at kernel boot time messages and extracting
         a hardware signature to determine the nodetype to then determine the
         control net.  Now we just DHCP on all interfaces and decree that the
         interface that answers is our control net interface.
      
         An extraordinary number of sleezy tricks were needed to get FBSD4,
         FBSD5, and RHL to DHCP on all interfaces without changing any standard
         scripts.
      
         For now, the nodetype/cpuspeed/chipset scripts still exist for the
         benefit of healthd, which uses the output of nodetype to determine
         what kernel module to load.  We should fix this.
      
         Side-effect: pump, the old RHL DHCP client, is history!  For older
         RHL releases, you will need a version of dhclient.
      
         Side-effect: in Linux, all non-control net interfaces are left up
         but without a legit IP address.  This is a consequence of dhclient.
         In FBSD, it was trivial to clean this up, RHL will take a little
         more work.  Up or down, it shouldn't matter.
      
      2. Add an mfs-install make target, a scaled-down version of the client
         install.  Added a mandatory DESTDIR check so you don't accidentally
         install in the wrong place on boss.
      ff2335dd
    • Mike Hibler's avatar
      fix one last thing before I remove this file entirely · 648d37da
      Mike Hibler authored
      (replaced by dhclient version)
      648d37da
  15. 13 Jul, 2004 2 commits
  16. 02 Jul, 2004 1 commit
  17. 26 Jun, 2004 1 commit
  18. 24 Jun, 2004 2 commits
    • Mike Hibler's avatar
      Improve the client-side install. With these changes, it should now be · 976133e4
      Mike Hibler authored
      possible to:
      
      	gmake client
      	sudo gmake client-install
      
      on a FBSD4, FBSD5, RHL7.3, and RHL9.0 client node.
      
      There are still some dependencies that are not explicit and which would
      prevent a build/install from working on a "clean" OS.  Two that I know of are:
      you must install our version of the elvin libraries and you must install boost.
      976133e4
    • Mike Hibler's avatar
      Prep work for DHCP discovery of control net interface: · 16c1bc02
      Mike Hibler authored
      - have pump/dhclient script record the DHCP'ed interface in
        /var/emulab/boot/control_interface
      
      - change control_interface script to first check for that file
        and use the contents if it exists
      
      Note that, as of this commit, we are still telling pump/dhclient which
      interface to DHCP on (i.e., we still determine the control net interface
      the old way to invoke pump/dhclient) so this commit is not that useful.
      
      What still has to be done is to change the startup to invoke dhclient/pump
      on all interfaces.  This turns out to be a royal, royal PITA.
      
      Stay tuned...
      16c1bc02
  19. 21 Jun, 2004 1 commit
  20. 01 Jun, 2004 1 commit
  21. 20 May, 2004 1 commit
  22. 12 May, 2004 3 commits
  23. 05 May, 2004 2 commits
  24. 26 Apr, 2004 2 commits
    • Mike Hibler's avatar
      Cleanup Makefiles: · 297019fb
      Mike Hibler authored
      1. "make clean" will just remove stuff built in the process of a regular build
      2. "make distclean" will also clean out configure generated files.
      
      This is how it was always supposed to be, there was just some bitrot.
      297019fb
    • Mike Hibler's avatar
      Added config option DISABLE_EXPORTS_SETUP for sites without proper control · 56acaee5
      Mike Hibler authored
      of their file server (aero)
      
      Extend DISABLE_NAMED_SETUP: when set, we don't set a nodes hostname to
      <name>.<eid>.<pid>.<domain> since that won't resolve.  Just stick with
      pc<XXX>.<domain> in those cases.  The various sethostname* scripts are
      now .in so that they get preprocessed to check for the option.
      56acaee5
  25. 20 Apr, 2004 3 commits
    • Mike Hibler's avatar
      Improve the client-install. You can now do a "make client-install" from · 361ee691
      Mike Hibler authored
      the top level.  This will build all the necessary binaries and then install
      them.  This works on FBSD4 and RHL7.3.  It still doesn't work on FBSD5
      (newer compiler that no longer supports a style of use of _FUNCTION_ in the
      event lib) or RHL9 (event lib needs SSL lib which has a bad dependency
      on Kerberos).  Notes:
      
      - requires that elvin libraries be installed on nodes (they are) to build
        event agents, requires linuxthreads be installed on FBSD (it is now) to
        build imagezip (which is installed, but is not strictly necessary)
      
      - installed event-agents and other binaries are stripped
      
      - added a few missing files to the source tree for bsd (healthd.conf)
        and linux (healthd.conf, rc.local)
      
      - the only thing that doesn't get rebuilt in /usr/local/etc/emulab is
        healthd, I couldn't quickly find how it gets built
      
      - uses a scaled down version of libtb with no DB functions (since mysql
        isn't installed on nodes).  N.B. DO NOT DO A CLIE...
      361ee691
    • Mike Hibler's avatar
      Cosmetic: don't unconditionally probe i2c-piix4 since that is no longer · c6d589dd
      Mike Hibler authored
      common to all our machines.
      c6d589dd
    • Mike Hibler's avatar
      changes for aero · 95e57ca0
      Mike Hibler authored
      95e57ca0
  26. 13 Apr, 2004 1 commit
  27. 12 Apr, 2004 1 commit
  28. 09 Apr, 2004 2 commits
    • Leigh B. Stoller's avatar
      First cut at client side configuration of wireless nodes. Redhat only, · c0dcd3b6
      Leigh B. Stoller authored
      no freebsd support.
      
      The primary change is that tmcd now sends down a list of setting to
      apply to each interface, and that list is turned into a hash table,
      and provided to rc.config, which passes them along to the machine
      dependent routine in liblocsetup.
      
      Then in the linux version of liblocsetup there is a bunch of new code
      to configure wireless links using iwconfig and iwpriv, using the
      settings array.
      
      All of this is bound to change once we get more experience with it.
      c0dcd3b6
    • Leigh B. Stoller's avatar
      Add probe of ath0 device. · 0790e1dc
      Leigh B. Stoller authored
      0790e1dc
  29. 19 Mar, 2004 1 commit
  30. 15 Mar, 2004 1 commit