Now let's not worry about who put it there; the important part is that
it is fixed.
(cherry picked from commit 0c9cb66d262568f076a0ec1806e5edc56c6e38a5)

(cherry picked from commit 030f0a93e4449d4006682fb84777e505e366b7ef)

And a couple of error-printf bugfixes
(cherry picked from commit e31153aee1c7da2bb92d8528f951b34b952d0eda)

need to get setup and should not be messed with.

Imageinfo hides the nastiness of what we need to do to get size or mtime
info about shared images for which the caller does not have direct access.
In these cases we need to make a proxied frisbee master server query and
parse its output.

This allows us to more easily disable a subboss in the event of a temporary
subboss outage (e.g., hardware failure). Previously we would have to remove
the related rows from the DB and restore them later.

not 000000000000.

Til we have snmpit working on the Arista, we statically configure a single
10Gb LAN and put one interface from each of the d820s into it.

This is controlled by setting the node_attribute.shared_lan_* attributes
for each node (ip,mask,mac,speed).

Til we have snmpit working on the Arista, we statically configure a single
10Gb LAN and put one interface from each of the d820s into it.

This is controlled by setting the node_attribute.shared_lan_* attributes
for each node (ip,mask,mac,speed).

that we can return the tags from tmcd even if snmpit has
not created the vlan yet.

little room.

attribute in the node_type_attributes or node_attributes table. This
value will override whatever libvnode_openvz calculates.

or the node_attributes table.

Note that I had to fix the query; the original select required that
the key be in the node_type_attributes table, else it would fail to
find it in the node_attributes table. In other words, I could not put
vgaonly on a specific node unless there was a definition in the
node_type_attributes table.

I've changed the query to use a "union" of two selects; this query is
intended to select certain attributes from node_type_attributes table,
but allow them to be overridden by entries in the node_attributes
table for the node making the request. The "union" of two selects,
allow results from the second select on node_attributes to overwrite
anything returned for the same key in the first select on
node_type_attributes.

Well, isn't that special. We had the arguments to memcpy backward (probably
dating from the time when we use bcopy instead). So instead of copying bytes
of goodness into the zeroed nonce buffer, we were copying bytes out.
Net result: a nonce of zeros.

bootwhat will now return a FLAGS=%d value corresponding to the flags
field in the boot_what struct.

NOTE: THIS REQUIRED A TMCD VERSION BUMP. We are now at version 35.
The issue was backward compatibility with existing CD/dongle boot images
which are overly strict in their parsing of the returned bootwhat values.

Added a new boot_what flag (the whole point of this) to signify if the
entity being returned is part of the "secure boot" path. This is used
by the gPXE dongle to determine whether it needs to do a trusted boot
path "sign-off" for the MFS it downloads. We used to use the name of
the MFS as our heuristic for this.

bootinfo uses the new tbdb.os_info osfeature "ontrustedboot" to determine
whether to set the flag.

As if things weren't hairy enough for the pxe_boot_path, we need a per-node
default value. This should not be confused with the next_pxe_boot_path or
pxe_boot_path fields in the nodes table, which is a per-node value but only
for the lifetime of the current experiment.

We need this new field specifically so that we can switch some, but not all,
of the d710s over to the TPM-aware pxeboot.

For the record, the select order for setting the filename field in
dhcpd.conf is:

 1. nodes.next_pxe_boot_path for node
 2. nodes.pxe_boot_path for node
 3. "pxe_boot_path" node_attribute for node
 4. "pxe_boot_path" node_type_attribute for node type
 5. don't set (i.e., use the dhcpd.conf global default).

(plumbing for disk agents).

Fixed the query for server name, ip, and mac so that it works with
multiple subbosses.  Previously the query would fail due to the
subquery returning multiple rows.

virtual nodes. We now create an interfaces table entry so that we do
not special code to find the control network interface. This entry is
delated along with the node entries when the experiment is swapped
out.

Of course, we still have existing nodes with jailip entries, so not
much code was removed, but this saves me from having to add more
special cases for XEN elabinelab, and at some point we can remove the
deprecated code.

your NS file:

	$node0 add-attribute jailip 155.98.36.229
	$node0 add-attribute jailipmask 255.255.252.0

to override the default jail ip assignment. Use this carefully of
course since there is no checking yet.

You can also do something like this:

	$myboss add-attribute XEN_EXTRADISKS "disk1:10G,disk2:10G,disk3:10G"
	$myops  add-attribute XEN_EXTRADISKS "disk1:4G,disk2:10G"

which will add these extra disks to your xen containers. Note that
this requires clientside changes from another commit to be installed
in the XEN image.

otherwise the client has no way to determine what to do, when the boot
does not involve a reload. The image must of course already exist on
the host.

stale.

Firewalls now work with nodes which require a subboss. Had to introduce new
firewall rules which skipped around the checks that no packets to/from
node control net IPs should pass through the firewall, if the IP in question
belongs to a subboss (since subboss is on the node control network). It
actually checks for all Emulab servers (boss, ops, fs or any subboss),
so the code should work for an Emulab install which has a non-segmented
control network in which all servers were in the same subnet as the nodes.

In addition to the new rules, we also had to pass in additional information
via "tmcc firewallinfo" giving the IP/MAC of those server nodes that are on
the node control network. We use this to establish ARP entries on the
inside network so that nodes can find the servers. Since the existing
client-side firewall code in libsetup.pm would blow up if it got a line
that it didn't recognize, I had to bump the tmcd version number and add
some conditional code to tmcd.c:dofwinfo() to not return the extra info for
old versions.

Added a couple of new firewall variables EMULAB_BOSSES and EMULAB_SERVERS
that are used in the new rules. Fixed the support scripts in firewall/
to properly initialize these variables.

IMPORTANT: tmcd looks up boss, ops, fs, and subbosses in the interfaces
table to find their IPs and MAC addresses. By default, we do not create
such interface table entries for boss/ops/fs. We have them at Utah for
other reasons. These entries are only needed if you have a non-segmented
control network (or a subboss) and you want to firewall such nodes.
The script to initialize the firewall variables (initfwvars.pl) will
print out a warning for configurations that are affected and don't have
the entries.

When determining the frisbee server to use for a vnode, look up in the
subbosses table by the hosting pnode. This way d710 vnodes will use subboss
rather than boss for their frisbee.

This is for FreeBSD to turn off use of the CLFLUSH instruction via the
hw.clflush_disable loader var. We have encountered some opteron machines
on which this causes problems.

The attribute can be set for the node_type (via the web page for editing
node types) or the node (via brute-force SQL hackary) to override whatever
FreeBSD would do by default. This attribute is passed via tmcd to the
diskloader MFS which will fixup the loader.conf file post-frisbee.

1. Support for "one-shot" PXE booting ala the one-shot osid. Switches to
   pxelinux to boot WinPE and then switch back after done. Painful now
   because we have to HUP dhcpd everytime we change the PXE path, but we
   may be able to fix this in the future by going all-pxelinux-all-the-time.

2. Added pxe_select, analogous to os_select, for changing the pxe_boot_path
   including the one time path.

3. Added the WIMRELOAD state machine to shepherd a node through the process.
   Still has some rough edges and may need refining.

clientside requres it to be there. As noted in previous revision, the
full emulab build always includes the clientside subdir, but a
clientside build will not necessarily include the rest of Emulab.

directory.

the new library directory.

library.