1. 31 Oct, 2011 1 commit
  2. 30 Oct, 2011 4 commits
  3. 28 Oct, 2011 4 commits
  4. 27 Oct, 2011 2 commits
    • Gary Wong's avatar
      Eschew M2Crypto.m2xmlrpclib. It dies horribly under Python 2.7. · 4b5547a2
      Gary Wong authored
      Invoke HTTPConnection or M2Crypto's HTTPSConnection directly, instead, and
      process everything through xmlrpclib's utility functions on the way in and
      out by hand.
      (Note that we can't use native Python's HTTPSConnection, or native
      xmlrpclib with an HTTPS URL for that matter, because Python's SSL
      support does not handle custom callbacks to retrieve passphrases,
      which we want to do.  We can't override that behaviour with Python
      code, since it lives in a binary shared library.)
    • Jonathon Duerig's avatar
  5. 26 Oct, 2011 2 commits
  6. 25 Oct, 2011 3 commits
  7. 24 Oct, 2011 5 commits
  8. 19 Oct, 2011 1 commit
  9. 13 Oct, 2011 5 commits
  10. 12 Oct, 2011 1 commit
  11. 11 Oct, 2011 8 commits
    • Ryan Jackson's avatar
      Merge imagezip ext4 code into extfs code · b8d79ac6
      Ryan Jackson authored
      Merge the ext4 support for imagezip into the extfs code.  There's no
      real reason to keep it separate, since ext4 is backward-compatible
      with ext3 and ext2.
      All of the macro definitions in extfs.c were changed from EXT2_* or
      EXT3_* to EXT4_*.  The primary reason for this is that while ext4 is
      backward compatible, the data structures have been extended and some
      of the definitions needed to change to handle them.  Some things that
      were constant before (block group descriptor sizes, for example) are
      now dynamic and must be calculated from other fields in the
      Since imagezip and frisbee don't support 64-bit block numbers, ext4
      filesystems that are larger than 2 TB (assuming 512-byte sectors) are
      not supported.  These can be detected by examining the
      feature_incompat field of the superblock.  Imagezip will fail if the
      user tries to compress one of these filesystems.
    • Leigh B Stoller's avatar
    • Leigh B Stoller's avatar
      Since there is currently no way to set/clear the global bit on an · fd75a209
      Leigh B Stoller authored
      image, I added it to grantimage:
      	boss> grantimage -a pid,osname
      and to revoke:
      	boss> grantimage -r -a pid,osname
    • Mike Hibler's avatar
      Switch to using version 2.0.0 of the libntfs library for Windows images. · 5d115d2c
      Mike Hibler authored
      I ran about 50 Windows images through this to "verify" that it produces the
      same results as the old 1.7.1 library.
    • Mike Hibler's avatar
    • Mike Hibler's avatar
      Add -Z option to zero free space included in the image due to -F. · 5a02dd31
      Mike Hibler authored
      Previously, this "internal free space" was whatever garbage happened to
      be on the disk we were imaging. By zeroing, we eliminate any leakage of
      information from the source disk and also allow the image to compress just
      a tad (1-4%) better.
      Why isn't this the default? Eh...no good reason, other than that this whole
      squish-out-small-free-ranges-to-allow-longer-writes optimization should be
      done by the client and should not be encoded in the image.
    • 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
      	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.
    • Mike Hibler's avatar
      Frisbee Master Server support for image_permissions table. · 64b3c003
      Mike Hibler authored
      To finish what Leigh started. Note that the master server currently only
      does node (IP) based authentication so "user" permissions in the
      image_permissions table are applied based on the uid of the swapper of
      the experiment that the contacting node is a part of.
  12. 10 Oct, 2011 4 commits
    • Mike Hibler's avatar
      Get rid of another "use GeniHRN". · 27e63721
      Mike Hibler authored
      I do not know if this fix is correct or complete. It is however, sufficient
      to make a non-protogeni elabinelab work again.
    • Mike Hibler's avatar
    • Mike Hibler's avatar
      Correctly create the leader account for the initial project in elabinelab. · 6539fb71
      Mike Hibler authored
      Since some DB state is pre-loaded during elabinelab setup, the initial
      project leader's account was appearing as though it was already setup.
    • 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
      	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.