[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876258#comment-17876258
]
Doug Rohrer commented on CASSANDRA-18508:
-----------------------------------------
There's a note buried in the source code that explains how to resolve what I
think your issue is. Assuming you're running on MacOS, you likely have to add
aliases for 127.0.0.2,3,4,... to localhost. On Linux, I believe this is
automatic (so the CI system doesn't need it) but MacOS doesn't have them by
default...
[https://github.com/apache/cassandra/blob/1c1fbfd3d33213d3c5d8e2bd90744463f29d22bf/test/distributed/org/apache/cassandra/distributed/impl/Instance.java#L797]
Note that I generally only do 0-2 for subnet, but this should work.
{{for subnet in $(seq 0 5); do for id in $(seq 0 5); do sudo ifconfig lo0 alias
\"127.0.$subnet.$id\"; done; done;}}
For some background in case you haven't worked with the in-jvm dtest framework
much - it spins up multiple instance of Cassandra and, by default, uses a
different IP address in the 127.0.X.Y address space. Eachwill use a different X
(starting at 0) for the subnet (to support multiple _clusters_ running in the
same test if I remember correctly) and then assign a different IP in the last
octet (Y) for each node. Without the aliases that are created by the command
above, MacOS throws the bind exception you're seeing (even though it's not
quite accurate that it's "already in use").
See
[https://github.com/apache/cassandra/blob/251ae80bb0f27ebca0b88c43d944b55dd7c34201/test/distributed/org/apache/cassandra/distributed/impl/INodeProvisionStrategy.java#L92]
for some more details on the node provisioning strategy if you're interested
in understanding it a bit more.
> Sensitive JMX SSL configuration options can be easily exposed
> -------------------------------------------------------------
>
> Key: CASSANDRA-18508
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18508
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Local/Config
> Reporter: Anthony Grasso
> Assignee: Maulin Vasavada
> Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We need a way to specify sensitive JMX SSL configuration options to avoid
> them being easily exposed.
> When encrypting the JMX connection the passwords for the key and trust stores
> must be specified using the {{javax.net.ssl.keyStorePassword}} and
> {{javax.net.ssl.trustStorePassword}} options respectively in the
> _cassandra-env.sh_ file. After Cassandra is started it is possible to see the
> passwords by looking the running process ({{ps aux | grep "cassandra"}}).
> Java 8 has the ability to specify a configuration file that can contain these
> security sensitive settings using the {{com.sun.management.config.file}}
> argument. However, despite what the documentation
> ([https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html#gdevf])
> says, both the {{com.sun.management.jmxremote}} and
> {{com.sun.management.jmxremote.port}} arguments need to be defined in the
> _cassandra-env.sh_ for the JVM to read the contents of the file.
> The problem with defining the {{com.sun.management.jmxremote.port}} argument
> is it conflicts with the {{cassandra.jmx.remote.port}} argument. Even if the
> port numbers are different, attempting an encrypted JMX connection using
> {{nodetool}} fails and we see a {{ConnectException: 'Connection refused
> (Connection refused)'}} error.
> One possible way to fix this is to introduce a new option that would allow a
> file to be passed containing the JMX encryption options.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
