having ptopgen put it into the advertisement.

devices with network interfaces. Emulab's spp and bbg nodes are
examples, but I did all that by hand inserting sql. An spp node is a
shared node with some interfaces. Users can allocate one or more of
those interfaces and establish vlans to the interfaces. The node is a
"fakenode" in "shared" mode, and everything else falls out. The mapper
assigns virtual nodes until all of the interfaces are allocated,
snmpit does its work on the interfaces, and the user then does the
rest.

Anyway, to added a special device:

  boss> wap addspecialdevice -s -t goober goober1

The -t argument is the name of the node type, created if it does not
exists. The last argument is the name of the fakenode to create in the
DB. The -s option says the special device is shared. Without -s, the
device is allocated exclusively.

Then to add interfaces to the device:

  boss> wap addspecialiface -b 1Gb -s cisco4,100,100 goober1 eth0

The -b option is the speed (either 100Mb or 1Gb). The -s option is the
switch side of the interface (switchname,card,port). The last two
arguments are the nodename and iface name for the interfaces table.

After the interface and wires table entry are added to the DB, snmpit
is called to put the switch port into tagged mode (if the node is
shared). To skip the snmpit step, add the -t option.

Integrated into install process. Now it is a part of the exclusive sbin club.

node. There auth method has to be ssh-key in the DB, since I did not
feel like dealing with password auth and the required tty stuff.

Appears to be a known problem (well, feature). So, I added ilo3 as a
type and use that to send the proper termination (formfeed).

shared, I mean that an experiment can request that a port be put into
a vlan belonging to another experiment. This started out as a hack to
support openflow enabled vlans in Geni, but then I got a request to
make it a little more general purpose. You all know how that goes.

Okay, say you have an experiment E1 in some project and that
experiment has a link or lan call "lan0". You want other experiments
to be able to stick ports in that vlan. On boss, you would do this
after E1 is swapped in:

boss> wap sharevlan -o testbed,E1 lan0 mysharedlan

The -o option says to make the vlan open to anyone; without that
option, only admins can swap in an experiment that requests a port in
lan0.  The token "mysharedlan" is just a level of indirection for the
NS file (or rspec).

Next you create a new experiment E2, and in your NS file:

	$ns make-portinvlan $n1 "mysharedlan"

which says to create a lan with a interface on node n1, in the vlan
named by the token mysharedlan. The token keeps specific pid/eids out
of the NS file. 

When E2 is swapped in, assign does its thing, and the selected port is
added to the members list for lan0 in testbed,E1 and then we call
snmpit with the syncvlansfromtables (-X) option to get the port added.

When E2 is swapped out, we undo the members list and call snmpit with
the -X option again.

The access issue is a bit of hack of course (open or admins) but I did
not want to invent a new permission mechanism (yet).

And of course, this is still a work in progress.

geniuser).

/etc/emulab. So stick the isvgaonly file in both places!

management interfaces more of a first class citizen instead of a
hack. New script:

management_iface -t <type> -a [key|pswd] [-s <switchinfo>]
                        <node_id> mac IP arg1 arg2
management_iface -r <node_id>
  -h       This message
  -t type  Management type; ilo, ilo2, drac
  -s info  Optional switch info; switch,card,port
  -s -     Search output of switchmac to find switch info
  -a pswd  Password auth; provide login and password.
  -a key   SSH key auth; provide login and key path.
  -r       Remove management interface from DB.

which adds the management interface to the database (interfaces,
outlets and outlets_remoteauth. Optionally adds the wires table
entry if you add -s option. Uses switchmac to find the switch info or
you can specify it on the command line. So for example, here is what I
did to add the ilo2 interface for a node:

management_iface -t ilo2 -a pswd -s - pc1 e8:39:35:ae:c9:7c \
                 155.98.34.100 elabman mypasswd
or
management_iface -t ilo2 -a key -s - pc1 e8:39:35:ae:c9:7c \
                 155.98.34.100 elabman /root/.ssh/somekey

Of course someone had to have added the elabman user and key or
password to the ilo config via its interface. 

* dhcpd_makeconf will add local node management interfaces to the
  config file. We can set them to dhcp instead of hardwiring the IP in
  the management interface.

* The DB changes add a management type to the enums in the interfaces
  and wires table, and updates the existing interface entries.

install script, but I pulled out to create an independent script).
This works on both freebsd and linux based MFSs. The intent is to do
all of the localization automcatically for site admins, so that they
can import new MFSs more easily. This is also used from the new
install code to bring in the initial MFSs and localize them.

