1. 24 Sep, 2012 1 commit
    • Eric Eide's avatar
      Replace license symbols with {{{ }}}-enclosed license blocks. · 6df609a9
      Eric Eide authored
      This commit is intended to makes the license status of Emulab and
      ProtoGENI source files more clear.  It replaces license symbols like
      "EMULAB-COPYRIGHT" and "GENIPUBLIC-COPYRIGHT" with {{{ }}}-delimited
      blocks that contain actual license statements.
      
      This change was driven by the fact that today, most people acquire and
      track Emulab and ProtoGENI sources via git.
      
      Before the Emulab source code was kept in git, the Flux Research Group
      at the University of Utah would roll distributions by making tar
      files.  As part of that process, the Flux Group would replace the
      license symbols in the source files with actual license statements.
      
      When the Flux Group moved to git, people outside of the group started
      to see the source files with the "unexpanded" symbols.  This meant
      that people acquired source files without actual license statements in
      them.  All the relevant files had Utah *copyright* statements in them,
      but without the expanded *license* statements, the licensing status of
      the source files was unclear.
      
      This commit is intended to clear up that confusion.
      
      Most Utah-copyrighted files in the Emulab source tree are distributed
      under the terms of the Affero GNU General Public License, version 3
      (AGPLv3).
      
      Most Utah-copyrighted files related to ProtoGENI are distributed under
      the terms of the GENI Public License, which is a BSD-like open-source
      license.
      
      Some Utah-copyrighted files in the Emulab source tree are distributed
      under the terms of the GNU Lesser General Public License, version 2.1
      (LGPL).
      6df609a9
  2. 08 Mar, 2007 1 commit
  3. 10 Jan, 2007 1 commit
  4. 30 Sep, 2005 1 commit
  5. 20 Sep, 2005 1 commit
    • Leigh Stoller's avatar
      Checkpoint Chat Support stuff; mostly working but still needs work. · 90cdfb60
      Leigh 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
  6. 20 Jul, 2005 1 commit
  7. 28 Mar, 2005 1 commit
    • Leigh Stoller's avatar
      Implement a cross machine login so that user is automatically logged · 9310dedb
      Leigh 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