GitLab

a (slightly) larger selection of NFS mount options, then just yes/no.

in the image_versions table. This new one is to handle the fact that users
are allowed to refer to an image by its generic (most recent version) or
to a specific image. We do not want to duplicate image imports anymore,
which is what we have been doing.

Also add a missing regex.

instead of doing nothing.

   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.