[
https://issues.apache.org/jira/browse/CASSANDRA-5112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13576079#comment-13576079
]
Aleksey Yeschenko commented on CASSANDRA-5112:
----------------------------------------------
bq. LGTM, except relying on SUPERUSER_SETUP_DELAY seems a bit fragile. Can we
slot it into the right spot in init_server instead perhaps?
Oh, we are not relying on it, of course. We are relying on QUORUM and on the
the fixed TIMESTAMP for the superuser. The timeout is there to reduce "Failed
to create superuser: unavailable exception" log spam. It's safe to remove the
delay, but since it's only *required* once in the cluster's lifetime, I think
it's okay to leave it.
> 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
