Not able to connect to remote cassandra - java

I am trying to access Cassandra(2.1.0) installed on my machine from other machine using my ip address. Here is how I am trying to do it in other machine:
Cluster cluster = Cluster.builder().addContactPoint("192.168.3.51").build();
Session session = cluster.connect("adaequare");
But I am not able to access it. Here are few configurations from Cassandra installed on my machine:
listen_address: localhost
start_native_transport: true
native_transport_port: 9042
rpc_address: localhost
rpc_port: 9160
I tried changing localhost to my ip address. But it did not work either. Do I have to make any other changes in my cassandra.yaml to get this done?

You need to post the error. By saying "It didn't work" gives no clue at all.
Anyway, rpc_addressin cassandra.yaml should point to the IP you configured. In case it is 192.168.3.51, then it needs to go there.

Related

Debug Port in containerized WebLogic server

I have a containerized WebLogic server which is running on my docker host mapped with three port: 5556, 6001, 7001. I have deployed my java product and everything is successful. I have also assaign a debug port on 8453 based on this article on WebLogic:
https://docs.oracle.com/en/cloud/paas/java-cloud/jscug/enable-jvm-debug-port.html#GUID-C83E051D-3A28-4FE7-8333-20F40A06DAEA
In Intellij IDE, I configured my debug port on localhost port 8453 in ‘Edit Configuration…’ . here everything seems extremly OK and good. But as I am going to debug connection gets failed.
"unable to open debugger port (localhost:8453): java.net.connectException "Connection refused: connect"
I am a little bit naive in WebLogic server. It might be because somehow given port not mapped causes this error. Please help me if anybody there had such experience before.
The environmental variable JAVA_OPTIONS is typically being set on startWeblogic.sh. With using a dockerized weblogic, the same variable needs to be set with the debug options and the address.
For example, you can set the variable on your Dockerfile.
The following will set the debug port for the Weblogic applications to 4000 :
ENV JAVA_OPTIONS $JAVA_OPTIONS -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=4000,server=y,suspend=n
Also this port needs to be exposed.
For example on docker-compose.yml:
ports:
- 4000:4000
On IntelliJ IDEA, the handshake is succesful without using IP Address of the container.

If I use "localhost", is it guaranteed that the client is local? (considering I can edit the system hosts file)

If I use this solution:
new ServerSocket(9090, 0, InetAddress.getByName("localhost"))
...and the user changes it's system hosts file to access my website as "localhost", will this fail to prevent access from non-local client?
(in response to the bounty call)
As always in computer security, guarantee depens on attacker capabilities.
The attacker is lame and knows nothing. Then yes, localhost guarantees the locality of the client.
The attacker has login access to the system and can run SSH to the outer world. Then no guarantees - SSH can forward internal ports through tunnels:
ssh -R *:8080:localhost:9090 some.external.server
Executing this command on the box with your java server will result in establishing a tunnel. All requests addressed to some.external.server:8080 will be delivered to localhost:9090 of the target box.
VPS nowdays costs almost nothing, so the attacker can easily rent such external box and use it as the proxy between your localhost and the whole world.
You may try to protect your server by filtering out all requests where Host header is not localhost. It could be easily countermeasured by including a header-rewriting proxy, such as nginx, to the forwarding chain.
Summary
As you can see, guarantee means that users in the target box must be severely limited: no forwarding software. It implies denying users access to system utilities like ssh or installing and/or running them with user privileges. This is highly unlikely unless the box is a set-top box without any user login or software reconfiguration.
Localhost address
The first comment to the question suggests a trick with localhost name resolution:
the user could probably override localhost to that it's no longer 127.0.0.1
The idea is to place a record to /etc/hosts or c:\Windows\System32\Drivers\etc\hosts that binds localhost name to another IP address.
If your box has an Ethernet connection with, say, address 1.2.3.4, then the line
1.2.3.4 localhost
might cause change of localhost address. If this happens, then the line
new ServerSocket(9090, 0, InetAddress.getByName("localhost"))
will bind the port 9090 on the external network interface, that is accessible from the outside of the box.
I tried this on Ubuntu 18.04, and it worked. I successfully connected to the app running on localhost in the box on the other side of Pasific.
BUT
Once upon a time MS Windows developers hardcoded localhost to be 127.0.0.1. Here is the Medium post about that.
I checked with my Windows 10 box. Confirmed: localhost resolves to 127.0.0.1. The test program
package org.example;
import java.net.*;
import java.io.*;
public class TryLocalhost {
public static void main(String[] args) throws IOException {
System.out.println("localhost: " + InetAddress.getByName("localhost"));
}
}
produces
localhost: localhost/127.0.0.1
while hosts file tried to bind localhost to the link-local address
# localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost
192.168.0.198 localhost
The comment is original, from Microsoft.

