A "4-server Scalr" server stack in aws is only available by accessing it's private IP - 172.*.*.* , unavailable by it's public IP. Anything went wrong?

[Brant Fortest]

Hi, Team,

I just set up a "4-server Scalr" server stack in aws, but it is only available by accessing it's private IP - 172.*.*.* , unavailable by it's public IP. 

Anything went wrong?

You can have a try on https://54.222.154.149

Looking forward to hearing from you asap. Thanks! 

And here's the content of scalr-server.rb file.

------------------

root@ip-172-31-5-21:/etc/scalr-server# cat scalr-server.rb 

########################################################################################

# IMPORTANT: This is NOT a substitute for documentation. Make sure that you understand #

# the configuration parameters you use in your configuration file.                     #

########################################################################################

# Disable all services by default

enable_all false

##########################

# Topology Configuration #

##########################

# You can use IPs for the below as well, but hostnames are preferable.

app_server_host = '54.222.154.149'  # This MUST be reachable by your instances.

main_mysql_server_host = '54.222.215.202'

ca_mysql_server_host = '54.222.215.202'

# Server IPs. Those MUST be IPs, not hostnames.

app_server_ip = '54.222.154.149'

worker_server_ip = '54.222.154.88'

####################

# External Routing #

####################

proto = 'https'  # Set up the SSL settings and this to 'https' to use HTTPS

endpoint = app_server_host

routing[:endpoint_scheme] = proto

routing[:endpoint_host] = endpoint

####################

# Internal Routing #

####################

# Use separate hosts for MySQL

app[:mysql_scalr_host] = main_mysql_server_host

app[:mysql_scalr_port] = 3306

app[:mysql_analytics_host] = ca_mysql_server_host

app[:mysql_analytics_port] = 3306

# Use Memcached locally (it's running on the same servers as the app servers)

app[:memcached_servers] = ['127.0.0.1:11211']

# Look for the app and graphics locally as well

proxy[:app_upstreams] = ['127.0.0.1:6000']

proxy[:graphics_upstreams] = ['127.0.0.1:6100']

proxy[:plotter_upstreams]  = ['127.0.0.1:6200']

proxy[:ssl_enable] = true

proxy[:ssl_redirect] = true

proxy[:ssl_cert_path] = "/etc/ssl/certs/server.pem"

proxy[:ssl_key_path] = "/etc/ssl/private/server.key"

# Bind the proxy publicly

proxy[:bind_host] = '0.0.0.0'

# But bind everything else locally, since it'll go through the proxy

web[:app_bind_host] = '127.0.0.1'

web[:app_bind_port] = 6000

web[:graphics_bind_host] = '127.0.0.1'

web[:graphics_bind_port] = 6100

service[:plotter_bind_host] = '127.0.0.1'

service[:plotter_bind_port] = 6200

# Bind MySQL publicly, because it'll need to be accessed by the app & worker

mysql[:bind_host] = '0.0.0.0'

mysql[:bind_port] = 3306

# The app and Memcached are running on the same server, so bind locally

memcached[:bind_host] = '127.0.0.1'

memcached[:bind_port] = 11211

#####################

# App configuration #

#####################

app[:ip_ranges] = ["#{app_server_ip}/32", "#{worker_server_ip}/32",]

app[:instances_connection_policy] = 'public' # 'local' or 'public'

app[:configuration] = {}  # Add extra configuration here

------------------

