1. 17 Apr, 2007 1 commit
  2. 07 Mar, 2007 2 commits
  3. 14 Feb, 2007 1 commit
  4. 12 Feb, 2007 2 commits
    • 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
    • Leigh B. Stoller's avatar
      * Replace the argument processing code in all pages. Currently we rely on · 48acc8e3
      Leigh B. Stoller authored
        register_globals=1 to turn POST/GET/COOKIES arguments in local variables.
        This is known to be a terrible security risk, and we keep saying we are
        going to fix it, and now I am. In order to accomplish this on a
        transitional basis (since I don't want the entire web interface to stop
        working while I debug it), and because the code just needs the cleanup, I
        am doing it like this: Each page will sport new declarations at the top:
      
      	RequiredPageArguments("experiment", PAGEARG_EXPERIMENT,
                                    "template",   PAGEARG_TEMPLATE,
                                    "instance",   PAGEARG_INSTANCE,
                                    "metadata",   PAGEARG_METADATA,
                                    "osinfo",     PAGEARG_OSINFO,
                                    "image",      PAGEARG_IMAGE,
                                    "project",    PAGEARG_PROJECT,
                                    "group",      PAGEARG_GROUP,
                                    "user",       PAGEARG_USER,
      			      "node",       PAGEARG_NODE,
      			      "yesno",      PAGEARG_BOOLEAN,
      			      "message",    PAGEARG_STRING,
      			      "age",        PAGEARG_INTEGER,
                                    "cost",       PAGEARG_NUMERIC,
                                    "formfields", PAGEARG_ARRAY,
                                    "unknown",    PAGEARG_ANYTHING);
      
      	OptionalPageArguments("canceled", PAGEARG_BOOLEAN);
      
        The first token in each pair is the name of the global variable to
        set, and the second token is the type. So, for "experiment" we look at
        the URL for a pid/eid or exptidx, etc, sanity check them (safe for a
        DB query), and then try to find that experiment in the DB. If it maps
        to an experiment, set global variable $experiment to the object. Since
        its a required argument, produce an error if not supplied. Similar
        treatment for optional arguments, with the obvious difference.
      
        The goal is to have ALL argument processing in one place, consistent,
        and correct. I've found numerous places where we leak unchecked
        arguments into queries. It also cuts out a lot of duplicated code.
      
      * To make the above easier to deal with, I've been replacing lots of
        hardcoded URLS in the code of the form:
      
      	foo.php3?pid=$pid&eid=$eid ...
      
        with
      
              CreateURL("foo", $experiment)
      
        which creates and returns the neccessary url string, by looking at
        the type of its arguments (experiment, template, instance, etc.)
      
        Eventually plan to replace them all so that URL handling throughout
        the code is all defined in one place (all the new URL code is in
        url_defs.php).
      
      * I have cranked up error reporting to tell me anytime a variable is
        used before it is initialized, plus a bunch of other stuff that PHP
        deems improper. Think of it like -Wall ... and boy we get a lot of
        warnings.  A very large percentage of the diffs are to fix all these
        warnings.
      
        The warnings are currently going to /usr/testbed/log/php-errors.log,
        and I'll be adding a script to capture them each night and mail them
        to tbops. This file also gets errors (this will be a change for
        developers; rather then seeing errors and warnings dumped in the
        middle of web pages, they will go to this file instead).
      
      * Major refactoring of the code. More objects (nodes, images, osids).
        Moving tons of queries into the objects in the hopes of someday
        getting to a point where we can split the web interface onto a
        different server.  Lots of general cleanup.
      48acc8e3
  5. 23 Jan, 2007 1 commit
  6. 16 Jan, 2007 1 commit
    • Leigh B. Stoller's avatar
      Move the bulk (or guts) of newuser and newproject from the web · 16aaa101
      Leigh B. Stoller authored
      interface to the backend. There are new scripts that can be called
      from the command line:
      
      	newuser xmlfile
      	newproj xmlfile
      
      They both run from small xmlfiles that are generated by the web
      interface from the form data. I also moved user verification to the
      backend so that we do not have duplicated email functions, but that
      was a small change.
      
      Upon error, the xmlfile is saved and sent to tbops so that we can
      rerun the command by hand, rather then force user to fill out form
      again. I also do a better job of putting the form back up intact when
      there are internal errors.
      
      If the user provides an initial public key, that is put into the xml
      file as well and addpubkey is called from newuser instead of the web
      interface. A more general change to addpukey is that it is now
      *always* called as "nobody". This script was a morass of confusion
      cause of having to call it as nobody before the user actually
      exists. In fact, another of my ongoing projects is to reduce the
      number of scripts called as a particular user, but thats a story for
      another day. Anyway, the script is always called as nobody, but we
      pass along the implied user in the environment so that it can do
      permission checks.
      16aaa101
  7. 09 Jan, 2007 1 commit
  8. 20 Dec, 2006 2 commits
  9. 01 Dec, 2006 1 commit
  10. 27 Nov, 2006 2 commits
    • Leigh B. Stoller's avatar
    • Leigh B. Stoller's avatar
      Call this commit "Snow in Corvallis" ... · 4998b2d7
      Leigh B. Stoller authored
      The major functional change in this revision is converting from user
      selected UIDs to system selected UIDs. This is controlled by the
      variable $USERSELECTUIDS in defs/defs.php3.in which is now set to
      zero, so system selected UIDs is the default.
      
      The algo for creating the uid is to take the email address, strip the
      @whatever from it, squeeze out dots and dashes and underlines, and
      make sure any +foo tokens are removed. Then make sure it is unique by
      taking the first 5 characters and then adding a 3 digit number,
      derived by checking the DB to see what exists.
      
      Since we will want to (more often) change the UID selected, there is a
      new admin only menu option on the Show User page. It calls the backend
      script to do the work (sbin/changeuid).
      
      The login page now defaults to storing and showing the email address
      for login, rather then the UID. It will still accept either one though
      (has for a long time).
      
      Along the way I also reorg'ed a number of pages to use the new user,
      group, and project classes and moved some common functionality into
      the class defs.
      
      Also changed the way addpubkey is called, to avoid some confusion.
      4998b2d7
  11. 09 Nov, 2006 1 commit
  12. 03 Nov, 2006 1 commit
    • Leigh B. Stoller's avatar
      Big set of changes intended to solve a couple of problems with long · ff9061d4
      Leigh B. Stoller authored
      term archiving of firstclass objects like users, projects, and of
      course templates.
      
      * Projects, Users, and Groups are now uniquely identified inside the
        DB by a index value that will not be reused. If necessary, this
        could easily be a globally unique identifier, but without federation
        there is no reason to do that yet.
      
      * Currently, pid, gid, and uid still need to be locally unique until
        all of the changes are in place (which is going to take a fairly
        long time since the entire system operates in terms of those, except
        for the few places that I had to change to get the ball rolling).
      
      * We currently archive deleted users to the deleted_users table (their
        user_stats are kept forever since they are indexed by the new index
        column). Eventually do the same with projects (not sure about
        groups) but since we rarely if ever delete a project, there is no
        rush on this one.
      
      * At the same time, I have started a large reorg of the code, to move
        all of the user, group, project code into modules, both in php and
        perl, turning them into first class "objects" (as far as that goes
        in php and perl). Eventually, the number of query statements
        scattered around the code will be manageable, or so I hope.
      
      * Another related part of this reorg is to make it easier to move the
        new user/project/group code in the perl backend so that it can be
        made available via the xmlrpc interface (without duplication of the
        code).
      ff9061d4
  13. 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
  14. 28 Mar, 2006 1 commit
  15. 09 Mar, 2006 1 commit
  16. 26 Jan, 2006 1 commit
  17. 04 Jan, 2006 1 commit
  18. 15 Dec, 2005 1 commit
  19. 06 Dec, 2005 2 commits
    • Mike Hibler's avatar
      Phase II in disk state saving for swapout. · ed0d25b4
      Mike Hibler authored
      Exec summary: after this checkin, the infrastructure exists (once enabled)
      to create swapout-time "delta" images for all machines in experiments.
      There is only a single, cumulative swap image per node (i.e., all diffs
      are from the base image, not from the previous swap).
      
      What doesn't yet exist, is the mechanism for reloading the delta at
      swapin time.  That is Phase III.
      
      The nitty-gritty:
      
      1. Keep disk image signature files for all nodes in an experiment.
      
         New fields in the DB to track, for each disk partition, what image the
         partition was loaded from.  This enables us at swapin or os_load time to
         create signature files in /proj/<pid>/exp/<eid>/swapinfo for the current
         contents of a node disk/partition.  All nodes with the same image loaded
         will share (via symlink) the same signature file.  TODO: no longer
         referenced signature files should be removed.
      
         Signature info is only collected in the swapinfo directory if the
         experiment is set to have disk state saving enabled (see #5 below).
         Info consists of the <vname>.sig file, which is the file created
         by imagehash, and <vname>.part which says what the root disk is
         for the node and whether to look at the whole disk or just a single
         partition when crafting the delta image.
      
      2. Swapout-time hook for creating swapout image.
      
         If the experiment is marked as allowing disk state saving, tbswap
         will arrange to run and then monitor the create-swapimage command
         on each node.  This script will run the modified version of imagezip
         which uses the signature file to create a delta image.
      
         The command to run and maximum timeout are specified via sitevars
         (previously checked in).  Note that the tbswap script currently has
         special knowledge of /usr/local/bin/create-swapimage as a swapout
         time script.  If the swap/swapout_command sitevar is set to that,
         Magic Stuff shall occur (i.e. it will monitor the command and make
         periodic reports of progress).  The sitevars are a total hack and
         will disappear at some point.
      
      3. Client-side script for creating swapout image.
      
         os/create-swapimage, very similar to create-image.  Uses the info
         stashed in /proj/..blahblah../swapinfo to create a delta image.
      
         XXX fer now hack: the script first looks in /proj/<pid>/bin for an
         imagezip binary to use.  Failing that, it uses the one in the MFS.
         This allows for easier development of the imagezip changes (i.e.,
         don't have to update the MFS every time.
      
      4. Auto creation of signature files for new images.
      
         The create_image script (the one that runs on boss when creating images
         for users) has been modified to automatically create a signature via
         imagehash.  The .sig file winds up in /usr/testbed/images/sigs or
         in /proj/<pid>/images/sigs.  From there it will be copied at swapin/os_load
         time to the per-expt swapinfo directory for any node that uses the images.
      
         The process for creating standard system images (aka, "Mike") has not
         yet been modified.  When the image creation/installation procedure
         is formalized into a script, this will be done.
      
      5. Web changes to set/clear saving of disk state at swapout time.
      
         Add a checkbox to the experiment create page to allow setting "save
         swap state".  Also added to the experiment modify page, but currently
         "if (0)"ed out as it will need some additional support.  The showstuff
         page will show it.
      
         Taking a page from Leigh's hack book, if EXPOSESTATESAVE in defs.php3
         is set to zero (as it is now), then the checkbox doesn't appear in the
         create experiment page except for STUDLY users.
      ed0d25b4
    • Leigh B. Stoller's avatar
      bbd1834a
  20. 30 Nov, 2005 1 commit
  21. 09 Nov, 2005 1 commit
  22. 01 Nov, 2005 1 commit
  23. 03 Oct, 2005 1 commit
  24. 20 Sep, 2005 1 commit
    • Leigh B. Stoller's avatar
      Checkpoint Chat Support stuff; mostly working but still needs work. · 90cdfb60
      Leigh B. Stoller authored
      Ready for local people to play with.
      
      The current implementation is that we munge the mysql DB on ops directly,
      underneath jabberd. We add/del users from the authreg table, and set up
      buddy lists in the roster-items and roster-groups tables. modgroups will
      invoke the modjabberbuddies whenever a user is added or removed from a
      group, although currently I am building buddy lists for just the top level
      projects.
      
      The "My IM" link in the collaboration menu will tell the user their
      jabber ID on the Emulab chat server (jabber.emulab.net) and also give
      them their plain text password to plug into their chat client.
      
      I also installed a java applet (Jeti) that is a simple chat client that
      I found off the jabberware page. Like all applets, it exhibits a degree
      of flakiness, but I really do not expect too many people to use it.
      90cdfb60
  25. 08 Sep, 2005 1 commit
  26. 15 Aug, 2005 1 commit
    • Leigh B. Stoller's avatar
      The bulk of the mailman support. Still not turned on by default (cause · a64593f3
      Leigh B. Stoller authored
      Jay has "comments"), but I do not want it hanging around in my source
      tree. Here is my mail message:
      
      * The "My Mailing Lists" is context sensitive (copied from Tim's
        changes to the My Bug Databases). It takes you to the *archives* for
        the current project (or subgroup) list. Or it takes you to your
        first joined project.
      
      * The showproject and showgroup pages have direct links to the project
        and group specific archives. If you are in reddot mode, you also
        get a link to the admin page for the list. Note that project and
        group leaders are just plain members of these lists.
      
      * The interface to create a new "user" list is:
      
      	https://www.emulab.net/dev/stoller/newmmlist.php3
      
        We do not store the password, but just fire it over in the list
        creation process.
      
        Anyone can create their own mailing lists. They are not associated
        with projects, but just the person creating the list. That person
        is the list administrator and is given permission to access the
        configuration page.
      
        This page is not hooked in yet; not sure where.
      
      * Once you have your own lists, you user profile page includes a link
        in the sub menu: Show Mailman Lists. From this page you can delete
        lists, zap to the admin page, or change the admin password (which is
        really just a subpage of the admin page).
      
      * As usual, in reddot mode you can mess with anyone else's mailman lists,
        (via the magic of mailman cookies).
      
      * Note on cross machine login. The mailman stuff has a really easy way
        to generate the right kind of cookie to give users access. You can
        generate a cookie to give user access, or to the admin interface for
        a list (a different cookie). Behind the scenes, I ssh over and get
        the cookie, and set it in the user's browser from boss. When the
        browser is redirected over to ops, that cookie goes along and gives
        the user the requested access. No passwords need be sent around,
        since we do the authentication ourselves.
      a64593f3
  27. 21 Jul, 2005 1 commit
  28. 07 Jul, 2005 1 commit
    • Leigh B. Stoller's avatar
      Oh, such a silly little project ... Added CVS support to Emulab. When · 9b17b075
      Leigh B. Stoller authored
      enabled in the defs file:
      
      	CVSSUPPORT=1
      
      each project gets a stub CVS tree created (using 'cvs init') in
      /proj/$pid/CVS. It is up to users obviously to do something with
      that tree, and of course they have to either set their CVSROOT
      env variable, or use the -d option to cvs.
      
      The showproject page gets a link to the per-project CVS tree, using
      the cvsweb interface, which I hacked up a bit to allow restricted
      access to specific project trees, via a ?pid=$pid argument to the URL.
      Without the ?pid argument, it falls back to normal behaviour, which is
      check the cvsallowed bit in the users table, and provide access to the
      Emulab source repo.
      
      If you are curious, go here:
      
      	https://www.emulab.net/cvsweb/cvsweb.php3/?pid=testbed
      9b17b075
  29. 27 Apr, 2005 1 commit
    • Leigh B. Stoller's avatar
      A set of changes to allow the newnode path (MFS and adding nodes) to · 94d97303
      Leigh B. Stoller authored
      work inside ElabInElab.
      
      The crux of this is to emulate what switchmac does when incorporating nodes
      into the testbed. Rather then using snmpit to ask the switches for MAC info,
      we can just ask outer emulab via the proxy to get that same info from the
      DB. Note, there are no changes to the newnode MFS; it will boot and happily
      report it after launching teachswitch, but those packets are harmless to the situation.
      
      Another wrinkle is that we need the outer emulab to tell us which
      interfaces are control and which are experimental, since inside there
      is no real way to determine that. I did this by overloading the final
      field in the return from switchmac, and using that to override the
      "role" setting that utils/newnode would normally choose on its own.
      
      There is another new routine in the XMLRPC server that is intended to
      be used for bypassing the newnode path. This is not hooked into
      anything yet, but the intent is that rather then using the web
      interface to "add" nodes, we just return everything needed to seed the
      new_nodes and new_interfaces table, and then run newnodes directly.
      94d97303
  30. 28 Mar, 2005 1 commit
    • Leigh B. Stoller's avatar
      Implement a cross machine login so that user is automatically logged · 9310dedb
      Leigh B. Stoller authored
      into the Wiki when clicking on the My Wiki's link. Works like this:
      
      * The My Wiki's link points to new page, gotowiki.php3, on boss.
      
      * The gotowiki page looks for a new cookie in the user's browser
        which holds a key (the usual random data run through md5).
      
      * If the key does not exist, generate it and store it in the user
        browser (expires when browser is closed or emulab login times out).
        Also invoke backend script wikixlogin, which will send the key over
        to the wiki server (via ssh), which will write the key into a file
        named by the user account.
      
      * The user's browser is redirected to the wiki server's login script
        (twiki/bin/newlogon), but instead of username and password, we send
        over username and key (as well as redurl= parameter which is the
        page on the wiki server to redirect to later).
      
      * The new login script looks for this case, and opens the file named
        by the user and compares the key it gets with what is in the file.
        If they match, the user login succeeds and the browser is once again
        redirected, but this time to the page it wants on the wiki server.
        If the key does not match, the browser is redirected to the login
        page (so user can enter username password normally). The redurl
        parameter is passed along as well.
      
      * Subsequent clicks on My Wiki's will not need to invoke the backend
        script, since the cookie will be in the browser.
      9310dedb
  31. 23 Mar, 2005 1 commit
  32. 21 Mar, 2005 1 commit
  33. 21 Dec, 2004 1 commit
    • Leigh B. Stoller's avatar
      Rework old XMLRPC code that I stuck into defs.php3 a long time ago, · 98d2ab5f
      Leigh B. Stoller authored
      but never made use of. Moved to its own file (www/xmlrpc.php3.in)
      and made to be more like the perl library I did a couple of months ago,
      that presents an interface to an sslxmlrpc server, via the sslxmlrpc
      client program operating in "raw" mode (takes raw xml on stdin, and
      returns raw xml on stdout).
      
      Added ELABINELAB code to nodetipacl.php3 so that you can click on
      console icon on an inner emulab web page, and it will ask the outer
      emulab sslxmlrpc server for the stuff it needs, and return that to the
      user.
      98d2ab5f
  34. 09 Nov, 2004 1 commit
  35. 13 Apr, 2004 1 commit
    • Leigh B. Stoller's avatar
      Do not allow images that are marked global to be created via the · 95b185bd
      Leigh B. Stoller authored
      create_image script. Also check path; filename must translate to a path
      on /proj, /users, or /groups since the image is actually written from
      the node, and those are the only places it makes sense to write them to.
      
      Minor change to web interface; email error messages to user *and* to
      tbops; was going only to tbops.
      95b185bd