How to connect to a Cluster prommatically

Am successfully installed cassandra and when i testing with "connect localhost/9160;" it is working fine for me.I want connect with different IP address/Port.I was changed the listen_address in cassandra.yaml file and restarted the server and tested it showing below error.
Exception retrieving information about the cassandra node, check you have connected to the thrift port.
org.apache.thrift.transport.TTransportException: Read a negative frame size (-21
13929216)!
at org.apache.thrift.transport.TFramedTransport.readFrame(TFramedTranspo
rt.java:133)
at org.apache.thrift.transport.TFramedTransport.read(TFramedTransport.ja
va:101)
at org.apache.thrift.transport.TTransport.readAll(TTransport.java:84)
at org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.ja
va:362)
at org.apache.thrift.protocol.TBinaryProtocol.readI32(TBinaryProtocol.ja
va:284)
at org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryPr
otocol.java:191)
at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:69)
at org.apache.cassandra.thrift.Cassandra$Client.recv_describe_cluster_na
me(Cassandra.java:1206)
at org.apache.cassandra.thrift.Cassandra$Client.describe_cluster_name(Ca
ssandra.java:1194)
at org.apache.cassandra.cli.CliMain.connect(CliMain.java:138)
at org.apache.cassandra.cli.CliClient.executeConnect(CliClient.java:2393
)
at org.apache.cassandra.cli.CliClient.executeCLIStatement(CliClient.java
:282)
at org.apache.cassandra.cli.CliMain.processStatementInteractive(CliMain.
java:201)
at org.apache.cassandra.cli.CliMain.main(CliMain.java:331)
It is really helpful for me.Sorry my bad English..
If the only parameter you changed is listen_address, then you still need to use port 9160 to connect with cassandra-cli. If you want to change that port as well, then you need to adjust the rpc_port in cassandra.yaml accordingly. listen_address defines the port that two Cassandra nodes would communicate over. It is independent of the port used for Thrift clients (like cassandra-cli).

Elasticsearch server discovery configuration

