[IPython-dev] coercing to Unicode error in IPython.MultiEngineClient

Barry Wark barrywark at gmail.com
Tue Jun 10 19:43:59 EDT 2008


Brian,

This looks like a great system! Thanks for implementing a security
model. This will make deploying IPython on "open" networks much less
scary!

Barry

On Tue, Jun 10, 2008 at 12:55 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> This is not a unicode error, but rather, our API for starting the
> client has changed due to the new security stuff.  This is the stuff
> that I am working on documenting as we speak.
>
> Here is a minimal description:
>
> 1) When the controller now starts, it creates a set of files (in your
> .ipython directory by default)
>
> ipcontroller-tc.furl
> ipcontroller-mec.furl
> ipcontroller-engine.furl
>
> 2)  These files contain a secure URL that 1) tells the engine and
> clients where the controller is running and 2) gives the engine and
> clients authority to connect to the controller in a secure manner.
>
> 3) To use these files, they have to be available to the client and
> engines when they start.  The easiest way of handling this is to
>
> a) copy ipcontroller-engine.furl to the .ipython directory on the
> machine(s) where the engines will run
>
> b) copy ipcontroller-tc and -mec to the .ipython dir of the machine
> where the clients will run.
>
> Then everything will "just work".  By this, I mean that you can create
> the clients with no arguments:
>
> mec = client.MultiEngineClient()
>
> If you have put the .furl files in different locations you can do:
>
> mec = client.MultiEngineClient('/Users/me/furlfiles/ipcontroller-mec.furl')
>
> In all of this, you can think of the furl files as being keys (just
> like a house key) that grants an entity access to a particular
> resource.  The controller creates the keys and the engines/client must
> present/use them to use the capabilities of the controller.
>
> See if you can use this to get things working.  The big benefit of
> using all this is:
>
> 1) Users don't have to track what ip/port the controller is running on.
>
> 2) Everything is secure by default - authentication + encryption (if
> you have pyOpenSSL installed
>
> 3) The controller now uses random port numbers, making it even more
> difficult for hostiles to discover.
>
> Let me know if you have any more problems getting this working.  We
> would love feedback if you have ideas of how things could be made
> easier.
>
> Also, check out the new command line flags on the ipcontroller and
> ipengine scripts to control where the furl files are created and
> looked for.
>
> Cheers,
>
> Brian
>
> On Tue, Jun 10, 2008 at 12:57 PM, Doug Jones <dfj225 at gmail.com> wrote:
>> Hi all,
>>
>> I tried a simple test of the latest IPython branch and the
>> MultiEngineClient. When I attempted to connect to a running cluster on my
>> local machine, I got the following error:
>>
>>  mec = client.MultiEngineClient(('localhost', 10105))
>> ---------------------------------------------------------------------------
>> TypeError                                 Traceback (most recent call last)
>>
>> /home/djones/svn/basin_remote/trunk/scripts/<ipython console> in <module>()
>>
>> /home/djones/local/lib64/python2.5/site-packages/IPython/kernel/client.pyc
>> in get_multiengine_client(furl_or_file)
>>      67     """
>>      68     client =
>> blockingCallFromThread(_client_tub.get_multiengine_client,
>> ---> 69         furl_or_file)
>>      70     return client.adapt_to_blocking_client()
>>      71
>>
>> /home/djones/local/lib64/python2.5/site-packages/IPython/kernel/twistedutil.pyc
>> in blockingCallFromThread(f, *a, **kw)
>>      97                 result.raiseException()
>>      98             except Exception, e:
>> ---> 99                 raise e
>>     100         return result
>>     101
>>
>> TypeError: coercing to Unicode: need string or buffer, tuple found
>>
>>
>>
>> Thanks,
>> ~Doug
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>>
>>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>



More information about the IPython-dev mailing list