I'm trying to get a Yaws web server working on a cloud service (Amazon AWS). I've compilled and installed a local copy on the server. My problem is that I can't get Yaws to run while running on either port 8000 or port 80.
I have the following configuration in yaws.conf:
port = 8000
listen = 0.0.0.0
docroot = /home/ubuntu/yaws/www/test
dir_listings = true
This produces the following successful launch/result:
Eshell V5.8.5 (abort with ^G)
=INFO REPORT==== 16-Sep-2012::17:21:06 ===
Yaws: Using config file /home/ubuntu/yaws.conf
=INFO REPORT==== 16-Sep-2012::17:21:06 ===
Ctlfile : /home/ubuntu/.yaws/yaws/default/CTL
=INFO REPORT==== 16-Sep-2012::17:21:06 ===
Yaws: Listening to 0.0.0.0:8000 for <3> virtual servers:
- http://domU-12-31-39-0B-1A-F6:8000 under /home/ubuntu/yaws/www/trial
-
=INFO REPORT==== 16-Sep-2012::17:21:06 ===
Yaws: Listening to 0.0.0.0:4443 for <1> virtual servers:
-
When I try to access the the url (http://ec2-72-44-47-235.compute-1.amazonaws.com), it never connects. I've tried using paping to check if port 80 or 8000 is open(http://code.google.com/p/paping/) and I get a "Host can not be resolved" error, so obviously something isn't working.
I've also tried setting the yaws.conf so its at Port 80, appearing like this:
port = 8000
listen = 0.0.0.0
docroot = /home/ubuntu/yaws/www/test
dir_listings = true
and I get the following error:
=ERROR REPORT==== 16-Sep-2012::17:24:47 ===
Yaws: Failed to listen 0.0.0.0:80 : {error,eacces}
=ERROR REPORT==== 16-Sep-2012::17:24:47 ===
Can't listen to socket: {error,eacces}
=ERROR REPORT==== 16-Sep-2012::17:24:47 ===
Top proc died, terminate gserv
=ERROR REPORT==== 16-Sep-2012::17:24:47 ===
Top proc died, terminate gserv
=INFO REPORT==== 16-Sep-2012::17:24:47 ===
application: yaws
exited: {shutdown,{yaws_app,start,[normal,[]]}}
type: permanent
{"Kernel pid terminated",application_controller,"
{application_start_failure,yaws,>>>>>>{shutdown,>{yaws_app,start,[normal,[]]}}}"}
I've also opened up the port 80 using iptables. Running sudo iptables -L gives this output:
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- ip-192-168-2-0.ec2.internal ip-192-168-2-16.ec2.internal tcp dpt:http
ACCEPT tcp -- 0.0.0.0 anywhere tcp dpt:http
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT tcp -- anywhere anywhere tcp dpt:http
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Thanks for the patience
Actually, I found the answer to why I couldn't get it to work, through this forum post (http://www.trapexit.org/forum/viewtopic.php?p=42923).
It states:
2a. I run yaws on 8080 and have nginx reverse proxying
from http://mydomain:80 to 8080. Yaws won't run as a
low-privilege user if you want it to listen on port
80.
2b. nginx.conf needs the following directives:
server {
listen 80;
server_name yourdomain.com;
access_log /path/to/access/log.log
location / {
proxy_pass http://127.0.0.1:8080;
proxy_redirect default;
}
}
Basically, I installed nginx, and configured it to run as a proxy server.
I have used the same solution in order to get a Chicago Boss framework to run, the only difference is that I have nginx proxy_pass set to >http://127.0.0:8001 since Chicago Boss runs on 8001 by default. Anyone know how this effects an erlang servers concurrency advantages if someone is using nginx as a proxy server, or it has no effect what so ever?
One of the error reports you've pasted shows the reason why you cannot start the server on port 80: permissions ({error, eaccess}).
=ERROR REPORT==== 16-Sep-2012::17:24:47
=== Yaws: Failed to listen 0.0.0.0:80 : {error,eacces}
Regarding the launch on port 8000, did you try to SSH to the machine and connect to the server locally (e.g. via telnet)? If that works, your problem must be, as others suggested, related to either the Ubuntu firewall not having port 8000 open or the Security Group for your EC2 instance not containing a route which allows inbound traffic on that port.
Said that, this question should probably be moved to ServerFault or AskUbuntu.
There are two things to look for:
check your security group settings for your instance and make sure that the port 80 or 8000 is open (accessible from 0.0.0.0/32).
try binding your server to the internal IP address of the machine. Some servers need to listen to this interface instead of 0.0.0.0. You can find out your internal IP either in the console or with ifconfig
Its worth noting that the interactive command line requires root permissions:
sudo su
yaws -i --id whatever
You must also specify an ID if the yaws daemon is running at the same time.
http://hyber.org/privbind.yaws
binding to privileged ports
A common misfeature found on UN*X operating systems is the restriction that only root can bind to ports below 1024. Many a dollar has been wasted on workarounds and -often- the results are security holes.
$ setcap 'cap_net_bind_service=+ep' /usr/lib/erlang/erts-5.7.4/bin/beam
#Bernard is correct that the EC2 instance has a firewall protecting it. You need to modify the EC2 Security Group (You can find it on the left hand side in the management console web interface) for the instance to allow inbound TCP traffic to the port you want to use. For port 80 you can select HTTP from the combo box. For port 8080, select Custom TCP Rule and type in the port number.
Related
For testing purpose, I want to install Collabora online on a Jelastic environment.
I'm trying to follow this basic steps : https://www.collaboraoffice.com/code/quick-tryout-nextcloud-docker/
First I configure the topology with the docker image given in the link.
Next cloud is installed successfully after I went to the given URL.
Then I add the variable extra_params=--o:ssl.enable=false as said in the instructions :
Then I try to map port by adding a Endpoint:
It map the port 9980 with the public port 11010.
So Finaly, I install the collabora app on nextCloud and configure the Collabora server url on the dedicated Collabora settings page:
jelastic-node-ndd.com:11010
And I got this message when trying to open an Open office document :
Failed to load Collabora Online - please try again later
I don't know how to investigate. When I try to reach the Collabora server on my brother with the given port, I got a connection fails error.
We think the main reason of the issue is the fact that port mapping doesn't work in your case.
In other words, telnet $(hostname) 11010 says "connection refused" inside container since mapping works correct only from the Internet.
This can be easily overcome by adding of External IP. So, in the settings of "Collabora online" you have to specify URL http://EXT.IP:9980 and remove mapping.
Another way is a mapping trick. In this case, you can left only internal IP and make mapping as you did.
Then, edit mapping and specify Private Port equal to Public Port
Further, inside container add NAT rule, like:
iptables -t nat -A DOCKER ! -i docker0 -p tcp -m tcp --dport 11010 -j DNAT --to-destination 172.21.0.2:9980
Where, 11010 - is your mapping port. 172.21.0.2 - IP you get while performing iptables -L DOCKER -vnt nat
Thus, DOCKER chain should look like this:
root#node210795-nextcloud-test:~# iptables -L DOCKER -vnt nat
Chain DOCKER (2 references)
pkts bytes target prot opt in out source destination
19 1140 RETURN all -- docker0 * 0.0.0.0/0 0.0.0.0/0
106 6360 DNAT tcp -- !docker0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:9980 to:172.21.0.2:9980
55 3300 DNAT tcp -- !docker0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:11031 to:172.21.0.2:9980
As a result, Collabora online URL in your case can be left as jelastic-node-ndd.com:11010
Besides this, you can face the issue described here
We were able to fix this issue using the article Setting up and configuring collabora/code Docker image (Use the configuration file directly). Before coping loolwsd.xml back to docker (step 3) you might need to chmod this file:
chmod 666 loolwsd.xml
Note:
It's better to specify additional parameter --restart always in step 5 of Quick tryout with Nextcloud docker
Variable DOCKER_EXPOSE_PORT should be left intact (80)
extra_params=--o:ssl.enable=false is a variable of collabora/code, so no needs to specify it in Variables
I've configured my server to run with the following flags:
Server--> Server Types --> WebSphere application servers --> Additional Properties --> Debugging Service:
JVM Debug Arguments= -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8888
JVM Port= 8888
I configured eclipse debug configuration with the server ip (verified that ip is reachable with the ping command) and port
To be sure i increased the debugger timeout as well .
I've got: Failed to connect to remote VM. Connection refused.
Connection refused: connect
so i did a port scan on the server with (nmap xxx.xxx.xxx.xxx -p 8888) and the port seems:
PORT STATE SERVICE
8888/tcp closed sun-answerbook
moreover looking at the section Server--> Server Types --> WebSphere application servers --> Communications-->Ports of WebSphere admin consolle
i don't see the port 8888 in the list.
what do i need to do?
open the port on the machine? (how?)
add the port in the list of the above mentioned section?
other?
###### EDITED ########
ADDITIONAL CHECKS
netstat -na | grep 8888 --->no listening port/doesn't show me nothing
----------------------------------------------------------------------------
[root#dmgr ~]# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
----------------------------------------------------------------------------
C:\Users\alex>nmap 192.168.115.235 -p 8888
Starting Nmap 7.60 ( https://nmap.org ) at 2018-02-23 10:58 ora solare Europa occidentale
Nmap scan report for xxxx.xxxxxxxxxxxx.com (192.168.115.235)
Host is up (0.0018s latency).
PORT STATE SERVICE
7777/tcp closed cbt
Nmap done: 1 IP address (1 host up) scanned in 4.59 seconds
so, no listening port on 8888, no iptables rules that deny the connection, how to investigate further?
You are almost there :-)
On the Debugging Service page where you set the port and arguments, there is a checkbox - Enable service at server startup - ensure that it is checked.
If not, check, and restart the server.
After that you should see the debugging port open. You can check it for example via netstat -an.
If the port is open and you still cannot connect then it is probably the firewall issue.
Here some more details about setting the debug - Starting the application server in debug mode
I have an EC2 instance which is running with the following security groups:
HTTP - TCP - 80 - 0.0.0.0/0
Custom UDP Rule - UDP - 1194 - 0.0.0.0/0
SSH - TCP - 22 - 0.0.0.0/0
Custom TCP Rule - TCP - 943 - 0.0.0.0/0
HTTPS - TCP - 443 - 0.0.0.0/0
However, when I try to access http://{PUBLIC_IP} or https://{PUBLIC_IP} in the browser, I get a "{IP} refused to connect" error. I'm new to AWS. Am I missing something here? What should I do to debug?
One way to debug this particular class of problem is to use netcat in order to determine where the problem lies.
If you run netcat against port 80 on the public IP address of your instance and just get a hang (no output at all), then most likely your security group isn't allowing traffic through. Here is an example from an EC2 instance that is in a security group that doesn't allow port 80 traffic inbound:
% nc -v 55.35.300.45 80
<just hangs>
Whereas if the security group is changed to allow port 80, but the EC2 instance doesn't have any process listening on port 80, you'll get the following:
% nc -v 55.35.300.45 80
nc: connectx to 52.38.300.43 port 80 (tcp) failed: Connection refused
Given that your browser gave you a similar "connection refused", most likely the problem is that there is no web server running on your instance. You can verify this by ssh'ing into the instance and seeing if you can connect to port 80 there:
ssh ec2-user#55.35.300.45
% nc -v localhost 80
nc: connect to localhost port 80 (tcp) failed: Connection refused
If you get something like the above, you're definitely not running a webserver.
I'm not sure if it's too late to help but I was stuck with a similar issue with my test server
SG Inbound: ssh -> 22
HTTP -> 80
NACL: default allow/deny settings
but still couldn't ping to the server from my browser, then I realize there's nothing running on the server that can serve the request, and I started httpd server (webserver) and it worked.
sudo yum -y install httpd
sudo service httpd start
this way you can test the connectivity if you are playing with SGs and NACLs and of course it's not the only way, just an example if you're figuring your System N/W out.
Have you installed webserver(ngingx/apache) to serve your requests. If so please share your the config files. (So that it will help to troubleshoot)
I think the reason is probably that you did not set up a web server for your EC2 instance, because if you try to access http://{PUBLIC_IP} or https://{PUBLIC_IP}, you need to have a background server to serve the http request as #Niranj Rajasekaran said.
By the way, by simply pinging the {PUBLIC_IP}, you could see if your connection to your EC2 instance is normal or not.
In command prompt or terminal, type
ping {PUBLIC_IP}
In my case, the server was running but available on just 127.0.0.1 so it refused connections from external hosts. To see if this is your situation, you can run
netstat -an | grep <port number>
If it says 127.0.0.1:<port number> instead of 0.0.0.0:<port number>, you have this problem.
Usually there's a flag or an argument in your server code somewhere to set the host to 0.0.0.0:
app.run(host='0.0.0.0') # flask example
However, in my case, I had already set this so I thought that couldn't possibly be the issue, which is how I ended up on this thread, which asks more generally about the problem. Unfortunately, I was using docker, and had set 0.0.0.0 on the container but was mapping that explicitly to 127.0.0.1 on the host in the docker-compose port-mapping:
ports:
- "127.0.0.1:<port number>:<port number>"
Changing that line to remove the host IP specification fixed the problem upon re-deploy:
ports:
- "<port number>:<port number>"
I have my Single node Hadoop installed on Google Compute Engine instance and i want to open port 50070 on that machine to access the hadoop dashboard. i configured in the firewall rule as tcp:50070 in compute engine networks. but still i am unable to access my port outside the network (ie . via internet). I tried nmap for the public ip of my GCE instance and i got a result which has only ssh port got opened all other ports are filtered .
Note: i am using debian 7.5 image
Make sure your daemon is listening on port 50070. If you have more than one networks in you project make sure the port is opened on the right network. You can run the following commands to check the information about your instance and network.
lsof -i
gcutil --project= getinstance
gcutil --project= listnetworks
gcutil --project= listfirewalls
gcutil --project= getfirewall
Check if IP/Port is allowed in iptables or not.
iptables -L
would show you all the records.
To allow port in iptables you can do the following:
sudo iptables -A INPUT -p tcp -m tcp --dport 50070 -j ACCEPT
sudo iptables-save -c
Short answer
In addition to configure the firewall rule at GCE web console make sure that your server is listening at 0.0.0.0 instead of 127.0.0.1
Long answer
In the context of servers, 0.0.0.0 means all IPv4 addresses on the local machine. If a host has two IP addresses, 192.168.1.1 and 10.1.2.1, and a server running on the host listens on 0.0.0.0, it will be reachable at both of those IPs - Source
In contrast 127.0.0.1 is the IP address used to stablish a connection to the same machine used by the user this address is usually referred as the localhost.
It's often used when you want a network-capable application to only serve clients on the same host. A process that is listening on 127.0.0.1 for connections will only receive local connections on that socket. - Source
Hence, if you try to stablish a connection to your server from internet and your server is listening at 127.0.0.1 at your GCE machine, then, from the server point of view a request has never been received and as a consequence Goocle Cloud Firewall will refuse the connection because there is no server listening at the opened port (in your case 50070).
I hope this answer helps to solve your problem. Best regards.
This is a very basic Amazon EC2 question, but I'm stumped so here goes.
I want to launch an Amazon EC2 instance and allow access to HTTP on ports 80 and 8888
from anywhere. So far I can't even allow the instance to connect to on those ports using
its own IP address (but it will connect to localhost).
I configured the "default" security group for HTTP using the standard HTTP option on the management console (and also SSH).
I launched my instance in the default security group.
I connected to the instance on SSH port 22 twice and in one window launch an HTTP server
on port 80. In the other window I verify that I can connect to HTTP using the "localhost".
However when I try to access HTTP from the instance (or anywhere else) using either the public DNS or the Private IP address I het "connection refused".
What am I doing wrong, please?
Below is a console fragment showing the wget that succeeds and the two that fail run from the instance itself.
--2012-03-07 15:43:31-- http://localhost/
Resolving localhost... 127.0.0.1
Connecting to localhost|127.0.0.1|:80... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: /__whiff_directory_listing__ [following]
--2012-03-07 15:43:31-- http://localhost/__whiff_directory_listing__
Connecting to localhost|127.0.0.1|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: “__whiff_directory_listing__”
[ <=>
] 7,512 --.-K/s in 0.03s
2012-03-07 15:43:31 (263 KB/s) - “__whiff_directory_listing__” saved [7512]
[ec2-user#ip-10-195-205-30 tmp]$ wget http://ec2-50-17-2-174.compute-1.amazonaws.com/
--2012-03-07 15:44:17-- http://ec2-50-17-2-174.compute-1.amazonaws.com/
Resolving ec2-50-17-2-174.compute-1.amazonaws.com... 10.195.205.30
Connecting to ec2-50-17-2-174.compute-1.amazonaws.com|10.195.205.30|:80... failed:
Connection refused.
[ec2-user#ip-10-195-205-30 tmp]$ wget http://10.195.205.30/
--2012-03-07 15:46:08-- http://10.195.205.30/
Connecting to 10.195.205.30:80... failed: Connection refused.
[ec2-user#ip-10-195-205-30 tmp]$
The standard tcp sockets interface requires that you bind to a particular IP address when you send or listen. There are a couple of somewhat special addresses: localhost (which you're probably familiar with) which is 127.0.0.1. There's also a special address, 0.0.0.0 or INADDR_ANY (internet protocol, special shorthand for ANY ADDRESS). It's a way to listen on ANY or more commonly, ALL addresses on the host. This is a way to tell the kernel/stack that you're not interested in a particular IP address.
So, when you're setting up a server that listens to "localhost" you're telling the service that you want to use the special reserved address that can only be reached by users of this host, and while it exists on every host, making a connection to localhost will only ever reach the host you're making the request from.
When you want a service to be reachable everywhere (on a local host, on all interfaces, etc.) you can specify 0.0.0.0.
(0) It's silly but the first thing you need to do is to make sure that your web server is running.
(1) You need to edit your Security Group to let incoming HTTP packets access your website. If your website is listening on port 80, you need to edit the Security Group to open access to port 80 as mentioned above. If your website is listening on some other port, then you need to edit the Security Group to access that other port.
(2) If you are running a Linux instance, the iptables firewall may be running by default. You can check that this firewall is active by running
sudo service iptables status
on the command line. If you get output, then the iptables firewall is running. If you get a message "Firewall not running", that's pretty self-explanatory. In general, the iptables firewall is running by default.
You have two options: knock out the firewall or edit the firewall's configuration to let HTTP traffic through. I opted to knock out the firewall as the simpler option (for me).
sudo service iptables stop
There is no real security risk in shutting down iptables because iptables, if active, merely duplicates the functionality of Amazon's firewall, which is using the Security Group to generate its configuration file. We are assuming here that Amazon AWS doesn't misconfigure its firewalls - a very safe assumption.
(3) Now, you can access the URL from your browser.
(4) The Microsoft Windows Servers also run their personal firewalls by default and you'll need to fix the Windows Server's personal firewall, too.
Correction: by AWS default, AWS does not fire up server firewalls such iptables (Centos) or UAF (Ubuntu) when you are ordering the creation of new EC2 instances - That's why EC2 instances that are in the same VPC can ssh into each other and you can "see" the web server that you fired up from another EC2 instance in the same VPC.
Just make sure that your RESTful API is listening on all interfaces i.e. 0.0.0.0:portID
As you are getting connection refused (packets are being rejected) I bet it is iptables causing the problem. Try to run
iptables -I INPUT -p tcp --dport 80 -j ACCEPT
iptables -I INPUT -p tcp --dport 8888 -j ACCEPT
and test the connection.
You will also need to add those rules permanently which you can do by adding the above lines into ie. /etc/sysconfig/iptables if you are running Red Hat.
Apparently I was "binding to localhost" whereas I needed to bind to 0.0.0.0 to respond to port 80 for the all incoming TCP interfaces (?). This is a subtlety of TCP/IP that I don't fully understand yet, but it fixed the problem.
Had to do the following:
1) Enable HTTP access on the instance config, it wasn't on by default only SSH
2) Tried to do nodejs server, so port was bound to 80 -> 3000 did the following commands to fix that
iptables -F
iptables -I INPUT -p tcp --dport 80 -j ACCEPT
sudo service iptables-persistent flush
Amazon support answered it and it worked instantly:
I replicated the issue on my end on a test Ubuntu instance and was able to solve it. The issue was that in order to run Tomcat on a port below 1024 in Ubuntu/Unix, the service needs root privileges which is generally not recommended as running a process on port 80 with root privileges is an unnecessary security risk.
What we recommend is to use a port redirection via iptables :-
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
I hope the above information helps.