From ea66c16818a3f242ffb70cc00d95fbb63eb6904f Mon Sep 17 00:00:00 2001 From: Tzach Livyatan Date: Sun, 25 Sep 2022 08:34:00 +0300 Subject: [PATCH] Fix Enable Authorization doc page references a wrong CL used by a 'cassandra' user Fix https://github.com/scylladb/scylladb/issues/11633 Closes #11637 --- docs/operating-scylla/security/enable-authorization.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/operating-scylla/security/enable-authorization.rst b/docs/operating-scylla/security/enable-authorization.rst index 33dbd95440..81230021f0 100644 --- a/docs/operating-scylla/security/enable-authorization.rst +++ b/docs/operating-scylla/security/enable-authorization.rst @@ -64,7 +64,7 @@ By default, the superuser credentials are username cassandra, password cassandra cqlsh -u cassandra -p cassandra -.. note:: The cassandra user is special. When you try to login with this username, it is required to usen EACH_QUORUM consistency level(CL) for replies. On the other hand, your own user requires LOCAL_ONE consistency level. +.. note:: The cassandra user is special. When you try to login with this username, it is required to usen QUORUM consistency level(CL) for replies. On the other hand, your own user requires LOCAL_ONE consistency level. This can be a problematic in certain situations, such as adding or removing DCs. In such cases the cassandra user won't be able to login. Creating a superuser role and assigning yourself to the role is definitely the best way forward. Refer to :doc:`RBAC ` for an example of how to create roles and refer to :doc:`Grant Authorization ` for information on using the grant clause.