1. 20 Oct, 2010 1 commit
  2. 28 Jul, 2010 2 commits
  3. 17 Jun, 2010 1 commit
  4. 10 May, 2010 1 commit
  5. 29 Apr, 2010 1 commit
  6. 30 Oct, 2009 1 commit
  7. 15 May, 2009 1 commit
  8. 02 Mar, 2009 1 commit
    • Leigh Stoller's avatar
      A bunch of changes for a "standalone" clearinghouse. Presently this · 60f04310
      Leigh Stoller authored
      its really a hugely stripped down Emulab boss install, using a very
      short version of install/boss-install to get a few things into place.
      
      I refactored a few things in both the protogeni code and the Emulab
      code, and whacked a bunch of makefiles and configure stuff. The result
      is that we only need to install about 10-12 files from the Emulab
      code, plus the protogeni code. Quite manageable, if you don't mind
      that it requires FreeBSD 6.X ... Still, I think it satisfies the
      requirement that we have a packaged clearinghouse that can be run
      standalone from a running Emulab site.
      60f04310
  9. 01 Dec, 2008 1 commit
  10. 31 Oct, 2008 1 commit
  11. 09 Jul, 2008 1 commit
  12. 30 May, 2008 1 commit
  13. 06 Feb, 2006 1 commit
  14. 15 Sep, 2005 2 commits
  15. 04 May, 2005 1 commit
  16. 29 Mar, 2005 1 commit
  17. 08 Mar, 2005 2 commits
  18. 03 Feb, 2005 3 commits
  19. 30 Nov, 2004 1 commit
  20. 27 Oct, 2004 2 commits
  21. 04 Oct, 2004 1 commit
    • Leigh Stoller's avatar
      Add several configure variables to the defs file so that the ssl certificates · ad3a6c5b
      Leigh Stoller authored
      (config files) can be localized:
      
      	C                      = @SSLCERT_COUNTRY@
      	ST                     = @SSLCERT_STATE@
      	L                      = @SSLCERT_LOCALITY@
      	O                      = @SSLCERT_ORGNAME@
      
      Which are initialized locally to:
      
      	SSLCERT_COUNTRY="US"
      	SSLCERT_STATE="Utah"
      	SSLCERT_LOCALITY="Salt Lake City"
      	SSLCERT_ORGNAME="Utah Network Testbed"
      
      Also added an "apache" target which will generate an initial cert/key
      for the apache server. This is a self signed certificate of course, which
      is fine for getting a new site off the ground. Note that the cert/key are
      installed during by install/boss-install.
      ad3a6c5b
  22. 27 Sep, 2004 2 commits
  23. 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
  24. 20 Aug, 2004 1 commit
  25. 22 Apr, 2004 1 commit
  26. 03 Mar, 2004 1 commit
  27. 21 Jan, 2004 1 commit
  28. 20 Jan, 2004 1 commit
  29. 18 Apr, 2003 1 commit
  30. 20 Dec, 2002 1 commit
  31. 12 Dec, 2002 1 commit
  32. 10 Sep, 2002 1 commit
  33. 21 Aug, 2002 1 commit