the same vlan to be on multiple phys devices.

the number is fixed and small.

script.

Subbosses authenticate to the XML-RPC server as elabman, which means the
resulting server process runs as the elabman user.  Unfortunately, this
doesn't work well when the subboss wants to launch a frisbeed for an
image for which elabman doesn't have read permission (like images under
/proj).

To fix this, a setuid wrapper script is run instead of trying to run
frisbeelauncher directly.  This script makes sure the calling user is
elabman, and then becomes root and execs frisbee_launcher.

The protogeni-wrapper change inadvertently lost the disabling of UUID
checks in the AM. The AM module is now recognized and certs without
UUIDs are allowed to pass through rather than generating an error.

This change required that the path parsing be moved earlier. The path
parse itself remains exactly the same, it just happens earlier on when
processing a request.

The -a flag causes the new authority to be written to the geni-cm
database. This is needed by the AM to allow new slice authorities in
development mode. In production mode the existing args would probably
suffice.

Resurrect the disabling of UUID checks that was lost in the change to
a unified protogeni-wrapper. Moved the disabling to the GeniAM module
to avoid premature loading of GeniDB in protogeni-wrapper.

The parallelization code in the stack module puts the devices in
child processes, which means that when they lookup their allowed
VLAN ranges, they can no longer update the value in the parent
stack object (which is in a different process). So, we have to do
it here too.

Some Ciscos limit the number of trunks on which you can configure
'extended range' VLANs (above 1k). This includes clearing them from
the trunk (eg. you don't actually have to be *using* them to get
this error). So, as a workaround, if the stack is not conifgured
to use VLANs over 1k, don't clear this range when cleaning out
trunk ports.

Add the short sha1 to the end of the subject line for MUAs that thread by
subject instead of References/In-Reply-To headers.

You would think I would have got this right, since I got bit by this
just a week ago!  Long-term memory...who needs it!

nodes; pickup up linkdelays for all nodes on the shared node.

Hack, hack...

This allows nsverify to be built on FreeBSD 7+.  Based on patches from John
Hickey <jhickey@isi.edu> and Serge van Ginderachter <serge@vanginderachter.be>,
thanks guys!

I also moved all the logic for downloading/patching the tarball from the
GNUmakefile into ns-patch.sh to bring this in line with our other third-party
packages that do the same.  This is in pursuit of one day having a GUDS
(Grand Unified Download Script).

a merge.

It's no longer necessary to specify '-l -l' when listing orphaned
VLANs, -O implies wanting to see VLANs that aren't in the database.

This reverts commit efdf34a0.

Attempt to solve some problems with trunk creation by reverting
this change. It's not *certain* that this change is at fault, but
I want to factor out some possible causes

trivial link betweem two VMs on the same phys host. There is no vlan,
but we can fake things enough so that everything looks as it should by
creating a bridge device with no vlan devices in it.

This reverts commit a31f1a5b.

this, you could fix a VM to specific physical node, but not to another
node in the topology. This change allows you to do something like the
following:

set n1 [$ns node]
set n2 [$ns node]
set n3 [$ns node]
set v1 [$ns node]
set v2 [$ns node]
set v3 [$ns node]

tb-set-hardware $v1 pcvm
tb-set-hardware $v2 pcvm
tb-set-hardware $v3 pcvm
# Fix the VMs to other nodes in the topology.
tb-fix-node $v1 $n1
tb-fix-node $v2 $n2
tb-fix-node $v3 $n3

# This mix requires vlan encap all around
tb-set-vlink-emulation "vlan"

# A link between the two phys nodes.
set link0 [$ns duplex-link $n1 $n2 100Mb 0ms DropTail]

# A link between the two VMs.
set link1 [$ns duplex-link $v1 $v2 10Mb 0ms DropTail]

# A lan of three physical nodes.
set lan0 [$ns make-lan "$n1 $n2 $n3" 100Mb 0ms]

# A lan of three VMs
set lan1 [$ns make-lan "$v1 $v2 $v3" 10Mb 0ms]

# Lets mix things up.
set link2 [$ns duplex-link $n1 $v2 10Mb 0ms DropTail]
set lan2 [$ns make-lan "$n1 $v2 $n3" 10Mb 0ms]

tb-set-node-os $n1 FEDORA8-OVZ-STD
tb-set-node-os $n2 FEDORA8-OVZ-STD
tb-set-node-os $n3 FEDORA8-OVZ-STD
tb-set-node-os $v1 OPENVZ-STD
tb-set-node-os $v2 OPENVZ-STD
tb-set-node-os $v3 OPENVZ-STD