You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Kurt Greaves (JIRA)" <ji...@apache.org> on 2017/11/21 05:11:00 UTC
[jira] [Updated] (CASSANDRA-14063) Cassandra will start listening
for clients without initialising system_auth after a failed bootstrap
[ https://issues.apache.org/jira/browse/CASSANDRA-14063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kurt Greaves updated CASSANDRA-14063:
-------------------------------------
Status: Awaiting Feedback (was: Open)
> Cassandra will start listening for clients without initialising system_auth after a failed bootstrap
> ----------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-14063
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14063
> Project: Cassandra
> Issue Type: Bug
> Components: Auth
> Reporter: Vincent White
> Assignee: Vincent White
> Priority: Minor
>
> This issue is closely related to CASSANDRA-11381. In this case, when a node joining the ring fails to complete the bootstrapping process with a streaming failure it will still always call org.apache.cassandra.service.CassandraDaemon#start and begin listening for client connections. If no authentication is configured clients are able to connect to the node and query the cluster much like write survey mode. But if authentication is enabled then it will cause an NPE because org.apache.cassandra.service.StorageService#doAuthSetup is only called after successfully completing the bootstrapping process. With the changes made in CASSANDRA-11381 we could now simply call doAuthSetup earlier since we don't have to worry about calling it multiple times but reading some of the concerns related to third party authentication classes, and now that "Incremental Bootstrapping" as described in CASSANDRA-8494 and CASSANDRA-8943, don't appear to be nearing implementation any time soon I would probably prefer that bootstrapping nodes simply didn't start listening for clients following a failed bootstrapping attempt.
> I've attached a quick and naive patch that demonstrates my desired behaviour. I ended up creating a new variable for this for clarity but I also had a bit of trouble finding already existing information that wasn't tied up in more complicated or transient processes that I could use to determine this particular state. I believe org.apache.cassandra.service.StorageService#isAuthSetupComplete would also work in this case so we could tie it to that instead. If someone has something simpler or knows the correct place I should be querying for this state from, I welcome all feedback.
> This [patch|https://github.com/vincewhite/cassandra/commits/system_auth_npe] also doesn't really address enabling/disabling thrift/binary via nodetool once the node is running. I wasn't sure if we should disallow it completely or include a force flag.
> Cheers
> -Vince
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org