I am running node server running react application.server is run by webpack. Server is running on 10.121.45.23:3005. I tried opening the application on other machine but page displays connection timed out. I have tried following things to resolve the issue, but nothing helped.
ping 10.121.45.23 from another machine. It is successful.
On server, netstat -ano. I am able to see 10.121.45.23:3005 listening. No loopback address was there as mentioned in many answers on Stack Overflow.
On another machine,telnet 10.121.45.23 3005. It fails and say cannot connect on port 3005. Telnet to some other port on which java is running, is successful. It fails only for node.js server.
So my problems are:
telnet is not working to that port.
Not able to open application on other machine's browser.
Am I missing any checks?
Sounds like you've tested quiet a bit. Have you tried another port, just in case there's a firewall or something?
Also, try explicitly telling webpack to listen on the all-hosts address 0.0.0.0
webpack-dev-server --port 9000 --host 0.0.0.0
I have NRPE daemon process running under xinetd on amazon ec2 instance and nagios server on my local machine.
The check_nrpe -H [amazon public IP] gives this error:
CHECK_NRPE: Error - Could not complete SSL handshake.
Both Nrpe are same versions. Both are compiled with this option:
./configure --with-ssl=/usr/bin/openssl --with-ssl-lib=/usr/lib/i386-linux-gnu/
"allowed host" entry contains my local IP address.
What could be the possible reason of this error now??
If you are running nrpe as a service, make sure you have this line in your nrpe.cfg on the client side:
# example 192. IP, yours will probably differ
allowed_hosts=127.0.0.1,192.168.1.100
You say that is done, however, if you are running nrpe under xinetd, make sure to edit the only_from directive in the file /etc/xinetd.d/nrpe.
Don't forget to restart the xinetd service:
service xinetd restart
To check if you have access to it at all attempt a simple telnet on the address:port, a ping or traceroute to see where it is blocking.
telnet IP port
ping IP
traceroute -p $port IP
Also check on the target server that the nrpe daemon is working properly.
netstat -at | grep nrpe
You also need to check the versions of OpenSSL installed on both servers, as I have seen this break checks on occasion with the SSL handshake!
check your /var/sys/system.log . In my case, it turned out my monitored IP was set to something else than the one I set in nrpe.cfg file. I don't know the cause of this change, though.
#jgritty was right.
you should edit nrpe.cfg and nrpe config files to allow your master nagios server's access:
vim /usr/local/nagios/etc/nrpe.cf
allowed_hosts=127.0.0.1,172.16.16.150
and
vim /etc/xinetd.d/nrpe
only_from= 127.0.0.1 172.16.16.150
That's somewhat of a catch-all error message for NRPE. Check your firewall rules and make sure that port is open. Also try disabling SELinux and seeing if that lets the connection through. It's likely not an SSL issue, but just an issue with the connection being refused.
It looks like you are running your Nagios server in a virtual machine on a host-only network. If this is so, this would stop any external access. Ensure that you have a NAT or Bridged Network available.
So many answers, none of them hit the reason why I ran into this issue.
It turns out that nagios has terrible cross-version support and this was caused by me having a version 2 "client" (machine being monitored) and a version 3 "server" (monitoring machine).
Once I upgraded the client to version 3, the problem went away and I could do a check_nrpe -H [client IP] without issues.
Note that I am not sure if client/server are the right terms with nagios, as in the case of an NRPE call, the server is really the machine being called, but I digress.
Make sure that you have restarted the Nagios Client Plugin as well.
I'm running nrpe using the xinetd service.
Make sure also (in addition to the above basic steps) that your nagios user is authenticating properly. In my case:
Jun 6 15:05:52 gse2 xinetd[33237]: **Unknown user: nagios**<br>[file=/etc/xinetd.d/nrpe] [line=9]
Jun 6 15:05:52 gse2 xinetd[33237]: Error parsing attribute user - DISABLING
SERVICE [file=/etc/xinetd.d/nrpe] [line=9]
Jun 6 15:05:52 gse2 xinetd[33237]: **Unknown group: nagios**<br>[file=/etc/xinetd.d/nrpe] [line=10]
Jun 6 15:05:52 gse2 xinetd[33237]: Error parsing attribute group - DISABLING
SERVICE [file=/etc/xinetd.d/nrpe] [line=10]
Jun 6 15:05:52 gse2 xinetd[33237]: Service nrpe missing attribute user - DISABLING
Was showing in the /var/log messages.
It escaped me at first, but then I did a check on ypbind service and found it was not started.
After starting ypbind, nagios user and group was authenticating properly, the error went away.
some edge cases restarting nagios-nrpe-server doesn't help, due to the fact that process was not killed or it was not properly restarted.
just kill it manually then, and start.
SSL handshake error msg.Beside the allow_host you should assign.
your nagios server is in a local lan with C type ip address such as 192.168.xxxx
when the target monitored server feedback the ssl msg to your local nagios server,the message should first comes to your public IP of your line,the message cannot across the public IP into your nagios server which ip is an internal one.
you need NAT to guide the SSL message from target server to inner nagios server.
Or you better use "GET" method which just get monitor message from the nagios client side,such as SNMP to fulfill the remote monitor of local resource of linux servers.
SSL need feedback in double direction.
Best Regards
For me setting the following in /etc/nagios/nrpe.cfg on Client worked:
dont_blame_nrpe=1
It's and ubuntu 16.04 machine.
For other possible problems, I recommend looking at nrpe logs. Here is good article for configuring logs.
If you are running Debian 9 then there is a known issue regarding this problem, caused by OpenSSL dropping support for the method NRPE uses to initiate anonymous SSL connections.
The issue seems to be fixed but the fix hasn't made it into the official packages, yet.
Currently there seems to be no secure work-around.
check configuration in /etc/xinetd.d/nrpe and verify the server IP. If it is showing only_from = 127.0.0.1 change it with Server IP .
I'm fairly sure that this is a bug in node v0.10.18, but it has created a pollution on my machine which I don't know how to clear.
I have this simple tcp server (coffee) script:
net = require 'net'
server = net.createServer ->
server.listen 'localhost:4545'
when I run it using coffee z.coffee and then press Ctrl+C to interrupt it, I am unable to run it again on the same port due to EADDRINUSE exception. The process repeats on different ports with the same results.
I am aware of other answers about a similar issue, but they aren't able to solve mine because even restarting the machine (osx ml) still leaves the port blocked. Obviously, ps -A | grep node shows nothing as well.
What can I do to free up the stuck ports again?
Edit
Here is an abstract of the comments below. It seems that node uses SO_REUSEADDR be default, so TIME_WAIT should not be the issue, especially since the ports have been stuck for over an hour. Neither netstat nor lsof as root show anything using the ports, and neither multiple reboots, nor killing all but essential programs helped the issue resolve. There is no VPN or firewall.
https://github.com/joyent/node/blob/3d4c663ee68326990e0732a4aa76445688e1064e/lib/net.js#L1159
You are passing invalid arguments to server.listen. It is interpreting your string as a unix domain socket filesystem path.
This program works fine and can be killed and restarted immediately.
net = require "net"
server = net.createServer ->
console.log "connection"
server.listen 1337, "127.0.0.1"
Pass correct arguments to server.listen and all is well.
I am new to linux and just deployed a java program to run on a linux server. I tried to connect from my windows machine to the linux box with jconsole and got an error.
Connection Failed: non-JRMP server at remote endpoint
I searched online and found the following suggestion was to run the following:
java -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=
[YOUR PORT] -Dcom.sun.management.jmxremote.ssl=
false -Dcom.sun.management.jmxremote.authenticate=false -jar [YOUR JAR NAME]
I entered the following into a batch file and executed it. I then tried to connect using jconsole using the follow command
service:jmx:rmi:///jndi/rmi://ipaddress:port/jmxrmi
as suggested but still cannot (Connection failed: retry)/
I got the same issue but the reason was different, I was hitting http port instead of JMX port.
The error message appeared same as in your case but later I figured out it was port issue.
Since JMX process runs on different port so be careful while opening JConsole on remote server.
Resolved situation by setting hostname to ipaddress when calling process on linux
I faced this problem at localhost.
Wrong port was used.
So, I changed my JMX port to be different from application port in my run configuration and yet, the port changes did not take effect until the application container was restarted.
Fixing above resolved my issue.
Another possible reason for error message Connection failed: non-JRMPserver at remote endpoint: the RootCA-certificate of the server hasn't been added into the client's cacerts file.
I'm setting up my web server on Amazon's EC2. My site used to run locally and used my ISP's SMTP server to send email, which hasn't been a problem before - but now that the emails are originating from outside my ISP won't accept them.
Therefore, I'm trying the advice here to use EmailRelay to forward emails, adding authentication, via my account on Google.
I've followed the instructions, created the emailrelay.auth file, run the configure, make, make install, but when I try to start the emailrelay service I'm getting this error:
$ emailrelay --as-proxy smtp.gmail.com:587 --client-tls --client-auth /etc/emailrelay.auth
emailrelay: error: cannot bind the listening port: 0.0.0.0:25
emailrelay: exception: cannot bind the listening port: 0.0.0.0:25
I've looked through the user guide, tried using the --interface option thinking this might be the issue - providing various IPs, with no joy - and I don't know what to try next.
(my server is running Oracle Enterprise Linux 5.1)
EDIT:
Since sendmail is running on port 25, I've tried an alternative port. Now I get a new error:
$ emailrelay --as-proxy smtp.gmail.com:587 --client-tls --client-auth /etc/emailrelay.auth --port 8025
emailrelay: error: cannot do tls/ssl: openssl not built in
emailrelay: exception: cannot do tls/ssl: openssl not built in
After killing sendmail, I've retried with port 25 and I get the same error ("cannot do tls/ssl: openssl not built in").
EDIT:
Looks like openssl is not installed:
$ grep ssl config.log
$ ./configure --with-openssl
configure:7373: checking for openssl
conftest.cpp:31:25: error: openssl/ssl.h: No such file or directory
| #include <openssl/ssl.h>
configure:7431: WARNING: ignoring --with-openssl, check config.log and try setting CFLAGS
config.status:719: creating src/gssl/Makefile
The error means that it can't gain exclusive access to port 25 (the default port for SMTP). This is either because it is already in use, or because, as an unprivileged user, you don't have access to ports numbered less than 1024.
There may already be a program running on port 25. Probably sendmail, but possibly postfix or qmail (I don't know what Oracle uses for mail). You will need to shut any such program down.
If you shut down any email software on the computer and run emailrelay as root, you will probably not get that error message.
I got to this question having the same issue on an EC2 instance running Ubuntu.
For Ubuntu:
first sudo apt-get install libssl-dev
then (re-)run ./configure && make && sudo make install
Now either using :25 if clear, or feeding another port to emailrelay --port 12345 it works as expected.