see whether they are running, and their exit code if exited.

return now selects that profile.

this check, now that the image server and jacks constraints are working.

as possible since we never know that this script exists with failure
on teardown.

names that are greater the Linux max of 28 characters, and make it
backward compatible with running VMs.

Our cricket graphs have been broken since January...oops.

Use tail -r instead.

thing, and it is convenient to do the setup in the context of a different
user (say geniuser, for a slice experiment), since we are now importing all
global images into the GeniSlices project. There is still another backwards
compat problem I need to think about.

array inside of the formfields array.

user doing the image snapshot. At the image origin cluster, use this URN
to set the updater urn for the new image version, and if that urn is fot
a real local user, also set the updater,updater_idx accordingly. Lastly,
the image import *must* be done in the context of a user in the project
of the image, so fall back to using the image creator.

origin cluster; this change just added the slot we need in the DB.

and always import into the GeniSlices project. Previously, images were
being imported into the project of the slice experiment, by the geniuser.

When PROTOGENI_LOCALUSER is turned off, this change does not affect
anything, since it is still geniuser doing the import, and all imported
images are consider global and thus cross-project usable. So where we stick
the image is not really important, but putting all geni imported images in
one place is more convenient (sure makes it easier to find them). But more
important, this change is backwards compatible with existing imports. 

Later, if the source image is updated, and a new user (in another project)
uses that image, the update (pulling the updated image scross) is done by
geniuser (who is the leader of all geni holding projects), who has write
access to the image whatever project it is in. 

What about when PROTOGENI_LOCALUSER is turned on? There are actually two
sub cases here.

1. The user is using an aggregate in a different domain then their SA. Say,
   when a Cloudlab Portal user is creating an experiment at the Clemson
   cluster (which has PROTOGENI_LOCALUSER=1). In this case, clemson does
   not know anything about the user anyway, and so its pretty much like the
   case described above since everything is done by the geniuser in holding
   projects owned by the geniuser.

2. The user is using the same aggregate as their SA. Say, when a Cloudlab
   Portal user is creating an experiment at the Emulab cluster. In this
   case Emulab knows the user and project, and everything is done as that
   user in the actual project (there is no geni holding project).

   If we import the image into that project as the actual user, we are okay
   at first; as above, all images are global and cross-project, so anyone
   can use it. But what if the source image changes and then a different
   user in a different project tries to use it? The backend is going to try
   to import the new version, but that fails cause the current user does
   not have write access to the image.

   Hence the real reason for this change; if always import into GeniSlices
   as geniuser, we do not get into this permission problem.

descriptor from getting created, so we fail sooner rather then waiting till
later after the resources are allocated and we discover that we are not
allowed to ete the image file.

was causing an undefined variable.

disable the console and console log option in the context menu.

parameterized profile.

tainted nodes.

Pass authinit index, not tag, to targetgroup.
Set serial number via extent, not target.

when doing image tracker stuff.