Commit a0b07afa authored by Leigh B. Stoller's avatar Leigh B. Stoller

Remove cruft from aforementioned document.

parent 97f2350e
......@@ -97,70 +97,3 @@ Notes on testing.
Generating your own copy of the DB needs to be addressed.
My approach is intended to minimize the number of scripts that need to
be run through configure rewritting to get the --prefix argument into
them. I also want to enable testing from private install trees. We
also need to minimize security risks, so we can't use an environment
variable of course, since we have a number of setuid scripts that
cannot be invoking sub programs based on a path in an environment
variable. Anyway, here is my rundown.
* People test their own stuff by installing and running from thier
prefix directory. This is not as convenient as running out of your
source directory, but its the only workable solution that provides a
reasonable testing harness that looks like the real thing, and will
allow you to do testing with your own versions of things.
* We use a --prefix directory. It defaults to /usr/testbed/. This
implies we start using configure. Other configurable items we need
to consider are the name of the DB and the paths in the web page
stuff so that we can test diffferent versions of the pages, using
different versions of the DB, etc.
* All user executable "front end" programs should be installed to
${PREFIX}/bin. (ex: tbrun, tbend). This is a flat directory.
* All admin executable "front end" programs should be installed to
${PREFIX}/sbin. (ex: os_load, nalloc, tmcd). This is a flat directory.
* All of the other backend support stuff from tbsetup and other places
go into ${PREFIX}/libexec. This directory can have subdirs. The ir
parsing stuff, support perl/tcl libraries, etc.
* Configuration files go into ${PREFIX}/etc. (ex: pxe).
* There are no hardwired paths in the scripts. Any script that needs
to access another testbed program or library has to be rewritten by
configure. Something like this in "" which will get
rewritten as "script"
$ENV{'PATH'} = "$TBROOT/bin:$TBROOT/sbin:...";
$handle_ip = "$TBROOT/libexec/ir/handle_ip";
* DB name (tbdb). Same for the DB name.
* We rewrite www/defs.php3 with config, much as I do know for testing
on my home machine. This way, we can all share the web server,
running individual versions of the web pages. Your version of the
web pages can either operate on the real DB, or on your own private
version of the DB (say, tbdb-lbs) which you can create with
mysqldump for testing.
* Even though the name of the DB is not hardwired in, there are still
problems with this approach, like allocating machines from your DB
that are already allocated in the real DB! We can probably solve
this with a little trick; reserve some nodes in the real testbed DB,
and reduce the number of nodes in your private DB to exactly that
* What about things like snmpit? Well, you gotta test that out using
the real switches. As long as you can test it from your own
directory, and with a set of nodes reserved out of the testbed DB,
it should be mostly safe. Use caution though.
* Other cases like the above?
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment