[jira] [Commented] (CASSANDRA-12525) 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 c
[ https://issues.apache.org/jira/browse/CASSANDRA-12525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15454064#comment-15454064 ] Atin Sood commented on CASSANDRA-12525: --- Sam, unfortunately don't have these handy ATM, but let me try to get these by next week. We were able to consistently replicate this and have the cluster handy in dev, so let me get you the logs as soon as I free up from my day to day work. Appreciate you looking into this. > 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: Configuration >Reporter: Atin Sood >Priority: Minor > > 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 (v6.3.4#6332)
[jira] [Created] (CASSANDRA-12525) When adding new nodes to a cluster which has authentication enabled, we end up loosing cassandra user's current crendentials and they get reverted back to default ca
Atin Sood created CASSANDRA-12525: - Summary: When adding new nodes to a cluster which has authentication enabled, we end up loosing 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: Configuration Reporter: Atin Sood Priority: Minor 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 (v6.3.4#6332)
[jira] [Created] (CASSANDRA-12510) Decommission process should raise an error flag when nodes in a DC don't have any nodes to stream data to
Atin Sood created CASSANDRA-12510: - Summary: Decommission process should raise an error flag when nodes in a DC don't have any nodes to stream data to Key: CASSANDRA-12510 URL: https://issues.apache.org/jira/browse/CASSANDRA-12510 Project: Cassandra Issue Type: Bug Components: Streaming and Messaging Environment: C* version 3.3 Reporter: Atin Sood Priority: Minor Steps to replicate : - Create a 3 node cluster in DC1 and create a keyspace test_keyspace with table test_table with replication strategy NetworkTopologyStrategy , DC1=3 . Populate some data into this table. - Add 5 more nodes to this cluster, but in DC2. Also do not alter the keyspace to add the new DC2 to replication (this is intentional and the reason why the bug shows up). So the desc keyspace should still list NetworkTopologyStrategy with DC1=3 as RF - As expected, this will now be a 8 node cluster with 3 nodes in DC1 and 5 in DC2 - Now start decommissioning the nodes in DC1. Note that the decommission runs fine on all the 3 nodes, but since the new nodes are in DC2 and the RF for keyspace is restricted to DC1, the new 5 nodes won't get any data. - You will now end with the 5 node cluster which has no data from the decommissioned 3 nodes and hence ending up in data loss I do understand that this problem could have been avoided if we perform an alter stmt and add DC2 replication before adding the 5 nodes. But the fact that decommission ran fine on the 3 nodes on DC1 without complaining that there were no nodes to stream its data seems a little discomforting. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
