1. 26 Aug, 2003 5 commits
  2. 22 Aug, 2003 2 commits
  3. 20 Aug, 2003 4 commits
  4. 19 Aug, 2003 3 commits
  5. 18 Aug, 2003 1 commit
  6. 15 Aug, 2003 2 commits
  7. 14 Aug, 2003 1 commit
  8. 12 Aug, 2003 2 commits
    • Austin Clements's avatar
      These are scripts/config files necessary in the boot process of a Plab · 9226f2b5
      Austin Clements authored
      vserver node.  The process starts with rc.vinit, which is called
      either by the service manager, the pnode boot, or by a vnode reboot.
      rc.vinit calls vnodesetup, which calls rc.inplab, which calls
      plabsetup.
      9226f2b5
    • Austin Clements's avatar
      Plab node setup now basically works. There are just a few bugs to · f3beec6e
      Austin Clements authored
      iron out.  TMCD/libsetup now has a plabconfig commands that parallels
      the jailconfig command.  The Plab boot process has been added to
      libsetup and a -p option has been added to vnodesetup to parallel the
      -j option.  Parts of the code that were Jail-specific, but labeled
      just as vnode stuff have been renamed.  $vnodedir in vnodesetup has
      been removed, since it was redunant with libsetup's CONFDIR, and
      CONFDIR is much more intelligent.
      f3beec6e
  9. 08 Aug, 2003 1 commit
  10. 07 Aug, 2003 2 commits
  11. 06 Aug, 2003 1 commit
  12. 05 Aug, 2003 2 commits
    • Mike Hibler's avatar
      Restore a comment (Bad Mike!) · b1b6ee4a
      Mike Hibler authored
      b1b6ee4a
    • Leigh B. Stoller's avatar
      The rest of the sync server additions: · 212cc781
      Leigh B. Stoller authored
      * 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.
      212cc781
  13. 04 Aug, 2003 3 commits
  14. 01 Aug, 2003 1 commit
  15. 31 Jul, 2003 3 commits
    • Leigh B. Stoller's avatar
      Some minor perf tweaks requested by Mr Zippy: Reduce the amount of · 9f6fbfb1
      Leigh B. Stoller authored
      syslogging to a fraction of its former self. Actually, its mostly been
      moved under if (verbose) tests. Instead, just syslog the number of
      bytes returned for each request.
      
      Added a signal handler to change the verbosity of a running tmcd.
      To turn on verbosity:
      
      	kill -USR1 `cat /var/run/tmcd.pid`
      
      To turn off verbosity:
      
      	kill -USR2 `cat /var/run/tmcd.pid`
      
      You can send the signal to individual children, but that would be
      silly and pointless.
      9f6fbfb1
    • Leigh B. Stoller's avatar
      Add Mike's NFS/NULL mount changes to mkjail.pl · 5b16105a
      Leigh B. Stoller authored
      Also a couple perf hacks:
      
      * Local vnodes can start with the password/group file from the
        physnode, since locally they will be the same anyway. This avoids a
        blizzard of accounts requests at startup, which is by far the
        biggest chunk of data returned (well, except for host tables).
      
      * To help serialize boot startup, vnodesetup now waits for the jail to
        finish starting up before it exits. It does this via a "goofy"
        mechanism I will not bother to describe.
      5b16105a
    • Leigh B. Stoller's avatar
      Add DBDIR def to paths. · 1c28424e
      Leigh B. Stoller authored
      1c28424e
  16. 24 Jul, 2003 5 commits
  17. 22 Jul, 2003 1 commit
    • Kirk Webb's avatar
      · d356ef16
      Kirk Webb authored
      Here we have the Linux delaysetup startup script - first revision.  This
      uses iproute2+tc, modprobe, and iptables to setup traffic shaping.
      A few notes are warranted:
      
      1) [g]red is not yet supported
         - need to make these modules classful in the kernel first
      
      2) sysctls are used here to up the amount of buffer space available for
         sk_bufs (socket buffers).  Couldn't see a place to do this in the kernel
         config.
      
      3) Only linkdelay support is implemented
         - probably could add normal delay-node support without too much trouble.
      
      4) reverse pipe numbers are (currently) ignored
         - not needed since the IMQ device used to shape incoming traffic
           is distinct from the actual interface - no namespace collision.
      
      5) Kernel selection is similar to FBSD: check running kernel, and reboot
         if the kernel version isn't what we expect (have to rerun lilo too)
      d356ef16
  18. 03 Jul, 2003 1 commit