Turns out some combination of ebtables userspace and kernel doesn't
respect the --stp-type matcher.  So just drop all forwarded packets
destined to the bridge group address.

Anyway, this STP-less firewall bridge should be a better fit for most
switches.

Given that in an Emulab per-experiment firewall, there is only one
switch port in the experiment that is in the default control net vlan
(the firewalled nodes' ports are only in the per-experiment private
control net vlan), there is no risk of a control net loop, so it is safe
to turn off STP for the firewall's control net bridge.

However, when STP is off, Linux then seems to forward BPDUs across the
bridge (i.e. https://lists.linuxfoundation.org/pipermail/bridge/2007-April/005406.html),
which we don't want.  They intended it to support transparent bridges,
but this is not a transparent bridge, and there is no risk of it causing
a loop scenario.

we can infer if an extension request has been limited by the reservation
schedule.

we can infer if an extension request has been limited by the reservation
schedule.

I noticed that group_root could not delete users from projects. Seems
like we should allow that, but with the restriction that a group_root
cannot delete another group_root. Simple enough, right? Well thats not
how the permission system works; permission to do stuff to users is
based on who you are in the project, not who you are doing it to.

And then there are the subtle differences in permission handling between
the Classic interface and the Portal interface. And I am fully
unmotivated to fix anything in the Classic interface, hard to believe?

Anyway, most people are not going to notice anything since the bulk of
the changes affect sub groups. Sigh.

interfaces from the wires table. Helpful for debugging.

getting cleared properly after submit.

issue #366.

System images that are not released yet are stored over in /proj
until released. Imagevalidate (and other utilities) need to look
there for the image file(s) not /usr/testbed.

A new tmcd command, publicaddrinfo, just dumps the relevant bits of
virt_node_public_addr to any node in an experiment that has addrs
allocated (we don't want to restrict based on calling node_id or
pool_id).

Then the generic getfwconfig() function calls that, and sets some bits.
I also extended this function to add some dynamic clientside vars
(EMULAB_DOMAIN, EMULAB_EXPDOMAIN, EMULAB_PUBLICADDRS) so that user
firewall rule writers can use them to refer to the control net IPs of
nodes in their experiment (i.e., node-0.EMULAB_EXPDOMAIN); and so that
rules can be written over EMULAB_PUBLICADDRS -- a command-delineated
list of IP addrs).

Finally, I extended the Linux firewalling code to allow any experiment
node to answer ARPs for the public IP addresses; we can't know a priori
which node should answer -- and it could change.

This closes #353 .

renaming of card/port in the interfaces table.

The limit is the number of hours since the experiment is created, so a
limit of 10 days really just means that experiments can not live past 10
days. I think this makes more sense then anything else. There is an
associated flag with extension limiting that controls whether the user
can even request another extension after the limit. The normal case is
that the user cannot request any more extensions, but when set, the user
is granted no free time and goes through need admin approval path.

Some changes to the email, so that both the user and admin email days
how many days/hours were both requested and granted.

Also UI change; explicitly tell the user when extensions are disabled,
and also when no time is granted (so that the users is more clearly
aware).

ajax entrypoint, since we need guest access enabled for that.

The "basic shell sleezy trick" we do only creates that file if the
imagezip fails. However, if it succeeded but there happened to be
an imagezip.stat file left-over from a previous run, we would think
we failed. This would only be a problem when taking images from
somewhere other than in an MFS (e.g., taking an image-backed data
set image from the node itself).

maximum extension limit.

that already validated. Even when submitting for real, the cluster still
does the validate check and returns status.

in the same approval state; admins know what they are doing. Note that
the modification has to be feasible, we do not override that!

hand side so that you can click on it. 2) Another fix for 1 datapoint.

the way it was; note that an approved reservation cannot be shrunk,
but an unapproved reservation can shrink or grow, and we want to
keep it in the same state. This overrides the -a and -p flags.