GitLab

NS files. Tweak permission check in Geni CM to also allow this,
although at this time only global images from any project are allowed.
The virt_nodes table has been changed to accommodate pid/osname
syntax:

	tb-set-node-os $nodeA somepid/someos

Note: we are really exporting permission to use images, not entries in
the os_info table (OSIDs) which is what the NS parser and protogeni CM
are using. But in fact, an image is both an image descriptor and an OS
descriptor linked together, so if you export an image or make it
global, you are implicitly doing the same for the OS descriptor. As
mentioned many times in the past, OSIDs suck.

To finish what Leigh started. Note that the master server currently only
does node (IP) based authentication so "user" permissions in the
image_permissions table are applied based on the uid of the swapper of
the experiment that the contacting node is a part of.

I do not know if this fix is correct or complete. It is however, sufficient
to make a non-protogeni elabinelab work again.

Since some DB state is pre-loaded during elabinelab setup, the initial
project leader's account was appearing as though it was already setup.

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.

We were doing this just in the CONFIG_SINGLENET case, but we have to
do this even when the experiment has a private cnet since the inner
dhcpd has to respond to PXE boots on the real control net.

[ this is a re-commit of a faulty earlier commit. ]

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.

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.

Subtle: if your elabinelab uses a VM for ops, then there will be no
myops.eid.pid.emulab.net DNS alias created outside (since there is no actual
ops node in the topo) and thus the inner ops cannot be used as a proxy for
ssh'ing to the unroutable inner nodes. In that case we use the inner boss
instead.

The former will filter out the bogus NULLs we occasionally see.

Per-repository 'keywords' may now be configured by setting the
hooks.gitmail.keyword option.  One X-Git-Repo-Keyword header is added
to commit mails for each keyword specified.

The primary use case for this is to configure related repositories
with the same keyword(s), so that commit mails for those repositories
can be filtered with a single rule rather than one for each
repository.

use this path when setting up the vlan, instead of recomputing the set
of trunks that are need. Assign does a much better job of this, so
throwing the info away is bad.

But, if there is no switch path, we still have to be careful cause the
switch infrastructure might have loops, and the existing algorithm did
not take that into account. And in fact, Utah has loops and this was
causing grief. I added a simple spanning tree function (Prim's Greedy)
to calculate a loop free set of trunks.

An added complication is if the vlans are modified on the command
line, and the there is a switch path in the DB. In this case we have
to throw that away, and revert to dumb loop free calculation.

Note that we also have to store the switch path in the vlans table,
since for swapmod/synctables, we need to know how to undo stale vlans
(which are no longer in the lans table).

actual switch details.

lans.

loopfree path from a set of trunk links.

Silly place for this, but I need it in libvtop.

table, and is a lan attribute).

will be subsumed by the NewMapper feature when that is exported to all
sites, which will happen soon.

context instead.

flag that says to reregister certs and resources. This is used from an
update script (21) that updates the certificates with a new URL that
uses http on a different port then 443.