I'm not sure why you aren't able to connect with cqlsh, there may be
something in your log files to help figure that out.

As for your config, even if you do figure out why you can't connect, you're
still going to have to change your settings since you won't be able to
connect to your cluster from a machine outside localhost.

Comment out listen_address.  Using that is, imo, generally wrong, since it
means you need to have different configs on each machine.  I'm not wild
about the "do the right thing" part in there - instead set your
listen_interface to en0 (or whatever network device you're using) and
Cassandra will attach to the external IP and stuff *shoiuld just work*.  If
it doesn't, check your logs for errors.

Jon

On Sun, Oct 30, 2016 at 12:38 PM Raimund Klein <chessra...@gmail.com> wrote:

> Hi guys,
>
> Thank you for your responses. Let me try to address them:
>
>
>    - I just tried cqlsh directly with the IP, no change in behaviour. (I
>    previously tried the hostnames, didn't work either.)
>    - As for the "empty" ..._address: I meant that I leave these blank.
>    Please let me quote from the default cassandra.yaml:
>    # Leaving it blank leaves it up to InetAddress.getLocalHost(). This
>    # (hostname, name resolution, etc), and the Right Thing is to use the
>    # address associated with the hostname (it might not be).
>    # will always do the Right Thing _if_ the node is properly configured
>    So what should I put instead?
>    - Requested outputs:
>
>    nodetool status
>    Datacenter: datacenter1
>    =======================
>    Status=Up/Down
>    |/ State=Normal/Leaving/Joining/Moving
>    --  Address       Load       Tokens       Owns (effective)  Host ID
>                                Rack
>    UN  <IP_1>   344.56 KB  256          100.0%
>    6271c749-e41d-443c-89e4-46c0fbac49af  rack1
>    UN  <IP_2>  266.91 KB  256          100.0%
>    e50a1076-7149-45f3-9001-26bb479f2a50  rack1
>
>    # netstat -lptn | grep java
>    tcp        0      0 <IP_1>:7000        0.0.0.0:*               LISTEN
>        17040/*java*
>    tcp        0      0 127.0.0.1:36415         0.0.0.0:*
>    LISTEN      17040/*java*
>    tcp        0      0 127.0.0.1:7199          0.0.0.0:*
>    LISTEN      17040/*java*
>    tcp6       0      0 <IP_1>:9042        :::*                    LISTEN
>        17040/
>
> *java *
>    # netstat -lptn | grep java
>    tcp        0      0 127.0.0.1:43569         0.0.0.0:*
>    LISTEN      49349/*java*
>    tcp        0      0 <IP_2>:7000       0.0.0.0:*               LISTEN
>        49349/*java*
>    tcp        0      0 127.0.0.1:7199          0.0.0.0:*
>    LISTEN      49349/*java*
>    tcp6       0      0 :::8009                 :::*
>    LISTEN      42088/*java*
>    tcp6       0      0 :::8080                 :::*
>    LISTEN      42088/*java*
>    tcp6       0      0 <IP_2>:9042       :::*                    LISTEN
>        49349/*java*
>    tcp6       0      0 127.0.0.1:8005          :::*
>    LISTEN      42088/*java*
>
> Jonathan, thank you for reassuring me that I didn't misunderstand seeds
> completely. ;-)
>
> Any ideas?
>
> Regards
> Raimund
>
> 2016-10-30 18:48 GMT+00:00 Jonathan Haddad <j...@jonhaddad.com>:
>
> I always prefer to set the listen interface instead of listen adress
>
> Both nodes can be seeds. In fact, there should be more than one seed.
> Having your first 2 nodes as seeds is usual the correct thing to do.
> On Sun, Oct 30, 2016 at 8:28 AM Vladimir Yudovin <vla...@winguzone.com>
> wrote:
>
> >Empty listen_address and rpc_address.
> What do you mean by "Empty"? You should set either ***_address or
> ***_interface. Otherwise
> Cassandra will not listen on port 9042.
>
> >Open ports 9042, 7000 and 7001 for external communication.
> Only port 9042 should be open to the world, Port 7000 for internode
> communication, and 7001 for internode SSL communication (only one of them
> is used).
>
> >What is the best order of steps
> Order doesn't really matter.
>
> >Define both machines as seeds.
> It's wrong. Only one (started first) should be seed.
>
>
> >nodetool sees both of them
> cqlsh refuses to connect
> Can you please give output of
> *nodetool status*
> and
> *netstat -lptn | grep java*
>
> Best regards, Vladimir Yudovin,
>
> *Winguzone <https://winguzone.com?from=list> - Hosted Cloud
> CassandraLaunch your cluster in minutes.*
>
>
> ---- On Sun, 30 Oct 2016 14:11:55 -0400*Raimund Klein
> <chessra...@gmail.com <chessra...@gmail.com>>* wrote ----
>
> Hi everyone,
>
> We've managed to set up a Cassandra 2.2.6 cluster of two physical nodes
> (nodetool sees both of them, so I'm quite certain the cluster is indeed
> active). My steps to create the cluster were (this applies to both
> machines):
>
>  - Empty listen_address and rpc_address.
>  - Define a cluster_name.
>  - Define both machines as seeds.
>  - Open ports 9042, 7000 and 7001 for external communication.
>
>
>
> Now I want to secure access to the cluster in all forms:
>
>  - define a different database user with a new password
>  - encrypt communication bet ween clients and the cluster including client
> verification
>  - encrypt communication between the nodes including verification
>
> What is the best order of steps and correct way to achieve this? I wanted
> to start with defining a different user, but cqlsh refuses to connect after
> enforcing user/password authentication:
>
> cqlsh -u cassandra -p cassandra
> Connection error: ('Unable to connect to any servers', {'127.0.0.1':
> error(111, "Tried connecting to [('127.0.0.1', 9042)]. Last error:
> Connection refused")})
>
>
>
> This happens when I run the command on either of the two machines. Any
> help would be greatly appreciated.
>
>
>

Reply via email to