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. 10 Jan, 2007 1 commit
  3. 13 Feb, 2003 1 commit
  4. 24 Oct, 2002 1 commit
    • Leigh Stoller's avatar
      Add stuff to update the SFS keys on the fileserver after someone uses · cc1c4e54
      Leigh Stoller authored
      the web page to add/delete a key! Nodes were getting updated, but
      the SFS server was not cause there was no program to fire the new keys
      over there.
      
      The operation is currently simple. sfskey_update on boss constructs a
      new sfs_users file. Then it runs sfskey_update.proxy on ops (vis ssh
      of course), and gives it the new file via stdin. The proxy creates the
      .pub version from that file, and then moves the two new files into
      place in /etc/sfs. I employ the same locking stuff that Rob did in
      exports_setup and named_setup to prevent multiple updates from
      stacking up. Not likely, but might as well. Also note that the entire
      file is regenerated. When we get 5000 users this might have to change
      a little bit!
      
      Also changed mkacct slightly. Instead of doing a "sfskey register" on
      ops after generating the new key, just add it to the DB. Then fire off
      an sfskey_update to push the new keys over. Also add a -f flag to
      mkacct for use from the web page to indicate that the user has changed
      his SFS keys. Note that mkacct should probably take a series of flags
      since we have it as a wrapper for several things. Or maybe split all
      this stuff up.
      cc1c4e54