[
https://issues.apache.org/jira/browse/CASSANDRA-5112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Yeschenko resolved CASSANDRA-5112.
------------------------------------------
Resolution: Fixed
Reviewer: jbellis
Rolling upgrade issue turned out to be a non-issue - was caused by another
experiment with removing commitlog.
Committed.
> Setting up authentication tables with custom authentication plugin
> ------------------------------------------------------------------
>
> Key: CASSANDRA-5112
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5112
> Project: Cassandra
> Issue Type: Improvement
> Components: API
> Affects Versions: 1.2.0
> Reporter: Dirkjan Bussink
> Assignee: Aleksey Yeschenko
> Priority: Minor
> Fix For: 1.2.2
>
>
> I'm working on updating https://github.com/nedap/cassandra-auth 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 it.
> 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
> MigrationManager.java:320, because the gossiper hasn't been started yet.
> - 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: http://www.atlassian.com/software/jira
