GitLab

the javascript code, but still playing around.

the firewall section to see if myip needs to be replaced
in the exceptions.

Set initial expiration to 16 hours for real users. Leave at 3 hours
for guests.

Watch for REFUSED return code from Renew().

is not acceptable.

the aggregate to use.

yet, mostly for testing code I added to the IG path.

if a profile is public, make sure all the nodes are firewalled.

Firewall support is preliminary and is relevant to XEN containers
only. A suitable rspec fragment for your node is:

    <emulab:firewall style=closed'>
      <emulab:exception port='80' direction='incoming' ip='myip'/>
    </emulab:firewall>

won't bother to explain, its obvious and going to change pretty
quickly. Well, I should mention that "myip" means to replace the
ip with the ip address of the caller.

Linkedelay support allows passing through basic Emulab traffic shaping
parameters, in a linkdelay only configuration.

containers.

tables for disable, since that would wipe out the rules for
domUs too.

reload.

This is because at different times, users in different subgroups can
create an experiment with the same name. If the directory has the
unix group of the initial experiment with that name, then any other future
experiment with that name but in a different subgroup will not be able
to write the directory.

This differs from the current firewall support, which assumes a single
firewall for an entire experiment, hosted on a dedicated physical
node. At some point, it would be better to host the dedicated firewall
inside a XEN container, but that is a project for another day (year).

Instead, I added two sets of firewall rules to the default_firewall_rules
table, one for dom0 and another for domU. These follow the current
style setup of open,basic,closed, while elabinelab is ignored since it
does not make sense for this yet.

These two rules sets are independent, the dom0 rules can be applied to
the physical host, and domU rules can be applied to specific
containers.

My goal is that all shared nodes will get the dom0 closed rules (ssh
from local boss only) to avoid the ssh attacks that all of the racks
are seeing.

DomU rules can be applied on a per-container (node) basis. As
mentioned above this is quite different, and needed minor additions to
the virt_nodes table to allow it.

and into the js files associated with the code.