would take too long!

Currently it is configured (hardwired) to run every 15 minutes, even that
may be too frequent as things don't happen too fast in lease-world.

trying to start the testbed.

And add DEBUG setting in rc.d startup scripts. This is something we had been
doing on subbosses with a hack, but I kept overwriting the hack!

This ensures that if testbed services are disabled on boss (in particular
tmcd), we can still boot ops without hanging!

Make sure sitevars get initialized on initial installation of an Emulab.
Fixes to the update_sitevars script, mostly in case we someday want to
run it on every testbed software install (which we do not do right now).

For ops and fs there is a race with boss that prevents us from locking
down ARP entries early. For now, we do the lock down later in the boot.
If someone spoofs boss or the gateway before then, we will detect it
when we request the ARP info via SSL-enabled tmcc.

Also, add verbose mode and log to /var/emulab/logs/fixarpinfo.log so we
can track what changes.

It works like this. Certain nodes that are on the node control net
(right now just subbosses, but ops coming soon) can set static ARP entries
for the nodes they serve. This raises the bar for (but does not eliminate
the possibility of) nodes spoofing servers. Currently this is only for
FreeBSD.

When such a server boots, it will early on run /etc/rc.d/arplock.sh
which will in turn run /usr/local/etc/emulab/fixarpinfo. fixarpinfo
asks boss via an SSL tmcc call for "arpinfo" (using SSL ensures that the
info coming back is really from boss). Tmcd on boss returns such arpinfo
as appropriate for the node (subboss, ops, fs, etc.) along with the type
of lockdown being done. The script uses this info to update the ARP
cache on the machine, adding, removing, or making permanent entries
as appropriate.

fixarpinfo is intended to be called not just at boot, but also whenever
we might need to update the ARP info on a server. The only other use right
now is in subboss_dhcpd_makeconf which is called whenever DHCP info may
need to be changed on a subboss (we hook this because a call to this script
might also indicate a change in the set of nodes served by the subboss).
In the future, fixarpinfo might be called from the newnode path (for ops/fs,
when a node is added to the testbed), the deletenode path, or maybe from
the watchdog (if we started locking down arp entries on experiment nodes)

The type of the lockdown is controlled by a sitevar on boss,
general/arplockdown, which can be set to 'none', 'static' or 'staticonly'.
'none' means do nothing, 'static' means just create static arp entries
for the given nodes but continue to dynamically arp for others, and
'staticonly' means use only this set of static arp entries and disable
dynamic arp on the control net interface. The last implies that the server
will only be able to talk to the set of nodes for which it got ARP info.

As mentioned, tmcd is responsible for returning the correct set of arp
info for a given request. The logic currently is:

 * Only return ARP info to nodes which are on the CONTROL_NETWORK.
   If the requester is elsewhere (e.g., Utah's boss and ops are currently
   segregated on different IP subnets) then this whole infrastructure
   does not apply and nothing is returned.

 * If the requester is a subboss, return info for all other servers that
   are on the node control network as well as for the set of nodes
   which the subboss serves.

 * If the requester is an ops or fs node, again return info for all
   other servers and info for all testnodes or virtnodes whose control
   net IP is on the node control net.

 * Otherwise, return nothing.

One final note is that the ARP info for servers such as boss/ops/fs or
the gateway router is not readily available in most Emulab instances
since those machines are not in the DB nodes or interfaces tables.
Eventually we will fix that, but for now the info must come from new
site variables. To help initially populate those variables, I added
the utils/update_sitevars script which attempts to determine which
servers are on the node control net and gathers the appropriate IP and
MAC info from them.

This commit is intended to makes the license status of Emulab and
ProtoGENI source files more clear.  It replaces license symbols like
"EMULAB-COPYRIGHT" and "GENIPUBLIC-COPYRIGHT" with {{{ }}}-delimited
blocks that contain actual license statements.

This change was driven by the fact that today, most people acquire and
track Emulab and ProtoGENI sources via git.

Before the Emulab source code was kept in git, the Flux Research Group
at the University of Utah would roll distributions by making tar
files.  As part of that process, the Flux Group would replace the
license symbols in the source files with actual license statements.

When the Flux Group moved to git, people outside of the group started
to see the source files with the "unexpanded" symbols.  This meant
that people acquired source files without actual license statements in
them.  All the relevant files had Utah *copyright* statements in them,
but without the expanded *license* statements, the licensing status of
the source files was unclear.

This commit is intended to clear up that confusion.

Most Utah-copyrighted files in the Emulab source tree are distributed
under the terms of the Affero GNU General Public License, version 3
(AGPLv3).