Here is what we localize:

* The timezone is copied from boss:/etc/localtime to mfs:/etc. Ryan
  says the upcoming version of the linux MFS will actually use
  localtime. 

* Copy boss:/usr/testbed/etc/{emulab.pem,client.pem} to mfs:/etc/emulab. 
  The former is for TPM, the later for the ssl version of tmcc.

* Copy out boss root ssh keys (pub) to mfs:/root/.ssh/authorized_keys.
  In an ElabInElab we take care to combine with outer boss keys.

* Copy out the image ssh host keys. These are the keys that we put on
  every image to avoid the ssh host key change sillyness. See notes
  below on how these keys are initialized on an existing emulab. The
  keys are copied from boss:/usr/testbed/etc/image_hostkeys to
  mfs:/etc/ssh directory.
  
* Initialize the root and toor passwords from a new sitevar named
  images/root_password (which is the encryption hash, not plain
  text). See notes below on how this sitevar is initialized on an
  existing emulab.

About initializing the host keys and the root password hash ... I
added a new update script (27) that will go out to the current frisbee
MFS and mount it, grab the current keys and password hash, and put
them into place on boss. At the moment I only look for a FreeBSD
frisbee MFS, since not too many people are running the linux mfs, and
this was hard enough as it is!

For a new installation, a new install phase script will build the them
and install into /usr/testbed/etc/image_hostkeys. I have not dealt
with the password yet.

with testbed-control, and then I reboot boss, I do not want the
daemons to start up until I call testbed-control again.

job. For the geni racks. Not complete yet, just getting it into the
repo.

tbadmin.

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.

Supporting the uploader through the cnet firewall right now would require
opening up every possible unprivileged TCP port. Don't want to go there.

image, I added it to grantimage:

	boss> grantimage -a pid,osname

and to revoke:

	boss> grantimage -r -a pid,osname

image_permissions stores access info for images. You can share an
image with a user or a group (project), and you can specify write
access to allow updating the image in place. Note that write access
does not allow the descriptor to be modified, only the image itself.
Well, that is how it will be after Mike changes mfrisbeed.

The front end script to modify permissions is grantimage:

	boss> grantimage -u stoller -w tbres,myimage
	boss> grantimage -u stoller -w tbres,myimage

which grants write access to stoller. Or:

	boss> grantimage -g testbed,testbed tbres,myimage

which grants access to the testbed project. Notice that you can
specify subgroups this way.

	boss> grantimage -l tbres,myimage

will give you a list of current permissions. To revoke, just add -r
option:

	boss> grantimage -g testbed,testbed -r tbres,myimage

Who is allowed to grant access to an image? 1) An adminstrator of
course, 2) the image creator, and 3) any group_root in the group that
the image belongs to. Being granted access to use an image does not
confer permission to grant access to others.

One last task; while the web interface displays the permissions, there
is no web interface to modify the permissions; users will still have
to ask us for now.

This reverts commit fc89eb38.

Checked in a bunch of crap that was unrelated.

When downloading an image, start the frisbeed process with the minimum set of
gids necessary to access the image. This includes the unix gid of the
project that the image is in and, optionally, the unix gid of the project
subgroup if the image is part of one.

Previously, we just use the gid set of the uid of the swapper of the
experiment. Not only was this excessive, but it might also not include the
gids needed in the case of a "global" image that is not in the world-readable
/usr/testbed/images directory.

(cherry picked from commit 6356721e)

Newer PHP complains if you don't explicitly set your timezone, so this script
allows us to determine it in a scriptable way as part of {boss,ops}_install.

You would think this info would be readily available, but I couldn't find an
easy way!

For the backend script to properly grok it, we must set wholedisk=1 and
loadpart=<which ever partN_osid is defined>.

Anal alert: output the attributes in sorted order, cuz that is the kinda
guy I am.