(mngmnt).

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.

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.

For ease of debugging.

should do.

This should never have been there in the first place, and I don't want to
carry that hack forward into the post-frisbeelauncher world.

This op_mode is intended for nodes that require configure to be pushed
to them.  Initially, it's accessible from MINIMAL.

use EmulabFeatures;

if (EmulabFeatures->FeatureEnabled("NewMapper", $user, $group, $experiment)) {
   # Do something
}
else {
   # Do something else.
}

where $user, $group, and $experiment is the current Emulab user, group, and
experiment the script is operating as. Any of them can be undef. Note that
features can easily be globally enabled or disabled (bypassing user/group
check). See below.

There are two scripts to deal with features. The easy one is the script to
grant (or revoke) feature usage to a particular user or group or experiment:

boss> wap grantfeature -u stoller NewMapper
boss> wap grantfeature -p geni NewMapper
boss> wap grantfeature -e geni,myexp NewMapper

Add -r to revoke the feature.

The other script is for managing features. To create a new feature:

boss> wap emulabfeature create NewFeature 'A pithy description'

which adds the feature to the emulab_features DB table. Use "delete"
to remove a feature from the DB.

You can globally enable and disable features for all users/groups (the
user/group checks are bypassed). Global disable overrides global
enable. There are actually two different flags. Lots of rope, I mean
flexibility.

boss> wap emulabfeature enable NewFeature 1
boss> wap emulabfeature enable NewFeature 0

boss> wap emulabfeature disable NewFeature 1
boss> wap emulabfeature disable NewFeature 0

To display a list of all features and associated settings:

boss> wap emulabfeature list

To show the details (including the users and groups) of a specific
feature:

boss> wap emulabfeature show NewFeature

Oh, if a test is made in the code for a feature, and that feature is
not in the emulab_features table (as might be the case on other
Emulab's), the feature is "disabled".

This is a fer-now hack.  Perl 5.10 has issues with bogus taint check
triggers that appear quite often when using the SelfLoader.  Now if you put:
    SELFLOADER_DATA=""
In your defs-* file, it will disable the uses that cause problems.  Yes,
the configure script should figure out if this is needed for you, but...
another time.

That change I made to EmulabConstants.pm.in only worked around one instance
of the problem.  Apparently in perl 5.10 there is a known bug related to
taint mode and self loading?  Anyway, the short-term fix is either to move
to perl 5.12 (no thanks) or disable taint checking failures when we hit the
problem.

We get taint check failures with perl 5.10.1 when __DATA__ is in there.

starting any one of our scripts can take a second or two. That time is
spent including and compiling 10000s of thousands of lines of perl
code, both from our libraries and from the perl libraries.

Mostly this is just a maintenance thing; we just never thought about
it much and we have a lot more code these days.

So I have done two things.

1) I have used SelfLoader() on some of our biggest perl modules.
   SelfLoader delays compilation until code is used. This is not as
   good as AutoLoader() though, and so I did it with just a few 
   modules (the biggest ones).

2) Mostly I reorganized things:

  a) Split libdb into an EmulabConstants module and all the rest of
     the code, which is slowly getting phased out.

  b) Move little things around to avoid including libdb or Experiment
     (the biggest files).

  c) Change "use foo" in many places to a "require foo" in the
     function that actually uses that module. This was really a big
     win cause we have dozens of cases where we would include a
     module, but use it in only one place and typically not all.

Most things are now starting up in 1/3 the time. I am hoping this will
help to reduce the load spiking we see on boss, and also help with the
upcoming Geni tutorial (which kill boss last time).