1. 01 Jun, 2005 1 commit
  2. 31 May, 2005 1 commit
  3. 27 May, 2005 1 commit
  4. 25 May, 2005 1 commit
    • Leigh B. Stoller's avatar
      Add a "nosetup" option to elabinelab experiments. In the experiments · eed85271
      Leigh B. Stoller authored
      table, if elabinelab_nosetup is non-zero, boss and ops setup will do
      just enough to get the nodes into a state that hopefully approximates
      what a real installation might look like before installing our stuff.
      I do install the packages cause there is no point in waiting for that
      to finish interactively.
      
      From this point, you can log into the console(s) and run the setup
      instructions verbatim, although I have not actually tried that yet.
      
      The nice thing is that if you manage to get things properly setup, it
      can function as a real elabinelab since the outer environment has been
      setup. This is quite a bit different then how we tested during the
      last release frenzy.
      
      Its not quite perfect of course, since the images are not "clean", but
      I think this is okay for testing.
      eed85271
  5. 16 May, 2005 1 commit
    • Leigh B. Stoller's avatar
      Add ability to check out a specific source tag from the mirrored CVS · 603b59f9
      Leigh B. Stoller authored
      tree we keep on boss (which is update each night). Still need to
      arrange for tmcd to pass back CVSSRCTAG=xyz in the emulabconfig
      request, but if it did, that tag is passed along to the web interface,
      which calls new backend script to do the checkout, tar it up, gzip
      it, and spit to stdout.
      603b59f9
  6. 13 May, 2005 1 commit
    • Mike Hibler's avatar
      New config variables: · 7d2bb50d
      Mike Hibler authored
           $emulabconfig{"JAILIPBASE"} = "172.16.0.0";
           $emulabconfig{"JAILIPMASK"} = "255.240.0.0";
      
      These are used to establish a route on boss and ops so they can talk to
      inner vnodes.
      
           $emulabconfig{"MFSTARBALL"} = "tftpboot-elabinelab.tar.gz";
           $emulabconfig{"MFSVERSION"} = "53";
           $emulabconfig{"MFSCONSOLE"} = "sio";
      
      Allow for customization of the MFSes.  The first is the most useful,
      it provides some backend support for something Leigh suggested: the ability
      to select in the NS file whether the inner-elab should use a "release"
      set of files (MFSes, images, emulab source) or the current elabinelab version.
      The last two might not be as useful.
      
      Currently none of these new variables are actually passed in via tmcd,
      they just get the default values shown above.
      7d2bb50d
  7. 06 May, 2005 2 commits
  8. 15 Apr, 2005 2 commits
  9. 14 Apr, 2005 1 commit
  10. 22 Mar, 2005 2 commits
  11. 18 Feb, 2005 2 commits
  12. 10 Feb, 2005 1 commit
  13. 08 Feb, 2005 1 commit
    • Leigh B. Stoller's avatar
      Remove testbed source and object trees from inner ops once the node is · ad39ab3a
      Leigh B. Stoller authored
      constructed. This is avoid the emulab source code leaking out too
      easily.
      
      We leave it on boss, since at the moment mere users do not get shells
      on inner boss, so getting the source code that way is a bit harder
      (although not that hard of course). Besides, for development its much
      nicer to have that source left on boss.
      ad39ab3a
  14. 31 Jan, 2005 1 commit
  15. 28 Jan, 2005 3 commits
    • Mike Hibler's avatar
      0afe9c54
    • Leigh B. Stoller's avatar
      8d1bce8a
    • Leigh B. Stoller's avatar
      Changes to elabinelab setup. The source code for inner boss/ops no · 03cf92cb
      Leigh B. Stoller authored
      longer comes from the project directory (really, my source directory
      in the various projects). Instead, the source code comes from one of
      two places:
      
      * Using fetch on the inner ops and boss, make a special request to the
        outer webserver to return a tarball, currently stored in
        /usr/testbed/src, and created by toplevel makefile target "elabinelab".
        So, in your object tree (preferably one that is pure, without any of your
        own hacks) run "make elabinelab" and it will create the tarfile for you.
        The tarball is returned only to elabinelab experiments providing the
        experiment secret key (a variant of the existing spewrpmtar file stuff).
      
      * Using the standard tarfile install command, albiet indrectly cause of how
        we hide all of the elabinelab NS goo. So, in your NS file you can do:
      
      	tb-elab-in-elab 1
      	set ::TBCOMPAT::elabinelab_source_tarfile \
      			"/proj/testbed/tarfiles/emulab-src.tar.gz"
      
        Which will arrange for this tarfile to be installed in /usr/src, and then
        copied to the approriate place later when inner boss and inner ops are
        setup. The tarfile should be created in the top of your testbed source
        tree. This is given preference over method 1 above.
      
      XXX Currently the tarfile is unpacked in /usr/src cause install-tarfile
      does not create the target directory. As soon as we have new images, I'll
      move this unpacking to a more suitable place.
      03cf92cb
  16. 27 Jan, 2005 2 commits
  17. 26 Jan, 2005 1 commit
  18. 07 Jan, 2005 1 commit
  19. 21 Dec, 2004 1 commit
  20. 07 Dec, 2004 1 commit
  21. 16 Nov, 2004 1 commit
  22. 11 Nov, 2004 1 commit
    • Leigh B. Stoller's avatar
      Checkpoint the client side of ElabInElab changes in case some whacko is · a5c1e591
      Leigh B. Stoller authored
      dying to see whats going on. These changes can go into new images; it will
      be ignored in non ElabInElab experiments;
      
      rc.inelab: A terrible hack that I now regret. The whole point of this
      script to allow inner boss/ops to 1) play by the standard state machine goo
      (ISUP) for the outer emulab. That way os_setup, node_reboot, etc all work
      when dealing with setting up the inner elab. 2) Since the inner
      control can fall on any of the interfaces (as picked by assign), we
      need to still do ifc/route configuration using tmcd. At the time I did
      this, I expected that swapmod/swapin/swapout would be possible and
      that boss/ops would be coming in on different nodes using different
      interfaces for the inner control net, and that I would want to ask
      each reboot. Well, I think swapping an inner emulab is a really long
      way off, maybe so far off I'll be retired by that time.
      
      rc.mkelab: A lot of very ugly code that turns a node into an inner ops
      or boss. I won't bother to describe this code other than to say the
      operating model for this rev is to create a fully functional inner
      emulab based on the DB state provided by the outer emulab. Currently,
      the current testbed software is expected to be in the /proj tree, and
      a full boss/ops install is done, followed by all kinds of
      customizations (like building accounts for members of the project,
      etc) to make it a fully function emulab with just a single project;
      the project in which the inner emulab was created.
      a5c1e591