GitLab

during ops-install.

   No longer rely on looking at kernel boot time messages and extracting
   a hardware signature to determine the nodetype to then determine the
   control net.  Now we just DHCP on all interfaces and decree that the
   interface that answers is our control net interface.

   An extraordinary number of sleezy tricks were needed to get FBSD4,
   FBSD5, and RHL to DHCP on all interfaces without changing any standard
   scripts.

   For now, the nodetype/cpuspeed/chipset scripts still exist for the
   benefit of healthd, which uses the output of nodetype to determine
   what kernel module to load.  We should fix this.

   Side-effect: pump, the old RHL DHCP client, is history!  For older
   RHL releases, you will need a version of dhclient.

   Side-effect: in Linux, all non-control net interfaces are left up
   but without a legit IP address.  This is a consequence of dhclient.
   In FBSD, it was trivial to clean this up, RHL will take a little
   more work.  Up or down, it shouldn't matter.

2. Add an mfs-install make target, a scaled-down version of the client
   install.  Added a mandatory DESTDIR check so you don't accidentally
   install in the wrong place on boss.

possible to:

	gmake client
	sudo gmake client-install

on a FBSD4, FBSD5, RHL7.3, and RHL9.0 client node.

There are still some dependencies that are not explicit and which would
prevent a build/install from working on a "clean" OS.  Two that I know of are:
you must install our version of the elvin libraries and you must install boost.

into a testbed boot CD in a mostly automated manner. There are still a
few things that need to be done by hand, which are described in the
cdboot/README file.

Add tmcd/freebsd/cdboot directory of little scripts and files that
need to onto the fixit disk.

The install target is cdboot-install (must be run as root) and if you
are brave enough to run it, you better give it a DESTDIR argument or
you will write a bunch of files onto the local node that will cause
mayhem and havoc at the next reboot.

1. "make clean" will just remove stuff built in the process of a regular build
2. "make distclean" will also clean out configure generated files.

This is how it was always supposed to be, there was just some bitrot.

the top level.  This will build all the necessary binaries and then install
them.  This works on FBSD4 and RHL7.3.  It still doesn't work on FBSD5
(newer compiler that no longer supports a style of use of _FUNCTION_ in the
event lib) or RHL9 (event lib needs SSL lib which has a bad dependency
on Kerberos).  Notes:

- requires that elvin libraries be installed on nodes (they are) to build
  event agents, requires linuxthreads be installed on FBSD (it is now) to
  build imagezip (which is installed, but is not strictly necessary)

- installed event-agents and other binaries are stripped

- added a few missing files to the source tree for bsd (healthd.conf)
  and linux (healthd.conf, rc.local)

- the only thing that doesn't get rebuilt in /usr/local/etc/emulab is
  healthd, I couldn't quickly find how it gets built

- uses a scaled down version of libtb with no DB functions (since mysql
  isn't installed on nodes).  N.B. DO NOT DO A CLIENT INSTALL FROM YOUR
  REGULAR OBJ TREE OR ELSE YOU MAY WIND UP WITH A NEUTERED VERSION OF
  libtb.a!

The build-as-well-as-install semantics are counter to the regular install
targets, but this is what we gotta do for now.  Once the TB source builds
under Linux and newer BSDs, we could undo this and just require that people
do a regular "make" followed by "make client-install"  OTOH, there should
be no reason to require installation of mysql and other server-side packages
just to build clients (or make them sit through the compilation of assign),
so maybe we will keep the client build special.

"client-install"

this by moving (well, copying) the rcs file in the CVS tree so that we do
not lose the history.

as defined in the defs-* file (e.g. "TBLOGFACIL=local2").  The default is
"local5" which is what we are setup to use so you shouldn't need to mess
with your defs- file!

perl scripts just get this value configured in when configure is run.
C programs get the value in two ways.  For programs that are intimate with
the testbed infrastructure, and include "config.h", they just get it from
that file.  For programs that we sometimes use outside the Emulab build
environment (e.g., frisbee, capture) and that don't include config.h,
the value is set via a "-DLOG_TESTBED=..." in the GNUmakefile build line.
If the value isn't set, it defaults to what it used to be (usually LOG_USER).

Still to do: healthd, hmcd (whose build doesn't seem to be completely
integrated) and plabdaemon.in (since its icky python :-)

message about no libmysql on a testbed node.

local nodes to connect to tmcd without using ssl, and this binary can
be used on the MFS.

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.

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.

event support in the build (tmcd links against the event lib now).

findif against elvin stuff; Makes it easier to compile those on client
nodes where those libs do not exist!

state. Records this state (and the time at which it was reported) into
the database. Returns nothing.
(eg. 'tmcc state REBOOTING')

If the event system is enabled, also sends events on receipt of state
change reports. These will be monitored by a (not yet finished)
daemon.

defines.

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

stuff. Use -p option to use UDP instead of TCP connection.

This program is now invoked from the setup script to determine which
interface needs to be configured. Changed tmcd to return the MAC
address from the DB in the ifconfig response. All this because the
ordering of the interfaces is no longer consistent between linux and
freebsd.

the testbed list.

on paper. tmcc runs on the testbed nodes. The linux and freebsd directories
have the scripts and skeleton passwd/group file stuff. There are makefiles
in those directories for installing on the testbed node (typically before
you cut an image!).