GitLab

grotesque dhcp-on-all-interfaces hacks :-)

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.

2. after killing dhclient, "ifconfig down" the non-control net IFs
   that get left up by dhclient

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.

Rename a couple of really misleading sounding functions and make
sure that linktest does get run for linkdelay nodes.

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

(recently changed) FreeBSD version of the function.

   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.

(replaced by dhclient version)

loopback interface (yeah, Linux will really do that...)

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.

- 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...

nodes, rather then hardwiring the speed/duplex in delaysetup. We
already started doing this for phys interfaces underlying veth
interfaces, but Mike requested we do this for delay nodes as well so
that we do not hardwire 100Mb into the script.

or undotted notation.

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.

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.

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...

common to all our machines.

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.

Sometime we might want to offer an option on the experiment create page to
automatically setup the 4th partition for people.

For now they can run it as /usr/testbed/bin/mkextrafs