fooling around with.

Rev 20 of the tarball has no new function, it is just slimmed down.
I replaced our large statically linked binaries with dynamically linked ones.
Also found and stripped a couple of other binaries.

The resulting tarball goes from 5.7MB to 0.9MB.

The Makefile changes are to incorporate the NOSTATIC=1 environment hack
to enable building the dynamic binaries above.

of event/program-agent/program-agent.c

But opsrecv and friends were never officially installed, so took care of
that too (conditional on PELABSUPPORT in the defs file).

Two-day boondoggle to support "/scratch", an optional large, shared filesystem
for users.  To do this, I needed to find all the instances where /proj is used
and behave accordingly.  The boondoggle part was the decision to gather up all
the hardwired instances of shared directory names ("/proj", "/users", etc.)
so that they are set in a common place (via unexposed configure variables).
This is a boondoggle because:

1. I didn't change the client-side scripts.  They need a different mechanism
   (e.g., tmcd) to get the info, configure is the wrong way.

2. Even if I had done #1 it is likely--no, certain--that something would
   fail if you tried to rename "/proj" to be "/mike".  These names are just
   too ingrained.

3. We may not even use "/scratch" as it turns out.

Note, I also didn't fix any of the .html documentation.  Anyway, it is done.
To maintain my illusion in the future you should:

1. Have perl scripts include "use libtestbed" and use the defined PROJROOT(),
   et.al. functions where possible.  If not possible, make sure they run
   through configure and use @PROJROOT_DIR@, etc.

2. Use the configure method for python, C, php and other languages.

3. There are perl (TBValidUserDir) and php (VALIDUSERPATH) functions which
   you should call to determine if an NS, template parameter, tarball or
   other file are in "an acceptable location."  Use these functions where
   possible.  They know about the optional "scratch" filesystem.  Note that
   the perl function is over-engineered to handles cases that don't occur
   in nature.

Bump plab rootball version.

Bump rootball version.

bump up plab rootball version

present the per-experiment stuff is not hooked in, but will be for
templates later. Anyway, each user gets a mysql account on ops, with
password set to the same as their mailman password (which is also
their jabber password, etc). Each project gets a DB named by the
project, and each group gets a DB named by pid,gid. Users are placed
on the access lists for the DBs as you would expect.

There is a little bit of complexity to make sure that we can create
DBs on ops outside the Emulab path and grant access to them, without
Emulab getting confused or mucking things up.

I'll get a news item done ...

    - added a new defs var, TBROBOCOPSEMAIL

  * tbsetup/power_mail.pm.in:
    - add some new info to robot powerup mails

  * db/libdb.pm.in:
    - add a new function to determine if an experiment contains nodes of a
      given class/type

  * tbsetup/swapexp.in:
    - check if exp is a robot exp; that is, if it has robots or motes; if
      so, cc error msgs to TBROBOCOPSEMAIL in addition to TBOPS

Bump rootball version - event system now supported

GNUmakefile auto generated.

Bump rootball revision.

Bump the plab rootball version up.

Ready for local people to play with.

The current implementation is that we munge the mysql DB on ops directly,
underneath jabberd. We add/del users from the authreg table, and set up
buddy lists in the roster-items and roster-groups tables. modgroups will
invoke the modjabberbuddies whenever a user is added or removed from a
group, although currently I am building buddy lists for just the top level
projects.

The "My IM" link in the collaboration menu will tell the user their
jabber ID on the Emulab chat server (jabber.emulab.net) and also give
them their plain text password to plug into their chat client.

I also installed a java applet (Jeti) that is a simple chat client that
I found off the jabberware page. Like all applets, it exhibits a degree
of flakiness, but I really do not expect too many people to use it.

Entailed new instructions for manual setup as well as integration into
elabinelab framework.  First, the manual path:

setup.txt, setup-boss.txt, setup-ops.txt and new setup-fs.txt:
    Updated to reflect potential for separate fs node.  The org here
    is a little dicey and could be confusing with ops+fs vs. ops and fs.
    Has not been field tested yet.

*/GNUmakefile.in: new fs-install target.

configure, configure.in, defs-*:
    Somewhat unrelated, make min uid/gid to use be a defs setting.
    Also add config of fs-install.in script.

boss-install.in, ops-install.in and new fs-install.in:
    Handle distinct fs node.  If you have one, fs-install is run before
    ops-install.  All scripts rely on the defs file settings of FSNODE
    and USERNODE to determine if the fs node is seperate.

