It may be an artifact of the email client, but that's not a valid INSERT
statement - the closing quote on the password hash is U2019 (right side
quotation mark) but the opening quote is U0027 (apostrophe) - which is what
cqlsh expects. Can you just SELECT * from system_auth.roles and check that
the salted_hash is correct?
On 18 July 2018 at 11:06, Thomas Lété <thomas.l...@soprism.com> wrote:
> Yes it’s the config I’m using and I’m trying to add the Password Auth to
> :-)
>
> Here is the content of the roles table :
>
> INSERT INTO roles (role,can_login,is_superuser,member_of,salted_hash)
> VALUES ('cassandra',true,true,null,'$2a$10$7sXeNr3okw61oisR9pCyHeWEO3wPzx
> 3w8r/LKwtDSW2Tt68f4KFmi’);
>
> It seems correct but I’m not able to authenticate (using cqlsh v5.0.1 or
> DevCenter 1.6.0)
>
> I’m starting to consider going from scratch and use the default config and
> check if it works...
>
> Le 18 juil. 2018 à 12:03, Sam Tunnicliffe <s...@beobal.com> a écrit :
>
> With that config you'll be using the default AllowAllAuthenticator, so I
> assume you are able to connect cqlsh without any credentials? If so, can
> you verify the contents of the system_auth.roles table? It should contain
> only the cassandra user.
>
> On 18 July 2018 at 08:02, Thomas Lété <thomas.l...@soprism.com> wrote:
>
>> I’m using the default ones, the commented parts are the one I use when I
>> try the PasswordAuthenticator :) (line 19 to 24)
>>
>> > Le 18 juil. 2018 à 08:51, Horia Mocioi <horia.moc...@ericsson.com> a
>> écrit :
>> >
>> > If this is the file that you are currently using...he first things that
>> > I see is that you do not have any authenticator and role_manager:
>> >
>> > https://github.com/apache/cassandra/blob/1d506f9d09c880ff2b2693e3e27fa5
>> > 8c02ecf398/conf/cassandra.yaml#L103
>> >
>> > https://github.com/apache/cassandra/blob/1d506f9d09c880ff2b2693e3e27fa5
>> > 8c02ecf398/conf/cassandra.yaml#L123
>> >
>> > On ons, 2018-07-18 at 08:33 +0200, Thomas Lété wrote:
>> >> Unfortunately, I’m not a java dev so I’m not able to create an
>> >> authenticator…
>> >>
>> >> I don’t like to do that usually but I share with you a gist of the
>> >> config, it was generated by OpsCenter when it was free, I just
>> >> updated it for Cassandra >= 3… Maybe you will see something :
>> >>
>> >> https://gist.github.com/bistory/ececc0bef7627f39a21e4e8f0c8d841c
>> >>
>> >>> Le 18 juil. 2018 à 00:28, Horia Mocioi <horia.moc...@ericsson.com>
>> >>> a écrit :
>> >>>
>> >>> Cassandra allows to use custom authenticators so I would create a
>> >>> CustomPasswordAuthenticator. This would be a copy of the existing
>> >>> PasswordAuthenticator. I would add several debugging info like:
>> >>> provided username and password, the output of the checkpw function,
>> >>> what cql statement is executed etc (any other info that would help
>> >>> me to understand what is being executed in the authenticator).
>> >>> From: Thomas Lété <thomas.l...@soprism.com>
>> >>> Sent: Tuesday, July 17, 2018 5:24:39 PM
>> >>> To: user@cassandra.apache.org
>> >>> Subject: Re: System auth empty, how to populate it
>> >>>
>> >>> Thanks for your reply,
>> >>>
>> >>> - I have not defined role_manager in the config
>> >>> - I dropped the users table, it was present in the keyspace
>> >>> - Cassandra then created a record in the roles table, yay !
>> >>>
>> >>> But when I do clash -u cassandra -p cassandra
>> >>>
>> >>> => Invalid credentials supplied.
>> >>> Authentication error on host xxxxxx: Provided username cassandra
>> >>> and/or password are incorrect
>> >>>
>> >>> I already repaired system_auth a few times, nothing help...
>> >>>
>> >>>> Le 17 juil. 2018 à 16:47, Sam Tunnicliffe <s...@beobal.com> a
>> >>>> écrit :
>> >>>>
>> >>>> The default superuser is only created at startup if 3 conditions
>> >>>> are met:
>> >>>>
>> >>>> i) The default role manager is configured. In cassandra.yaml, you
>> >>>> should see "role_manager: CassandraRoleManager". This is also the
>> >>>> default value, so unless you're explicitly using a custom role
>> >>>> manager it should be good.
>> >>>> ii) The system_auth.users table (legacy, pre-2.2) should not be
>> >>>> present. Present means present in the schema, not on disk. Unlike
>> >>>> most system tables, this table is droppable (in fact this is a
>> >>>> necessary step in upgrading from earlier versions).
>> >>>> iii) There should be no preexisting roles present in the
>> >>>> system_auth.roles table. This is verified with a regular query,
>> >>>> so you must either use CQL to delete existing roles, or remove
>> >>>> the data directories and commit logs on *all* nodes.
>> >>>>
>> >>>> Even if these three conditions are met, but the default user
>> >>>> isn't being created the manual insert that Horia suggested should
>> >>>> work. If system_auth.roles table exists and you are able to
>> >>>> perform the insert, I'm very surprised when you say it's empty
>> >>>> after you issue the insert. If you check again and it turns out
>> >>>> the manual insert is working as expected, you need to make sure
>> >>>> that the legacy tables have been dropped from schema (assuming
>> >>>> you upgraded from a pre-3.0 version at some point). If the legacy
>> >>>> tables are still present, the authenticator will continue to read
>> >>>> from them and so would be ignoring the new entry in the roles
>> >>>> table. (see: https://github.com/apache/cassandra/blob/cassandra-3
>> >>>> .11.2/NEWS.txt#L619-L640)
>> >>>>
>> >>>>
>> >>>> On 17 July 2018 at 15:18, Thomas Lété <thomas.l...@soprism.com> w
>> >>>> rote:
>> >>>> Yes I did that multiple time, always following the same procedure
>> >>>> : stop Cassandra, on all nodes, remove data, update config then
>> >>>> restart nodes one by one…
>> >>>>
>> >>>> I really don’t understand when I could have done wrong...
>> >>>>
>> >>>>> Le 17 juil. 2018 à 16:15, Simon Fontana Oscarsson <simon.fontan
>> >>>> a.oscars...@ericsson.com> a écrit :
>> >>>>>
>> >>>>> This is very strange behavior if Cassandra won't recreate the
>> >>>> cassandra user when you delete the folder.
>> >>>>> So just to make sure, you are stopping Cassandra on all nodes
>> >>>> and deleting the data directory?
>> >>>>>
>> >>>>> --
>> >>>>> SIMON FONTANA OSCARSSON
>> >>>>> Software Developer
>> >>>>>
>> >>>>> Ericsson
>> >>>>> Ölandsgatan 1
>> <https://maps.google.com/?q=%C3%96landsgatan+1+%0D%0A+37133+Karlskrona,+Sweden&entry=gmail&source=g>
>> >>>>> 37133 Karlskrona, Sweden
>> <https://maps.google.com/?q=%C3%96landsgatan+1+%0D%0A+37133+Karlskrona,+Sweden&entry=gmail&source=g>
>> >>>>> simon.fontana.oscars...@ericsson.com
>> >>>>> www.ericsson.com
>> >>>>>
>> >>>>> On tis, 2018-07-17 at 16:01 +0200, Thomas Lété wrote:
>> >>>>>> It’s empty...
>> >>>>>>
>> >>>>>>>
>> >>>>>>> Le 17 juil. 2018 à 15:59, Horia Mocioi <horia.mocioi@ericsson
>> >>>> .com> a écrit :
>> >>>>>>>
>> >>>>>>> Could you also send the output of "select * from
>> >>>> system_auth.roles"?
>> >>>>>>> (you will need to change authenticator to
>> >>>> AllowAllAuthenticator and
>> >>>>>>> authorizer to AllowAllAuthorizer)
>> >>>>>>>
>> >>>>>>> On tis, 2018-07-17 at 15:43 +0200, Thomas Lété wrote:
>> >>>>>>>>
>> >>>>>>>> Ok I tried that, nothing better (I already tried dropping
>> >>>> the entire
>> >>>>>>>> system_auth folder that way, same result)
>> >>>>>>>>
>> >>>>>>>> When I open the log, I found nothing about « Password » and
>> >>>> when I
>> >>>>>>>> search for « roles », I only find that :
>> >>>>>>>>
>> >>>>>>>> DEBUG [main] 2018-07-17 15:37:39,420
>> >>>>>>>> CompactionStrategyManager.java:380 - Recreating compaction
>> >>>> strategy -
>> >>>>>>>> disk boundaries are out of date for system_auth.roles.
>> >>>>>>>> DEBUG [main] 2018-07-17 15:37:39,420
>> >>>> DiskBoundaryManager.java:53 -
>> >>>>>>>> Refreshing disk boundary cache for system_auth.roles
>> >>>>>>>> DEBUG [main] 2018-07-17 15:37:39,422
>> >>>> DiskBoundaryManager.java:56 -
>> >>>>>>>> Updating boundaries from
>> >>>>>>>>
>> >>>> DiskBoundaries{directories=[DataDirectory{location=/home/cassandr
>> >>>> a/da
>> >>>>>>>> ta}], positions=[max(9223372036854775807)], ringVersion=3,
>> >>>>>>>> directoriesVersion=0} to
>> >>>>>>>>
>> >>>> DiskBoundaries{directories=[DataDirectory{location=/home/cassandr
>> >>>> a/da
>> >>>>>>>> ta}], positions=[max(9223372036854775807)], ringVersion=16,
>> >>>>>>>> directoriesVersion=0} for system_auth.roles
>> >>>>>>>>
>> >>>>>>>> The configuration I use for Auth is the following :
>> >>>>>>>>
>> >>>>>>>> authorizer: CassandraAuthorizer
>> >>>>>>>> permissions_validity_in_ms: 2000
>> >>>>>>>> permissions_update_interval_in_ms: 2000
>> >>>>>>>> authenticator: PasswordAuthenticator
>> >>>>>>>> credentials_validity_in_ms: 2000
>> >>>>>>>> credentials_update_interval_in_ms: 2000
>> >>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> Le 17 juil. 2018 à 15:26, Simon Fontana Oscarsson
>> >>>> <simon.fontana.os
>> >>>>>>>>> cars...@ericsson.com> a écrit :
>> >>>>>>>>>
>> >>>>>>>>> Could you try the following steps?
>> >>>>>>>>>
>> >>>>>>>>> Stop Cassandra.
>> >>>>>>>>> Change authenticator in yaml to PasswordAuthenticator if
>> >>>> not
>> >>>>>>>>> already done.
>> >>>>>>>>> Remove data directory with `rm -rf data/system_auth/roles-
>> >>>> *`
>> >>>>>>>>> Start Cassandra.
>> >>>>>>>>> Login with `cqlsh -u cassandra -p cassandra`
>> >>>>>>>>>
>> >>>>>>>>> Works for me.
>> >>>>
>> >>>>
>> >>>> ---------------------------------------------------------------
>> >>>> ------
>> >>>> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
>> >>>> For additional commands, e-mail: user-h...@cassandra.apache.org
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
>> > For additional commands, e-mail: user-h...@cassandra.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: user-h...@cassandra.apache.org
>>
>>
>
>
