cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Tunnicliffe (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-9694) system_auth not upgraded
Date Thu, 02 Jul 2015 11:43:04 GMT


Sam Tunnicliffe commented on CASSANDRA-9694:

The new {{system_auth}} tables - {{roles}}, {{role_members}}, {{role_permissions}} & {{resource_role_permissions_index}}
- are created on each node as it is upgraded. When a 2.2 node comes up, if it detects the
old tables are present it will attempt the conversion to the new tables. This conversion will
necessarily fail until enough nodes have been upgraded. 

You'll see log messages to this effect on the upgraded nodes. e.g.:
INFO  [OptionalTasks:1] 2015-07-02 12:15:21,510 - Converting
legacy users
INFO  [OptionalTasks:1] 2015-07-02 12:15:23,539 - Unable to
complete conversion of legacy auth data (perhaps not enough nodes are upgraded yet). Conversion
should not be considered complete
INFO  [OptionalTasks:1] 2015-07-02 12:15:23,539 - Converting
legacy permissions data
INFO  [OptionalTasks:1] 2015-07-02 12:15:25,544 - Unable to complete
conversion of legacy permissions data (perhaps not enough nodes are upgraded yet). Conversion
should not be considered complete

While the cluster is in the mixed state, authentication & authorization will continue
to use the old tables, even on the upgraded nodes. Once all nodes have been upgraded &
the data conversion completed, the legacy system_auth tables {{users}}, {{credentials}} &
{{permissions}} should be dropped. For safety reasons this is not done automatically, so an
operator with su privileges needs to do this via cqlsh. Once those tables are removed, auth
will automatically begin using the new tables without any further intervention. 

You can verify that the migration has happened correctly from the system log on upgraded nodes.
Once enough 2.2 nodes are available, the messages will change from those above to:
INFO  [OptionalTasks:1] 2015-07-02 12:23:05,222 - Converting
legacy users
INFO  [OptionalTasks:1] 2015-07-02 12:23:05,252 - Completed
conversion of legacy users
INFO  [OptionalTasks:1] 2015-07-02 12:23:05,252 - Migrating
legacy credentials data to new system table
INFO  [OptionalTasks:1] 2015-07-02 12:23:05,265 - Completed
conversion of legacy credentials
INFO  [OptionalTasks:1] 2015-07-02 12:23:05,265 - Converting
legacy permissions data
INFO  [OptionalTasks:1] 2015-07-02 12:23:05,274 - Completed conversion
of legacy permissions

This isn't quite as clear as it could be in NEWS.txt, so I'm attaching a patch to clarify

Finally, on 2.2.0-rc1 you'll notice a delay of ~10s logging into cqlsh when the cluster is
in a mixed state. This is due to the bundled python driver attempting to wait for a schema
agreement that will never come. It is resolved in 2.2.0-rc2 by virtue of the bundled driver
incorporating [PYTHON-303|]

> system_auth not upgraded
> ------------------------
>                 Key: CASSANDRA-9694
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>         Environment: Windows-7-32 bit, 3.2GB RAM, Java 1.7.0_55
>            Reporter: Andreas Schnitzerling
>            Assignee: Sam Tunnicliffe
>         Attachments: system_exception.log
> After upgrading Authorization-Exceptions occur. I checked the system_auth keyspace and
have seen, that tables users, credentials and permissions were not upgraded automatically.
I upgraded them (I needed 2 times per table because of CASSANDRA-9566). After upgrading the
system_auth tables I could login via cql using different users.
> {code:title=system.log}
> WARN  [Thrift:14] 2015-07-01 11:38:57,748 - CassandraAuthorizer
failed to authorize #<User updateprog> for <keyspace logdata>
> ERROR [Thrift:14] 2015-07-01 11:41:26,210 - Error occurred
during processing of message.
> java.lang.RuntimeException:
org.apache.cassandra.exceptions.ReadTimeoutException: Operation timed out - received only
0 responses.
> 	at$Segment.get( ~[guava-16.0.jar:na]
> 	at ~[guava-16.0.jar:na]
> 	at ~[guava-16.0.jar:na]
> 	at$LocalLoadingCache.get( ~[guava-16.0.jar:na]
> 	at org.apache.cassandra.auth.PermissionsCache.getPermissions(
> 	at org.apache.cassandra.auth.AuthenticatedUser.getPermissions(
> 	at org.apache.cassandra.service.ClientState.authorize( ~[apache-cassandra-2.2.0-rc1.jar:2.2.0-rc1]
> 	at org.apache.cassandra.service.ClientState.checkPermissionOnResourceChain(
> 	at org.apache.cassandra.service.ClientState.ensureHasPermission(
> 	at org.apache.cassandra.service.ClientState.hasAccess( ~[apache-cassandra-2.2.0-rc1.jar:2.2.0-rc1]
> 	at org.apache.cassandra.service.ClientState.hasColumnFamilyAccess(
> 	at org.apache.cassandra.cql3.statements.SelectStatement.checkAccess(
> 	at org.apache.cassandra.cql3.QueryProcessor.processStatement(
> 	at org.apache.cassandra.cql3.QueryProcessor.process( ~[apache-cassandra-2.2.0-rc1.jar:2.2.0-rc1]
> 	at org.apache.cassandra.cql3.QueryProcessor.process( ~[apache-cassandra-2.2.0-rc1.jar:2.2.0-rc1]
> 	at org.apache.cassandra.thrift.CassandraServer.execute_cql3_query(
> 	at org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(
> 	at org.apache.cassandra.thrift.Cassandra$Processor$execute_cql3_query.getResult(
> 	at org.apache.thrift.ProcessFunction.process( ~[libthrift-0.9.2.jar:0.9.2]
> 	at org.apache.thrift.TBaseProcessor.process( ~[libthrift-0.9.2.jar:0.9.2]
> 	at org.apache.cassandra.thrift.CustomTThreadPoolServer$
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [na:1.7.0_55]
> 	at java.util.concurrent.ThreadPoolExecutor$ Source) [na:1.7.0_55]
> 	at Source) [na:1.7.0_55]
> {code}

This message was sent by Atlassian JIRA

View raw message