3

I have two CentOS 7 boxes, called Turbo and Demo. I started a daemon/service on the first one, Turbo, and wish to call the service from the second one, Demo. I started the service to monitor port 8081. Another daemon uses port 8080, so I thought to use the next port, 8081.

Neither box has the firewall daemon, FirewallD, running.

I added an entry to the iptables and restarted the system. Here is the contents of the file.

# Generated by iptables-save v1.4.21 on Tue Nov 10 13:00:36 2015
*filter
:INPUT ACCEPT [900:143014]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [781:136535]
-A INPUT -p tcp -m state --state NEW -m tcp --dport 8081 -m comment --comment "DataMover Service Port" -j ACCEPT
COMMIT
# Completed on Tue Nov 10 13:00:36 2015

Here is the expected result when trying to open the port using the Firewall (disabled).

[root@Turbo Downloads]# firewall-cmd --permanent --add-port=8081/tcp
FirewallD is not running

The curl command that I used is:

[hts@jmr-server2 raid1]$ curl -H "Accept: application/xml" "http://192.168.20.88:8081/base/TestService/sayHello"

I did a Google search and most results indicate editing iptables or opening the port on the firewall.

I looked at this site, which states common port numbers for CentOS.

It states the following for the two ports:

8080  webcache  World Wide Web (WWW) caching service  
8081  tproxy  Transparent Proxy  

Per request, here is the result of iptables -L.

[root@Turbo Downloads]# service iptables restart
Redirecting to /bin/systemctl restart  iptables.service
[root@Turbo Downloads]# iptables -L
Chain INPUT (policy ACCEPT)
    target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             anywhere             state NEW tcp dpt:tproxy /* TestService Service Port */

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
[root@Turbo Downloads]# 

Here is the questions:

[root@Turbo Downloads]# netstat -nap|grep 8081
tcp6       0      0 127.0.0.1:8081          :::*                    LISTEN      7272/java           
[root@Turbo Downloads]# 

I am doing testing using local host, but wanted to take the next step and go to a different machine. Here is a localhost result:

[root@Turbo Downloads]# curl -H "Accept: application/xml" "http://localhost:8081/base/TestService/getHello"
<?xml version="1.0" encoding="UTF-8"?>
<note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>

I started the service from a terminal window. I am not to the point, where I am loading the service automatically.

Is curl access from one server to the other only possible on port 8080 and not using a different port or is there some other problem?

  • Try typing iptables -L and adding the result to the question. – Tom Hunt Nov 10 '15 at 23:40
  • @TomHunt question updated. – Sarah Weinberger Nov 10 '15 at 23:45
  • Did the service start successfully? Please check if the process is running and check with netstat if the port is listening (netstat -nap|grep 8081 should return a line that says "LISTENING", please add that to your question. If that is successful test the curl on the first system (the one running the process) first with localhost then with the server's name or IP. – Bram Nov 11 '15 at 0:22
  • @Bram I updated the question with the answers to your query. – Sarah Weinberger Nov 11 '15 at 0:38
  • That is interesting! I just tried using curl on Turbo using the actual IP rather than localhost and I receive the same message, connection refused. – Sarah Weinberger Nov 11 '15 at 0:41
3

This is the problem -- your netstat output shows the service listening on localhost instead of an externally-accessible IP:

127.0.0.1:8081

Edit the service to listen on an (or 'any') IP and restart it.

  • Or usually easiest (often the default) listen on the 'wildcard' address 0.0.0.0 for IPv4 or ::0 for IPv6. – dave_thompson_085 Nov 11 '15 at 1:28
  • Sorry, good catch -- meant to say 'any' instead of 'all' -- will edit. – Jeff Schaller Nov 11 '15 at 1:30
  • The service did indeed have localhost as the URI, not the IP address. Thanks for the 0.0.0.0 tip! – Sarah Weinberger Nov 11 '15 at 17:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.