sorting options. I have not done anything with the experiment listing
though since I'm hoping to get better info out of the slothd stuff, so
might as well wait.

Instead, have genlastlog update a new DB table with that info.
genlastlog was already reading login info the nodes, so might as
well use the same mechansism.

Instead, have genlastlog update a new DB table with that info.
genlastlog was already reading login info the nodes, so might as
weel use the same mechansism.

didn't get checked in, etc.

	# Turn on manual routing.
	$ns rtproto Manual

	# Set manual routes
	$nodeA add-route $nodeC $nodeB
	$nodeC add-route $nodeA $nodeB

results in this information being returned from the tmcd routing
command:

	ROUTERTYPE=manual
	ROUTE DEST=192.168.2.3 DESTTYPE=host DESTMASK=255.255.255.0 \
		NEXTHOP=192.168.3.2 COST=0

The reason for DESTTYPE and DESTMASK is so that we can also support
routing to links and lans, since doing it on a per host basis if not
only hugely tedious, but plain impossible if the destination node has
multiple links; the add-route syntax takes a node, but we need the IP
of the relevant link in order to run the route add commands on the
nodes. So, I've "extended" the syntax of add-route so that you can
give it a Link or a Lan as the dest:

	$nodeA add-route $link0 $nodeB
	$nodeA add-route [$ns link $nodeB $nodeC] $nodeB

In this case, the DESTTYPE=net, and the netmask is no longer ignored;
it is used in the route add command. Currently, the mask is hardwired
in the DB to 255.255.255.0, but by providing it in the tmcd command,
we change it later if needed.

I did not implement add-route-to-adj-node since that is not really
useful in our context, and we definitely do not want the user to
change the default routes on his nodes. But, its easy to add if we
need to.

The client side stuff is not done yet.

Runs on a node and uses libpcap to count packets going by. Opens a
socket, so that remote programs can connect and, say, graph its
output. The client gets to specify the interval at which it wants
counts reported. Supports multiple interfaces, and multiple clients
(with different intervals.) It can also write packet counts to a file,
for analysis later.

solve the problem with tmcd hanging!

which registering with the event system twice from the same process
causes a core dump. EventSend use to register once per call, but now
it keeps the connection open between calls. It gets unregistered in an
END{} block.

size of 20000 entries! Well, if each entry takes 12K, yikes. Well, who
knows how much memory this would eat up. Anyway, I turned the session
cache off since there is no point; tmcc exits, and so there is nothing
to cache. On the other hand, I probably do not understand this
caching, but no time to mess with it. Lets see what happens ...

call 'em tuits (okay, I have no idea what a tuit is).

Operational mode (op_mode in the database) affects the state diagram
and timeouts for a node. Modes planned so far are:
NORMAL    - Normal operation
DELAYING  - Acting as a delay node
UNKNOWNOS - Running an OS that does not report its state (OSKit kernels, etc.)
RELOADING - Disk reloading

stated now responds to to TBNODEOPMODE events, and sets database state
accordingly. The set of state timeouts and valid state transitions are
affected by a node's operational mode.

The nodes table now stores information about operational modes, and
the state_transitions and state_timeouts tables include the operational
mode in addition to states.

Next step will be to get the appropriate programs to send TBNODEOPMODE
events.

reasons, as happens when Dave's autostatus daemon connects and closes
right away.

Deal with ssl/nossl clients; at Chad's suggestion add a small handshake
tag to ssl enabled tmcc/tmcd which tells tmcd that it needs to enter
full SSL mode. This allows old tmcc to connect to an ssl enabled tmcd,
and still work okay.

I've also ironed out the verification stuff. At the client, we make sure
that the CommonName field of the peer cert maps to the same address that
we connected to (bossnode).

At the server, we check the OU field of the cert (we create the client
certs with the OU field set to the node type; a convention I made up!).
It must match the type of the node, as we get it from the nodes table.
Also check the CommonName to make sure it matches our hostname. This is
by no means bulletproof, but perfection is costly, and we don't have the
money!

Also cleaned up the REDIRECT testmode stuff. Instead of ifdef'ed under
TESTMODE, leave it compiled in all the time, but only allow it from the
local node (where tmcd is running). Mere users will not be able to
access it, but testbed people can use it since they have accounts on the
boss node.

interaction with the user. The main point to note is that for the
clients, there is a localnode.cnf and a ronnode.cnf. The difference is
that I encode the type (pcron) in one of the extra fields so that tmcd
can do a check on it. This is in lieu of per client certs, which would
be a big pain in the butt right now. As we add other remote groups, we
will create new config files. I bet this will change over time, as
we learn more.

Chad, it would be nice the tiptunnel cert could be generated from this
setup.

up or not (what the up/down page does, but its more useful on this
page.

should have no reply (e.g., "ready")

testbed experimental node names to ip addresses. A new class TbResolver
has been written that uses gethostbyname() to resolve ip addresses.
In case this doesn't work, we try the 'tmcc hostnames' approach

creator.

Add "$ns rtproto Session" and change tge FAQ and tutorial as needed.

lists are stored on users:/etc/mail/lists. For example, you can send
email to ron-users@users.emulab.net. An alias entry is added (and
newaliases run) if there is no alias in /etc/mail/aliases (by the proxy
of course). There are two new options to genelists (on boss):

	"Use the -a option to generate lists for all projects.\n".
	"Use the -n option to generate lists for a new user.\n";

With no options, generate the all users and active users lists
(renamed to emulab-users and emulab-active-users). With the -n option
(used by mkacct) regen the lists for all the projects the user is a
member of.

It would be nice to archive the email, but that requires a publically
readable directory and a u+S archive file; the mailer daemon runs as
user daemon, and the project tree is 770, so it cannot write the
archive file. At some point we will have to go to majordomo or spam
filtering, when the first list is spamm'ed. Sigh.

To tip (or tiptunnel on a normal acl,) capture behaves the same.
However, if a client connects and presents "USESSL" as the first six characters of their
connection key, both sides initiate SSL negotiation.
The server then attempts to get the key again. The second one is used for the check.

SSL initialization is done on the first attempt by a client to connect via SSL.
Capture assumes $(prefix)/etc/capture/cert.pem contains its certificate unless
the '-c <certfile>' option is used.. if the certificate is not found or invalid, that
connection fails, but normal connections will still succeed (and it will try to find the file
again, next time an SSL connection is attempted.)

On the client side, tiptunnel only uses ssl if there is a "ssl-server-cert:"
property in the acl file. This is the SHA hash of the certificate that the capture server is
expected to have (in hex.) If the certificate presented by the server does not hash to the
same value, the connection is dropped.

Added "fakie telnet" to tunnel; tells client to not act stupid (no local echo and no line-at-a-time,)
and filters out client telnet replies so they don't blow the server's mind.

for building an Emulab.

The contents of this file come largely from communications with Nate
Sanders at Kentucky, from messages we sent filling in gaps in our
other documentation.