utils/checkquota.in:
    Just return "ok" if quotas are not used (i.e., if defs file FS_WITH_QUOTA
    string is null.

install/ports/emulab-fs:
    Meta ...

described elsewhere ...

Note that until Jay approves the new menu config, mere users will *not*
see the new collaboration menu. Only STUDLY() users will see the new
menu, although everyone will see the rest of the front page menu changes
since they are fairly minor.

enabled in the defs file:

	CVSSUPPORT=1

each project gets a stub CVS tree created (using 'cvs init') in
/proj/$pid/CVS. It is up to users obviously to do something with
that tree, and of course they have to either set their CVSROOT
env variable, or use the -d option to cvs.

The showproject page gets a link to the per-project CVS tree, using
the cvsweb interface, which I hacked up a bit to allow restricted
access to specific project trees, via a ?pid=$pid argument to the URL.
Without the ?pid argument, it falls back to normal behaviour, which is
check the cvsallowed bit in the users table, and provide access to the
Emulab source repo.

If you are curious, go here:

	https://www.emulab.net/cvsweb/cvsweb.php3/?pid=testbed

in the defs file, so that it is easier to export a default value.
The local defs-default turns it on for all of us, while the default in
configure.in is off. It is currently off by default in defs-example.

I have left the --enable-windows and --disable-windows arguments for
backwards compatability; they just override whatever the defs file
says but otherwise have no effect if not specified.

Wiki support is turned on in the defs file with a WIKISUPPORT=1 directive.

	FSNODE_IP
	EXTERNAL_FSNODE_IP

which default to ops' IP address if not set.  This allows for separate
ops/fs nodes, a config Aero has.

Also push some IP addresses (boss, ops, fs) into config.h so they can
be used in C programs.  Specifically tmcd for returning values of
"firewall variables" that can be used in default firewall rules.
But I will likely wind up putting the var/value pairs in the DB rather
than compiling them into tmcd.

request, beef up named setup so that sites like DETER are handled
properly. I have added 4 new defs variables:

    #
    # If your boss/ops nodes are multihomed (and typically, one of the
    # networks is a public routable network, and the other is an internal
    # unroutable network), then define the the external addresses here (and
    # the internal addresses above).
    #
    EXTERNAL_BOSSNODE_IP=$BOSSNODE_IP
    EXTERNAL_USERNODE_IP=$USERNODE_IP

    #
    # As above, if you have internal and external networks, define the
    # external network here, and the internal network above.
    #
    EXTERNAL_TESTBED_NETWORK=$TESTBED_NETWORK
    EXTERNAL_TESTBED_NETMASK=$TESTBED_NETMASK

which if not set default to the internal values. When the external and
internal networks are different, generate two sets of reverse zone
files and two forward files (one internal and one external).

variable in the defs file. Nice for elabinelab to avoid inner named
from having to do too much work.

(config files) can be localized:

	C                      = @SSLCERT_COUNTRY@
	ST                     = @SSLCERT_STATE@
	L                      = @SSLCERT_LOCALITY@
	O                      = @SSLCERT_ORGNAME@

Which are initialized locally to:

	SSLCERT_COUNTRY="US"
	SSLCERT_STATE="Utah"
	SSLCERT_LOCALITY="Salt Lake City"
	SSLCERT_ORGNAME="Utah Network Testbed"

Also added an "apache" target which will generate an initial cert/key
for the apache server. This is a self signed certificate of course, which
is fine for getting a new site off the ground. Note that the cert/key are
installed during by install/boss-install.

parameters in the defs file. Pretty simplistic at the moment, but will work
for our current setup, and for elabinelab. Rob is gonna either laugh or
shoot me.

the defs file when PLABSUPPORT=1 or an error is raised by configure.  Whenever
the official rootball name/version needs do be bumped, do so in defs-default.
You may track the defs-default rootball name in your defs file, or use your
own divergent name for testing.

* Added 'leaseend' column to plab_slices table.

A couple of things:

1) Added PLAB_SLICEPREFIX so that we can separately instantiate plab slices
from mini, or elsewhere.  On the mainbed, its set to "emulab".  On mini, its
set to "emulab_mini".  The "emulab" part has to exist first so that the new
plab node manager doesn't nuke our dslice slivers.

2) Fixed up Plab.getFree() so that it doesn't try to add the same IP twice
to the DB if a new one is found, and listed more than once.