[Marc O'Brien]

Hi Brant,

Telnet to port 80 and 443 on host 54.222.154.149 fails.  You may need to open your security group firewall rules to allow HTTP(s) traffic on this public interface.

Many thanks,
Wm. Marc O'Brien
Scalr Technical Support

[Brant Fortest]

Hi, Marc,

Thanks for your quick reply.

I did open both 80/443.

Telnet 54.222.154.149 80/443 isn't working here for me as well. But on 172 is fine.

Any other tips? Thanks!

Brant

On Saturday, June 25, 2016 at 12:26:23 AM UTC+8, Marc O'Brien wrote:

Hi Brant,

Telnet to port 80 on host 54.222.154.149 fails.  You may need to open your security group firewall rules to allow HTTP traffic on this public interface.

[Marc O'Brien]

Hi Brant,

If you are having the same behavior it is likely that there is either a networking problem or an app server service config problem.  As a first step you may want to verify what services are listening on what ports on this app server with netstat.

Many thanks,
Wm. Marc O'Brien
Scalr Technical Support

[Marc O'Brien]

Hi Brant,

It also looks like you may have the following configuration value commented out:  app[:ip_ranges] = ["#{app_server_ip}/32", "#{worker_server_ip}/32",]

Many thanks,
Wm. Marc O'Brien
Scalr Technical Support

[Brant Fortest]

Hi, Marc,

Port 80/43 are listening on IP 0.0.0.0. They should be right.

root@ip-172-31-5-21:~# netstat -anp

Active Internet connections (servers and established)

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      942/sshd        

tcp        0      0 127.0.0.1:6200          0.0.0.0:*               LISTEN      17229/python    

tcp        0      0 127.0.0.1:6010          0.0.0.0:*               LISTEN      1182/0          

tcp        0      0 127.0.0.1:6011          0.0.0.0:*               LISTEN      20587/1         

tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      17361/httpd     

tcp        0      0 127.0.0.1:11211         0.0.0.0:*               LISTEN      1582/memcached  

tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      17361/httpd     

tcp        0      0 127.0.0.1:6000          0.0.0.0:*               LISTEN      17361/httpd     

tcp        0      0 127.0.0.1:6100          0.0.0.0:*               LISTEN      17361/httpd     

tcp        1      0 127.0.0.1:56593         127.0.0.1:6000          CLOSE_WAIT  17364/httpd     

tcp        0      0 172.31.5.21:40868       54.222.215.202:3306     TIME_WAIT   -               

tcp        1      0 127.0.0.1:56589         127.0.0.1:6000          CLOSE_WAIT  17738/httpd     

tcp        1      0 127.0.0.1:56596         127.0.0.1:6000          CLOSE_WAIT  17363/httpd     

tcp        0      0 172.31.5.21:443         172.31.7.88:51012       TIME_WAIT   -               

tcp        1      0 127.0.0.1:56610         127.0.0.1:6000          CLOSE_WAIT  17730/httpd     

tcp        0      0 172.31.5.21:22          15.89.167.135:50896     ESTABLISHED 20512/sshd: ubuntu 

tcp        0      0 127.0.0.1:6000          127.0.0.1:56621         FIN_WAIT2   -               

tcp        0      0 127.0.0.1:11211         127.0.0.1:39774         TIME_WAIT   -               

tcp        1      0 127.0.0.1:56607         127.0.0.1:6000          CLOSE_WAIT  17731/httpd     

tcp        1      0 127.0.0.1:56603         127.0.0.1:6000          CLOSE_WAIT  17729/httpd     

tcp        1      0 127.0.0.1:56617         127.0.0.1:6000          CLOSE_WAIT  17366/httpd     

tcp        1      0 127.0.0.1:56600         127.0.0.1:6000          CLOSE_WAIT  17737/httpd     

tcp        0      0 172.31.5.21:22          15.89.167.135:49232     ESTABLISHED 1128/sshd: ubuntu [

tcp        1      0 127.0.0.1:56621         127.0.0.1:6000          CLOSE_WAIT  17736/httpd     

tcp        1      0 127.0.0.1:56614         127.0.0.1:6000          CLOSE_WAIT  17365/httpd     

tcp6       0      0 :::22                   :::*                    LISTEN      942/sshd        

tcp6       0      0 ::1:6010                :::*                    LISTEN      1182/0          

tcp6       0      0 ::1:6011                :::*                    LISTEN      20587/1         

udp        0      0 0.0.0.0:37493           0.0.0.0:*                           597/dhclient    

udp        0      0 127.0.0.1:11211         0.0.0.0:*                           1582/memcached  

udp        0      0 0.0.0.0:68              0.0.0.0:*                           597/dhclient    

udp6       0      0 :::49811                :::*                                597/dhclient   

-------------------------------------------

app_server_host = '54.222.154.149'

endpoint = app_server_host

Brant 

On Saturday, June 25, 2016 at 12:46:29 AM UTC+8, Marc O'Brien wrote:

Hi Brant,

If you are having the same behavior it is likely that there is either a networking problem or an app server service config problem.  As a first step you may want to verify what services are listening on what ports on this app server with netstat.  Also ensure that endpoint = app_server_host has the correct value.

[Brant Fortest]

In my condition,

"#{app_server_ip}/32" is '54.222.154.149'/32

"#{worker_server_ip}/32" is '54.222.154.88'/32

[Marc O'Brien]

Hi Brant,

I am able to telnet to port 22 on this IP but still not 80 or 443.  Perhaps there is a problem with your firewall config? A screenshot of the SG rule details may be useful:

Many thanks,
Wm. Marc O'Brien
Scalr Technical Support

On Friday, June 24, 2016 at 10:21:12 AM UTC-6, Brant Fortest wrote:

[Daniele Testa]

Please stop all scalr services with "scalr-server-manage stop all"

Then start a simple echo server. Something like this:

ncat -l 80 -k -c 'xargs -n1 echo'

Then try to telnet to port 80. If you still can't connect, you have a firewall issue.

--
You received this message because you are subscribed to the Google Groups "scalr-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scalr-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Regards,

Daniele Testa | Solutions Architect @ Scalr | dan...@scalr.com | www.scalr.com | blog.scalr.com

[Brant Fortest]

[Brant Fortest]

Seems fine to telnet 54.222.154.149 80. Please have a try. Thanks!

Brant

[Marc O'Brien]

Hi Brant,

Telnet still fails for me:

Many thanks,
Wm. Marc O'Brien
Scalr Technical Support

[Brant Fortest]

telnet from one US machine.

telnet from China.

Strange!

[Brant Fortest]

But if I change the cmd to "ncat -l 443 -k -c 'xargs -n1 echo'", test results changed.

from one US machine, got this.

from one China machine, got this.

I was wondering is this behavior related to AWS China restrictions that we cannot control?

Brant

[Marc O'Brien]

Hi Brant,

This very well may be related to AWS China restrictions as you have experienced issues related to this in the past.  You may want to bring this up with AWS China support for their insight.

Many thanks,
Wm. Marc O'Brien
Scalr Technical Support

[Brant Fortest]

Hi, Marc,

I just set up a temp Scalr stack(db/app/worker) for comparison in AWS Oregon region successfully!

Can you or your team members continue to dig more info out of this AWS China issue? Thanks!  I believe you'll have more and more requirements from customers located in China.

One more thing to your attention, the command "apt-get install -y scalr-server" could be quick or could be very slow, even for several hours, running in AWS China.

Looking forward to your good new!

Best Wishes!
Brant

[Brant Fortest]

Hi, Marc,

so this format should be app[:ip_ranges] = ["app_server_ip/32", "worker_server_ip/32",], right?

[Brant Fortest]

Why even I changed app config to these：

----

app[:ip_ranges] = ["x.x.x.x/32", "x.x.x.x/32",]

app[:instances_connection_policy] = 'public'  # Or 'public'

----

Still cannot get through establishing ssh connection, and I checked, these's no single IP assigned into Inbound white-list in Security Group of AWS, What did i miss here? Thanks! 

----

Jun 27, 2016 02:48:49

Scalr unable to establish SSH connection with server on Error: Unable to connect to SSH server on 52.41.116.229:22

Jun 27, 2016 02:47:49

Initializing SSH2 session to the server

----

[Igor Savchenko]

Hi Brant,

If security groups were already created with old ip_ranges, changing this in config won't update them. So, can you please open AWS console, and find security groups that were created by scalr and then check rules there. You can update rules manually or just remove all these security groups and let scalr re-create them with correct IP ranges.

Regards,

Igor

--