server, turning xmlrpc/module into "program module".

I view this as temporary; paperbag exists and allows me to quickly export
the server. Long term, we need a different solution.

checking.

brought on by too much thinking and not enough hacking.

programs before I start whacking on them.

except for a few that we consider to be 'safe'.

Also, fixed a message to use @USERNODE@ instead of hardcoding to
ops.emulab.net .

from commvirtsig-branch into main trunk

Two testsuite tests fail: tbcmd and vtypes . Need to fix.

interactive shell is allowed or not - paperpag will just exit
silently if interactive shells are not allowed, but no command was
given on the command line.

This variable is now off to prevent interactive shells, but all the
interactive code is still in place, in case we ever have a reason to
want it.

Add nscheck as allowable command.

as it is on ops, so move eventsys_control to bin (from sbin)

Also improved the usage message.

testbed boot process and the freebsd pxeboot/MFS kernel. I'm hoping
this will be useful enough for users to load their own disk images,
but we shall see. Usage is simple:

	/usr/testbed/bin/node_admin on|off pcXXX

The "on" state boots the MFS, and the "off" states sets it back to
normal.

Also made the 'forbidden character' message somewhat more helpful.

/proj/<proj>/tiplogs/<exp>/ . If set, virutal node name are used for the
destination filename.

Run by batch_daemon on experiment termination, and also available to users
(through paperbag/plasticwrap) any time during an experiment.

experiment creators, and project leaders need apply.

This uses the pxe booted freebsd kernel and MFS. In addition, I use
the standard testbed mechanism of specifying a startup command to
run, which will do the imagezip to NFS mounted /proj/<pid>/.... The
controlling script on paper sets up the database, reboots the node,
and then waits for the startstatus to change. Then it resets the DB
and reboots the node so that it returns back to its normal OS. The
format of operation is:

	create_image <node> <imageid> <filename>

Node must be under the user's control of course. The filename must
reside in the node's project (/proj/<pid>/whatever) since thats the
directory that is mounted by the testbed config software when the
machine boots. The imageid already exists in the DB, and is used to
determine what part of the disk to zip up (say, using the slice option
to the zipper). Since this operation is rather time consuming, it does
the usual trick of going to background and sending email status later.

I was checking $ARGV[0] w/o making sure it was defined first.

to mere users.

the testbed list.