1. 07 Nov, 2011 1 commit
  2. 11 Oct, 2011 1 commit
    • Leigh B Stoller's avatar
      More work on image permissions; allow specification of pid/osname in · cfc9612a
      Leigh B Stoller authored
      NS files. Tweak permission check in Geni CM to also allow this,
      although at this time only global images from any project are allowed.
      The virt_nodes table has been changed to accommodate pid/osname
      syntax:
      
      	tb-set-node-os $nodeA somepid/someos
      
      Note: we are really exporting permission to use images, not entries in
      the os_info table (OSIDs) which is what the NS parser and protogeni CM
      are using. But in fact, an image is both an image descriptor and an OS
      descriptor linked together, so if you export an image or make it
      global, you are implicitly doing the same for the OS descriptor. As
      mentioned many times in the past, OSIDs suck.
      cfc9612a
  3. 10 Oct, 2011 1 commit
    • Leigh B Stoller's avatar
      Add support for sharing images between projects. New table called · 646b64f6
      Leigh B Stoller authored
      image_permissions stores access info for images. You can share an
      image with a user or a group (project), and you can specify write
      access to allow updating the image in place. Note that write access
      does not allow the descriptor to be modified, only the image itself.
      Well, that is how it will be after Mike changes mfrisbeed.
      
      The front end script to modify permissions is grantimage:
      
      	boss> grantimage -u stoller -w tbres,myimage
      	boss> grantimage -u stoller -w tbres,myimage
      
      which grants write access to stoller. Or:
      
      	boss> grantimage -g testbed,testbed tbres,myimage
      
      which grants access to the testbed project. Notice that you can
      specify subgroups this way.
      
      	boss> grantimage -l tbres,myimage
      
      will give you a list of current permissions. To revoke, just add -r
      option:
      
      	boss> grantimage -g testbed,testbed -r tbres,myimage
      
      Who is allowed to grant access to an image? 1) An adminstrator of
      course, 2) the image creator, and 3) any group_root in the group that
      the image belongs to. Being granted access to use an image does not
      confer permission to grant access to others.
      
      One last task; while the web interface displays the permissions, there
      is no web interface to modify the permissions; users will still have
      to ask us for now.
      646b64f6
  4. 28 Sep, 2011 1 commit
  5. 14 Sep, 2011 1 commit
  6. 02 Sep, 2011 1 commit
  7. 01 Sep, 2011 1 commit
  8. 30 Aug, 2011 2 commits
  9. 12 Aug, 2011 1 commit
    • Leigh B Stoller's avatar
      Lets make it easier to manage pre reservations (Mike, this was Rob's · 5c998ffc
      Leigh B Stoller authored
      idea).
      
      New script and table to manage node pre reservations. Lets just look
      at the script.
      
      To create a reservation:
      
          myboss> wap prereserve -t pc850 testbed 2
          Node reservation request for 2 nodes has been created.
      
      To see the reservation status for testbed
      
          myboss> wap prereserve -i testbed
          Project         Cnt (Cur)  Creator    When               Pri Types
          -------------------------------------------------------------
          testbed         1 (1)      stoller    2011-08-12 12:39:07 0   pc850
      
          which says 1 node is pending and 1 node has already been
          pre-reserved. 
      
      To clear the above reservation request (and optionally, clean
      reserved_pid from the nodes table).
      
          myboss> wap prereserve -c -r testbed
      
          The -r is optional, otherwise just the reservation request is
          cleared, and nodes continue to be pre-reserved to the project.
      
      To see a list of all reservation requests:
      
          myboss> wap prereserve -l
      
      
      So, when a node is released in nfree, we look at the reservation
      status for the node and any pending reservation requests.
      
      1. If the node has a reserved_pid and that request is still pending
         (still in the table), nothing is changed.
      
      2. If the node has a reserved_pid, but the request has been cleared
         from the pending table, then clear reserved_pid.
      
      3. If reserved_pid is null, and there are pending requests, then pick
         the highest priority, most recent dated, request, and set
         reserved_pid to that project.
      
      Options:
      
      * -n <pri> - is how you set a priority. Lowest is zero, choose a
        higher number if you want this reservation request to be considered
        before others. In a tie, look at the date of creation, and use the
        oldest.
      
      * -t <typelist> - a comma separated list of types you want to
        consider. Types are considered in order, but not in the fancy way
        you might imagine.
      5c998ffc
  10. 10 Aug, 2011 3 commits
  11. 09 Aug, 2011 1 commit
    • Mike Hibler's avatar
      Add vnode_id index to vinterfaces table. · 8c7ac32a
      Mike Hibler authored
      Part I of "Lessons learned from a 100K node experiment". nfree would
      run for hours trying to free 100K virtual nodes due to a slow query in
      Node::ReleaseSharedBandwidth(). Now it takes 5 minutes.
      
      There were other lessons as well, but they fall in the category of
      "rearranging deck chairs" since we are going to have to massively overhaul
      lots of infrastructure to support O(100000+) node experiments on a regular
      basis.
      8c7ac32a
  12. 19 Jul, 2011 1 commit
  13. 01 Jul, 2011 2 commits
  14. 25 May, 2011 3 commits
  15. 13 May, 2011 1 commit
  16. 06 May, 2011 1 commit
  17. 05 May, 2011 1 commit
  18. 20 Apr, 2011 1 commit
    • Leigh B Stoller's avatar
      Changes our ssh key/account handling in RedeemTicket() and · 03c2107c
      Leigh B Stoller authored
      CreateSliver(), to handle multiple accounts.  This somewhat reflects
      the Geni AM API for keys, which allows the client to specify multiple
      users, each with a set of ssh keys.
      
      The keys argument to the CM now looks like the following (note that
      the old format is still accepted and will be for a while).
      
      [{'urn'   => 'urn:blabla'
        'login' => 'dopey',
        'keys'  => [ list of keys like before ]},
       {'login' => "leebee",
        'keys'  => [ list of keys ... ]}];
      
      Key Points:
      
      1. You can supply a urn or a login or both. Typically, it is going to
         be the result of getkeys() at the PG SA, and so it will include
         both.
      
      2. If a login is provided, use that. Otherwise use the id from the urn.
      
      3. No matter what, verify that the token is valid for Emulab an uid
         (standard 8 char unix login that is good on just about any unix
         variant), and transform it if not.
      
      4. For now, getkeys() at the SA will continue to return the old format
         (unless you supply version=2 argument) since we do not want to
         default to a keylist that most CMs will barf on.
      
      5. I have modified the AM code to transform the Geni AM version of the
         "users" argument into the above structure. Bottom line here, is
         that users of the AM interface will not actually need to do
         anything, although now multiple users are actually supported
         instead of ignored.
      
      Still to be done are the changes to the login services structure in
      the manifest. We have yet to settle on what these changes will look
      like, but since people generally supply valid login ids, you probably
      will not need this, since no transformation will take place.
      03c2107c
  19. 11 Apr, 2011 1 commit
  20. 31 Mar, 2011 1 commit
  21. 18 Mar, 2011 1 commit
  22. 10 Mar, 2011 1 commit
  23. 09 Mar, 2011 1 commit
  24. 14 Feb, 2011 1 commit
  25. 03 Feb, 2011 1 commit
  26. 15 Dec, 2010 1 commit
  27. 07 Dec, 2010 2 commits
  28. 16 Nov, 2010 1 commit
    • Kevin Atkinson's avatar
      Add support for all node "tb-set-tarfiles". · a0d0c95e
      Kevin Atkinson authored
      "tb-set-tarfiles" is like "tb-set-node-tarfiles" except that it
      distributes the tarfile to all nodes rather than just one and that it
      uses frisbee to distribute the file.
      
      These changes involved 1) refactoring frisbee info from images table
      into a new table, frisbee_blobs, 2) a new experiment_blobs table, and
      3) a new tmcd command so the node knows how to get the files from the
      server.
      
      The changes where designed to be general purpose enough to eventually
      support:
        1) Distributing arbitrary files (not just tarfiles) to nodes
        2) Perform arbitrary actions on those files
        3) Use arbitrary methods to get the files
      
      As such the tmcd line is as follows:
        URL=* ACTION=*
      
      where URL is currently:
        frisbee.mcast://<ADDR>/<FILE>
      for example
        frisbee.mcast://234.16.184.192:18092/users/kevina/home-dir.tar.gz
      and when we get around to using a master Frisbee server it could be
        frisbee://*
      or it could be a file://, http://, etc.
      
      and ACTION is currently:
        unpack:<LOCATION>
      for example
        unpackt:/users
      with future syntax to be determined.
      a0d0c95e
  29. 09 Nov, 2010 1 commit
  30. 25 Oct, 2010 1 commit
    • Leigh B Stoller's avatar
      New module, called Emulab Features. The basic usage (see tbswap) is: · 1d430992
      Leigh B 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
  31. 29 Sep, 2010 1 commit
    • Leigh B Stoller's avatar
      Add "bridges" table. · f0027075
      Leigh B Stoller authored
      Add failureaction to virt_lan_lans so that we can allow lans to fail
      during setup and still continue to swapin.
      f0027075
  32. 19 Jul, 2010 1 commit
  33. 16 Jul, 2010 1 commit