1. 03 Sep, 2013 1 commit
  2. 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
  3. 30 Apr, 2012 1 commit
  4. 20 Dec, 2004 1 commit
  5. 15 Nov, 2004 1 commit
  6. 09 Nov, 2004 1 commit
    • Leigh Stoller's avatar
      Here is a fun little change. Lacking native perl SSL XMLRPC tools, I · a7482569
      Leigh Stoller authored
      put together a little library that provides the illusion of nativeness.
      
      sslxmlrpc_client.py.in: New "rawmode" (-r) option. Instead of the
      usual command line operation, input raw XMLRPC goo and send that over
      to the server. The raw XMLRPC reply goo is spit out on stdout. In
      other words, it is up to the caller to generate the XML stuff, and
      convert back from XML to a reply structure.
      
      libxmlrpc.pm.in: A new perl library that exports one real method
      called, interestingly enough, CallMethod($$$). The first and second
      arguments are the module and method to invoke in the RPC server. The
      third argument is an arbitrary perl data structure to convert into XML
      and pass to the server. For example:
      
      	libxmlrpc::CallMethod("experiment", "state",
      	                      {"proj" => "testbed", "exp" => "myemulab"});
      
      The return value of CallMethod is whatever data structure the server
      returned, or undef if there is an internal error or if the RPC fails
      with a transport error (one of the errors in emulabclient.py).
      
      In case it is not obvious, CallMethod converts the argument to XML
      using the RPC:XML perl module, forks off a child to run
      sslxmlrpc_client.py.in in rawmode, sends it the XML on its stdin,
      reads back the XML for the reply from its stdout, and converts that to
      a perl data structure to return to the caller.
      
      The more interesting use of this new goo is to invoke the new
      "elabinelab" module in the RPC server, which exports some new methods
      to support elabinelab. The idea is that the inner boss will invoke
      routines (like setup/destroy vlans, or power cycle) using the RPC
      server, and the SSL key of the creator of the inner emulab. This will
      be described in more detail when I check in those changes.
      
      There is also a Config() method that is used to set the SSL cert path,
      debugging, verbosity, etc. You can take a look if you are interested.
      
      This can be arbitrarily fancy, but I don't need this for many things.
      a7482569
  7. 08 Nov, 2004 1 commit
    • Timothy Stack's avatar
      · 605141d4
      Timothy Stack authored
        * xmlrpc/sslxmlrpc_client.py.in: Need to add a path to the URI used
          to connect to the server.
      
        * xmlrpc/sslxmlrpc_server.py.in: Only add devel paths for admins
      605141d4
  8. 02 Nov, 2004 1 commit
  9. 01 Sep, 2004 1 commit
    • Leigh Stoller's avatar
      SSL version of the XMLRPC server. · a9c1045e
      Leigh Stoller authored
      * SSL based server (sslxmlrpc_server.py) that wraps the existing Python
        classes (what we export via the existing ssh XMLRPC server). I also have a
        demo client that is analogous the ssh demo client (sslxmlrpc_client.py).
        This client looks for an ssl cert in the user's .ssl directory, or you can
        specify one on the command line. The demo client is installed on ops, and
        is in the downloads directory with the rest of the xmlrpc stuff we export
        to users. The server runs as root, forking a child for each connection and
        logs connections to /usr/testbed/log/sslxmlrpc.log via syslog.
      
      * New script (mkusercert) generates SSL certs for users. Two modes of
        operation; when called from the account creation path, generates a
        unencrypted private key and certificate for use on Emulab nodes (this is
        analagous to the unencrypted SSH key we generate for users). The other mode
        of operation is used to generate an encrypted private key so that the user
        can drag a certificate to their home/desktop machine.
      
      * New webpage (gensslcert.php3) linked in from the My Emulab page that
        allows users to create a certificate. The user is prompted for a pass
        phrase to encrypt the private key, as well as the user's current Emulab
        login password. mkusercert is called to generate the certificate, and the
        result is stored in the user's ~/.ssl directory, and spit back to the user
        as a text file that can be downloaded and placed in the users homedir on
        their local machine.
      
      * The server needs to associate a certificate with a user so that it can
        flip to that user in the child after it forks. To do that, I have stored
        the uid of the user in the certificate. When a connection comes in, I grab
        the uid out of the certificate and check it against the DB. If there is a
        match (see below) the child does the usual setgid,setgroups,setuid to the
        user, instantiates the Emulab server class, and dispatches the method. At
        the moment, only one request per connection is dispatched. I'm not sure
        how to do a persistant connection on the SSL path, but probably not a big
        deal right now.
      
      * New DB table user_sslcerts that stores the PEM formatted certificates and
        private keys, as well as the serial number of the certificate, for each
        user. I also mark if the private key is encrypted or not, although not
        making any use of this data. At the moment, each user is allowed to get
        one unencrypted cert/key pair and one encrypted cert/key pair. No real
        reason except that I do not want to spend too much time on this until we
        see how/if it gets used. Anyway, the serial number is used as a crude form
        of certificate revocation. When the connection is made, I suck the serial
        number and uid out of the certificate, and look for a match in the table.
        If cert serial number does not match, the connection is rejected. In other
        words, revoking a certificate just means removing its entry from the DB
        for that user. I could also compare the certificate itself, but I am not
        sure what purpose that would serve since that is what the SSL handshake is
        supposed to take of, right?
      
      * Updated the documentation for the XMLRPC server to mention the existence
        of the SSL server and client, with a pointer into the downloads directory
        where users can pick up the client.
      a9c1045e
  10. 27 Aug, 2004 1 commit
    • Leigh Stoller's avatar
      Guts of the new ssl server implemented. The server operates more or less · 5a025f36
      Leigh Stoller authored
      like this:
      
      * Listen for connections on port 3069. The server requires client
        authentication, and will fail if a certificate is not provided by
        the client.
      
      * Once the certificate is accepted, the server forks a new child.
      
      * The child looks inside the certificate to get the CN field of the
        Distinguished Name (subject). The CN field must hold the uid of the
        user, which is checked against the DB for a matching user. We get
        the groupslist from the DB, and do a setgid,setgroups,setuid to flip
        to the user in the child.
      
      * A instance of the emulabserver class is created, and the request is
        dispatched.
      
      I added an sslxmlrpc_client.py script that mirrors the ssh version of
      the client script. I could probably roll these into one, but decided
      not to to avoid confusing people who might download it.
      5a025f36
  11. 25 Aug, 2004 1 commit
  12. 03 Aug, 2004 1 commit
    • Leigh Stoller's avatar
      A couple more minor changes before I turn the new stuff loose. · 8fddf3ce
      Leigh Stoller authored
      * Added a wrapper class so that you can invoke methods as
        experiment.swapexp or node.reboot. So instead of invoking as
        /XMLRPC/experiment can calling swapexp, you can call the server as
        /XMLRPC and call experiment.swapexp. This allows you to use a single
        connection to talk to different parts of the API. Note this is standard
        (or is it defacto) syntax in XMLRPC.
      
      * Changed the demonstration client to talk the server this way.
      
      * Changed paperbag to allow this as well; the xmlrpc server is invoked with
        no args, which tells it to export the wrapper interface instead of a
        specific module interface.
      
      * A few more cleanups in the server, more permission checks, etc.
      8fddf3ce
  13. 21 Jun, 2004 1 commit
  14. 12 May, 2004 1 commit
    • Leigh Stoller's avatar
      Minor change so that I can feed dictionaries on the command line, as · 9049532a
      Leigh Stoller authored
      would be required to use delay_config or link_config. For example:
      
      	sshxmlrpc_client.py link_config proj=testbed exp=two-wireless \
      		link=lan0 "params={'a': 4}"
      
      Note last argument, which is eval'ed into a dictionary before it is
      sent across in the RPC. This is done whenever first character of the
      value is a "{" ... otherwise it is treated as a literal.
      9049532a
  15. 07 May, 2004 1 commit
  16. 23 Mar, 2004 2 commits
    • Leigh Stoller's avatar
      Add some silly options for testbed developers: · 8af58167
      Leigh Stoller authored
      * -a: This already existed; it modifies the path given to the server
        so that people without a paperbag shell can run the rpc server.
      
      * -z: Modify the path above so that it runs the server from the
        current user's devel tree instead of the main tree.
      
      * -x <user>: Instead of the current user's devel tree, use another
        devel tree.
      
      So, to run my own server:
      
      	/usr/testbed/devel/stoller/bin/sshxmlrpc_client.py -a -z
      
      To run Rob's devel server:
      
      	/usr/testbed/devel/stoller/bin/sshxmlrpc_client.py -a -z -x ricci
      
      Sorry for all this sillyness.
      8af58167
    • Leigh Stoller's avatar
  17. 18 Mar, 2004 1 commit
  18. 17 Mar, 2004 3 commits
  19. 16 Mar, 2004 1 commit
  20. 15 Mar, 2004 1 commit
  21. 10 Mar, 2004 1 commit