You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Samphel Norden (JIRA)" <ji...@apache.org> on 2014/07/22 18:30:39 UTC
[jira] [Commented] (CASSANDRA-7585) cassandra sstableloader
connection refused with inter_node_encryption
[ https://issues.apache.org/jira/browse/CASSANDRA-7585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070463#comment-14070463 ]
Samphel Norden commented on CASSANDRA-7585:
-------------------------------------------
sstableloader always fails with connection refused, if internode encryption is on... The naive explanation (at least to me) is that it is somehow causing some activity on port 7000 between nodes (whether streaming is the reason is unknown) which is not the port on which nodes talk to each other when internode encryption is enabled... As I said above, sstableloader works correctly if only client to server encryption is enabled (that was a bug fixed in 2.0.4 IIRC).
I think in both cases it is using the default ports 9160 and 7000. The client encryption part works fine since it also uses the default 9160 port even if client-to-server encryption is enabled.. The problem I think is that sstableloader is using 7000 (for unknown reasons) and the nodes no longer listen on 7000 when we have inter-node encryption enabled. Thats my speculative thinking. Whatever the reason might be, this is a critical bug for us since we have to enable encryption in enterprise deployments and need sstableloader to work for backup restores.
> cassandra sstableloader connection refused with inter_node_encryption
> ---------------------------------------------------------------------
>
> Key: CASSANDRA-7585
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7585
> Project: Cassandra
> Issue Type: Bug
> Components: Core, Tools
> Reporter: Samphel Norden
> Assignee: Yuki Morishita
>
> cassandra sstableloader connection refused with inter_node_encryption
> When using sstableloader to import tables (cassandra 2.0.5) with inter-node encryption and client encryption enabled, I get a connection refused error
> I am using
> sstableloader -d $myhost -p 9160 -u cassandra -pw cassandra -ciphers TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA -st JKS -tf org.apache.cassandra.thrift.SSLTransportFactory -ts /path/to/truststore -tspw <passwd> $fullpath/$table
> Errors out with
> Streaming session ID: 1bc395c0-fbb2-11e3-9812-73da15121373
> WARN 17:13:34,147 Failed attempt 1 to connect to
> Similar problem reported in cassandra 2.0.8 by another user
> http://stackoverflow.com/questions/24390604/cassandra-sstableloader-connection-refused-with-inter-node-encryption
> ==================
> Relevant cassandra.yaml snippet (with obfuscation)
> server_encryption_options:
> internode_encryption: all
> keystore:/path/to/keystore
> keystore_password: <passwd>
> truststore:/path/to/truststore
> truststore_password:<passwd>
> # More advanced defaults below:
> protocol: TLS
> algorithm: SunX509
> store_type: JKS
> cipher_suites: [TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA]
> require_client_auth: true
>
> # enable or disable client/server encryption.
> client_encryption_options:
> enabled: true
> keystore: /path/to/keystore
> keystore_password: <truststorepasswd>
> #require_client_auth: true
> # Set trustore and truststore_password if require_client_auth is true
> truststore:/path/to/truststore
> truststore_password: <truststorepasswd>
> # More advanced defaults below:
> protocol: TLS
> algorithm: SunX509
> store_type: JKS
> cipher_suites: [TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA]
> ======================
> Note that by setting inter-node encryption to "none" sstableloader works.. but setting it to "all" fails... It seems like sstableloader uses 7000 is my guess instead of using the ssl port 7001 for streaming/gossip.
--
This message was sent by Atlassian JIRA
(v6.2#6252)