Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 31 May 2017 12:55:04 +0000 (UTC)
From: "Sam Tunnicliffe (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.13073601.1495238090000.331038.1496235304799@Atlassian.JIRA>
In-Reply-To: <JIRA.13073601.1495238090000@Atlassian.JIRA>
References: <JIRA.13073601.1495238090000@Atlassian.JIRA> <JIRA.13073601.1495238090912@jira-lw-us.apache.org>
Subject: [jira] [Commented] (CASSANDRA-13540) QUORUM CL is used for new
 superuser
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 31 May 2017 12:55:11 -0000


    [ https://issues.apache.org/jira/browse/CASSANDRA-13540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031101#comment-16031101 ] 

Sam Tunnicliffe commented on CASSANDRA-13540:
---------------------------------------------

[~denno] are you sure that's a response to a request using your new superuser credentials as {{org.apache.cassandra.auth.PasswordAuthenticator}} should definitely only issue queries at {{QUORUM}} for the {{cassandra}} user

Are there any corresponding errors in the server log when you attempt to log in with the new user? 
Are you still able to use the default superuser credentials?
If rf=2, then at least 1 node must be partitioned from the one you're logging into, what happens when there are no nodes being reported {{DOWN}}?


> QUORUM CL is used for new superuser
> -----------------------------------
>
>                 Key: CASSANDRA-13540
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13540
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Distributed Metadata
>            Reporter: Dennis Noordzij
>
> After bootstrapping Cassandra, we're creating a new superuser, and setting RF of system_auth keyspace to 2, NetworkTopologyStrategy. Then a nodetool repair on the system_auth KS. 
> Documentation says 
> {quote}
> The system_auth keyspace uses a QUORUM consistency level when checking authentication for the default cassandra user. For all other users created, superuser or otherwise, a LOCAL_ONE consistency level is used for authenticating.
> {quote}
> But for my new superuser, new node members are rejected because QUORUM CL can't be achieved: 
> {code}
> May 19th 2017, 17:40:14.462	Connection error: ('Unable to connect to any servers', {'xx.xx.xx.xx': AuthenticationFailed('Failed to authenticate to xx.xx.xx.xx: Error from server: code=0100 [Bad credentials] message="org.apache.cassandra.exceptions.UnavailableException: Cannot achieve consistency level QUORUM"',)})
> {code}


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org