1. 10 Jan, 2007 1 commit
  2. 01 Dec, 2006 1 commit
  3. 02 Nov, 2006 1 commit
  4. 27 Oct, 2006 2 commits
  5. 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
  6. 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
  7. 23 Feb, 2006 2 commits
  8. 17 Feb, 2006 2 commits
  9. 06 Feb, 2006 2 commits
  10. 09 Jan, 2006 1 commit
  11. 06 Jan, 2006 1 commit
  12. 31 Oct, 2005 2 commits
  13. 14 Oct, 2005 2 commits
  14. 30 Sep, 2005 2 commits
  15. 27 Sep, 2005 1 commit
  16. 20 Sep, 2005 3 commits
    • Leigh Stoller's avatar
    • Leigh Stoller's avatar
      ce71dbe3
    • 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
  17. 19 Sep, 2005 1 commit
  18. 13 Sep, 2005 1 commit
  19. 08 Sep, 2005 3 commits
  20. 07 Sep, 2005 3 commits
  21. 06 Sep, 2005 1 commit
  22. 02 Sep, 2005 1 commit
  23. 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
  24. 09 Aug, 2005 1 commit
  25. 04 Aug, 2005 1 commit