Re: [Ocamlnet-devel] Two issues with Netplex

[Thomas C. <cal...@gm...>]

Hi Gerd,

I have successfully tested the fix you mentioned in your reply.
You'll find attached a patch to address the issue (for ocamlnet-3.6.6) of
child containers becoming zombies when the socket connection fails
unexpectedly.

It would be great if this modification could make it upstream.

Regarding the system_shutdown() issue we discussed I have not made any
progresses, it would be great if we could filter the RPC calls available to
child
containers given a policy defined by the controller process.

Regards.

Thomas C.


On Mon, Nov 11, 2013 at 9:15 AM, Thomas Calderon
<cal...@gm...>wrote:

> Hi Gerd,
>
>
>
>
> On Sun, Nov 10, 2013 at 1:24 PM, Gerd Stolpmann <in...@ge...>wrote:
>
>> Am Donnerstag, den 07.11.2013, 19:34 +0100 schrieb Thomas Calderon:
>> > Hi there,
>> >
>> >
>> > I am having two issues with netplex at the moment.
>> >
>> >
>> > The first one is related to rpc-ssl support. The netplex service is
>> > configured with SSL enabled (TLSv1) and if you are connecting with a
>> > client that forces newer TLS versions (openssl s_client -connect
>> > host:port -tls1_1), an Ssl exception is raised.
>>
>> Well, the ocaml-ssl bindings only offer TLS-1.0, even if openssl
>> supports more. That's basically a problem of the bindings. (Fyi, I'm
>> currently implementing complete bindings for GnuTLS to overcome all
>> limitations with ocaml-ssl.)
>>
>
> OK that's what I thought as well, I added the missing symbols to ocaml-ssland some other missing features (DH/
> ECDH). This is immediately available from the git version of the code,
> but having a GnuTLS alternative is also good news.
>
>
>>
>> > However, the container process still continues to run but is not able
>> > to process any data, netplex then spawn a new child process to handle
>> > subsequent connections.
>> > From the client side, the socket is closed and we end up not knowing
>> > in which state the "zombie" container is.
>> > We looked for a proper way to fix this in our code, but the exception
>> > is caught from within rpc_netplex.ml (line 183), is there a proper way
>> > to handle this case from our code or is it only a fix you can
>> > provide ?
>>
>> You could close fd, and then call when_done() from the is_error
>> callback. This is how it is indicated that the task is done.
>>
>
> Alright I'll look into this to fix the issue with the current ocaml-sslbindings.
>
>
>>
>> Probably this is really the best thing you can do here. When I
>> programmed this I could probably not imagine what kind of things can go
>> wrong at this spot, and hence opted to do nothing.
>>
>> > The second issue is related the function
>> > "Netplex_cenv.system_shutdown()". This function can be used to
>> > completely shutdown the service, I would like to know if it is
>> > possible to restrict this function to be only callable from within the
>> > controller instance ? This way a container process could not call this
>> > function and stop the service and all the other containers from
>> > running.
>>
>> Without modifying the sources, there is probably no way to get this
>> effect.
>>
>> What's actually happening is that the controller accepts requests on the
>> admin socket (which is a Unix domain socket visible in the filesystem),
>> and if the container wants to do a system shutdown, is just connects to
>> this socket, and invokes the right RPC. I don't see how you could
>> prevent the container from doing so even if the connect code were
>> removed from the netplex sources. Maybe the only way is to set a
>> password on this service, and not telling the container the password.
>>
>
> OK thanks for your input on that.
>
>
>>
>> Out of curiosity, what's your concern with system shutdowns?
>>
>
> Netplex controller can be seen as task schedulers spawning child
> processes to handle requests.
> Now let's suppose the service your are offering becomes essential on your
> system, then availability becomes something you really care about. For
> example if one of the container's flow of execution is compromised, you
> can can live with that as long as it cannot hurt your availability or use
> privileged APIs.
>
> I'll have a look at the admin socket and check if nothing more can be done
> here.
>
> Thanks for your answers.
>
> Thomas C.
>
>
>>
>> Gerd
>>
>> >
>> > Thanks.
>> >
>> >
>> > Thomas C.
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > November Webinars for C, C++, Fortran Developers
>> > Accelerate application performance with scalable programming models.
>> Explore
>> > techniques for threading, error checking, porting, and tuning. Get the
>> most
>> > from the latest Intel processors and coprocessors. See abstracts and
>> register
>> >
>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>> > _______________________________________________ Ocamlnet-devel mailing
>> list Oca...@li...
>> https://lists.sourceforge.net/lists/listinfo/ocamlnet-devel
>>
>> --
>> ------------------------------------------------------------
>> Gerd Stolpmann, Darmstadt, Germany    ge...@ge...
>> My OCaml site:          http://www.camlcity.org
>> Contact details:        http://www.camlcity.org/contact.html
>> Company homepage:       http://www.gerd-stolpmann.de
>> ------------------------------------------------------------
>>
>>
>