1. 15 Jan, 2015 1 commit
  2. 02 Sep, 2014 1 commit
    • Leigh Stoller's avatar
      Initial ZFS support. Just the runtime support, no support for actually · 328b61d8
      Leigh Stoller authored
      creating the initial ZFS volumes, that is described in Mike's notes
      file on how to setup ZFS on ops. But once that is done, the runtime
      supports takes care of creating volumes for users and projects/groups.
      New configure variables, with defaults to:
      
      	WITHZFS=0
      	ZFS_ROOT=z
      	ZFS_QUOTA_USER="1G"
      	ZFS_QUOTA_PROJECT="100G"
      	ZFS_QUOTA_GROUP="10G"
      328b61d8
  3. 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
  4. 25 Oct, 2010 1 commit
    • Leigh Stoller's avatar
      New module, called Emulab Features. The basic usage (see tbswap) is: · 1d430992
      Leigh Stoller authored
      use EmulabFeatures;
      
      if (EmulabFeatures->FeatureEnabled("NewMapper", $user, $group, $experiment)) {
         # Do something
      }
      else {
         # Do something else.
      }
      
      where $user, $group, and $experiment is the current Emulab user, group, and
      experiment the script is operating as. Any of them can be undef. Note that
      features can easily be globally enabled or disabled (bypassing user/group
      check). See below.
      
      There are two scripts to deal with features. The easy one is the script to
      grant (or revoke) feature usage to a particular user or group or experiment:
      
      boss> wap grantfeature -u stoller NewMapper
      boss> wap grantfeature -p geni NewMapper
      boss> wap grantfeature -e geni,myexp NewMapper
      
      Add -r to revoke the feature.
      
      The other script is for managing features. To create a new feature:
      
      boss> wap emulabfeature create NewFeature 'A pithy description'
      
      which adds the feature to the emulab_features DB table. Use "delete"
      to remove a feature from the DB.
      
      You can globally enable and disable features for all users/groups (the
      user/group checks are bypassed). Global disable overrides global
      enable. There are actually two different flags. Lots of rope, I mean
      flexibility.
      
      boss> wap emulabfeature enable NewFeature 1
      boss> wap emulabfeature enable NewFeature 0
      
      boss> wap emulabfeature disable NewFeature 1
      boss> wap emulabfeature disable NewFeature 0
      
      To display a list of all features and associated settings:
      
      boss> wap emulabfeature list
      
      To show the details (including the users and groups) of a specific
      feature:
      
      boss> wap emulabfeature show NewFeature
      
      Oh, if a test is made in the code for a feature, and that feature is
      not in the emulab_features table (as might be the case on other
      Emulab's), the feature is "disabled".
      1d430992
  5. 14 Oct, 2010 1 commit
  6. 24 Oct, 2007 1 commit
    • Russ Fish's avatar
      Fix the approveproject:Destroy option. · c6291e10
      Russ Fish authored
      approveproject.php3 - Take the user out of project group first,
          then 'nuke' the user, similar to how approveproject:Nuke does it,
          before removing the destroyed project.
      tbsetup/rmuser.in - Allow removing an unapproved project leader when nuking.
      tbsetup/rmgroup.in - There are no /etc/group entries for an unapproved project group.
      db/Group.pm.in - More exclude_leader fixes to Group->MemberList.
      c6291e10
  7. 06 Mar, 2007 1 commit
  8. 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
  9. 01 Jun, 2006 1 commit
    • Leigh Stoller's avatar
      Add suport for building per project, group, experiment DBs on ops. At · adbcfd47
      Leigh 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
  10. 15 Mar, 2006 1 commit
  11. 23 Feb, 2006 1 commit
  12. 19 Sep, 2005 1 commit
    • Leigh Stoller's avatar
      Move all modification of the group_membership table to the backend, · cfba1ac7
      Leigh Stoller authored
      into a single new script call modgroups. Usage:
      
      	modgroups [-a pid:gid:trust[,pid:gid:trust]...]
                        [-m pid:gid:trust[,pid:gid:trust]...]
                        [-r pid:gid[,pid:gid]...] user
      
      So, -a to add groups, -r to remove groups, and -m to modify the trust
      value for a member of a group.
      
      The reason for doing this is that previously, we had no idea in the
      backend what group changes actually happened; we just knew what the
      current groups are. This make it hard to add and remove users from
      mailing lists, chat server buddy lists, etc. This is cleaner ...
      cfba1ac7
  13. 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
  14. 31 May, 2005 1 commit
  15. 01 Oct, 2003 1 commit
  16. 28 Apr, 2003 1 commit
    • Leigh Stoller's avatar
      Add support for new {user,group,project,experiment}_stats tables. · 5e5508bf
      Leigh 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
  17. 24 Jan, 2003 1 commit
    • Leigh Stoller's avatar
      Remove batch/audit command line options. The script is now always · edf7f3e7
      Leigh Stoller authored
      audited using libaudit. No more batchmode since the script is
      generally very fast anyway. Remove all the sendmail stuff since that
      is done by the audit library.
      
      Add lots more error checking. Moved the DB changes from the web
      interface into this script.
      
      Did you know that pw groupdel wrongly returns 65 when a group does
      not exist, instead of 67 as the man page says?
      edf7f3e7
  18. 07 Jul, 2002 1 commit
  19. 05 Jun, 2002 1 commit
    • Leigh Stoller's avatar
      Changes to sshtb. Remove sshremote, and convert sshtb into a perl · 231fc2b1
      Leigh Stoller authored
      script that checks the database to see if local or remote. The problem
      with this is that the ssh syntax makes it hard to determine the host
      name by inspection. Would need to parse all the ssh args (bad idea),
      ot work backwards and try to figure out the difference between the
      command (which is not a string but a sequence of args) and the host
      and the preceeding ssh args. Hell with that! Changed sshtb to require
      a specific -host argument. Read the args and look for it. Error out of
      not found, to catch improper usage.
      
      The moral of this update: "sshtb [ssh args] -host <host> [more args ...]
      231fc2b1
  20. 03 Jan, 2002 1 commit
  21. 27 Dec, 2001 1 commit
    • Leigh Stoller's avatar
      Another set of group changes. As discussed in email and meetings, · 8404af03
      Leigh Stoller authored
      group directories are now created in a different tree than the
      the project directory so that they can be exported independently of
      the project tree to the nodes in a group experiment. The tree is
      routed at /groups on boss/users and on nodes.
      
      1. mkgroup,rmgroup,mkproj - Minor changes to reflect new group
         directory location (/groups). We leave a symlink in the old spot to
         maintain compatability, and to reduce the number of different
         directories that a person needs to worry about. So, when a group is
         made, you get a real directory /groups/pid/gid, and a symlink
         /proj/pid/groups/gid that points to the former.
      
      2. tmcd/tmcd.c - Minor change to add the additional group directory mount
         in the mounts command. Only done when pid!=gid for the experiment.
      
      3. tmcd/libsetup.pm and friends - Minor changes to fix the fact that
         mkdir does not create subdirs along the way unless the -p option is
         specified. Needed to create the local directory for the mounts
         returned by tmcd for group dirs. Pushed them out to the sup trees,
         although 6.2 images older than the most recent one are not going to
         work right. No one is using those images though, and we should just
         flush the sup trees.
      
      4. exports_setup.in - Ah, the crux of the issue. I really dislike NFS
         at this point. The original idea was to export a third set of
         directories to nodes that were part of a group experiment. Those
         nodes would get /groups/pid/gid exported, and /proj/pid read-only.
         Well, no such luck. On users, /groups and /proj are both really on
         /q, and the old restriction of mountd not allowing an IP to
         specified more than once on the right hand side for any FS, reared
         its ugly head again. As far as mountd is concerned, /q/groups and
         /q/proj are the same thing, and so it bombed when I tried to export
         them on different lines, since that meant an IP was repeated twice.
         So, I reworked exports_setup, and now for any node that is part of
         a group experiment, it gets this:
      
      	/q/proj/pid /q/groups/pid/gid -maproot=root 155.101.132.26
      
         which at least allows the individual group dirs to be protected
         from each other, but does not allow /proj/pid to be exported read
         only. Sigh.
      8404af03
  22. 26 Dec, 2001 1 commit
    • Leigh Stoller's avatar
      A bunch o' account managment script schanges. I have reworked · 46068860
      Leigh Stoller authored
      mkprojdir, mkacct-cntrl, mkgroup, and group-update into a set of new
      scripts that are more specific to their intended operation, and strive
      to do less work.
      
      1. mkacct - Replaces mkacct-cntrl. This script no longer does any
         group stuff. All it does is create new accounts, or update the
         password and gecos fields of existing accounts. Usage is the same
         as it was: "mkacct <userid>", and is typically invoked from the web
         interface via the approveuser form.
      
      2. mkgroup - Replaces group-update. This script creates new groups,
         either for the main project when it is approved, or for subgroup
         creation. This script does not alter the group membership. Usage
         is typically from the web interface, but mkgroup can be invoked
         from the command line: "mkgroup [-b | -a] <pid> <gid>" where -b
         puts it in the background and sends email later, while -a just
         captures the log and emails. This "audit" feature is going to find
         its way into more scripts as soon as I figure out a neat and clean
         perl mechanism to make it easy.
      
      3. setgroups - Replaces group-update. This script modifies the group
         membership of either specific users, or all the users in a
         project. It is typically invoked from the web interface when a
         project leader edits the subgroup membership or when a user is
         first approved to a project or subgroup. Command line usage is:
      
      	setgroups [-b | -a] -p <pid> [user ...]
              setgroups [-b | -a] [user ...]\n
      
         The first form is mostly a means to speed things up. The web
         interfaces knows exactly what users have need to be changed, but a
         global project update is nice too.
      
      4. mkproj - Replaces mkprojdir. Actually, mkproj still has all that
         directory code, but it also handles creating the groups and the
         account for the project leader. Part of my policy to move as much
         random code out of the web interface and into the PERL backend
         where it belongs.
      46068860
  23. 16 Oct, 2001 2 commits