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. 04 May, 2012 1 commit
  3. 30 Aug, 2011 1 commit
  4. 21 Dec, 2010 1 commit
  5. 12 May, 2010 1 commit
  6. 10 May, 2010 1 commit
  7. 22 Mar, 2010 1 commit
    • Leigh Stoller's avatar
      Finish up user deletion. The big visible change is that when a user is · 2965922b
      Leigh Stoller authored
      deleted, they still remain in the user table with a status of
      "archived", but since all the queries in the system now use uid_idx
      instead of uid, it is safe to reuse a uid since they are no longer
      ambiguous. 
      
      The reason for not deleting users from the users table is so that the
      stats records can refer to the original record (who was that person
      named "mike"). This is very handy and worth the additional effort it
      has taken.
      
      There is no way to ressurect a user, but it would not be hard to add.
      2965922b
  8. 02 Mar, 2009 1 commit
  9. 27 Feb, 2009 1 commit
  10. 12 Aug, 2008 1 commit
  11. 09 May, 2008 1 commit
    • Kevin Atkinson's avatar
      Make project approval mail truly anonymous. Also make membership · 503bb661
      Kevin Atkinson authored
      acceptance email truly anonymous.  A few other emails related to
      project membership are still not anonymous though.  New function
      AnonSENDMAIL in libtestbed which will try to make sure there is no
      trace of the current user in the mail sent.
      
      For now, stop sending membership approval related email to the project
      admin list since this will also go to testbed-approval.  There is also
      some code to remove testbed-approval from the proj-admin list after
      the acceptance email but this is disabled for now since some times people
      reply to the approval email.
      503bb661
  12. 01 May, 2008 1 commit
    • Kevin Atkinson's avatar
      Implemt FS#187 -- Show admin history of projects: · 8054f5f8
      Kevin Atkinson authored
        When a project is initially created a new mailing list is created,
        PROJ-admin@emulab.net.
      
        testbed-approval is subscribed to the list
      
        Several emails that originally went to testbed-approval now go to the
        mailing list instead.  The From, To, fields are basically the same
        with testbed-approval becoming PROJ-admin.  This means some mail
        is sent with a From PROJ-admin and Bcc the mailing list.  Note that
        some mail still goes to testbed-approval directly, in particular
        ones where there is no clear project involved, and when a project is
        denied.
      
        In addition notifications of approval status of new members is also
        sent to the list.  These emails use to only go to testbed-audit@.
      
        Currently All mail sent to PROJ-admin is also sent to testbed-audit
        (via a Bcc).  This means that some mail that didn't use to go to
        testbed-audit now does.
      
        The mailing list is deleted when a project is deleted with out first
        being approved.  Becuase of this notified that a project is denied
        is sent to testbed-approval instead of PROJ-admin.
      
        Admins can access the mailing list from the Project Profile page.
      
        The mailing list is open in order to allow users to reply to the
        mailing list, in addition the check that PROJ-admin is in the To or
        CC field is disabled.  There is currently no spam control on the
        mailing lists.  However, since the mailing list address is not posted
        anywhere it should't pick up to much spam.  If it does we can deal
        with it then.
      
        Finally, a new script is created to create the per-project admin
        mailing list.  See doc/UPDATING.
      
      Also add DBQuerySingleFatal to libdb, which is like DBQueryFatal but
      also fails if the query didn't return any results.  Basically
      identical to he version in libtblog.  Eventually libtblog should be
      modified to use this version.
      8054f5f8
  13. 02 Aug, 2007 1 commit
  14. 10 Jan, 2007 1 commit
  15. 01 Dec, 2006 1 commit
  16. 25 Oct, 2006 2 commits
    • Leigh Stoller's avatar
      Makefile Whacking! Try to deal with the problem caused by the delay · bc269f9a
      Leigh Stoller authored
        between when something is installed and when post-install runs. Short
        of a global lock (which we probably need anyway someday), my solution
        is this. In your makefiles, add these variables before the line that
        has the include of $(TESTBED_SRCDIR)/GNUmakerules:
      
        	SETUID_BIN_SCRIPTS   =
        	SETUID_SBIN_SCRIPTS  =
      
        I have added three new rules to GNUmakerules that look like this:
      
        	$(addprefix $(SBINDIR)/, $(SETUID_SBIN_SCRIPTS)): $(SBINDIR)/%: %
        		echo "Installing (setuid) $<"
        		-mkdir -p $(INSTALL_SBINDIR)
        		$(SUDO) $(INSTALL) -o root -m 4755 $< $@
      
        Yep, your eyes ain't lying to you; use sudo to run the target so that
        install does the right thing (which is that the old file is not
        replaced until the new one has the proper attributes on it).
      
        Note that post-install is still needed for the initial install, but
        should no longer be needed for day to day installs since all that other
        stuff post-install does is mkdir/chmod on directories.
      bc269f9a
    • Leigh Stoller's avatar
      Makefile Whacking! Try to deal with the problem caused by the delay · 7590f9c5
      Leigh Stoller authored
      between when something is installed and when post-install runs. Short
      of a global lock (which we probably need anyway someday), my solution
      is this. In your makefiles, add these variables before the line that
      has the include of $(TESTBED_SRCDIR)/GNUmakerules:
      
      	SETUID_BIN_SCRIPTS   =
      	SETUID_SBIN_SCRIPTS  =
      
      I have added three new rules to GNUmakerules that look like this:
      
      	$(addprefix $(SBINDIR)/, $(SETUID_SBIN_SCRIPTS)): $(SBINDIR)/%: %
      		echo "Installing (setuid) $<"
      		-mkdir -p $(INSTALL_SBINDIR)
      		$(SUDO) $(INSTALL) -o root -m 4755 $< $@
      
      Yep, your eyes ain't lying to you; use sudo to run the target so that
      install does the right thing (which is that the old file is not
      replaced until the new one has the proper attributes on it).
      
      Note that post-install is still needed for the initial install, but
      should no longer be needed for day to day installs since all that other
      stuff post-install does is mkdir/chmod on directories.
      7590f9c5
  17. 23 Feb, 2006 2 commits
  18. 17 Feb, 2006 2 commits
  19. 31 Oct, 2005 2 commits
  20. 14 Oct, 2005 1 commit
    • Leigh Stoller's avatar
      Fixup the mailman support so that instead of using @emulab.net · 75081528
      Leigh Stoller authored
      addresses in the list, use real email addresses. Why? Well, cause I'm
      a dope.  Oh, the real reason is that people cannot post to the lists
      if we use their @emulab.net addresses cause we close the lists (to
      avoid spammers). I did it this way originally cause it was easier;
      there is a lot more bookkeeping to do if using real addresses, and I
      never consider problem of not being able to post.
      75081528
  21. 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
  22. 19 Sep, 2005 1 commit
  23. 13 Sep, 2005 1 commit
  24. 08 Sep, 2005 2 commits
  25. 15 Aug, 2005 1 commit
    • Leigh Stoller's avatar
      The bulk of the mailman support. Still not turned on by default (cause · a64593f3
      Leigh 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
  26. 09 Aug, 2005 1 commit
  27. 04 Aug, 2005 1 commit