[
https://issues.apache.org/jira/browse/CASSANDRA-12525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17644958#comment-17644958
]
Stefan Miklosovic commented on CASSANDRA-12525:
-----------------------------------------------
Ok lets to this then. I would not increase default delay for that system
property. If we kept increasing this and other time that property, after a
while all the "waitings" together would slow-downed the overall startup
unbearably.
For your scenario, maybe I am completely wrong here, but I would expect that
nodes in dc2 would have as a seed a node from dc1. So the startup should not
even propagate that far to create the default role. It should not even start if
it can not see any seeds.
To test this, we could do this then with 2 nodes only. Start the first, change
the password, partition the network, start the second and it should create the
default role and then start the first node and repair the second. You should be
able to connect to the second node with the changed password.
To partition the network, there are already some examples how to drop the
communication, start to take a look at this (1) and you eventually figure it
out.
Please, tell me if it is too much for you to do this. We would be glad if you
figured it out, if you dont we are here to help to guide you. We are trying to
guide new contributors so they will be more comfortable here.
(1)
https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/shared/ClusterUtils.java#L124
> When adding new nodes to a cluster which has authentication enabled, we end
> up losing cassandra user's current crendentials and they get reverted back to
> default cassandra/cassandra crendetials
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-12525
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12525
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema, Local/Config
> Reporter: Atin Sood
> Assignee: German Eichberger
> Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> Made the following observation:
> When adding new nodes to an existing C* cluster with authentication enabled
> we end up loosing password information about `cassandra` user.
> Initial Setup
> - Create a 5 node cluster with system_auth having RF=5 and
> NetworkTopologyStrategy
> - Enable PasswordAuthenticator on this cluster and update the password for
> 'cassandra' user to say 'password' via the alter query
> - Make sure you run nodetool repair on all the nodes
> Test case
> - Now go ahead and add 5 more nodes to this cluster.
> - Run nodetool repair on all the 10 nodes now
> - Decommission the original 5 nodes such that only the new 5 nodes are in the
> cluster now
> - Run cqlsh and try to connect to this cluster using old user name and
> password, cassandra/password
> I was unable to connect to the nodes with the original credentials and was
> only able to connect using the default cassandra/cassandra credentials
> From the conversation over IIRC
> `beobal: sood: that definitely shouldn't happen. The new nodes should only
> create the default superuser role if there are 0 roles currently defined
> (including that default one)`
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
