Changes in run.sh script

[Aleksandr Shapkin <le...@gmail.com>]

Hi all,



There is the run.sh script that’s required for docker images deployment and
internally it just invokes the default ignite.sh script prior to starting a
node.



So far, so good, but we discovered that it doesn’t propagate system signals
to the JVM due to its internal logic and also lacks some configuration
parameters, like JVM options, therefore we have rewritten it in
https://issues.apache.org/jira/browse/IGNITE-13453 and hope to include it
in 2.9 release.



As it turned out there was another reason for modifying the script – there
was no way of disabling JMX using it, i.e. to set -nojmx=1, the flag
supported by ignite.sh. With the new version, JMX is disabled by default
and should be turned on explicitly setting the JVM options, like
-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=49112,
Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false



As far as I can remember, there were some drawbacks with the default JMX
setting and ignite.sh – It reduces security and could conflict with the
control.sh, since it’s trying to open the same port. But it’s the subject
for a separate discussion.



So the question is – do we need to set those properties by default (enable
JMX), most likely copying them from ignite.sh or it’s fine to have JMX
disabled by default for k8s/docker deployment?

-- 
Alex.

Re: Changes in run.sh script

[Stanislav Lukyanov <st...@gmail.com>]

I believe that remote JMX access should NOT be enabled by default in any Ignite distributions - neither docker nor regular binary package.

Enabling remote JMX requires caution. It is a powerful interface, and the fact that ignite.sh enables it by default with no security (!) bothers me a lot.
One could play the "THIS IS A SECURITY BUG!!!" card here, and this wouldn't be too far from truth.

I have also seen issues when a user who tried to enable remote JMX manually, following all best practices and enabling security, ran into issues due to ignite.sh overriding the user-provided JMX options.
Overall, I'd say that a user who doesn't know if they need remote JMX should start without it. A user who knows they need remote JMX should configure it with the necessary security options,
and the best way to do that in Ignite is currently to run with -nojmx (disabling ignite.sh's default options) and providing your own options. In other words, JMX options coming from ignite.sh do no good.

Note that this is all about remote JMX only. Local JMX monitoring (e.g. using JConsole or Prometheus Java agent exporter) is always available, even without any Java options.

I suggest to go ahead and disable remote JMX by default in Docker in 2.9, and plan to remove the remote JMX properties setting from ignite.sh in 2.10.

Thanks,
Stan

> On 22 Sep 2020, at 18:41, Aleksandr Shapkin <le...@gmail.com> wrote:
> 
> Hi all,
>  
> There is the run.sh script that’s required for docker images deployment and internally it just invokes the default ignite.sh script prior to starting a node.
>  
> So far, so good, but we discovered that it doesn’t propagate system signals to the JVM due to its internal logic and also lacks some configuration parameters, like JVM options, therefore we have rewritten it in https://issues.apache.org/jira/browse/IGNITE-13453 <https://issues.apache.org/jira/browse/IGNITE-13453> and hope to include it in 2.9 release.
>  
> As it turned out there was another reason for modifying the script – there was no way of disabling JMX using it, i.e. to set -nojmx=1, the flag supported by ignite.sh. With the new version, JMX is disabled by default and should be turned on explicitly setting the JVM options, like -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=49112, Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false
>  
> As far as I can remember, there were some drawbacks with the default JMX setting and ignite.sh – It reduces security and could conflict with the control.sh, since it’s trying to open the same port. But it’s the subject for a separate discussion.
>  
> So the question is – do we need to set those properties by default (enable JMX), most likely copying them from ignite.sh or it’s fine to have JMX disabled by default for k8s/docker deployment? 
> 
> -- 
> Alex.