After installing Spree Commerce and running these commands, I am unable to access my domain http://example.com:4000/ or http://example.com:4000/admin. When I run:
curl example.com:4000 I got: curl: (7) Failed to connect to example.com port 4000 after 27 ms: Connection refused.
What is the reason I cannot access Spree Commerce on port 4:000 after fresh install and how can I correct this?
There is no point for accessing - http://example.com:4000. As per the spree documentation, you should use http://localhost:4000 for accessing the spree application.
For Backend
For APIs
Hope this helps.
Firewall could be the principal problem. Have you tried checking opened ports?
List the current Iptables rules
sudo iptables -L
Add an Iptable rule (for example to open a Mysql port 3306)
sudo iptables -A INPUT -p tcp --dport 3306 -j ACCEPT
Remove an Iptable rule
sudo iptables -D INPUT -p tcp --dport xxxx -j ACCEPT
Related
I have setup an environment in Jelastic including a load balancer (tested both Apache and Nginx with same results), with public IP and an application server running Univention UCS DC Master docker image (I have also tried a simple Ubuntu 20.04 install).
Now the application server has a private IP address and is correctly reachable from the internet, also I can correctly SSH into both, load balancer and app server.
The one thing I can't seem to achieve is to have the app server access the internet (outbound traffic).
I have tried setting up the network in the app server and tried a few Nginx load-balancing configurations but to be honest I've never used a load balancer before and I feel that configuring load balancing will not resolve my issue (might be wrong).
Of course my intention is to learn load balancing but if someone could just point me in the right direction I would be so grateful.
Question: what needs to be configured in Jelastic or in the servers to have the machines behind the load balancer access the internet?
Thank you for your time.
Cristiano
I was able to resolve the issue by simply detaching and re-attaching the public IP address to the server, so it was no setup problem just something in Jelastic got stuck..
Thanks all!
Edit: Actually to effectively resolve the issue, I have to detach the public IP address from the univention/ucs docker image, attach it to another node in the environment (ie an Ubuntu server I have), then attach the public IP back to the univention docker image. Can’t really figure why but works for me.
To have the machines access the internet you should add a route in them using your load balancer as a gw like this:
Destination GW Genmask
0.0.0.0 LB #IP 255.255.255.0
Your VMs firewalls should not block 80 and 443 ports for in/out traffic, using iptables :
sudo iptables -A INPUT -p tcp -m multiport --dports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT -p tcp -m multiport --dports 80,443 -m conntrack --ctstate ESTABLISHED -j ACCEPT
In your load balancer you should masquerade outgoing traffic (change source ip) and forward input traffic to your vms subnet using the LB interface connected to this subnet:
sudo iptables --table NAT -A POSTROUTING --out-interface eth0 -j MASQUERADE
sudo iptables -A FORWARD -p tcp -dport 80 -i eth0 -o eth1 -j ACCEPT
sudo iptables -A FORWARD -p tcp -dport 443 -i eth0 -o eth1 -j ACCEPT
You should enable ip forwarding in your load balancer
echo 1 > /proc/sys/net/ipv4/ip_forward
I have an issue in regards to my iptables setup. My goal is to reach the https based webserver inside a docker container from the server machine itself.
The setup is the following:
The server is connected to the internet via eth0 and serves http via port 443.
Any users from the outside (internet) reach the server via the ip address 1.2.3.4.
It is connected to the internal network via eth1 and serves dhcp, dns and some more services.
Any users from the inside (intranet) reach the server via the ip address 10.0.0.1.
The docker container is connected via docker1 on the server. The later has the ip address 10.8.0.2 inside the docker network.
The docker container serves the webserver on port 1443, but iptables forwards (NAT) requests on port 443 to its address 10.8.0.1 and the destination port 1443.
What is working:
The webserver is perfectly reachable from the internet and the intranet.
The webserver can be reached from the server itself using the address 10.8.0.1:1443.
What is not working:
Any client which is working directly on the server can not reach the docker webserver using https://example.com:443. Using https://10.8.0.1:8443 would work, but fails due to a certificate error. It is not a goal to skip the certificate check as a workaround.
Excerpt of the iptable configuration:
iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT
iptables -P FORWARD DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i docker1 -o docker1 -j ACCEPT
iptables -A PREROUTING -t nat -p tcp -d 1.2.3.4 --dport 443 -j DNAT --to-destination 10.1.0.1:1443
iptables -A FORWARD -o docker1 -p tcp --dport 1443 -j ACCEPT
iptables -A INPUT -i docker1 -j DROP
iptables -A FORWARD -i docker1 -j DROP
Due to that "complicated" setup I am no longer able to understand which of the iptable rules and chains need to be applied to make this work so I am seeking for your help to solve that issue.
Brainstorming about the issue using a simplified model and my understanding of the iptable chains the way of the packages might/should look like this:
Origin is a local application (wget).
The packages go through the OUTPUT table.
The packages go through the POSTROUTING table.
Magic happens...
The packages arrive again in the PREROUTING table.
The packages might go trough INPUT again.
The packages might arrive at the target application (webserver).
I can't get logspout to connect to papertrail. I get the following error:
!! lookup logs5.papertrailapp.com on 127.0.0.11:53: read udp 127.0.0.1:46185->127.0.0.11:53: i/o timeout
where 46185 changes every time I run the container. It seems like a DNS error, but nslookup logs5.papertrailapp.com gives the expected output, as does docker run busybox nslookup logs5.papertrailapp.com.
Beyond that, I don't even know how to interpret that error message, let alone address it. Any help debugging this would be hugely appreciated.
My Docker Compose file:
version: '2'
services:
logspout:
image: gliderlabs/logspout
command: "syslog://logs5.papertrailapp.com:12345"
volumes:
- /var/run/docker.sock:/var/run/docker.sock
sleep:
image: benwhitehead/env-loop
Where 12345 is the actual papertrail port. Result is the same whether using syslog:// or syslog-tls://.
From https://docs.docker.com/engine/userguide/networking/configure-dns/:
the docker daemon implements an embedded DNS server which provides built-in service discovery for any container
It looks like your container is unable to connect to this DNS server. If your container is on the default bridge network, it won't reach the embedded DNS server. You can either set --dns to be an outside source or update /etc/resolv.conf. It doesn't sound like a Papertrail issue, at all.
(source)
Docker and iptables got in a fight. So I spun up a new machine, failed to set up iptables, and the problem was solved: no firewall at all to get in the way of Docker's connections!
Just kidding, don't do that. I got a toy database hacked that way.
Fortunately, it's now relatively easy to get iptables and Docker to live in harmony, using the DOCKER_USER iptables chain.
The solution, excerpted from my blog:
Configure Docker with iptables=true, and append to iptables configuration:
iptables -A DOCKER-USER -i eth0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A DOCKER-USER -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT
iptables -A DOCKER-USER -i eth0 -p tcp -m tcp --dport 443 -j ACCEPT
iptables -A DOCKER-USER -i eth0 -j DROP
I'm tried to start minecraft server on not custom port (25565 for example) with command:
java -jar craftbukkit.jar
but had an exception java.net.BindException:
Loading libraries, please wait...
[12:24:27 INFO]: Starting minecraft server version 1.7.2
[12:24:27 WARN]: To start the server with more ram, launch it as "java -Xmx1024M -Xms1024M -jar minecraft_server.jar"
[12:24:27 INFO]: Loading properties
[12:24:27 INFO]: Default game type: SURVIVAL
[12:24:27 INFO]: Generating keypair
[12:24:28 INFO]: Starting Minecraft server on 52.25.177.236:25565
[12:24:28 WARN]: **** FAILED TO BIND TO PORT!
[12:24:28 WARN]: The exception was: java.net.BindException: Cannot assign requested address
[12:24:28 WARN]: Perhaps a server is already running on that port?
After that I tried to stop all processes on this port with command:
fuser -k 25565/tcp
fuser -k 25565/tcp
but it didn't help too.
After that I tried to enable this port in iptables with commands:
iptables -A INPUT -p tcp --dport 25565 -j ACCEPT
iptables -A FORWARD -p tcp --dport 25565 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 25565 -j ACCEPT
but it didn't help too.
Then I seen ifconfig and noticed that indet addr because it is not public ip, with whitch I work through ssh, it is hidden ip of internal network in amazon.
eth0
Link encap:Ethernet HWaddr 02:89:4f:57:67:9d
inet addr:172.31.29.204 Bcast:172.31.31.255 Mask:255.255.240.0
This ip I can set when I create new hosting in amazon. But I can't choose public ip when I do it.
Can someone exlain what is this hidden ip address and can be trouble with I start minecraft server on public ip but eth0 interface show me only hidden internal?
Thank you :)
It could be that someone on the same machine is using port 25565. I would recommend contacting amazon and resolving it with them
I have been unable to install Ruby on Rails gems on my computer. Here is what I typed and the responses I received.
C:\Users\029607\Documents\NDAC Tech Studies\TES3>gem install bundler --source "http://rubygems.org"
This is the response:
Successfully installed bundler-1.5.3
WARNING: Unable to pull data from 'https://rubygems.org/': SSL_connect SYSCALL
returned=5 errno=0 state=SSLv2/v3 read server hello A (https://api.rubygems.org/
latest_specs.4.8.gz)
1 gem installed
C:\Users\029607\Documents\NDAC Tech Studies\TES3>bundle install
Fetching source index from https://rubygems.org/
Retrying source fetch due to error (2/3): Bundler::HTTPError Could not fetch specs from https://rubygems.org/
Retrying source fetch due to error (3/3): Bundler::HTTPError Could not fetch specs from https://rubygems.org/
Could not fetch specs from https://rubygems.org/
This seems to be an issue with Ruby and your TLS handshake. Try defining a certificate here.
Here are other possible solutions.
You need to get more information: bundle install --verbose
I was getting the same error and when I did bundle install verbose it became clearer. In my case ..
Gem::RemoteFetcher::FetchError: Errno::ETIMEDOUT: Connection timed out
- connect(2) for "s3.amazonaws.com" port 443 (https://rubygems.org/specs.4.8.gz)
It indicated that there was firewall issues (you need to allow firewall access to rubygems.org and s3.amazonaws.com on port 443).
I was doing nslookup rubygems.org getting the ip address and using it in whois ip address and using the CIDR addresses (54.240.0.0/12 etc) to allow access to the ruby gems through the firewall. My Iptables for Rubygems looked like this along with permitting established traffic. (You could equally have a policy of permit on outbound traffic and you wouldn't need complicated firewall tables ;-) )
-A service -d 54.240.0.0/12 -o eth0 -p tcp -m tcp --dport 443 -j ACCEPT
-A service -d 205.251.192.0/18 -o eth0 -p tcp -m tcp --dport 443 -j ACCEPT
-A service -d 54.216.0.0/14 -o eth0 -p tcp -m tcp --dport 443 -j ACCEPT
-A service -d 54.220.0.0/15 -o eth0 -p tcp -m tcp --dport 443 -j ACCEPT
-A service -d 54.208.0.0/13 -o eth0 -p tcp -m tcp --dport 443 -j ACCEPT
Rich