cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5112) Setting up authentication tables with custom authentication plugin
Date Mon, 11 Feb 2013 20:17:12 GMT


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:
>             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 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