GitLab

* Parser: Added new tb command to set the name of the sync server:

	tb-set-sync-server <node>

  This initializes the sync_server slot of the experiment entry to the
  *vname* of the node that should run the sync server for that
  experiment. In other words, the sync server is per-experiment, runs
  on a node in the experiment, and the user gets to chose which node
  it runs on.

* tmcd and client side setup. Added new syncserver command which
  returns the name of the syncserver and whether the requesting node
  is the lucky one to run the daemon:

    SYNCSERVER SERVER='nodeG.syncserver.testbed.emulab.net' ISSERVER=1

  The name of the syncserver is written to /var/emulab/boot/syncserver
  on the nodes so that clients can easily figure out where the server
  is.

  Aside: The ready bits are now ignored (no DB accesses are made) for
  virtual nodes; they are forced to use the new sync server.

* New os/syncd directory containing the daemon and the client. The
  daemon is pretty simple. It waits for TCP (and UDP, although that
  path is not complete yet) connections, and reads in a little
  structure that gives the name of the "barrier" to wait for, and an
  optional count of clients in the group (this would be used by the
  "master" who initializes barriers for clients). The socket is saved
  (no reply is made, so the client is blocked) until the count reaches
  zero. Then all clients are released by writting back to the
  sockets, and the sockets are closed. Obviously, the number of
  clients is limited by the numbed of FDs (open sockets), hence the
  need for a UDP variant, but that will take more work.

  The client has a simple command line interface:

    usage: emulab-sync [options]
    -n <name>         Optional barrier name; must be less than 64 bytes long
    -d                Turn on debugging
    -s server         Specify a sync server to connect to
    -p portnum        Specify a port number to connect to
    -i count          Initialize named barrier to count waiters
    -u                Use UDP instead of TCP

    The client figures out the server by looking for the file created
    above by libsetup (/var/emulab/boot/syncserver). If you do not
    specify a barrier "name", it uses an internal default. Yes, the
    server can handle multiple barriers (differently named of course)
    at once (non-overlapping clients obviously).

    Clients can wait before a barrier in "initialized." The count on
    the barrier just goes negative until someone initializes the
    barrier using the -i option, which increments the count by the
    count. Therefore, the master does not have to arrange to get there
    "first." As an example, consider a master and one client:

	nodeA> /usr/local/etc/emulab/emulab-sync -n mybarrier
	nodeB> /usr/local/etc/emulab/emulab-sync -n mybarrier -i 1

    Node A waits until Node B initializes the barrier (gives it a
    count).  The count is the number of *waiters*, not including the
    master. The master is also blocked until all of the waiters have
    checked in.

    I have not made an provision for timeouts or crashed clients. Lets
    see how it goes.

* Change Home page title to: Emulab - Network Emulation Testbed Home

* Change mainsite robot meta tags to include a description, set to the
  same as the new home page title above.

* Remote now sites get standard "noindex" robot directive; crawlers will
  follow links on remote sites but not index them in their search engines.

* Add a fixed link to www.emulab.net/netemu.php3 on all sites; used to
  be on mainsite only; that was dumb!

* Minor cosmetic changes to netemu.php3.

Take out a /~newbold/www/ that worked its way in there somehow, and change all the links that should be relative instead of absolute, so that it works more consistently in normal/devel trees.

they are going when you decrease the bandwidth.

/share.  I made it a FAQ question, if you can't tell from the commit!

Remove more old commented out code from modifyexp.

showexp page that its a batch experiment, by the menu options. Same
deal in the swapexp output, plus some other minor cleanup. The only
bug I found while trying to figure out the batchmode problem reported
this morning by the FileMover people, is that the cancelflag is not
cleared after swaping a running batch experiment out, so even after
reinjecting it into the queue, it will not run. Still, that does seem
to be what the FileMover people reported.

changes to the backend a while ago, but the form changes never got
made cause of the ongoing delay in the new form commit. So, you can
preload a batch experiment now.

little new icon if there are new nodes waiting.

can't make it look anything but ugly....

also.

final time, so that we can see how long things take. As per Jay's
request.

can I say? This page is public, and linked from various places.

* Generalized some statements a bit to cover both Linux and FreeBSD
* Added some Linux specifics

logged in the day before.

installed.

so that we can, say, ssh in to reboot it later.

Lots of changes to the form, both functional and aesthetic. See the
testbed ops mail logs for a list of all of them, and the rationale.

Corresponding updates to the showexp "edit meta-data" stuff, so that it
gets all the same error checks as the real form.

Also some backend changes in batchexp to pass through all the new form
values.

Also try to update much of the text that implied a mail-oriented and manual
system, but some of it remains.

Provide a way to re-number interfaces, in case the MFS discovers
them in something other than the preffered (ie. Linux) order.

Use the switch class from showmac to avoid problems where there is
leakage between the control and experimental net, so we see a MAC
on both.

Fix a dumb php bug - can you beleive the in_array() function wasn't
in php3?