Skip to content
GitLab
Projects
Groups
Snippets
Help
Loading...
Help
What's new
10
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
Open sidebar
emulab
emulab-devel
Commits
a0b07afa
Commit
a0b07afa
authored
Jan 08, 2001
by
Leigh B. Stoller
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Remove cruft from aforementioned document.
parent
97f2350e
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
0 additions
and
67 deletions
+0
-67
doc/testing.txt
doc/testing.txt
+0
-67
No files found.
doc/testing.txt
View file @
a0b07afa
...
...
@@ -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 "script.in" which will get
rewritten as "script"
$TBROOT = @TBROOT@;
$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
set.
* 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?
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
.
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment