Browse files

Update info in parallel docs.

  • Loading branch information...
1 parent c130ed1 commit 81d2608c4c4e0d9b22121d98311dd80fad8ed131 @takluyver committed Jul 8, 2011
Showing with 0 additions and 74 deletions.
  1. +0 −5 docs/source/parallel/parallel_mpi.txt
  2. +0 −69 docs/source/parallel/parallel_security.txt
5 docs/source/parallel/parallel_mpi.txt
@@ -4,11 +4,6 @@
Using MPI with IPython
-.. note::
- Not adapted to zmq yet
- This is out of date wrt ipcluster in general as well
Often, a parallel algorithm will require moving data between the engines. One
way of accomplishing this is by doing a pull and then a push using the
multiengine client. However, this will be slow as all the data has to go
69 docs/source/parallel/parallel_security.txt
@@ -248,75 +248,6 @@ capabilities based authentication model, in conjunction with SSH tunneled
TCP/IP channels, address the core potential vulnerabilities in the system,
while still enabling user's to use the system in open networks.
-Other questions
-.. note::
- this does not apply to ZMQ, but I am sure there will be questions.
-About keys
-Can you clarify the roles of the certificate and its keys versus the FURL,
-which is also called a key?
-The certificate created by IPython processes is a standard public key x509
-certificate, that is used by the SSL handshake protocol to setup encrypted
-channel between the controller and the IPython engine or client. This public
-and private key associated with this certificate are used only by the SSL
-handshake protocol in setting up this encrypted channel.
-The FURL serves a completely different and independent purpose from the
-key pair associated with the certificate. When we refer to a FURL as a
-key, we are using the word "key" in the capabilities based security model
-sense. This has nothing to do with "key" in the public/private key sense used
-in the SSL protocol.
-With that said the FURL is used as an cryptographic key, to grant
-IPython engines and clients access to particular capabilities that the
-controller offers.
-Self signed certificates
-Is the controller creating a self-signed certificate? Is this created for per
-instance/session, one-time-setup or each-time the controller is started?
-The Foolscap network protocol, which handles the SSL protocol details, creates
-a self-signed x509 certificate using OpenSSL for each IPython process. The
-lifetime of the certificate is handled differently for the IPython controller
-and the engines/client.
-For the IPython engines and client, the certificate is only held in memory for
-the lifetime of its process. It is never written to disk.
-For the controller, the certificate can be created anew each time the
-controller starts or it can be created once and reused each time the
-controller starts. If at any point, the certificate is deleted, a new one is
-created the next time the controller starts.
-SSL private key
-How the private key (associated with the certificate) is distributed?
-In the usual implementation of the SSL protocol, the private key is never
-distributed. We follow this standard always.
-SSL versus Foolscap authentication
-Many SSL connections only perform one sided authentication (the server to the
-client). How is the client authentication in IPython's system related to SSL
-We perform a two way SSL handshake in which both parties request and verify
-the certificate of their peer. This mutual authentication is handled by the
-SSL handshake and is separate and independent from the additional
-authentication steps that the CLIENT and SERVER perform after an encrypted
-channel is established.
.. [RFC5246] <>
.. [OpenSSH] <>

0 comments on commit 81d2608

Please sign in to comment.