GitLab

Now that I know the actual exitval, maybe I can fix the actual
problem!

Mac's statewait library to wait for nodes to through a MFSETUP,ISUP
transition. This ensures that the nodes actually came up in the MFS,
and not something else. No retry; just exit with failure if any node
fails.

MFS is booting, not some generic image (note that there is precedence
for this; the frisbee MFS sends RELOADSETUP). Since there is no state
transition table entries for the PXEFBSD OSID, this should be a
completely invisible change, even for remote sites.

	Usage: node_admin [-h] [-n | -w] <on | off> [node ....]
	       node_admin [-h] [-n | -w] -p pid,eid <on | off>
	-h   This message
	-n   Do not reboot node
	-w   Wait for node to come back up if rebooted
	-e   Operate on all nodes in an experiment

home page and My Emulab page.

are listed in the ntpinfo table.

to assume that the leader of a stack is the switch after which it was named -
we can now name stacks things like 'Control' or 'Experiment'.

Some cleanup of the robot vision system:

	* Makeconf.in: Add INSTALL_INCDIR for includes, EVENTSYS for
	whether or not the event system is available, HAVE_MEZZANINE for
	whether or not we'll be building mezzanine, and GTK_CONFIG which
	refers to the gtk-config binary, if there is one.

	* config.h.in: Add HAVE_LINUX_VIDEODEV_H and HAVE_MEZZANINE
	defines.

	* configure, configure.in: Check for the robot vision system
	dependencies.  Add mezzanine template files.

	* robots/GNUmakefile.in: Add some conditionals for directories
	that depend on the event-system and mezzanine.

	* robots/mezzanine/GNUmakefile.in,
	robots/mezzanine/libfg/GNUmakefile.in,
	robots/mezzanine/libmezz/GNUmakefile.in,
	robots/mezzanine/mezzanine/GNUmakefile.in,
	robots/mezzanine/mezzcal/GNUmakefile.in,
	robots/mezzanine/rtk2/GNUmakefile.in: Fold mezzanine into the
	testbed's build system.

	* robots/vmcd/GNUmakefile.in: When building the vmc-client, use
	the mezzanine that we build locally instead of an installed
	version.

	* robots/vmcd/test_vmc-client.sh.in, robots/vmcd/test_vmcd.sh.in,
	robots/vmcd/test_vmcd2.sh, robots/vmcd/test_vmcd3.sh,
	robots/vmcd/test_vmcd4.sh: Bring the test cases up-to-date with
	respect to the actual code.

	* robots/vmcd/vmc-client.c: A bunch of cleanups and bug fixes: add
	comments, set TCP_NODELAY on the client sockets (doh), etc...

rules back on. The ipfw silently fails, but if I do it a second time,
it works fine. This is bogus of course ...

but never made use of. Moved to its own file (www/xmlrpc.php3.in)
and made to be more like the perl library I did a couple of months ago,
that presents an interface to an sslxmlrpc server, via the sslxmlrpc
client program operating in "raw" mode (takes raw xml on stdin, and
returns raw xml on stdout).

Added ELABINELAB code to nodetipacl.php3 so that you can click on
console icon on an inner emulab web page, and it will ask the outer
emulab sslxmlrpc server for the stuff it needs, and return that to the
user.

variable in the defs file. Nice for elabinelab to avoid inner named
from having to do too much work.

the inner web interface can return the stuff that tiptunnel needs.
Tim already had a node.console routine that does this, so I just
invoke it from the elabinelab class, after elabinelab permission
checks.

loading emulabserver.py from the main tree.

nodes, and then if allocated and person has permission, the vname and
pid/eid.

Note that tip tool ballons have no formatting capabilities at all;
just a simple text string.

If we want fancier, I found some javascript code that will popup real
windows, and then kill them like a tool tip after a short pause or
when the user mouses out. The downside of the real window is that with
some window managers, you still get a status bar along the top, and so
it looks icky. The upside is that we can put real information and
formatting directives in the popup.

XMLRPC, but for now avoid the warnings.

Do not die when turning firewall rules back on fails. This is a transient
error I do not understand yet.
When firewalled and paniced, skip clean shutdown of inner nodes since
they are going to be powered off anyway later, and besides, the control
network is shut off, so no way to talk to inner boss anyway.

You can specify any display resolution you want; it doesn't have to be
one of the "normal" ones.  And you can switch back and forth by just starting
a new rdesktop and "grabbing" the rlogin session away from the previous one.

But once an rdesktop is started up, its display resolution is fixed.  If you make it
smaller than the previous one, it will push your windows around to fit.

web interface you are talking to!

the web interface.

is not currently working. Simple revert to previous revision when
camera is fixed.

Right now, these have to be built on ibapah, because it's got the
cross compiler neeeded.

Includes some of Kirk's SGGPIO code. This should probably get moved
to some other directory and made into more of a library.