My django server is running with port 9000 and I am trying to run ngrok for my local django server with the following command
./ngrok http 192.168.7.171:9000
But it is throwing 2 errors as
reconnecting (dial tcp [2600:1f16:59e:b200:7dc6:8c66:d95b:e236]:443: connect: network is unreachable)
then
reconnecting (read tcp 192.168.7.171:57604->52.15.196.176:443: i/o timeout)
The error is shown as below in terminal,
Session Status reconnecting (read tcp 192.168.7.171:47454->18.216.22.45:443: i/o timeout)
Update update available (version 2.3.27, Ctrl-U to update)
Version 2.2.8
Region United States (us)
Web Interface http://127.0.0.1:4040
Connections ttl opn rt1 rt5 p50 p90
0 0 0.00 0.00 0.00 0.00
Could anyone help me out of this issue?
Related
I know there are lots of resources on this topic, but I think I've done everything correctly and I still can't connect to my server.
I've started a simple node.js server on port 80.
sudo netstat -tnlp | grep 80
tcp 0 0 127.0.0.1:80 0.0.0.0:* LISTEN 3657/node
curl localhost:80
Welcome Node.js
I've configured the Security group for this instance as well as the VPC to allow traffic.
I've made sure there is no local firewall and that the VPC ACL is not blocking traffic (not that I expected it, since this is a completely new instance.)
service iptables status
Redirecting to /bin/systemctl status iptables.service
Unit iptables.service could not be found.
The output when I try to connect from my local machine:
curl 3.xxx.xxx.xxx
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- 0:00:03 --:--:-- 0
curl: (7) Failed to connect to 3.xxx.xxx.xxx port 80: Connection refused
Are there any other ideas on what to check next?
The answer to my problem was https://stackoverflow.com/a/14045163/2369000. The boilerplate code that I copied used a method to only listen to requests that originated from localhost. This could have been detected from the netstat output, which said 127.0.0.1:80 for the listening address. The answer was to use .listen(80, "0.0.0.0") or just .listen(80) since the default behavior is to listen for requests from any IP address.
I am trying to deploy a Spark job in a Kubernetes cluster (running on AWS EKS). I deploy a pod that executes spark-submit in client mode. The pod becomes the driver pod and then begins to launch executor pods. The executor pods try to connect to driver but fail causing the executors to crash. Here is the error message from the executor log:
Caused by: io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: data-loom-stats/10.135.131.239:9902
Caused by: java.net.ConnectException: Connection refused
The driver pod is exposed thru a headless Kubernetes service (per recommendations by Spark: https://spark.apache.org/docs/latest/running-on-kubernetes.html#client-mode-networking). The service exposes the driver with the DNS name data-loom-stats. Based upon the error message the DNS resolution appears to be working since it is correctly translating it to the pod IP address 10.135.131.239. To see what is happening on the driver end I opened a shell in the running driver container and was able to netstat the listening ports:
[root#data-loom-stats-7496b69994-9t8zs work-dir]# netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:4040 0.0.0.0:* LISTEN 673/java
tcp 0 0 127.0.0.1:40077 0.0.0.0:* LISTEN 673/java
tcp 0 0 127.0.0.1:9902 0.0.0.0:* LISTEN 673/java
tcp 0 0 0.0.0.0:41267 0.0.0.0:* LISTEN 673/java
As you can see port 9902 is bound to the loopback IP address. Port 4040 is the Spark UI and it is bound to 0.0.0.0. Since the executor pods are not stable I did some testing from another pod that is. I was able to curl port 4040:
/merida/src # curl -v http://10.135.131.239:4040
* Trying 10.135.131.239:4040...
* TCP_NODELAY set
* Connected to 10.135.131.239 (10.135.131.239) port 4040 (#0)
> GET / HTTP/1.1
> Host: 10.135.131.239:4040
> User-Agent: curl/7.67.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Date: Fri, 29 May 2020 22:50:46 GMT
< Location: http://10.135.131.239:4040/jobs/
< Content-Length: 0
< Server: Jetty(9.3.z-SNAPSHOT)
<
* Connection #0 to host 10.135.131.239 left intact
But trying to connect to port 9902 gives the connection refused error, just like the driver log.
/merida/src # curl -v http://10.135.131.239:9902
* Trying 10.135.131.239:9902...
* TCP_NODELAY set
* connect to 10.135.131.239 port 9902 failed: Connection refused
* Failed to connect to 10.135.131.239 port 9902: Connection refused
* Closing connection 0
curl: (7) Failed to connect to 10.135.131.239 port 9902: Connection refused
So it appears that my address/port binding needs to be fixed. Is this conclusion correct? If so is this something I can fix in the k8s manifest, or is it caused by something in the spark configuration?
I can supply more to help to identify a root cause.
Hi all I have successfully installed Oracle 11g Express addition on a Linux VM (google cloud compute)
I have sqlplus working and I can query data.
The listener is also working.
But as there is no GUI with Linux servers I cannot try local host and external machines have the connection refused.
My Questions are:
1) Does Apex come pre-installed on Oracle XE it used to but not mentioned anywhere.
2) if the ip address of the server is 123.123.123 what url would I use to get to apex from a remote machine? I have tried
http://123.123.123:8080/apex/
http://123.123.123/apex/
https://123.123.123:8080/apex/
3) How can I tell if it is the server or Oracle refusing the connection?
Firewall
$ netstat -ant
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
tcp 0 0 10.128.0.3:50776 169.254.169.254:80 ESTABLISHED
tcp 0 0 10.128.0.3:43548 10.128.0.3:1521 ESTABLISHED
tcp 0 0 10.128.0.3:50722 169.254.169.254:80 CLOSE_WAIT
tcp 0 0 10.128.0.3:50814 169.254.169.254:80 ESTABLISHED
tcp 0 0 10.128.0.3:50774 169.254.169.254:80 ESTABLISHED
tcp 0 64 10.128.0.3:22 74.125.41.105:38312 ESTABLISHED
tcp6 0 0 :::40070 :::* LISTEN
tcp6 0 0 :::8080 :::* LISTEN
tcp6 0 0 :::1521 :::* LISTEN
tcp6 0 0 :::22 :::* LISTEN
tcp6 0 0 ::1:25 :::* LISTEN
tcp6 0 0 10.128.0.3:1521 10.128.0.3:43548 ESTABLISHED
Listener
$ lsnrctl status
LSNRCTL for Linux: Version 11.2.0.2.0 - Production on 22-AUG-2017 02:59:51
Copyright (c) 1991, 2011, Oracle. All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC_FOR_XE)))
STATUS of the LISTENER
------------------------
Alias LISTENER
Version TNSLSNR for Linux: Version 11.2.0.2.0 - Production
Start Date 22-AUG-2017 02:00:17
Uptime 0 days 0 hr. 59 min. 33 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Default Service XE
Listener Parameter File /u01/app/oracle/product/11.2.0/xe/network/admin/listener.ora
Listener Log File /u01/app/oracle/diag/tnslsnr/centossmallblockpro/listener/alert/log.xml
Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC_FOR_XE)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=centossmallblockpro.c.sincere-destiny-176110.internal)(PORT=1521)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=centossmallblockpro.c.sincere-destiny-176110.internal)(PORT=8080))(Presentation=HTTP)(Session=RAW))
Services Summary...
Service "PLSExtProc" has 1 instance(s).
Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
Service "XE" has 1 instance(s).
Instance "XE", status READY, has 1 handler(s) for this service...
Service "XEXDB" has 1 instance(s).
Instance "XE", status READY, has 1 handler(s) for this service...
The command completed successfully
SQLPLUS working
sqlplus
SQL*Plus: Release 11.2.0.2.0 Production on Tue Aug 22 03:03:51 2017
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Enter user-name: system
Enter password:
Connected to:
Oracle Database 11g Express Edition Release 11.2.0.2.0 - 64bit Production
SQL> select * from dual;
D
-
X
.
Telnet XX.XXX.XXX.XX 8080
Telnet: Unable to connect to remote host: Connection timed out
1) Oracle XE (11g) comes with APEX version 3.2 I think. This is a very old APEX release. Follow the instructions how to drop this old version and get the latest from otn.oracle.com. Latest version should also work with 11g XE.
2) Tunnel
You can create a ssh-tunnel from your desktop machine to the end-point server where your services are running. Now you can access services on remote machine from your desktop environment aka. sqlplus, SQL Developer, Firefox, etc..
# Access Your Database Remotely Through an SSH Tunnel
# ssh -L [local port]:[database host]:[remote port] [username]#[remote host]
# console 1: 9998 is just an arbitrary port > 1024. Can be anything.
ssh -N -L 9998:10.128.0.3:1521 -i ~/.ssh/id_rsa user#35.184.136.98
# console 2:
sqlplus user/pwd#localhost:9998/XE
# firefox:
http://localhost:9998/apex
Great answers to 1 and 2 from Bjarte but the actual problem was not the Linux firewall but the Compute engine firewall.
I didn't know it even existed, when you select the check box to open Http it created a rule to TCP:80 but I needed TCP:8080.
Here is the article that solved it for me cant open port on google compute engine ...
The remote Linux computer is in an internal network and has no public IP address. So I installed ngrok.
ngrok tcp 22
ngrok by #inconshreveable (Ctrl+C to quit)
Tunnel Status online
Version 2.0.19/2.0.17
Web Interface http://127.0.0.1:4040
Forwarding tcp://0.tcp.ngrok.io:36428 ->
localhost:22
Connections ttl opn rt1 rt5 p50 p90
0 0 0.00 0.00 0.00 0.00
I checked that sshd is running.
At the local PC, I tried
ssh myuser#ngrok.com -p36428
which gave rise to
ssh: connect to host ngrok.com port 36428: Connection refused
You are connecting to the wrong destination address. The command should be
ssh myuser#0.tcp.ngrok.io -p36428
Notice the different hostname (ie 0.tcp.ngrok.io instead of ngrok.com).
And generally you would want to put the user#hostname after all the options (eg -p36428), even though it doesn't generally cause any issues.
I'm developing a Qt application and experience rather weird network issue.
Let me show how it looks from end-user perspective.
First I start up my server and verify that it's listening on a target port:
[user#host server]$ sudo netstat -anp | grep 30004
tcp 0 0 0.0.0.0:30004 0.0.0.0:* LISTEN 11113/./server
Then I connect to the server with telnet:
[user#host server]$ telnet localhost 30004
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.
Netstat displays that connection is now established. Nothing fancy so far:
[user#host server]$ sudo netstat -anp | grep 30004
tcp 0 0 0.0.0.0:30004 0.0.0.0:* LISTEN 11113/./server
tcp 0 0 127.0.0.1:30004 127.0.0.1:34608 ESTABLISHED 11113/./server
tcp 0 0 127.0.0.1:34608 127.0.0.1:30004 ESTABLISHED 12657/telnet
Then the server drops the connection based on application-specific timeout. It is set to 10 seconds at the moment:
[user#host server]$ sudo netstat -anp | grep 30004
tcp 0 0 0.0.0.0:30004 0.0.0.0:* LISTEN 11113/./server
tcp 0 0 127.0.0.1:30004 127.0.0.1:34608 TIME_WAIT -
I then shut down the server and verify that the listenning socket is destroyed:
[user#host server]$ sudo netstat -anp | grep 30004
tcp 0 0 127.0.0.1:30004 127.0.0.1:34608 TIME_WAIT -
Finally I start up the server again, but the listening port doesn't show up anymore:
[user#host server]$ sudo netstat -anp | grep 30004
tcp 0 0 127.0.0.1:30004 127.0.0.1:34608 TIME_WAIT -
As a result client cannot connect to the server:
[user#host server]$ telnet localhost 30004
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
What am I doing wrong here? I'm inclined to think that this is a configuration issue, not a bug in the application.
This scenario seems to work on my laptop's Ubuntu. The aforementioned output was produced on linux box as well.
UPDATE: One more thing that is different in these two environemnt is qt version. On my notebook I have 4.8.6, on linux box it's 4.6.2. Not sure if it matters.
Apparently there was an issue with versions of qt libraries. We upgraded it to latest 4.x.x and now the problem seems to be resolved.