Capserver and capture now handshake the owner/group of the tipline.
Owner is defaults to root, and the group defaults to root when the
node is not allocated. Capture will do the chmod after the handshake,
so if boss is down when capture starts, the acl/run file will get 0,0,
but will get the proper owner/group later after its able to handshake.
As a result, console_setup.proxy was trimmed down and cleaned up a
bit, since it no longer has to muck with some of this stuff.

A second change was to support multiple tiplines per node. I have
modified the tiplines table as such:

	| Field   | Type        | Null | Key | Default | Extra |
	+---------+-------------+------+-----+---------+-------+
	| tipname | varchar(32) |      | PRI |         |       |
	| node_id | varchar(10) |      |     |         |       |
	| server  | varchar(64) |      |     |         |       |

That is, the name of the tip device (given to capture) is the unique
key, and there can be multiple tiplines associated with each node.
console_setup now uses the tiplines table to determine what tiplines
need to be reset; used to be just the name of the node_id passed into
console_setup. Conversely, capserver uses the tipname to map back to
the node_id, so that it can get the owner/group from the reserved
table.

I also removed the shark hack from nalloc, nfree, and console_reset,
since there is no longer any need for that; this can be described
completely now with tiplines table entries. If we ever bring the
sharks back, we will need to generate new entries. Hah!

(somewhat) so that we can do submenu easily in other pages.

account for the time it may take for changes made at the master to
propagate to the slaves. Added a paramter to override this, as sometimes,
we know that we're talking to the master so the delay does not come into
play.

This should improve the running time of snmpit by about 10 seconds per VLAN
created, since we can tell right away if the VLAN already exists or not.

keys on boss and ops.

also noticed that the slower machines were getting very far behind the
faster machines (the faster machines requests chunks faster), and
actually dropping them cause they have no room for the chunks
(chunkbufs at 32). I increased the timeout on the client (if no blocks
received for this long; request something) from 30ms to 90ms.  This
helped a bit, but the real help was increasing chunkbufs up to 64.
Now the clients run in pretty much single node speed (152/174), and
the CPU usage on boss went back down 2-3% during the run. The stats
show far less data loss and resending of blocks. In fact, we were
resending upwards 300MB of data cause of client loss. That went down
to about 14MB for the 12 node test.

Then I ran a 24 node node test. Very sweet. All 24 nodes ran in 155 -
180 seconds. CPU peaked at 6%, and dropped off to steady state of 4%.
None of the nodes saw any duplicate chunks. Note that the client is
probably going to need some backoff code in case the server dies, to
prevent swamping the boss with unanswerable packets. Next step is to
have Matt run a test when he swaps in his 40 nodes.

on for now, since its minor code, and spits out good info to the
console.

forever.

statements from the two threads.

them today and see what happens.

changes for the mini testbed. Needs to be done up one level in the
rest of configure, but thats too much work right now.

all other testbed stuff. rc.d/3.testbed.sh now expects to find
capture in @prefix@/etc .

Also moved capserver out of the 'all' target in capture/GNUmakefile, so
that we don't try to build it on 'tipserv' machines, which won't have
the necessary mysql stuff.

and ops email address.

hostname (according to the rules).

fileserver - ie. fs.emulab.net . tmcd and exports_setup now use this
variable rather than a hard-coded node name.

tb-make-weighted-vtype.

make-vclass A 0.5 pc600 pc850

in the top file.  And then have nodes of type A.  Assign will try to put
them all as either pc600 or pc850.

Still need to write all the pre-assign stuff.

not include a year in the output, so I was using the current year to
init the tm structure. However, the log file could span from the old
year to the new year, and so all the dates could be wrong. Using Mac's
suggestion, look at the final time stamp, and if its in the future,
reset it back one year.

Also add [-a #] option to roll through the specified number of
rotation files, to make the job of reinitting all the records easier.
I ran it as "genlastlog -a 7", which makes it process logins.7.gz
through logins.0.gz, before doing the current log.