Update info in parallel docs.

takluyver · Jul 8, 2011 · 81d2608 · 81d2608
1 parent c130ed1
commit 81d2608
Show file tree

Hide file tree

Showing 2 changed files with 0 additions and 74 deletions.
diff --git a/docs/source/parallel/parallel_mpi.txt b/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

diff --git a/docs/source/parallel/parallel_security.txt b/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
-authentication?
-
-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] <http://tools.ietf.org/html/rfc5246>
 
 .. [OpenSSH] <http://www.openssh.com/>