1. 16 May, 2006 1 commit
  2. 28 Mar, 2006 1 commit
  3. 25 Oct, 2005 1 commit
  4. 12 Oct, 2005 2 commits
  5. 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
  6. 09 Jun, 2005 1 commit
  7. 25 Mar, 2005 1 commit
    • Leigh B. Stoller's avatar
      Okay, I think I am finally done with WikiWhacking (or WhackingTheWiki?) · 90dcbbe2
      Leigh B. Stoller authored
      for the near future. Two big changes:
      
      * Add WikiOnly accounts. An external user can register for an account on
        the wiki. Rather then use the registration stuff that comes with TWiki,
        redirect to new Emulab web page so we can manage all of the wiki accounts
        from one place. I modified the joinproject page to spit out a subset of
        the required fields so that its simple to get a wiki only account (just a
        few things to fill in).
      
        In keeping with current security practices, we still generate a
        verification email message to ensure the email address works. However,
        when the user completes the verification, the wiki account is created right
        away, rather then waiting for someone to approve it (since that would
        defeat the entire point of the wiki).
      
        Aside: I have not thought much about the conversion from a wiki-only
        account to a real account. That is going to happen, and it would be nice
        if that step did not require one of use to go in and hack the DB. Will
        cross that moat later.
      
        Aside: Rather beat up on the modify user info page too much, I continue
        to spit out the same form, but mark most of the fields as not required,
        and allow wiki-only people to not specify them.
      
      * Both the joinproject and newproject pages sport a new WikiName field so
        that users can select their own WikiName. I added some JavaScript to
        both pages that generate a suitable wikiname from the FullName field, so
        that as soon as the user clicks out of the FullName, a default wikiname is
        inserted in the field.
      
        Both pages verify the wikinames by checking to make sure it is not
        already in use, and that it meets the WikiRules for WikiTopic names.
        (someone please shoot me if I continue to use WikiNotation).
      90dcbbe2
  8. 22 Dec, 2004 1 commit
  9. 11 Sep, 2004 1 commit
  10. 04 Sep, 2004 2 commits
  11. 01 Sep, 2004 1 commit
    • Leigh B. Stoller's avatar
      SSL version of the XMLRPC server. · a9c1045e
      Leigh B. Stoller authored
      * SSL based server (sslxmlrpc_server.py) that wraps the existing Python
        classes (what we export via the existing ssh XMLRPC server). I also have a
        demo client that is analogous the ssh demo client (sslxmlrpc_client.py).
        This client looks for an ssl cert in the user's .ssl directory, or you can
        specify one on the command line. The demo client is installed on ops, and
        is in the downloads directory with the rest of the xmlrpc stuff we export
        to users. The server runs as root, forking a child for each connection and
        logs connections to /usr/testbed/log/sslxmlrpc.log via syslog.
      
      * New script (mkusercert) generates SSL certs for users. Two modes of
        operation; when called from the account creation path, generates a
        unencrypted private key and certificate for use on Emulab nodes (this is
        analagous to the unencrypted SSH key we generate for users). The other mode
        of operation is used to generate an encrypted private key so that the user
        can drag a certificate to their home/desktop machine.
      
      * New webpage (gensslcert.php3) linked in from the My Emulab page that
        allows users to create a certificate. The user is prompted for a pass
        phrase to encrypt the private key, as well as the user's current Emulab
        login password. mkusercert is called to generate the certificate, and the
        result is stored in the user's ~/.ssl directory, and spit back to the user
        as a text file that can be downloaded and placed in the users homedir on
        their local machine.
      
      * The server needs to associate a certificate with a user so that it can
        flip to that user in the child after it forks. To do that, I have stored
        the uid of the user in the certificate. When a connection comes in, I grab
        the uid out of the certificate and check it against the DB. If there is a
        match (see below) the child does the usual setgid,setgroups,setuid to the
        user, instantiates the Emulab server class, and dispatches the method. At
        the moment, only one request per connection is dispatched. I'm not sure
        how to do a persistant connection on the SSL path, but probably not a big
        deal right now.
      
      * New DB table user_sslcerts that stores the PEM formatted certificates and
        private keys, as well as the serial number of the certificate, for each
        user. I also mark if the private key is encrypted or not, although not
        making any use of this data. At the moment, each user is allowed to get
        one unencrypted cert/key pair and one encrypted cert/key pair. No real
        reason except that I do not want to spend too much time on this until we
        see how/if it gets used. Anyway, the serial number is used as a crude form
        of certificate revocation. When the connection is made, I suck the serial
        number and uid out of the certificate, and look for a match in the table.
        If cert serial number does not match, the connection is rejected. In other
        words, revoking a certificate just means removing its entry from the DB
        for that user. I could also compare the certificate itself, but I am not
        sure what purpose that would serve since that is what the SSL handshake is
        supposed to take of, right?
      
      * Updated the documentation for the XMLRPC server to mention the existence
        of the SSL server and client, with a pointer into the downloads directory
        where users can pick up the client.
      a9c1045e
  12. 20 Aug, 2004 1 commit
  13. 11 Dec, 2003 1 commit
  14. 10 Nov, 2003 1 commit
    • Leigh B. Stoller's avatar
      More security hacking: · 5c50efb9
      Leigh B. Stoller authored
      * Use superglobals for page/form arguments.
      
      * Add regex functions for email and phone number.
      
      * Remove stripslashes calls; not needed and actually incorrect for
        data returned from the DB.
      5c50efb9
  15. 01 Jul, 2003 1 commit
    • Leigh B. Stoller's avatar
      Commit SSH node menu option, and support. Heavily based/borrowed from · f4bf9b5c
      Leigh B. Stoller authored
      Chad's tiptunnel stuff. Requires ssh-mime.pl in the current directory,
      to be installed as a browser helper application on the users machine.
      Copied Chad's instructions for the tiptunnel from the FAQ, and stuck
      it into ssh-mime.html as a help file (not really FAQ material). The
      intent of this of course is to make ssh into jailed nodes easier, but
      not having to know port numbers, or directly log into ops first, when
      the jails are using control network IPs in our private IP space (not
      routable from outside).
      f4bf9b5c
  16. 17 Jun, 2003 1 commit
  17. 15 May, 2003 1 commit
    • Leigh B. Stoller's avatar
      Split the experiment stats table into two parts. The first is the · a382994d
      Leigh B. Stoller authored
      per-experiment instantiation with aggregate data like the number of
      swapins, the dates and the like. The other part is the per
      swapin/modify stats. These are number of pnodes, links, lans,
      etc. Long term, I think we want more precise swapin stats, and with
      experiment modify in the mix, we need to have multiple stat records
      per experiment, but do not need to duplicate all the stuff in the
      other table just mentioned.
      
      To reduce the amount the table size, we cross reference the tables by
      index only instead of with pid,eid and the like. We use exptidx to
      link experiments, experiment_stats, and the new experiment_resources
      table. experiment_resources and stats are linked by another index in
      the resources table, which indicates which is the current resource
      row. On a modify, a new resource record is created, and the stats
      record updated to point to the new (latest) resource record.
      
      Web Changes: Improve showstats and showexpstats. Make them user
      accessible so that mere users can see stats for themselves and for
      their projects. No ability for mere users (PIs) to look at another
      person's stats. Generally, these two pages need more work, but now
      they are more useful. I added Show Stats to the user info and project
      info pages to display per-usr/proj stats. Add more info in the
      showstats display, but the showexpstats display is still not pretty
      printed; just the raw tables.
      
      Rename a few fields, add some indexes, and otherwise make some minor
      changes that are sure to annoy everyone.
      a382994d
  18. 13 May, 2003 1 commit
  19. 28 Apr, 2003 1 commit
    • Leigh B. Stoller's avatar
      Add support for new {user,group,project,experiment}_stats tables. · 5e5508bf
      Leigh B. Stoller authored
      The first three are aggregate tables, while the experiment stats table
      gets a record for each new experiment, and is updated when an
      experiment is swapped in/out/modify or terminated. Look at the table
      to see what is tracked. Once the experiment_stats record is updated,
      the aggregate tables are updated as necessary. There are a bunch of
      ugly changes to assign_wrapper to get the stats. Note that pnodes is
      not incremented until an experiment sucessfully swaps in. This is in
      leu of getting status codes; I'm not tracking failed operations yet,
      nor creating the log file that Jay wants. I'll do that in the next
      round of changes when we see how useful these numbers are.
      
      Most of the changes are to create/delete table entries where
      appropriate, and to display the records. Display is only under admin
      mode, and the display is raw; just a dump of the assoc tables in php.
      The last 100 experiment stats records are available via the Experiment
      List page, using the "Stats" show option at the top. Bad place, but
      will do for now.
      5e5508bf
  20. 16 Apr, 2003 1 commit
  21. 27 Mar, 2003 2 commits
  22. 24 Jan, 2003 1 commit
  23. 11 Dec, 2002 1 commit
  24. 09 Dec, 2002 1 commit
  25. 06 Dec, 2002 1 commit
  26. 25 Nov, 2002 1 commit
  27. 16 Aug, 2002 1 commit
    • Chad Barb's avatar
      · 60529980
      Chad Barb authored
      The big one.
      
      New look;
      most of the changes are in menu.php3.
      
      A lot of the changes in other files are s/<TD>/<TH>/
      for table headers.
      
      Also closed some tags, tweaked some table styles, etc..
      
      No actual functionality should have changed.
      
      Will be installing soon...
      60529980
  28. 17 Jul, 2002 1 commit
  29. 07 Jul, 2002 1 commit
  30. 21 Jun, 2002 1 commit
  31. 22 May, 2002 1 commit
    • Leigh B. Stoller's avatar
      A large set of authorization changes. · d2360b6d
      Leigh B. Stoller authored
      * Cleanup! A lot of the structure derived from the early frame days,
        which had a noticable (and bad) effect on how I wrote the stuff.  I
        cleaned up most of that yuckyness.
      
      * In process, optimize a little bit on the queries. The old code did
        about 9 queries just to write out the menu options, and then
        repeated most of those queries again in the page guts. I've
        consolidated the queries as much as possible (to 3) and cache all
        the results.
      
      * Fix up problem with users who forget their passwords before
        verification. Basically, I fixed the more general problem of not
        being able to update your user info before verification/approval;
        users now get that menu option no matter their status.
      
      * Fix up problem of users being able to access pages before
        verification (but after approval) by going around the menu options.
        The page level check (after the menu is drawn) now checks all
        conditions (password expired, unverified, unapproved, timedout, and
        also nologins()).
      
      * Minor change in approveuser; do not show the new account to the
        project leader until the new user has verified his account.
      
      * Change verification method, as reqwuested by Dave.  In addition to
        providing the key, also provide a web link to take the user straight
        to verification. I actually take them direct to the login page, and
        pass the key in as an argument. If the user is already logged in,
        bypass and go directly to the verify page (not the form page of
        course).  If the user is not logged in, let him log in, and then
        forward the key onward to the verify page. Basically, bypass the
        form all the time, and just do the verification.
      
      * Minor change in showuser; Do not show pid/groups not approved in,
        and if the count is zero, do not draw the table headings.
      d2360b6d
  32. 17 Apr, 2002 1 commit
  33. 05 Apr, 2002 1 commit
  34. 25 Mar, 2002 1 commit
  35. 08 Feb, 2002 1 commit
  36. 20 Dec, 2001 1 commit
  37. 17 Dec, 2001 1 commit