should contact for services. Append :portnum if needed.

ops:/etc/ssh/ssh_known_hosts.

used for ElabinElab.

Add tbuisp, a frontend to uisp, the program used to upload code to
motes. Takes care of testbed permissions checking, and figuring out
most of the command-line arguments to uisp (like the programming board
chipset and microcontroller part number).

For now, only supports uploading code to a mote, and has debugging
output turned on.

Depends on 'uisp' being installed - right now, that doesn't happen
automatically. Probably what I should do is import the uisp code into
our CVS tree, since it's GPLed, and not _too_ huge ( O(dozen) files. )

node), and TBNodeTypeProcInfo (to get the processor and speed for a
given node type.)

to avoid silly questions that the event-scheduler cannot answer.

Make the hurting stop.  Make sshxmlrpc auto-detect things, fails over
properly, and dump useful information when it is unable to deal with
the peer.

  * xmlrpc/sshxmlrpc.py: Major update.  It now tries to autoconfigure
    itself by scanning the path for "ssh" and "plink.exe" (although I
    haven't actually tried it on windows).  Environment variables can
    now be used to turn on debugging and set the command to use for
    doing the ssh.  Before running ssh, it will check for an agent or
    a passphrase-less key and prints a warning if it finds neither.
    The last five lines read from the server, as well as the standard
    error output, are stored so they can be dumped later; helpful for
    figuring out what is actually being run on the other side.  The
    protocol layer between ssh and xml-rpc will now respond to a
    "probe" header so that clients can figure out who they are talking
    too.  The server side will now properly detect a closed connection
    and not write anything, which means no more annoying "Write to
    stdout failed" messages.  You can now pass additional options to
    ssh and set the identity.  The module can be run standalone, with
    the default action being to probe the peer:

      $ ./sshxmlrpc.py ssh://boss/xmlrpc
      Probe results for: ssh://boss/xmlrpc
        response time=1.49 s
      Response Headers
        date: Wed Oct 27 16:10:58 2004
	content-length: 0
	probe: /usr/testbed/devel/stack/lib/sshxmlrpc.py
	probe-response: EmulabServer

  * xmlrpc/sshxmlrpc_server.py.in: Set the value returned by a "probe"
    to the name of the invoked module.  This way, the other side can
    figure out who they are talking to (e.g. EmulabServer
    vs. experiment vs. fs vs. osid).

  * event/sched/event-sched.c, event/sched/rpc.cc, event/sched/rpc.h,
    xmlrpc/script_wrapper.py.in: Multiple paths (e.g. xmlrpc,
    $prefix/sbin/sshxmlrpc_server.py) are now probed before giving up.
    Force the use of the user's default identity and protocol one.
    For event-sched, a single connection is now made at startup and
    dropped before going into the event loop.

  * event/sched/GNUmakefile.in: Add a dependency for the install
    target and add -I$(OBJDIR) to the CXXFLAGS.

  * install/ports/ulsshxmlrpcpp/Makefile,
    install/ports/ulsshxmlrpcpp/distinfo,
    install/ports/ulsshxmlrpcpp/pkg-descr: Bump version number to 1.1
    and tweak the description.

  * config.h.in, configure, configure.in: Add a "#define TBROOT" that
    has the install prefix.

experiment from the web interface, I ran into another control network
problem, this time in bootinfo. When a node is sitting free, it waits
in pxeboot for a bootinfo packet from boss to tell it what to do (this
is different then when the node is allocated, and bootinfo tells it
what to do in a reply to the initial request). In the PXEWAIT case, we
*send* it a packet, addressed to its *control network* address, which
in the inner DB, is on the inner control network, but of course PXE is
really using the outer control network, so packets addressed to inner
control network are never seen by pxeboot.

This is the only (known) case of this happening, and rather then try
for some general, over engineered solution, I did something unusual,
and put in a hack, ifdefed for ELABINELAB (meaning, its an inner
elab). I know, you're thinking, how could he have done such a thing,
its so unlike him!

Well, it was damn easy! Anyway, this little hack checks the DB for an
interface tagged as role='outer_ctrl' and uses that IP instead of the
inner control network. When I create the inner DB from the outer DB, I
was already leaving the outer control network in place so that
bootinfo could find the proper node (again, cause the bootinfo request
packets are coming from the outer control network, and so its IP would
not match any nodes in the DB).

I'd like to say that this is the last problem with swapin, but I see
in my other window that the event scheduler failed to start on inner
ops with some silly error ssh permission denied error. Whats that all
about?

its an inner elab. Define ELABINELAB in the inner defs file. Actual hack
is coming in a bit.

nodes are treated specially. For inner boss/ops, ignore most of what
DHCPD returns; we need to do the DHCP so that we know what interface,
but for the moment stuff is hardwired into /etc/rc.conf when the inner
boss and ops are created. I can probably fix this up later as needed,
to be more dynamic for supporting swapout/swapin of an inner emulab,
but swapout and restore of an inner elab has som many open issues,
that not worrying about it now.

For inner nodes, the change is simple; If no hostname provided, ignore
the DHCPD reply completely, favoring a full reply from the inner
control network, and returning -1 from the exit hook so that dhclient
keeps trying in the foreground.

I am committing these so they get into new images.

place.

The only meaningful change was to insert a sched_yield() in the frisbee
decompressor path.  Apparently, the decompressor can run long enough to
cause the incoming socket buffer to overflow.  I was under the assumption
that the decompressor would not run much longer than a single time slice
(0.001 seconds, about 8 packets) before its priority would force it to
be context switched.  But it was running much longer than that!  Forcing
a periodic yield seems to have taken care of this.

One other cause of retransmitted blocks that I saw was where the server
was taking a long time to read data from a file (up to 0.25 seconds).
This would stall the clients and force them to rerequest blocks (which
they do after about 0.10 seconds).  We can improve on this by splitting
the file reading off to a seperate thread.

Most other changes are related to the event logging code.

bit to dhcpd_makeconf.in

the value of boss's control network IP address, which tells frisbeed
how to route our multicast addresses. This came up when trying to
runs frisbeed on elabinelab, where inner boss is effectively
multihomed, with a default route pointing to the external world, not
the inner world!

installs a new root pubkey into /root/.ssh, which comes from a
sitevar.

file with a timestamp in the future (maybe cause timezone not set when
dhclient runs?).

couple of weeks ago) so that tmcd can return the pubkey for image
localization.

does not use its compiled in name, which is qualified and points to
outer boss instead of the closest living boss.

determining the control network interface.

to have to be done in perl; trying to do it with simple substitution
is not really viable.

anchored (force them to be).

browser). This came up in elabinelab cause WWWHOST (www.myemulab.x.y.z) is
not an exported (from outer emulab) CNAME for the bossnode, so I have to
set WWWHOST equal to BOSSNODE, which causes the browser to complain.

retry when getting the topomap, to try and avoid transient NFS errors.
Very silly.

Lbs