Most Utah-copyrighted files related to ProtoGENI are distributed under
the terms of the GENI Public License, which is a BSD-like open-source
license.

Some Utah-copyrighted files in the Emulab source tree are distributed
under the terms of the GNU Lesser General Public License, version 2.1
(LGPL).

In particular, need to pass in a base multicast address for the null config
so we don't have to recompile on each subboss.

Otherwise, pubsubd won't start til after the testbed startup. Since
checknodes_daemon wants to send an event, it will hang forever if pubsubd
is not running.

Add "-Q <interval>" option to the master server to allow it to act as an
IGMP V2 querier in environment where there is otherwise not one. It does
essentially what the perl-based querier (code.google.com/p/perl-igmp-querier/)
does, sending out a v2 membership query at the specified interval.

This eliminates the need to run mrouted in some environments (e.g., elabinelab)
just to issue IGMP queries. As a result, all the boss-install and elabinelab
setup related to using mrouted to perform this function has been removed.
The elabinelab CONFIG_MROUTED option has been changed to CONFIG_QUERIER
(the former is still recognized and mapped to the latter). The undocumented
defs-* variable NEEDMROUTED has been changed to NEEDMCQUERIER (the former
still exists in install/installvars.pm.in but is always set to 0) to more
accurately reflect the variable's purpose. If NEEDMCQUERIER is set, then
the mfrisbeed startup script is modified to add the "-Q 30" option.

The implementation of the client and server "-K <interval>" keep-alive option
has been changed to directly send IGMP v2 membership reports containing the
associated MC address.

Note that the -K options have always been a hack to work-around assorted
IGMP-related misconfigurations and incompatibilities, and really should
only be used as a last resort. As implemented, they could cause the host
machine to be pruned out of other MC groups at the nearest switch since
they only report membership in the frisbee MC group. With the master server
acting as an IGMP querier, instances of the frisbee server on that host
should no longer need to do keep alives. We still have one case where it
is needed on the client-side: a FreeBSD 8.x or later host connected to an
IGMPv2-only switch. It appears that the IGMPv3 implementation added in
FreeBSD 8.x always sends v3 reports, even when the default is configured
(via sysctl or even recompiling the kernel) as v2.

I had never completed this. Two things to note:

1. Distribution via broadcast is still disabled by default in the master
   server. To enable it, see the comment added in 3.mfrisbeed.sh.in.
   To use broadcast by default in the client, see the comment in rc.frisbee.

2. If you specify broadcast (-b) in either the client or server, then you
   should use "-m 255.255.255.255". However, this will broadcast to ALL
   interfaces on the client/server. To limit to a specific interface, also
   include "-i <interface-IP>". This will tell the client/server to look up
   that interface and use the subnet broadcast address in place of
   255.255.255.255. Since the master server always starts up frisbeed
   instances with -i, broadcast will always be directed on the server.
   Since our rc.frisbee script also fires up the client with -i, it will
   likewise be directed.

with testbed-control, and then I reboot boss, I do not want the
daemons to start up until I call testbed-control again.

Add script to start it up with the right options and tweak the rc.mksubboss
script for setting up a subboss.

The big backward compatibility issue is that we no longer store running
frisbeed info in the DB.  This means that loadinfo could not return
address:port info to clients and thus old frisbee MFSes could no longer
work.  While not a show stopper to require people to update their MFS first,
I made a token effort to implement backward compat as follows.

When an old frisbee MFS does "tmcc loadinfo" (as identified by a tmcd
version < 33), tmcd will invoke "frisbeehelper" to startup a daemon.
Sound like frisbeelauncher?  Well sorta, but vastly simplified and I only
want this to be temporary.  The helper just uses the frisbee client to make
a "proxy" request to the localhost master server.  The Emulab configuration
of the master server now allows requests from localhost to proxy for another
node.

frisbeehelper is also used by webfrisbeekiller to kill a running daemon
(yes, just like frisbeelauncher).  It makes a proxy status request on
localhost and uses the returned info to identify the particular instance
and kill it.

No more frisbeelauncher or assorted subboss frisbee stuff.

More work on the hierarchical configuration for subboss. When doing host-based
authentication, allow client to pass an explicit host (IP) to the mserver.
If the mserver is configured to allow it, that IP is used for authenticating
the request instead of the caller's IP. Add a default ("null") configuration
so the mserver can operate out-of-the-box with no config file. The goal of
these two changes is for an mserver instance with the default config and a
proxy option to serve the needs of a subboss node (i.e., so no explicit
configuration will be needed).

It used to say FBSDVERSION != 6, but that was when there was only 4 and 6.

daemon that will gateway non elvin-compat clients into an elvin compat
server, as for protogeni cooked mode).