[
https://issues.apache.org/jira/browse/CASSANDRA-8557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16898906#comment-16898906
]
Tanaka edited comment on CASSANDRA-8557 at 8/2/19 1:55 PM:
-----------------------------------------------------------
{quote}1. The default installation doesn’t allow remote connections
{quote} * There is no mention of setting up remote access on the installation
page
* Follow this guide: [Setting up Cassandra for remote access ·
GitHub|https://gist.github.com/andykuszyk/7644f334586e8ce29eaf8b93ec6418c4]
* Follow this guide to JMX remote access:
[Documentation|http://cassandra.apache.org/doc/latest/operating/security.html?highlight=remote%20access]
{quote}2. The config file (cassandra.yaml) specifies the use of the
AllowAllAuthenticator. This is almost immediately replaced during setup by the
PasswordAuthenticator. Why not start there?
{quote} * Cassandra ships with two options included in the default distribution.
* By default, Cassandra is configured with AllowAllAuthenticator which
performs no authentication checks and therefore requires no credentials. It is
used to disable authentication completely. Note that authentication is a
necessary condition of Cassandra’s permissions subsystem, so if authentication
is disabled, effectively so are permissions.
* The default distribution also includes PasswordAuthenticator, which stores
encrypted credentials in a system table. This can be used to enable simple
username/password authentication.
{quote}3. The config file (cassandra.yaml) specifies the use of the
AllowAllAuthorizer. This is almost immediately replaced during setup by the
CassandraAuthorizer. Why not start there?
{quote} * Cassandra ships with two options included in the default distribution.
* By default, Cassandra is configured with AllowAllAuthorizer which performs
no checking and so effectively grants all permissions to all roles. This must
be used if AllowAllAuthenticator is the configured authenticator.
* The default distribution also includes CassandraAuthorizer, which does
implement full permissions management functionality and stores its data in
Cassandra system tables.
was (Author: tanakarm):
{quote}1. The default installation doesn’t allow remote connections
{quote} * There is no mention of setting up remote access on the installation
page
* Follow this guide: [Setting up Cassandra for remote access ·
GitHub|https://gist.github.com/andykuszyk/7644f334586e8ce29eaf8b93ec6418c4]
* Follow this guide to JMX remote access:
[Documentation|http://cassandra.apache.org/doc/latest/operating/security.html?highlight=remote%20access]
{quote}2. The config file (cassandra.yaml) specifies the use of the
AllowAllAuthenticator. This is almost immediately replaced during setup by the
PasswordAuthenticator. Why not start there?
{quote} * Cassandra ships with two options included in the default distribution.
* By default, Cassandra is configured with AllowAllAuthenticator which
performs no authentication checks and therefore requires no credentials. It is
used to disable authentication completely. Note that authentication is a
necessary condition of Cassandra’s permissions subsystem, so if authentication
is disabled, effectively so are permissions.
* The default distribution also includes PasswordAuthenticator, which stores
encrypted credentials in a system table. This can be used to enable simple
username/password authentication.
{quote}3. The config file (cassandra.yaml) specifies the use of the
AllowAllAuthorizer. This is almost immediately replaced during setup by the
CassandraAuthorizer. Why not start there?
{quote} * Cassandra ships with two options included in the default distribution.
* By default, Cassandra is configured with AllowAllAuthorizer which performs
no checking and so effectively grants all permissions to all roles. This must
be used if AllowAllAuthenticator is the configured authenticator.
* The default distribution also includes CassandraAuthorizer, which does
implement full permissions management functionality and stores its data in
Cassandra system tables.
> Default install from tarball is a bit puzzling
> ----------------------------------------------
>
> Key: CASSANDRA-8557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8557
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Tools, Local/Config
> Environment: Tested with Crunchbang Waldorf built on Debian 7 Wheezy.
> Java version:
> {noformat}
> $ java -version
> java version "1.8.0_25"
> Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
> {noformat}
> Python version:
> {noformat}
> $ python --version
> Python 2.7.3
> {noformat}
> I suspect this applies to all *nix tarball installs.
> Reporter: Chris E
> Assignee: Tanaka
> Priority: Low
> Labels: documentation, easyfix
>
> The default tarball installation of Apache Cassandra is kind of confusing for
> a newcomer.
> There are several different points of confusion:
> 1. The default installation doesn't allow remote connections.
> 2. The config file (cassandra.yaml) specifies the use of the
> AllowAllAuthenticator. This is almost immmediately replaced during setup by
> the PasswordAuthenticator. Why not start there?
> 3. The config file (cassandra.yaml) specifies the use of the
> AllowAllAuthorizer. This is almost immediately replaced during setup by the
> CassandraAuthorizer. Why not start there?
> 4. Why does cassandra-cli exist? It even tells the user "This is being
> deprecated." It's confusing figuring out whether to use cqlsh or
> cassandra-cli.
> 5. Running the cassandra script creates a background job that keeps
> running--if you control-c the script, the process continues running.
> 6. The config file (cassandra.yaml) has rpc_interface and rpc_address, and
> the docs there don't spell out that that address is *also* required for using
> remote logins from cqlsh.
> 7. On a freshly-created VM, the localhost flag to rpc_address doesn't appear
> to work (though this may be due to a misconfiguration of the VM). It seems to
> need the assigned IP address of the VM to get it accepting external
> connections.
> 8. The config file (cassandra.yaml) has the request_scheduler using
> NoScheduler--which is fine, but the docs are unclear as to whether or not
> this means that client requests won't be scheduled (at all).
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
