1. 07 Mar, 2007 1 commit
    • Leigh Stoller's avatar
      Changes for how we distribute the initial set of imageids and osids. · 3c1678d6
      Leigh Stoller authored
      * install/dump-descriptors <filename> will write out a set of insert
        statements for the images and os_info table, slightly munged. In
        fact, what I do is create temporary tables called temp_images and
        temp_os_info, clean them a bit, and then write out the insert
        statements to load them into new tables of the same name.
      
        There are some arrays at the top of this script that says what images and
        osids to write out.
      
      * install/load-descriptors <filename> takes the output of
        dump-descriptors, creates the two temporary tables and loads the
        data into them. Then it (optionally) updates those tables with the
        local indicies of elabman and the emulab-ops project and group.
      
        Then it computes an osidtoimageid table for all class='pc' types. On a
        new testbed this is a reasonable approach, in my opinion.
      
        Next it takes the contents of the two temp tables and moves them across
        to the actual tables.
      
      * install/descriptors.sql is the current data set which has everything
        contained in sql/database-fill-supplemental.sql and install/images/*
      3c1678d6
  2. 02 Mar, 2007 1 commit
    • David Johnson's avatar
      Adds rmcp support (for new wifi pcs) to the power command. For now, you · d31ab2bd
      David Johnson authored
      have to re-run the swig-wrappers target in tools/rmanage/GNUmakefile to
      generate the wrapper and perl module; this must of course be done when
      changes are made to the rmcp libs.
      
        * GNUmakefile.in, configure, configure.in: add tools/rmanage
        * tbsetup/GNUmakefile.in, tbsetup/power*.in: add rmcp to power command
        * tools/GNUmakefile.in: add rmanage
        * tools/rmanage/*.c,*.h: bugfixes, swig helper methods, etc.
        * tools/rmanage/rmcp.i: swig import control file
        * tools/rmanage/rmcp.pm,rmcp_wrap.c: rmcp wrapper/module generated by swig
      d31ab2bd
  3. 01 Mar, 2007 2 commits
  4. 26 Feb, 2007 1 commit
  5. 16 Feb, 2007 1 commit
    • Mike Hibler's avatar
      Hackery to make sure that Plab slices always have boss/ops in their hosts · 7d7c0999
      Mike Hibler authored
      file: we return info for boss/ops in the "hostnames" command, but only if
      the command would have otherwise returned something.
      
      This is because the default hosts file we distribute in the rootball already
      has boss/ops in it.  But if, during bootup, tmcd returns hostname info, that
      hosts file gets overwritten and boss/ops info gets lost.
      
      I could just grep out the info from the original hosts file and transfer it
      to the one we are building, but what do I grep for: "boss", "ops",
      "emulab.net"?  Don't really want to hardwire any of those in the client-side
      script.
      
      By returning this info via tmcd, I also don't have to modify the client-side
      and thus don't need to build a new rootball!
      7d7c0999
  6. 14 Feb, 2007 2 commits
  7. 12 Feb, 2007 1 commit
    • Robert Ricci's avatar
      New front page text, for the first time in a few years. More clearly · b3e8a3e5
      Robert Ricci authored
      enumerates the different experimental environments we support. Most
      of the new text only gets displayed at Utah, since no one else has
      wireless nodes, etc. Other sites get some short generic text.
      
      New banner, plus other visual tweaks. The new banner is turned on via
      the new @FANCYBANNER@ autoconf variable. This is turned on for
      TBMAINSITE, but defaults to off for other sites. This is so that
      existing sites which already have their own versions of the old banner
      don't have to update them right away.
      
      Made the usage iframe a little less prominent, by darkening it, and
      making it ever so slightly transparent on browsers that support it.
      
      Some minor visual tweaks to the background and content area.
      
      Added specific IDs for the main menu subgroups so that if we want, we
      can style them differently.
      
      Man, IE is a pain in the ass.
      b3e8a3e5
  8. 18 Jan, 2007 1 commit
  9. 16 Jan, 2007 1 commit
  10. 27 Dec, 2006 1 commit
  11. 14 Dec, 2006 1 commit
  12. 06 Dec, 2006 1 commit
  13. 04 Dec, 2006 2 commits
  14. 01 Dec, 2006 1 commit
  15. 27 Nov, 2006 1 commit
  16. 27 Oct, 2006 1 commit
  17. 25 Oct, 2006 1 commit
    • Leigh Stoller's avatar
      Makefile Whacking! Try to deal with the problem caused by the delay · 7590f9c5
      Leigh Stoller authored
      between when something is installed and when post-install runs. Short
      of a global lock (which we probably need anyway someday), my solution
      is this. In your makefiles, add these variables before the line that
      has the include of $(TESTBED_SRCDIR)/GNUmakerules:
      
      	SETUID_BIN_SCRIPTS   =
      	SETUID_SBIN_SCRIPTS  =
      
      I have added three new rules to GNUmakerules that look like this:
      
      	$(addprefix $(SBINDIR)/, $(SETUID_SBIN_SCRIPTS)): $(SBINDIR)/%: %
      		echo "Installing (setuid) $<"
      		-mkdir -p $(INSTALL_SBINDIR)
      		$(SUDO) $(INSTALL) -o root -m 4755 $< $@
      
      Yep, your eyes ain't lying to you; use sudo to run the target so that
      install does the right thing (which is that the old file is not
      replaced until the new one has the proper attributes on it).
      
      Note that post-install is still needed for the initial install, but
      should no longer be needed for day to day installs since all that other
      stuff post-install does is mkdir/chmod on directories.
      7590f9c5
  18. 20 Oct, 2006 1 commit
    • Mike Hibler's avatar
      Wow, this should make me look important! · afa5e919
      Mike Hibler authored
      Two-day boondoggle to support "/scratch", an optional large, shared filesystem
      for users.  To do this, I needed to find all the instances where /proj is used
      and behave accordingly.  The boondoggle part was the decision to gather up all
      the hardwired instances of shared directory names ("/proj", "/users", etc.)
      so that they are set in a common place (via unexposed configure variables).
      This is a boondoggle because:
      
      1. I didn't change the client-side scripts.  They need a different mechanism
         (e.g., tmcd) to get the info, configure is the wrong way.
      
      2. Even if I had done #1 it is likely--no, certain--that something would
         fail if you tried to rename "/proj" to be "/mike".  These names are just
         too ingrained.
      
      3. We may not even use "/scratch" as it turns out.
      
      Note, I also didn't fix any of the .html documentation.  Anyway, it is done.
      To maintain my illusion in the future you should:
      
      1. Have perl scripts include "use libtestbed" and use the defined PROJROOT(),
         et.al. functions where possible.  If not possible, make sure they run
         through configure and use @PROJROOT_DIR@, etc.
      
      2. Use the configure method for python, C, php and other languages.
      
      3. There are perl (TBValidUserDir) and php (VALIDUSERPATH) functions which
         you should call to determine if an NS, template parameter, tarball or
         other file are in "an acceptable location."  Use these functions where
         possible.  They know about the optional "scratch" filesystem.  Note that
         the perl function is over-engineered to handles cases that don't occur
         in nature.
      afa5e919
  19. 28 Aug, 2006 1 commit
    • Kirk Webb's avatar
      · 37f4392e
      Kirk Webb authored
      Updates to the plab monitor.  Fixed a couple of bugs and created a
      separate libplabmon library module.
      37f4392e
  20. 17 Aug, 2006 1 commit
    • Kirk Webb's avatar
      · f1fa5a51
      Kirk Webb authored
      New plab vnode monitor framework, now with proactive node checking action!
      
      The old monitor has been completely replaced.  The new one uses modular pools
      to test and track plab nodes.  There are currently two pool modules:
      good and bad.  THe good pool tests nodes that have are not known to have
      issues to proactively find problems and push nodes into the "bad" pool
      when necessary.  The bad pool acts similarly to the old plabmonitor; it
      does and end to end test on nodes, and if and when they finally come up,
      moves them to the good pool.  Both pools have a testing backoff mechanism
      that works as follows:
      
        * The node is tested right away upon entering either pool
        * Node fails to setup:
          * goodpool: node is sent to bad pool (hwdown)
          * badpool:  node is scheduled to be retested according to
                      an additive backoff function, maxing out at 1 hour.
        * Node setup succeeds:
          * goodpool: node is scheduled to be retested according to
                      an additive backoff function, maxing out at 1 hour.
          * badpool:  node is moved to good pool.
      
      The backoff thing may be bogus, we'll see.  It seems like a reasonable thing
      to do though - no need to hammer a node with tests if it consistently
      succeeds or fails.  Nodes that flop back and forth will get the most
      testing punishment.  A future enhancement will be to watch for flopping
      and force nodes that exhibit this behavior to pass several consecutive
      tests before being eligible for return back into the good pool.
      
      The monitor only allows a configurable window's worth of outstanding
      tests to go on at once.  When tests finish, more nodes tests are allowed
      to start up right away.
      
      Some refactoring needs to be done.  Currently the good and bad pools share
      quite a bit of duplicated code.  I don't know if I dare venture into
      inheritance with perl, but that would be a good way to approach this.
      
      Some other pool module ideas:
      
      * dynamic setup pools
      
      When experiments w/ plab vnodes are swapped in, use the plab monitor to
      manage setting up the vnodes by dynamically creating pools on a per-experiment
      basis.  This has the advantage that the monitor can keep a global cap on
      the number of outstanding setup operations.  These pools might also try to
      bring up vnodes that failed to setup during swapin later on, along with other
      vnode monitoring tasks.
      
      * "all nodes" pools
      
      Similar to the dynamic pools just mentioned, but with the mission to extend
      experiments to all plab nodes possible (as nodes come and go).  Useful for
      services.
      f1fa5a51
  21. 06 Jun, 2006 1 commit
  22. 02 Jun, 2006 1 commit
  23. 01 Jun, 2006 1 commit
    • Leigh Stoller's avatar
      Add suport for building per project, group, experiment DBs on ops. At · adbcfd47
      Leigh Stoller authored
      present the per-experiment stuff is not hooked in, but will be for
      templates later. Anyway, each user gets a mysql account on ops, with
      password set to the same as their mailman password (which is also
      their jabber password, etc). Each project gets a DB named by the
      project, and each group gets a DB named by pid,gid. Users are placed
      on the access lists for the DBs as you would expect.
      
      There is a little bit of complexity to make sure that we can create
      DBs on ops outside the Emulab path and grant access to them, without
      Emulab getting confused or mucking things up.
      
      I'll get a news item done ...
      adbcfd47
  24. 25 May, 2006 1 commit
  25. 13 Apr, 2006 1 commit
  26. 30 Mar, 2006 1 commit
  27. 21 Mar, 2006 2 commits
    • Kirk Webb's avatar
      · 7a3a7bf9
      Kirk Webb authored
      Fix up botched configure[.in].
      7a3a7bf9
    • Kevin Atkinson's avatar
      · be95cc12
      Kevin Atkinson authored
      Added libtblog.pm to configure
      be95cc12
  28. 16 Mar, 2006 1 commit
  29. 13 Mar, 2006 1 commit
    • Leigh Stoller's avatar
      A set of changes to run "prepare" on a node just prior to an image · d8f8f9b4
      Leigh Stoller authored
      being taken.
      
      The basic strategy is to have node_reboot (when -p option supplied)
      invoke a special command on the node that will cause the shutdown
      procedure to run prepare as it goes single user, but before the
      network is turned off and the machine rebooted. The output of the
      prepare run is capture and send back via the tmcd BOOTLOG command and
      stored in the DB, so that create_image can dump that to the logfile
      (so that the person taking the image can know for certain that the
      prepare ran and finished okay).
      
      On linux this is pretty easy to arrange since reboot is actually
      shutdown and shutdown runs the K scripts in /etc/rc.d/rc6.d, and at
      the end the node is basically single user mode. I just added a new
      script to run prepare and send back the output.
      
      On FreeBSD this is a lot harder since there are no decent hooks.
      Instead, I had to hack up init (see tmcd/freebsd/init/{4,5,6}) with
      some simple code that looks for a command to run instead of going to a
      single user shell. The command (script) runs prepare, sends the output
      back to tmcd, and then does a real reboot.
      
      Okay, so how to get -p passed to node_reboot? I hacked up the
      libadminmfs code slightly to do that, with new 'prepare' argument
      option. This may not be the best approach; might have to do this as a
      real state transition if problems develop. I will wait and see.
      
      Also, I changed www/loadimage.php3 to spew the output of the
      create_image to the browser.
      d8f8f9b4
  30. 08 Mar, 2006 1 commit
  31. 06 Mar, 2006 1 commit
  32. 17 Feb, 2006 1 commit
  33. 15 Feb, 2006 1 commit
    • David Johnson's avatar
      * Makeconf.in, configure, configure.in, defs-default, defs-johnsond-emulab: · 4982b9cd
      David Johnson authored
          - added a new defs var, TBROBOCOPSEMAIL
      
        * tbsetup/power_mail.pm.in:
          - add some new info to robot powerup mails
      
        * db/libdb.pm.in:
          - add a new function to determine if an experiment contains nodes of a
            given class/type
      
        * tbsetup/swapexp.in:
          - check if exp is a robot exp; that is, if it has robots or motes; if
            so, cc error msgs to TBROBOCOPSEMAIL in addition to TBOPS
      4982b9cd
  34. 26 Jan, 2006 1 commit
  35. 23 Jan, 2006 2 commits
    • Leigh Stoller's avatar
    • Timothy Stack's avatar
      · add602df
      Timothy Stack authored
      Parse the NS file with the real NS parser so we can make sure linktest is
      doing the "right" thing.
      
      	* configure, configure.in: Add tbsetup/nsverify files.
      
      	* tbsetup/GNUmakefile.in: Add nsverify subdir.
      
      	* tbsetup/tbprerun.in: Run verify-ns on the experiments NS file.
      
      	* tbsetup/ns2ir/nstb_compat.tcl: Bring up-to-date with the current
      	world.
      
      	* tbsetup/nsverify/GNUmakefile.in: Makefile.
      
      	* tbsetup/nsverify/ns-2.27.patch: Patch file for NS version 2.27.
      
      	* tbsetup/nsverify/nstbparse.in: Wrapper for the NS parser.
      
      	* tbsetup/nsverify/tb_compat.tcl: Different version of
      	tb_compat.tcl that is used to verify linktest parameters.
      
      	* tbsetup/nsverify/verify-ns.in: Script that runs on boss and
      	verifies that the testbed parser worked correctly.
      
      	* tbsetup/ns2ir/parse-ns.in, tbsetup/ns2ir/parse.proxy.in: Tweaked
      	a bit so parse.proxy can be used to run the regular NS parser in
      	addition to the testbed one.
      add602df