Now that I know the actual exitval, maybe I can fix the actual
problem!

unanticipated breakage. If that happens, just need to back out the
changes under the "suexec-stuff" tag. However, the better solution will
probably be to fix the PHP scripts that break by adding the proper
groups in the call to suexec (in the web page, see below) or by fixing
the backend Perl script that breaks.

This fix is primarily to address the problem of some users being in more
groups (cause of subgroups) then the max number of groups allowed
(NGROUPS).  The groups that really mattered (say, for creating an
experiment in a subgroup) could be left out cause they were at the end
of the list.

* suexec.c: Change how groups are handled. Instead of taking a single
  gid argument (the gid to setgid as), now takes a comma separated list
  of groups. Further, instead of doing a setgroups to the user's entire
  group list as specified in the groups file (getgroups), setgroups to
  just the groups listed on the command line, plus the user's primary
  group from the password file (this is to prevent potential breakage
  with accessing files from the users homedir, although might not really
  be necessary).

  This change is somewhat rational in the sense that in our case, suexec
  is not being used to run arbitrary user code (CGIs), but only to run
  specific scripts that we say should be run. The environment for
  running those scripts can be more tightly controlled then it would
  otherwise need to be if running some random CGI the user has in his
  public html directory.

* www: Change the gid argument to SUEXEC() in a number of scripts so
  that the project and subgroup are explicitly given to suexec, as
  described above. For example, in beginexp:

	SUEXEC(gid, "$pid,$unix_gid", ....);

  Aside: note that project names (pid) are always one to one with their
  unix group name, but subgroup names are not, and *always* have to be
  looked up in the DB, hence the "unix_gid" argument.

  Script breakage should require nothing more then adding the proper
  group to the list as above.

supporting both a shell script driven interface, plus the newer XMLRPC
interface. This change removes the script driven interface from boss,
replacing it with just the XMLRPC interface. Since we like to maintain
backwards compatability with interfaces we have advertised to users (and
which we know are being used), I have implemented a script wrapper that
exports the same interface, but which converts the operations into XMLRPC
requests to the server. This wrapper is written in python and uses our
locally grown xmlrpc-over-ssh library. Like the current "demonstation"
client, you can take this wrapper to your machine that has python and ssh
installed, and use it there; you do not need to use these services from
just users.emulab.net. Other things to note:

* The wrapper is a single python script that has a "class" for each wrapped
  script. Running the wrapper without any arguments will list all of the
  operations it supports. You can invoke the wrapper with the operation as
  its argument:

    {987} stoller$ script_wrapper.py swapexp --help
    swapexp -e pid,eid in|out
    swapexp pid eid in|out
    where:
         -w   - Wait for experiment to finish swapping
         -e   - Project and Experiment ID
         in   - Swap experiment in  (must currently be swapped out)
        out   - Swap experiment out (must currently be swapped in)

    Wrapper Options:
        --help      Display this help message
        --server    Set the server hostname
        --login     Set the login id (defaults to $USER)
        --debug     Turn on semi-useful debugging

   But more convenient is to create a set of symlinks so that you can just
   invoke the operation by its familiar scriptname. This is what I have
   done on users.emulab.net.

    {987} stoller$ /usr/tesbed/bin/swapexp --help
    swapexp -e pid,eid in|out
    swapexp pid eid in|out


* For those of you talking directly to the RPC server from python, I have
  added a wrapper class so that you can issue requests to any of the
  modules from a single connection. Instead using /xmlrpc/modulename, you
  can use just /xmlrpc, and use method names of the form experiment.swapexp,
  node.reboot, etc.

  Tim this should be useful for the netlab client which I think opens up
  multiple ssh connections?

* I have replaced the paperbag shell with a stripped down xmlrpcbag shell
  that is quite a bit simpler since we no longer allow access to anything
  but the RPC server. No interactive mode, no argument processing, no
  directory changing, etc. My main reason for reworking the bag is to make
  it easier to understand, maintain, and verify that it is secure. The new
  bag also logs all connections to syslog (something we should have done in
  the orginal). I also added some setrlimit calls (core, maxcpu). I also
  thought about niceing the server down, but that would put RPC users at a
  disadvantage relative to web interface users. When we switch the web
  interface to use the XMLRPC backend, we can add this (reniceing from the
  web server would be a pain cause of its scattered implementation).

* Added a wrapper class so that you can invoke methods as
  experiment.swapexp or node.reboot. So instead of invoking as
  /XMLRPC/experiment can calling swapexp, you can call the server as
  /XMLRPC and call experiment.swapexp. This allows you to use a single
  connection to talk to different parts of the API. Note this is standard
  (or is it defacto) syntax in XMLRPC.

* Changed the demonstration client to talk the server this way.

* Changed paperbag to allow this as well; the xmlrpc server is invoked with
  no args, which tells it to export the wrapper interface instead of a
  specific module interface.

* A few more cleanups in the server, more permission checks, etc.

1. "make clean" will just remove stuff built in the process of a regular build
2. "make distclean" will also clean out configure generated files.

This is how it was always supposed to be, there was just some bitrot.

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.

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.

as defined in the defs-* file (e.g. "TBLOGFACIL=local2").  The default is
"local5" which is what we are setup to use so you shouldn't need to mess
with your defs- file!

perl scripts just get this value configured in when configure is run.
C programs get the value in two ways.  For programs that are intimate with
the testbed infrastructure, and include "config.h", they just get it from
that file.  For programs that we sometimes use outside the Emulab build
environment (e.g., frisbee, capture) and that don't include config.h,
the value is set via a "-DLOG_TESTBED=..." in the GNUmakefile build line.
If the value isn't set, it defaults to what it used to be (usually LOG_USER).

Still to do: healthd, hmcd (whose build doesn't seem to be completely
integrated) and plabdaemon.in (since its icky python :-)

execing the program. We had a problem with daemons that detach and
continue to run, holding open all of the same FDs that the web server
had open, including the httpd socket! So it was not possible to
restart the web server cause processes were parked on the socket
holding it open.

I think this is the wrong place for this since there numerous ways to
run programs from the web server, and using suexec is optional (can
just run programs directly). Seems like a problem with php instead,
but the fix is here cause it will solve the problem for us.

Add nscheck as allowable command.

made the queries.

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

Instead, have genlastlog update a new DB table with that info.
genlastlog was already reading login info the nodes, so might as
well use the same mechansism.

Instead, have genlastlog update a new DB table with that info.
genlastlog was already reading login info the nodes, so might as
weel use the same mechansism.

Also improved the usage message.