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.

This actually seems to have startled the port build.

Starting with FreeBSD 11, rsa1 keys are no longer valid/accepted.
N.B. users can still import rsa1 keys, we might want to reconsider that.

next life.

page.

approved without a reason.

* New tables to store policies for users and projects/groups. At the
  moment, there is only one policy (with associated reason); disabled.
  This allows us to mark projects/groups/users with enable/disable
  flags. Note that policies are applied consecutively, so you can
  disable extensions for a project, but enable them for a user in that
  project.

* Apply extensions when experiments are created, send mail to the audit
  log when policies cause extensions to be disabled.

* New driver script (manage_extensions) to change the policy tables.

* Change the units of extension from days to hours along the extension
  path. The user does not see this directly, but it allows us to extend
  experiments to the hour before they are needed by a different
  reservation, both on the user extend modal and the admin extend modal.

  On the admin extend page, the input box still defaults to days, but
  you can also use xDyH to specify days and hours. Or just yH for just
  hours.

  But to make things easier, there is also a new "max" checkbox to
  extend an experiment out to the maximum allowed by the reservation
  system.

* Changes to "lockout" (disabling extensions). Add a reason field to the
  database, clicking the lockout checkbox will prompt for an optional
  reason.

  The user no longer sees the extension modal when extensions are
  disabled, we show an alert instead telling them extensions are
  disabled, and the reason.

  On the admin extend page there is a new checkbox to disable extensions
  when denying an extension or scheduling termination.

  Log extension disable/enable to the audit log.

* Clear out a bunch of old extension code that is no longer used (since
  the extension code was moved from php to perl).

This can happen if two commits to the repo happen very quickly. Spin
for a little bit before giving up. Not a great solution, needs more
thought when I have time.