I've installed ElasticSearch server, that i'm running by:
$ ./elasticsearch -f
{0.18.2}[11698]: initializing ...
loaded [], sites []
{0.18.2}[11698]: initialized
{0.18.2}[11698]: starting ...
bound_address {inet[/0:0:0:0:0:0:0:0:9300]}, publish_address {inet[/192.168.1.106:9300]}
new_master [Stingray][ocw4qPdmSfWuD9pUxHoN1Q][inet[/192.168.1.106:9300]], reason: zen-disco-join (elected_as_master)
elasticsearch/ocw4qPdmSfWuD9pUxHoN1Q
recovered [0] indices into cluster_state
bound_address {inet[/0:0:0:0:0:0:0:0:9200]}, publish_address {inet[/192.168.1.106:9200]}
{0.18.2}[11698]: started
How I can configure Java client to connect to this server?
I have just:
node.client=true
but, after trying to connect i'm receiving:
org.elasticsearch.discovery.MasterNotDiscoveredException:
at org.elasticsearch.action.support.master.TransportMasterNodeOperationAction$3.onTimeout(TransportMasterNodeOperationAction.java:162)
If i'm configuring java client as:
node.data=false
I'm getting following logs:
INFO main node:internalInfo:93 - [Stark, Tony] {0.18.2}[13008]: starting ...
INFO main transport:internalInfo:93 - [Stark, Tony] bound_address {inet[/0:0:0:0:0:0:0:0:9301]}, publish_address {inet[/192.168.1.106:9301]}
INFO elasticsearch[Stark, Tony]clusterService#updateTask-pool-13-thread-1 service:internalInfo:93 - [Stark, Tony] new_master [Stark, Tony][WkNn96hgTkWXRnsR0EOZjA][inet[/192.168.1.106:9301]]{data=false}, reason: zen-disco-join (elected_as_master)
As I understood it means that this new node (supposed to be client node) made itself a new master node. And I don't from log that it's found and connect to any other node.
Both server and client are started on same machine. 192.168.1.106:9200 are accessible from browser.
And I can't find any good documentation about discovery config. Where I can read more about ElasticSearch configurations? And how to configure Java client?
The most likely reason for this failure is firewall on your machine that blocks multicast discovery traffic on port 54328. Both client and master are broadcasting on this port during initial discovery and they don't hear back from each other. That's why when you specify node.client=true client node (that cannot be a master) fails with MasterNotDiscoveredException and node with no data elects itself as a master.
I ran into the same problem and by using IP numbers in the config file resolved it for me.
in /config/elasticsearch.yml
uncomment and change the network.host setting to:
network.host: 127.0.0.1
You can also change this to your machine IP number in ifconfig.
I had the same issue. Eventually, it turned out I had a firewall issue, with my firewall (on Ubuntu) blocking the ports of ElasticSearch. I'm using the default firewall on Ubuntu, ufw.
So, to open up the ports, I ran these commands on the terminal:
sudo ufw allow proto tcp to any port 9200:9400
sudo ufw allow proto tcp to any port 54328
My cluster runs locally on 9200, and all my clients open up on 9300+. So, I just opened the range 9200-9400 for them. 54328 is for the multicast broadcast.
Just to be complete: I also used the TransportClient, which works, but I added hardcoded my localhost to the address the TransportClient will work on. Not a good thing for production code :-)
Faced the same issue where the nodes were not able to elect a master on nodes restart.
The problem lies in the communication of nodes among themselves.
Please ensure in your elastic search logs, whether the node restart says
publish_address {127.0.0.1:9200}
or
publish_address {0.0.0.1:9200}
This means the current node is not publishing its IP address to other nodes and hence the nodes won't recognise this node even though the node IP might be present in the discovery.zen.ping.unicast.hosts
Solution
Make the following changes in elasticsearch.yml. Add
network.host: _non_loopback:ipv4_
and restart the node.
Ensure that the bound address now shows the <IP address>:<port no> and not the localhost.
This means that now your node is discoverable. The second step to make it discoverable in the cluster is to add the ip address of the node in the unicast hosts lists of all the master nodes, so that whenever we have a new master, the node is discoverable to the new master.
Add the node IP to the discovery.zen.ping.unicast.hosts
list of hosts of all the masters to make it disoverable. A masterpings all the
nodes present in the unicast list.
Something like this should work:
Settings s = ImmutableSettings.settingsBuilder()
.put(this.settings)
.build();
TransportClient client = new TransportClient(s);
client.addTransportAddress(new InetSocketTransportAddress(
"localhost",
9300)
);
What fouled me up was I originally tried connecting the client to 9200, not 9300. Guidance for settings above can be found from http://www.elasticsearch.org/guide/reference/java-api/client.html
Configure network host to localhost:
network.host: 127.0.0.1

java.net.UnknownHostException: Invalid hostname for server: local

