1. 06 Jan, 2004 1 commit
  2. 12 Dec, 2003 1 commit
  3. 21 Nov, 2003 3 commits
    • Mike Hibler's avatar
      Tweaks to support e1000 cards on the pc2000s. Installing this will break · 21e9611f
      Mike Hibler authored
      pc170-1 until those nodes actually have e1000 cards installed (next week).
      21e9611f
    • Mike Hibler's avatar
      Make sure we can hardwire speed/duplex on new Intel Pro/1000 (e1000) cards. · 5ad5ab99
      Mike Hibler authored
      Need to use ethtool instead of mii-tool to do this.  My comment:
      
        #
        # Linux is apparently changing from mii-tool to ethtool but some drivers
        # don't support the new interface (3c59x), some don't support the old
        # interface (e1000), and some (eepro100) support the new interface just
        # enough that they can report success but not actually do anything.  Sweet!
        #
      
      This requires that we load ethfind on the nodes, though the script will
      continue to work if it isn't (though will not work for e1000 cards).
      5ad5ab99
    • Mike Hibler's avatar
      Hack fix for an apparent boot-time race condition. Our pump-invoked · 633a7a12
      Mike Hibler authored
      sethostname script properly sets the hostname, but sometimes that hostname
      gets overridden by one of the static boot scripts which sets the hostname
      back to "localhost".  The sequence is something like:
      	pump runs on eth0 and fires off our sethostname script
      	sethostname blocks
      	ifup of eth1 starts, determines that hostname hasn't been
      	  set (i.e., is set to "localhost") and remembers (NEEDHOSTNAME)
      	sethostname finishes by setting the host name
      	ifup of eth1 finishes, seeing NEEDHOSTNAME is set but doesn't
      	  have anything to set it to so resets to "localhost"
      Weird.  Hack is to make sure it never thinks it needs to set the hostname
      by setting it to something that is not "localhost".  We do this once we
      identify the control net interface (and thus know we will be running pump RSN).
      633a7a12
  4. 12 Nov, 2003 1 commit
  5. 05 Nov, 2003 1 commit
    • Leigh B. Stoller's avatar
      Client side of the event system changes. · 70246c91
      Leigh B. Stoller authored
      * Download the eventkey with new tmcd call.
      
      * Pass -k option to various agents so that they can verify the HMACs
        in the incoming notifications.
      
      * Change program agent; The list of agents from tmcd now includes the
        command, which is written to a config file for the program-agent to
        read in. The command string in the event is now ignored.
      
      * Build the local proxy for linux, and add the goo to start the local
        elvind and use the proxy. It has been this way on FreeBSD for a
        while, but I never got it installed for Linux before now.
      70246c91
  6. 30 Oct, 2003 1 commit
  7. 24 Oct, 2003 1 commit
  8. 06 Oct, 2003 1 commit
    • Leigh B. Stoller's avatar
      * New libtmcc.pm module that encapsulates the tmcc interface. Most of the · 434a472a
      Leigh B. Stoller authored
        code that was in libsetup has moved into this library, and underwent a
        giant cleaning and pumping up. The interface from your typical perl
        script now looks like this:
      
        use libtmcc;
      
        if (tmcc(TMCCCMD_STATUS, "optional arguments", \@tmccresults) < 0) {
            warn("*** WARNING: Could not get status from server!\n");
            return -1;
        }
        foreach my $me (@tmccresults) {
      	print "bite $me";
        }
      
        The arguments and results are optional values. There is a fourth optional
        value that is a hash of config options (basically converted to command
        line switches passed to tmcc). For example, to set the timeout on an
        individual call, pass a fourth argument like:
      
      	("timeout" => 5)
      
        There is also a way to set global options so that all subsequent tmcc
        calls are affected:
      
      	configtmcc("timeout", 5);
      
        I'll probably clean this up a bit to avoid the direct strings.
      
        The result list is a list of strings. Since we are trending away from
        using tmcc to transfer large amounts of data, I think this is okay.
      
      * A new tmcc.pl which does little more than load libtmcc and use it.
        This will become the new tmcc, with the existing C version becoming a
        backend binary for it.
      
      * All of the perl scripts in tmcd have been changed to use the new
        library. I left the few uses of tmcc in shell scripts alone since they
        were of the simple variety (mostly "state" command).
      
      * And again, if you have read this far, you will learn why I bothered with
        all this. Well, the existing code was really bad and it was getting out
        of control. Sort of like a squid that was getting harder to control as
        its rotting tenticles slithered into more and more scripts. Anyway ...
      
        More important, my goal is to use the libtmcc library to add caching.  I
        have not worked out the details yet, but I am envisioning a configuration
        file, perhaps generated initially by tmcd, of all of the config
        values. If the library finds that file, it sucks the info out of the file
        instead of going to tmcd. Eventually, this config file would be generated
        as part of experiment swapping and stored in the DB, but thats a longer
        term project, and perhaps orthogonal (how we fill the cache is not as
        important as adding the ability to use a cache, right?).
      
        Note that certain operations (like "state" and "ready") are flagged by
        the library to always bypass the "cache".
      434a472a
  9. 25 Sep, 2003 1 commit
  10. 23 Sep, 2003 1 commit
  11. 22 Sep, 2003 1 commit
  12. 17 Sep, 2003 1 commit
  13. 16 Sep, 2003 1 commit
    • Leigh B. Stoller's avatar
      More IXP changes: · 47ddaeb0
      Leigh B. Stoller authored
      * Put a hosts file in /opt/config, which gets copied to /etc/hosts on
        the IXP.
      * Put a resolv.conf in /opt/config, which gets copied to /etc on
        the IXP.
      * Add support for startcmd, which will override the default boot.
      * Do not squash root in the /opt export.
      47ddaeb0
  14. 02 Sep, 2003 1 commit
    • Leigh B. Stoller's avatar
      Initial IXP support. Very primitive; the IXP does not configure from · 9da75cd2
      Leigh B. Stoller authored
      inside, but rather I do just enough to get the card booted (using
      Abhijeet's minicom/expect scripts, but with changes to support the
      configuration coming from tmcd. I also create a file of interface and
      routeadd directives, so that the network configures properly, but
      thats about it. Getting a more complete client side environment that
      includes perl and sshd for the arm will have to wait.
      9da75cd2
  15. 26 Aug, 2003 1 commit
  16. 20 Aug, 2003 1 commit
  17. 19 Aug, 2003 1 commit
  18. 15 Aug, 2003 2 commits
  19. 14 Aug, 2003 1 commit
  20. 24 Jul, 2003 2 commits
  21. 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
  22. 24 Jun, 2003 1 commit
  23. 16 Jun, 2003 1 commit
  24. 06 Jun, 2003 1 commit
  25. 04 Apr, 2003 3 commits
  26. 02 Apr, 2003 1 commit
  27. 14 Mar, 2003 1 commit
  28. 07 Mar, 2003 1 commit
  29. 15 Jan, 2003 3 commits
  30. 07 Jan, 2003 1 commit
  31. 06 Jan, 2003 1 commit
  32. 18 Dec, 2002 1 commit