GitLab

Add a section on using link_config and the XMLRPC interface to change
links on the fly.

would be required to use delay_config or link_config. For example:

	sshxmlrpc_client.py link_config proj=testbed exp=two-wireless \
		link=lan0 "params={'a': 4}"

Note last argument, which is eval'ed into a dictionary before it is
sent across in the RPC. This is done whenever first character of the
value is a "{" ... otherwise it is treated as a literal.

or undotted notation.

very specific to wireless links in general, and to iwconfig on Redhat
9.0. It allows you to control the entire lan or an individual member
of a wireless lan via the event system. For example to change the
accesspoint of a wireless lan, you could do this:

	tevc -e foo/bar now lan0 modify accesspoint=00:09:5B:93:0B:A4

The agent deciphers the event arguments and calls iwconfig with the
appropriate as needed. Note that there are many ways to make the lan
unusable doing this, so you want to be careful. You can get the MAC
addresses from the experiment info page (tbreport).

New script called link_config, which might be badly named since it
implies generality) to front end tevc. Operates mostly like
delay_config in that it will change the physical table settings, and
optionally (-m) the virtual table entries. So,

	link_config testbed two-wireless lan0 accesspoint=00:09:5B:93:0B:A4

You can change individual members of a lan too:

	link_config -s nodew1 testbed two-wireless lan0 txpower=50

Currently no web interface; too much work. I will add an xmlrpc
interface though since that is easy to do.

wireless) nodes.

or link the interface is operating for.

tutorial is just a simple walkthough of the GUI that has the user
create a two node experiment.

the name of the lan (virt_lans table entry) so that we can tell the
client what lan an interface is for. The reason this is horrible is
cause of how we describe lans/nodes in the DB with those member and
members slots. Terrible.

ssh libraries that want kerberos.

interface, and for what.

for the "links" aspect in experiments with no links.

booting the rest of the MFS (just go multiuser without doing any
testbed setup).

This is in addition to the normal bandwidth, and the difference is
that the estimated bandwidth is not enforced. It's just fed to assign
for mapping decisions. The idea is to allow for more efficient
packings by doing non-conservative bandwidth allocation.

Not documented yet, because it might change a little after I made it
work properly with asymmetric links.

that screws it up!

fixup /etc/fstab and anything else that might have hardwired DOS partition
information.  This is the piece of the puzzle needed for loading an image
into a partition other than the one in which it was created.  I never
installed it since there was no demand and it is one more piece on the disk
loading path that could break.

Just checking this in for the day when we might want it.  Note that it is
still not installed (i.e., I didn't change the Makefile to install it).

refill it from the server.

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.

the CDROM to read/write the magic config sector.

my windoze box cause my CD didn't work for some reason, but now it
does.

/usr/local/etc/emulab instead of /etc/testbed. Handle both cases.

on the new boot CDROM.

speaking the bootinfo protocol just like the pxeboot kernel does. This
is used when booting the CD-ROM to figure out what to do next (boot
partition, or continue booting into one of newnode, frisbee, freebsd
on the CDROM).

boss name in.

night, and process it into a file to stick into the testbed www
directory. This replaces the current approach of wishfully thinking
that people will remember to add their commit log messages to another
file and them install it. I'm one of the worst offenders these days ...

So, take the commit log, skip up to the first entry in 2004/01, then
take the rest of the file and reverse the entries. Copy the resulting
file over to the www directory.

This script is run from cron on our site only!

Note to Opera users; opera does not respect <XMP> properly, and so the
page is somewhat scrogged by HTML entities that are supposed to be
ignored when inside an XMP. Works okay on other browsers.

estimated bandwidth that will be used on the link/LAN. This can then
be passed to assign, to do less conservative bandwidth allocation.

onto the web download page for people to use on their own machine.