What are the steps I should take to solve the error:
java.net.UnknownHostException: Invalid hostname for server: local
I added the new virtual host name at Android emulator but the result returns to
java.net.UnknownHostException virtualhostname at
java.net.InetAddress.lookUpHostByName(InetAddress.java:506)
When I type my virtualhost URL on my PC, it works on display. Then again, when I ran on Emulator and check on Logcat, I couldn't be able to read or check the HTTP status if 200, 202, or an error code number. It simply returned to UnknownHostException
I was having the same issue on my mac. I found the issue when I pinged my $HOSTNAME from terminal and it returned ping: cannot resolve myHostName: Unknown host.
To resolve:
Do echo $HOSTNAME on your terminal.
Whatever hostname it shows (lets say myHostName), try to ping it : ping myHostName. If it returns ping: cannot resolve myHostName: Unknown host then add an entry into your /etc/hosts file.
For that edit /etc/hosts file and add following:
127.0.0.1 myHostName
What the exception is really saying is that there is no known server with the name "local". My guess is that you're trying to connect to your local computer. Try with the hostname "localhost" instead, or perhaps 127.0.0.1 or ::1 (the last one is IPv6).
From the javadocs:
Thrown to indicate that the IP address
of a host could not be determined.
127.0.0.1or ::1 or "localhost" should always be the loopback interface, so if that doesn't work I'd be really surprised.
If there really is a server called "local" on your network - examine your DNS settings or add it to your hosts file.
java.net.UnknownHostException: Host is unresolved:
Thrown to indicate that the IP address of a host could not be determined.
This exception is also raised when you are connected to a valid wifi but router does not receive the internet. Its very easy to reproduce this:
Connect to a valid wifi
Now remove the cable from the router while router is pluged-in
You will observe this error!!
You can't really solve this, You can only notify the user gracefully. (something like - "Unable to make a connection")
This is not specific to the question, but this question showed up when I was Googling for the mentioned UnknownHostException, and the fix is not found anywhere else so I thought I'd add an answer here.
The exception that was continuously received was:
java.net.UnknownHostException: google.com
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:184)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:589)
at java.net.Socket.connect(Socket.java:538)
at java.net.Socket.<init>(Socket.java:434)
at java.net.Socket.<init>(Socket.java:211)
...
No matter how I tried to connect to any valid host, printing it in the terminal would not help either. Everything was right.
The Solution
Not calling trim() for the host string which contained whitespace. In writing a proxy server the host was obtained from HTTP headers with the use of split(":") by semicolons for the HOST header. This left whitespace, and causes the UnknownHostException as a host with whitespace is not a valid host. Doing a host = host.trim() on the String host solved the ambiguous issue.
Your hostname is missing. JBoss uses this environment variable ($HOSTNAME) when it connects to the server.
[root#xyz ~]# echo $HOSTNAME
xyz
[root#xyz ~]# ping $HOSTNAME
ping: unknown host xyz
[root#xyz ~]# hostname -f
hostname: Unknown host
There are dozens of things that can cause this. Please comment if you discover a new reason.
For a hack until you can permanently resolve this issue on your server, you can add a line to the end of your /etc/hosts file:
127.0.0.1 xyz.xxx.xxx.edu xyz
This might happen due to various reasons
1) Check if you have VPN connected, you might get this error sometimes if yes
"Your hostname, localhost resolves to a loopback address: 127.0.0.1; using 10.xxx.1.193 instead (on interface cscotun0)"
2) Check your $HOSTNAME
3) try to ping $HOSTNAME on commandline and if it doesnt work, tweak the system settings to make your local host respond to pings
Try the following :
String url = "http://www.google.com/search?q=java";
URL urlObj = (URL)new URL(url.trim());
HttpURLConnection httpConn =
(HttpURLConnection)urlObj.openConnection();
httpConn.setRequestMethod("GET");
Integer rescode = httpConn.getResponseCode();
System.out.println(rescode);
Trim() the URL
Trying to connect to your local computer.try with the hostname "localhost" instead or perhaps ::/ - the last one is ipv6
Please try to set SPARK_LOCAL_IP environment variable to the ip address(can be localhost i.e. your own ip address) you want to connect. E.g.
$ export SPARK_LOCAL_IP=182.95.208.152
This way you will not be required to alter existing linux settings.
Worked for me, hope helps you too.
Connect your mobile with different wifi connection with different service provider.
I don't know the exact issue but i could not connect to server with a specific service provider but it work when i connected to other service provider. So try it!
I had this issue in my android app when grabbing an xml file the format of my link was not valid, I reformatted with the full url and it worked.
If you are here because your emulator gives you that Exception, Go to Tools > AVD Manager in your android emulator and Cold boot your Emulator.
I had the same issue.
Restart docker was the fix for me. For some reason it needed a restart, I don´t know why, but it worked.
If your /etc/localhosts file has entry as below:
Add hostname entry as below:
127.0.0.1 local host (add your hostname here)
::1 (add hostname here) (the last one is IPv6).
This should resolve the issue.

Categories