cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5112) Setting up authentication tables with custom authentication plugin
Date Fri, 04 Jan 2013 14:02:12 GMT


Sylvain Lebresne commented on CASSANDRA-5112:

bq. Does anyone have a recommendation for the path to follow here?

Someone can correct me if I'm wrong but I'm afraid there is no solution currently. If setup()
is called before the node has joined the ring, then you won't be able to properly do migrations,
nor for that matter write to any ColumnFamily except the system ones (which you're not supposed
to). Not sure what's the best way to fix this though.
> Setting up authentication tables with custom authentication plugin
> ------------------------------------------------------------------
>                 Key: CASSANDRA-5112
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: API
>    Affects Versions: 1.2.0
>            Reporter: Dirkjan Bussink
>            Priority: Minor
> I'm working on updating with the new authentication
API's in Cassandra 1.2.0. I have stumbled on an issue and I'm not really sure how to handle
> For the authentication I want to setup additional column families for the passwords and
permissions. As recommended in the documentation of IAuthorizer, I'm trying to create these
tables during setup(): "Setup is called once upon system startup to initialize the IAuthorizer.
For example, use this method to create any required keyspaces/column families.".
> The problem is that doing this seems to be a lot harder than I would think, or I'm perhaps
missing something obvious. I've tried various attempts, but all have failed:
> - CQL and QueryProcessor.processInternal to setup additional column families. This fails,
since processInternal will throw a UnsupportedOperationException due to it being a SchemaAlteringStatement.
> - CQL and QueryProcessor.process. This works after the system has successfully started,
but due to the moment setup() is called in the Cassandra boot process, it will fail. It will
throw an AssertionError in, because the gossiper hasn't been started
> - Internal API's. Mimicking how other column families are set up, using CFMetadata and
Schema.load. This seems to get the system in some inconsistent state where some parts do see
the additional column family, but others don't.
> Does anyone have a recommendation for the path to follow here? What would be the recommended
approach for actually setting up those column families during starting for authentication?
> From working on this, I also have another question. I see the default system_auth keyspace
is created with a SimpleStrategy and a replication factor of 1. Is this a deliberate choice?
I can imagine that if a node in a cluster dies, losing the authentication information that
happens to be available on that code could be very problematic. If I'm missing any reasoning
here, please let me know, but it struck me as something that could cause potential problems.
I also don't see a way I could reconfigure this at the moment, and API's such as CREATE USER
do seem to depend on this keyspace.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message