people who want to log into the delay nodes and change a specific link.

stuff so that the web page did not need to do anything except display
and form processing. Add tbsetup/node_control for backend so that it
can be called from the command line too. The virt_nodes table is also
updated (for those values that have virt_nodes equivalents), and this
mostly implies that changes can be applied only to swapped in
experiments since we use the reserved table to map pcXXX to its vname
so that the virt_nodes table can be updated. It is an easy extension
to allow changes based on the pid/eid/vname, but I do not see a reason
to support this ability yet. Note usage:

    Usage: node_control name=value [name=value ...] node [node ...]
           node_control -e pid,eid name=value [name=value ...]
           node_control -l
    For multiword values, use name='word0 ... wordN'
    Use -l to get a list of operational parameters you can change.
    Use -e to change parameters of all nodes in an experiment.

    {824} stoller$ /build/testbed/install//bin/node_control -l
      next_boot_osid            - (administrators only)
      startup_command
      bios_version              - (administrators only)
      rpms                      - (multiple options allowed)
      default_boot_cmdline
      default_boot_path
      default_boot_osid
      next_pxe_boot_path        - (administrators only)
      tarfiles                  - (multiple options allowed)
      pxe_boot_path             - (administrators only)
      next_boot_cmdline         - (administrators only)
      deltas                    - (multiple options allowed)
      next_boot_path            - (administrators only)

request.

whose idea was that. Oh right, mine.

a lurking case where GID is null. Need to find that, but in the
meantime this will keep the tmcd happy.

there have been 260,000 connects (and 260,000 disconnects) to the
mysqld server. 240,000 of them were from the TMCD! I've changed the DB
code to keep the connection to the server open, and let the server
time it out. The client side code library code already deals with a
auto reconnect if the server goes away, so no reason to open/close
this connection for every single DB query. Besides, it might help
reduce the amount of time it takes to answer a single tmcd query, and
that would be a good thing.

Made this number more easily tweakable: just set $max_tries in vlanLock().
Also, only prints out every 5th failure, and in a form that should make it
more clear that it's a transient, recoverable, error.

was preventing VLANs from being cleared out before they were delted.

document.

interface for this node.

control interface for this node.

operate on, but it turns out this can happen during normal operations. For
example, an experiment with no VLANs.

hold separate values for each of the two pipes. This allows us to
treat the links asymmetrically with respect to the delay node
configuration. Changes to tmcd to return the expanded info, and rework
(completely) delay_config to allow user to change the duplex
characteristics (just like before), or just simplex characteristics by
specifying the pipe number. By convention (I invented) pipe 0 is
traffic coming in on iface0. Of course, none of the front end stuff
has been changed, so the changing a single pipe does not cause
anything in virt_lans to be changed, so those changes will be lost at
swapout. Also get rid of all the ssh'ed pipe config stuff in
delay_config. Instead, add a client side script called update_delays
to /etc/testbed on the experiment nodes. After updating the delays
table, just ssh over and run that script, which calls the existing
code. Less distribution of knowledge.

we can now handle cross-switch links.

Now supports multiple switches and multiple stacks. To do this, the existing
snmpit_cisco module had to be modified to behave as a true object, and its
interface changed.

A new layer of abstraction has been added: the stack. This is to hide the
details of how things such as VLAN creation occur across multiple devices. For
example, in Cisco stacks, you always contact the stack leader (VTP server) to
create/delete VLANs. Other switches may have different semantics, such as
having to contact every switch to create the VLAN.

Now uses libdb for database access and permissions checks.

Hardware details are hidden as much as possible in the user interface. For
example, the creation and deletion commands now take VLAN identifiers, and
snmpit transparently turns these into device-specific VLAN numbers.

snmpit.in has been re-written from scratch. The new version uses three basic
steps:
1) Process command line options and determine operation to run
2) Determine which devices, ports, and VLANs will be involved and make
   the appropriate objects
3) Actually perform the operation
   when TESTMODE is set, does only steps 1 and 2

Some command-line options have changed. This is because we now use getopt,
rather than a home-grown parser, to parse the command line. As a result of the
large number of options, and an attempt to mimic old options as much as
possible, the options are no longer very mnemonic.

Uses a new table called switch_stacks to figure out which switches belong to
which stacks. A stack is defined as a set of switches that share VLANs.

All snmpit scripts and modules now run with 'use strict' to help catch certain
programming errors.

VLAN listing now prints out the pid/eid and vname for VLANs, if possible.

A few things have bitrotted due to these changes:
* snmpit_intel will need to be re-tooled to use the new interface, and to
  behave as a proper object
* vlansync, vlandiff, and resetvlans depend on the output of snmpit, and will
  need to be updated to understand its new output format