home page and My Emulab page.

to assume that the leader of a stack is the switch after which it was named -
we can now name stacks things like 'Control' or 'Experiment'.

button pressed, and when.

from the Unix usr_pswd MD5 hash string.

meter for the image.

least get the rest of the users.

so unhappy with my current approach that I decided to drop that idea
for now and just specify the eid of the experiment to run.  Obviously,
it has to be an existing experiment in the same project, whose nsfile
is grabbed from the DB and shipped over to the inner boss.

Minor additions to support node mobility events:

	* lib/libtb/tbdefs.h, lib/libtb/tbdefs.c, sql/database-fill.sql:
	Add SETDEST as an event type and NODE as an object type.

	* tbsetup/ns2ir/node.tcl:
	Add location (X_, Y_, Z_) and orientation attributes for mobile
	nodes.

	* tbsetup/ns2ir/sim.tcl:
	Add a "setdest" event for node types that lets the user move a
	mobile node.

* Add security_level to experiments table.

* Add a cross link between an experiment and its elabinelab container.
  This will like change at some point, but just messing around right now.

* Add elabinelab flag, security level, and cross eid to experiment_stats table.

opmode.

       ID in firewalls table:

       column in the reserved table and not the nodes table:

Also fix a cut/paste error and renumbed some items, we went from 1.279 to
1.270 and started counting up again.

archive (and restore) of news items. Add button at top to toggle
the display of archived items. All of this is admin mode only; mere users
see just the news.

this file. If the entries already exist, the errors are silently
ignored.

assigned outer elab vlan ids.

network addresses.

used for ElabinElab.

experiment, and not count its pnodes or duration as if it was swapped
in! Thanks Kirk.

The actual fix is simple. The script to fix up the existing stats
records was a bear and took me all morning to get right! Even so, its
probably no perfect, but close enough. That script in the sql directory
and mentioned in doc/UPDATING.

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)

passed to nodes at bootup (by tmcd).