[execnet-dev] Socket gateway windows service

[Charles Solar]

Ok I have a solution that works for my purposes.  I rethought my
original idea and figured out how to proxy the io instances to the new
popengateway that socketserver creates, so no modifications to execnet
internals was necessary.
I am attaching my solution, but there are some lines I would like you
to look at and probably fix marked by XXX
For those lines I either used a trick that could break at any update,
or I had to assume things that I am not sure should be assumed.

Look forward to seeing what you do with it :)

Charles

On Sat, Jul 3, 2010 at 3:02 AM, holger krekel <holger at merlinux.eu> wrote:
> Hi Charles,
>
> On Fri, Jul 02, 2010 at 16:31 -0500, Charles Solar wrote:
>> Ah, a few hours after sending this I found the scripts folder, and here I
>> thought socketserver.py was just an example.. oh well.
>
> Your code still makes sense - an installable windows service would be great.
>
>> Anyway after using this a bit I am afraid I need to modify how the
>> Socketgateway works and I would like a tip or two about a couple things.
>>
>> I noticed that socketgateways will run the remote code in their own world,
>> which is a bit different from ssh gateways where the ssh session terminates
>> when the job is done.  The sshd remains untainted because the remote server
>> spawned a nice python process for us.
>> However the socketgateways run the remote code in themselves and thus if the
>> remote code dirties up the interpreter the whole daemon is bad.
>
> True.
>
>> In my case I am starting a twisted reactor on the remote server, and once a
>> twisted reactor has been created its expected that it is alive as long as
>> the python process itself.  Because of this, the socket gateway daemon is
>> only good for 1 connection, then it crashes because twisted's reactor has
>> issues.
>>
>> The solution to this problem would be to execute the incoming remote code in
>> a new popen gateway on the remote server instead of inside the socket
>> gateway instance itself.  I have been skimming a few files but I am not
>> completely sure how or where would be a good place to put the popen gateway.
>> My gut tells me the proxy should be put in SocketIO, but I figured it might
>> save some time to send out an email to find out how these systems interact.
>
> not sure, but for now i'd rather not try to nest execnet gateways,
> mostly because it will be fun to debug (there is some logging and
> nested gateways generally work though).  Also, a nice property of
> the socketgateway server is that it's rather independent from execnet
> impl details.
>
> Rather, the socketgateway.py service could learn to act just like
> the ssh-daemon by using subprocess.Popen and allowing multiple connections.
> IMHO just using threads that own a socket and proxy IO to their subprocess'ed
> gateway could be straightforward.
>
> In any case, I am happy to review and integrate your code into the next release
> if you go down this route, both for the service and the socketserver issue.
>
> cheers,
> holger
>
>
>>
>> Thanks
>>
>> On Fri, Jul 2, 2010 at 11:31 AM, Charles Solar <charlessolar at gmail.com>wrote:
>>
>> > I wrote up a windows service script for starting a socket gateway.  Thought
>> > other people might like to use it.  Its pretty basic, but gets the job
>> > done.  PyWin32 is required.
>> >
>> > Thanks for the great library.
>> >
>> > Charles
>> >
>
>> _______________________________________________
>> execnet-dev mailing list
>> execnet-dev at codespeak.net
>> http://codespeak.net/mailman/listinfo/execnet-dev
>
>
> --
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: socketserver.py
Type: text/x-python
Size: 4215 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/execnet-dev/attachments/20100708/45347c78/attachment.py>