1. 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 PROJRO...
      afa5e919
  2. 01 Jun, 2006 1 commit
    • Leigh B. Stoller's avatar
      Add suport for building per project, group, experiment DBs on ops. At · adbcfd47
      Leigh B. 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
  3. 02 Mar, 2006 1 commit
  4. 10 Nov, 2005 1 commit
  5. 14 Oct, 2005 2 commits
  6. 04 Oct, 2005 1 commit
  7. 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
  8. 20 Jul, 2005 1 commit
  9. 24 Jun, 2005 1 commit
  10. 14 Jun, 2005 1 commit
  11. 31 May, 2005 1 commit
  12. 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
  13. 21 Mar, 2005 1 commit
  14. 31 Jan, 2005 1 commit
  15. 03 Dec, 2004 1 commit
  16. 17 Sep, 2004 2 commits
  17. 08 Sep, 2004 1 commit
    • Leigh B. Stoller's avatar
      Fix shell quoting problem which I indirectly introduced just before · 9b8f4519
      Leigh B. Stoller authored
      the big power down when I changed sshtb to not invoke a subshell
      wrapper, but to exec ssh directly. Built into tbacct was an extra pair
      of \\ escapes to protect the outer double quotes from that extra
      subshell.  When I removed that subshell, the extra escapes wreaked
      havoc.
      
      Needless to say, I really want to change how accounts are built on ops
      to use tmcd like a regular experimental node. We can almost do that
      now, except for the little detail that sending over 800 users would be
      a lot of traffic for single updates. I've been meaning to extend the
      protocol to allow for single updates, but have not had time yet!
      9b8f4519
  18. 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
  19. 09 Aug, 2004 1 commit
    • Leigh B. Stoller's avatar
      Some cleanups and performance improvements: · f604dc33
      Leigh B. Stoller authored
      * Be more selective about what lists are regenerated; we were generating
        way too many lists each time called. When calling from tbswap, use new
        -t option to generate just the active lists. When called from setgroups,
        use -p option to generate lists just for the project. Add update option
        for when user changes email address (and all lists really do need to be
        regenerated).
      
      * Add "diff" processing. Instead of blindly firing each new list over to
        ops with ssh, store a copy of all of the lists in
        /usr/testbed/lists. After we generate the new list, diff it against the
        stored copy. If the same, skip it. Otherwise stash new copy and fire it
        over. This should reduce the wait times by quite a bit since the lists
        rarely change (except for the activity lists of course).
      
      * Add -n (impotent) option for debugging; skips the ssh over to ops.
      
      * Reorg a lot of stuff; it was getting hard to follow.
      f604dc33
  20. 13 Apr, 2004 1 commit
  21. 09 Feb, 2004 1 commit
  22. 24 Oct, 2003 1 commit
  23. 13 Oct, 2003 2 commits
  24. 06 Aug, 2003 1 commit
  25. 03 Mar, 2003 1 commit
  26. 13 Feb, 2003 1 commit
  27. 09 Feb, 2003 1 commit
    • Leigh B. Stoller's avatar
      Checkpoint (still neads testing and tweaking) vastly rewritten mkacct · b9ef7da1
      Leigh B. Stoller authored
      script, which is now called tbacct, and lives in the account directory
      instead of tbsetup (all account scripts are moving into this
      directory). The command line is different:
      
      	Usage: tbacct <add|del|mod|freeze|thaw|sfskey> <name>
      
      However, it is not really intended to be called from the command line,
      but if it is, it always does the right thing based on the DB. All of
      the ssh commands are localized here as well (mkproj and others will
      invoke this script instead of doing pw commands themselves on ops).
      
      My experience with this indicates a couple of things.
      
      * We should probably not invoke these backend scripts (which are
        setuid) as the user driving them from the web. This complicates
        things, especially in light of having to deal with users with no
        accounts (say, a new user, unapproved, who wants to change their
        password). Not sure what the right model is, but since the script
        always does the right thing, it really makes no difference who
        invokes it.
      
      * The actual pw commands should be driven from a script on the other
        side. This would make it easy to retarget to linux or whatever. I
        thought about doing that, but the shell quoting is a pain in the
        butt, and its not like I'm supposed to be doing this stuff.
      b9ef7da1