table.

Mike's 'showmac' kernel) from cature logs, and generate SQL commands
to enter the interfaces it finds into the database.

capable of rerunning hunt, and it was too confusing anyway.

older tty version at the same time. We use that older version outside
the testbed.

Need to reset the getremote state so that we can do a second search
in /etc/remote file.

is actually used anymore.
Added a "generic" entry to /etc/remote so that we do not need tip
entries for each node; they all look the same anyway.
Change tip to lookup up generic /etc/remote entry, just to make
tip happy. The acl file comes from the tiplogs directory, as
set in the header file.

Takes information recorded during the wiring process, and generates SQL
commands to insert these wires into the database. Should be a big timesaver.

down.

machine.

with reference to tbstyle-plain.cc stylesheet. White background, smaller
fonts. This header is mostly ignored in non-printable, except for the
path, which is wrong in subdirs, so more fixes to change the base path
when docwrapping files in subdirs. Seems to work okay, but maybe not the
best solution.

as stored in the portmap table.

Updated to use ifaces instead of cards in delays table, since something stopped filling in card fields...

distributed tiplines (and capture processes).

unpredictable it is.

generate the summaries.

along with notes and delegation of responsibility for each.

Very specific to our current addition of ISP1100s, but could serve as
a useful record for future expansion or other sites.

real ones installed on our server. So to avoid confusion, or installation
of these older versions, I am removing them.

So while running client we specify in the command line whether Lans Exist in the
network or not. Making this a part of the query generated by the client node we
have some more flexibility!

queries..

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.

Fix up the print statements so that DOS slice numbering is consistent.
Remove a few printfs that were not under the debug flag.