From: Thomas C. <cal...@gm...> - 2013-11-11 08:15:28
|
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 > ------------------------------------------------------------ > > |