RELOADSETUP -> RELOADFAILED
   RELOADING -> RELOADFAILED
   RELOADFAILED -> SHUTDOWN

time we "xl create" and the guest sends in a TBSETUP. We sometimes hang up
here for reasons that elude us, but a restart from boss usually gets it
going the second time.

Also add a couple of missing state transitions that stated was whining
about.

and rspec that are used. This is to support Parameterized Profiles, where
the rspec is generated from a geni-lib script and user defined parameters.

Add manifest to apt_instance_history; I was not storing the manifest cause
I figured we could just ask the backend cluster for it. Well, that is kinda
silly, so lets store it locally. I'll have to go back and grab the
manifests for the current history entries.

Add isaptkey to user_pubkeys so that we can mark the key that comes in from
the instantiate page. This lets us keep the Emulab keys for a user
independent of the APT key, so that APT users only deal with a single key
on that path, without messing up their Emulab keys.

  "Experiment names get embedded as a DNS name (as we all know)
   and labels which end with a hyphen are illegal."

Hopefully, my last schema change related to images. If relocatable is not
set then an image must be loaded at the lba_low offset. If set, then the
image can be loaded at other offsets. Currently, all FBSD images are
relocatable courtesy of the relocation mechanism in imagezip (which can
fix up otherwise absolute offsets in an image). Sadly, Linux images are
not relocatable due to absolute block numbers in the grub partition
bootblock that we require. Ryan "taught" imagezip to relocate these, but
I need to find his changes.

Tracking this in the DB will eliminate the need to run imageinfo
from tmcd.

These are computed by imagedump for .ndz images. The plan is to
pass this info on to clients via tmcc so they can know the max disk
size required.

There will shortly be a utility to automatically update these values
when an image is created or updated. Stay tuned.

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.

Emulab can now propagate OS taint traits on to nodes that load these OSes.
The primary reason for doing this is for loading images which
require special treatment of the node.  For example, an OS that has
proprietary software, and which will be used as an appliance (blackbox)
can be marked (tainted) as such.  Code that manages user accounts on such
OSes, along with other side channel providers (console, node admin, image
creation) can key off of these taint states to prevent or alter access.

Taint states are defined as SQL sets in the 'os_info' and 'nodes' tables,
kept in the 'taint_states' column in both.  Currently these sets are comprised
of the following entries:

* usermode: OS/node should only allow user level access (not root)
* blackbox: OS/node should allow no direct interaction via shell, console, etc.
* dangerous: OS image may contain malicious software.

Taint states are inherited by a node from OSes it loads during the OS load
process.  Similarly, they are cleared from nodes as these OSes are removed.
Any taint state applied to a node will currently enforce disk zeroing.

No other tools/subsystems consider the taint states currently, but that will
change soon.

Setting taint states for an OS has to be done via SQL presently.

We have had the mechanism implemented in the client for some time and
available at the site-level or, in special cases, at the node level.
New NS command:

    tb-set-nonfs 1

will ensure that no nodes in the experiment attempt to mount shared
filesystems from ops (aka, "fs"). In this case, a minimal homdir is
created on each node with basic dotfiles and your .ssh keys. There will
also be empty /proj, /share, etc. directories created.

One additional mechanism that we have now is that we do not export filesystems
from ops to those nodes. Previously, it was all client-side and you could
mount the shared FSes if you wanted to. By prohibiting the export of these
filesystems, the mechanism is more suitable for "security" experiments.

and libraries. Rough, needs plenty more work.

Doing this required adding columns to the virt and physical blockstores
tables to mark the attributes that will be considered for mapping.
Unmarked entries just flow through to the client-side.

This commit also introduces filesystem support in the form of passing
through a mount point to the client-side.  It is left to the client to
decide what filesystem and fs options to use to setup the space, including
any logical volume aggregation required to support the request.

Specifically for pxe_boot_path settings.

about Emulab sites. Nothing private, just the equivalent of calling
testbed-version so that we know what sites exist and what software
they are running.

This is opt-out; sites that do not want to tell Utah about themselves
can set NOSITECHECKIN in their defs file.

In Utah, there is a new option in the Administration drop down menu to
print out the list from the DB.

Fix for a quibble from schemacheck.

This update includes updates to the sql update and database creation
for supporting blockstore objects in Emulab.  Three new tables are
introduced to track the physical objects, two for the virtual objects,
and one for reservation state.

URLs, as for importing images.

Add metadata_utl and imagefile_url to the images table; this is to be
used with image export/import.

We had a couple of different problems actually.

* We allow users to insert html into many DB fields (say, a project or
  experiment description).

* We did not sanitize that output when displaying back.

* We did not sanitize initial page arguments that were reflected in the
  output (say, in a form).

Since no one has the time to analyze every line of code, I took a couple of
shortcuts. The first is that I changed the regex table to not allow any <>
chars to go from the user into the DB. Brutal, but in fact there are only a
couple of places where a user legitimately needs them. For example, a
startup command that includes redirection. I handle those as special
cases. As more come up, we can fix them.

I did a quick pass through all of the forms, and made sure that we run
htmlspecialchars on everything including initial form args. This was not
too bad cause of the way all of the forms are structured, with a
"formfields" array.

I also removed a bunch of obsolete code and added an update script to
actually remove them from the www directory.

Lastly, I purged some XMLRPC code I did a long time ago in the Begin
Experiment path. Less complexity, easier to grok and fix.

	modified:   sql/database-fill.sql
	modified:   sql/dbfill-update.sql