GitLab

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.

"approved" designation is confusing. Changed to reflect group
membership trust!=none instead of user status=active since thats what
people really want to know.

by smarter brains by me (I have asked Dave to look it over). Anyway ...

I added a top level ssl directory which has a bunch of goo for
creating certificates and keys.  I currently create a Certificate
Authority, a server certificate, and a client certificate. The private
keys for all three are unencrypted, so no password is required. All
key/cert combos can be installed on boss. The client side needs the
key/cert pair (in one file), and the CA cert (no key!). There are
install targets to do this. NOTE, you do not want to create/install
these without being careful, since you could instantly invalidate all
the clients!

I have added the necessary SSL routines to tmcd/tmcc. See the ssl.c
and ssl.h file. I have set it up so that with all you need to do is
uncomment three lines in the makefile, and accept,connect,read,write,
and close are redirected to SSL'ified versions in ssl.c. The current
security model is that the client and server both "demand" certificate
verification from the other side (as opposed to just server side
verification). tmcd reads in server.pem, while tmcc reads in
client.pem. Both read in the emulab.pem (CA cert with no private
key).

Initial testing indicates I have done this at least partially
correctly. Whoever invented this stuff has a really twisted mind
though. There are some questions at the top of ssl.c that need to be
answered.

Oh, also redid all the syslog stuff throughout tmcd.

the other control node.

the tmcd parent. killall was messing things up somewhow.

TBNODESTATE/REBOOTING event. While I was at it, converted power to use
Getopt::Std for getting command-line arguments.

node_reboot uses this argument to prevent the event from getting sent twice
(sice node_reboot has already sent it.)

file in /etc/testbed, and if there such a file, take a different path
through the setup code that is a lot shorter (mounts, accounts,
startupcmd).  All the other stuff is bypassed. There are no
differences though between what you install on the MFS and what you
install on a regular node.  Just run the mfs-install target instead,
which creates the little ismfs file for you.