1. 08 Aug, 2008 1 commit
  2. 31 Aug, 2007 1 commit
  3. 27 Dec, 2006 1 commit
  4. 06 Feb, 2006 1 commit
  5. 05 Jan, 2005 1 commit
  6. 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
  7. 28 Apr, 2003 1 commit
  8. 02 Apr, 2003 1 commit
  9. 18 Dec, 2002 1 commit
  10. 28 Sep, 2002 1 commit
  11. 27 Sep, 2002 4 commits
    • Leigh B. Stoller's avatar
      Add timeout for tmcc call so that if the server cannot be contacted · 01e8ef33
      Leigh B. Stoller authored
      for some reason, fall back to using the existing config file. Don't
      want to hold up the boot forever ...
      01e8ef33
    • Leigh B. Stoller's avatar
      Add regex to leave the "refclock" lines alone, which look like · 3af1d4dd
      Leigh B. Stoller authored
      "server 127.127.xxx.xxx ..."
      3af1d4dd
    • Leigh B. Stoller's avatar
      4d55ff29
    • Leigh B. Stoller's avatar
      Add new ntpstart file, intended to wrap up ntpd startup code, after · b437e338
      Leigh B. Stoller authored
      first talking to tmcd to get the ntpdrift and ntp server/peer lists.
      This is a strict wrapper so it should be invoked from /etc/rc.conf
      like this:
      
      	xntpd_program="/usr/local/etc/emulab/ntpstart"
      	xntpd_flags="/usr/sbin/ntpd -p /var/run/ntpd.pid"
      
      which is to say that this program passes it entire argument list off
      to the shell once it sets up the config file. We fire off ntp no
      matter what happens though, and allow for no actual changes to the
      config file if tmcd does not provide anything.
      
      TMCD: Add ntpinfo and ntpdrift commands, as per Mike's specification.
      ntpinfo returns lines like:
      	SERVER=nnn.nnn.nnn.nnn
      	...
      	PEER=nnn.nnn.nnn.nnn
      	...
      	DRIFT=nnn.nn
      
      and "ntpdrift nnn.nn" allows the current drift setting to be placed
      into the DB, although thats not currently happening. In the DB,
      ntpdrift is a new float slot in the nodes table, that defaults to
      NULL. The servers/peers are stored in a new table that looks like
      this:
      
      	+---------+---------+--------+
      	| node_id | IP      | type   |
      	+---------+---------+--------+
      	| wa32    | 1.1.1.1 | server |
      	| wa32    | 1.1.1.2 | server |
      	| wa32    | 1.1.1.3 | peer   |
      	| wa32    | 1.1.1.4 | peer   |
      	+---------+---------+--------+
      b437e338