Here is the security group policy the role uses: TCP 22 - 22 10.1.100.26/32 UDP 8014 - 8014 10.1.100.26/32 TCP 8008 - 8013 10.1.100.26/32 TCP 3306 - 3306 10.1.100.26/32 OUTBOUND (3) TCP 80 - 80 10.1.100.26/32 ANY ANY 0.0.0.0/0 TCP 443 - 443 10.1.100.26/32
And the iptables of the pending machine is empty. 在 2016年3月18日星期五 UTC-7下午3:04:01，sqf写道： > > It's ubuntu 14.04 Trusty > hmmm...Is the proxy required for the case of Scalr runs in a single vpc? > in my case all the subnet ACLs and security groups are all open, and I > haven't found any statement on proxy setup for Scalr VPC use case from > Scalr wiki. > > 在 2016年3月18日星期五 UTC-7下午12:34:50，Daniele Testa写道： >> >> Not the complete "outside", just the cloud API. You can setup a proxy >> with outgoing access that the Scalarizr can use. >> >> The logs you posted shows Scalarizr going into a loop. What OS is running >> on this instance? Looks like it has issues with starting udev script. >> >> >> On Sat, Mar 19, 2016 at 2:20 AM, sqf <[email protected]> wrote: >> >>> Also, when go to troubleshooting wiki page( >>> https://scalr-wiki.atlassian.net/wiki/display/docs/Required+Network+Configuration+for+Scalr), >>> >>> found: >>> >>> The Scalr agent that is installed on your Servers needs access to the >>> APIs of the Cloud Platform the Server was launched in. >>> >>> Does it mean Scalarizr needs to talk to the outside? >>> >>> 在 2016年3月18日星期五 UTC-7上午10:42:02，sqf写道： >>> >>>> Hi Daniele, >>>> Thanks very much for feedback. >>>> Yes, I can run "curl 10.1.100.26" from the instance. >>>> As I said, I open all the traffic on all the ports for both inbound and >>>> outbound, I doubt it's the security group issue. >>>> The scalarizr is not running at all after I login to that instance... >>>> Here is content from the scalarizr_debug.log: >>>> >>>> 2016-03-18 17:26:57,628+00:00 - DEBUG - scalarizr.util - Wait 0.10 >>>> seconds before the next attempt >>>> >>>> 2016-03-18 17:26:57,628+00:00 - DEBUG - scalarizr.app - Open SQLite >>>> database (file: /etc/scalr/private.d/db.sqlite) >>>> >>>> 2016-03-18 17:26:58,051+00:00 - DEBUG - scalarizr.util - Wait 0.10 >>>> seconds before the next attempt >>>> >>>> 2016-03-18 17:26:58,151+00:00 - DEBUG - scalarizr.config - Bootstrap >>>> INI configuration (reload=False) >>>> >>>> 2016-03-18 17:26:58,151+00:00 - DEBUG - scalarizr.config - Loading main >>>> configuration >>>> >>>> 2016-03-18 17:26:58,152+00:00 - DEBUG - scalarizr.config - Reading >>>> configuration file /etc/scalr/public.d/config.ini >>>> >>>> 2016-03-18 17:26:58,152+00:00 - DEBUG - scalarizr.config - Reading >>>> configuration file /etc/scalr/private.d/config.ini >>>> >>>> 2016-03-18 17:26:58,153+00:00 - DEBUG - scalarizr.config - Loading >>>> platform configuration >>>> >>>> 2016-03-18 17:26:58,153+00:00 - DEBUG - scalarizr.config - Reading >>>> configuration file /etc/scalr/public.d/ec2.ini >>>> >>>> 2016-03-18 17:26:58,154+00:00 - DEBUG - scalarizr.config - Loading >>>> behaviours configuration >>>> >>>> 2016-03-18 17:26:58,154+00:00 - DEBUG - scalarizr.config - Loading >>>> handlers configuration >>>> >>>> 2016-03-18 17:26:58,154+00:00 - DEBUG - scalarizr.config - Reading >>>> configuration file /etc/scalr/public.d/ip_list_builder.ini >>>> >>>> 2016-03-18 17:26:58,231+00:00 - DEBUG - scalarizr.config - Reading >>>> configuration file /etc/scalr/public.d/script_executor.ini >>>> >>>> 2016-03-18 17:26:58,231+00:00 - DEBUG - scalarizr.config - Reading >>>> configuration file /etc/scalr/public.d/hooks.ini >>>> >>>> 2016-03-18 17:26:58,232+00:00 - DEBUG - scalarizr.app - Initialize >>>> script messaging >>>> >>>> 2016-03-18 17:26:58,233+00:00 - INFO - scalarizr.scripts.udev - >>>> Starting udev script... >>>> >>>> 2016-03-18 17:27:01,668+00:00 - DEBUG - scalarizr.util - Wait 0.10 >>>> seconds before the next attempt >>>> >>>> 2016-03-18 17:27:01,669+00:00 - DEBUG - scalarizr.app - Open SQLite >>>> database (file: /etc/scalr/private.d/db.sqlite) >>>> >>>> 2016-03-18 17:27:01,769+00:00 - DEBUG - scalarizr.config - Bootstrap >>>> INI configuration (reload=False) >>>> >>>> 2016-03-18 17:27:01,769+00:00 - DEBUG - scalarizr.config - Loading main >>>> configuration >>>> >>>> 2016-03-18 17:27:01,769+00:00 - DEBUG - scalarizr.config - Reading >>>> configuration file /etc/scalr/public.d/config.ini >>>> >>>> 2016-03-18 17:27:01,770+00:00 - DEBUG - scalarizr.config - Reading >>>> configuration file /etc/scalr/private.d/config.ini >>>> >>>> 2016-03-18 17:27:01,770+00:00 - DEBUG - scalarizr.config - Loading >>>> platform configuration >>>> >>>> 2016-03-18 17:27:01,770+00:00 - DEBUG - scalarizr.config - Reading >>>> configuration file /etc/scalr/public.d/ec2.ini >>>> >>>> 2016-03-18 17:27:01,771+00:00 - DEBUG - scalarizr.config - Loading >>>> behaviours configuration >>>> >>>> 2016-03-18 17:27:01,771+00:00 - DEBUG - scalarizr.config - Loading >>>> handlers configuration >>>> >>>> 2016-03-18 17:27:01,771+00:00 - DEBUG - scalarizr.config - Reading >>>> configuration file /etc/scalr/public.d/ip_list_builder.ini >>>> >>>> 2016-03-18 17:27:01,771+00:00 - DEBUG - scalarizr.config - Reading >>>> configuration file /etc/scalr/public.d/script_executor.ini >>>> >>>> 2016-03-18 17:27:01,771+00:00 - DEBUG - scalarizr.config - Reading >>>> configuration file /etc/scalr/public.d/hooks.ini >>>> >>>> 2016-03-18 17:27:01,772+00:00 - DEBUG - scalarizr.app - Initialize >>>> script messaging >>>> >>>> 2016-03-18 17:27:01,773+00:00 - INFO - scalarizr.scripts.udev - >>>> Starting udev script... >>>> >>>> >>>> >>>> BR >>>> >>>> 在 2016年3月18日星期五 UTC-7上午2:14:02，Daniele Testa写道： >>>>> >>>>> Hey! >>>>> >>>>> Based on the information provided, it seems that your instance cannot >>>>> "call home" to the Scalr server. The instances needs to be able to >>>>> contact >>>>> scalr on the IP set in routing[:endpoint_host] on port 88/443. >>>>> Please login to the instance that is stuck and check if you are able >>>>> to run something like "curl 10.1.100.26". Also check the Scalarizr log >>>>> found in /var/log on the instance. >>>>> >>>>> >>>>> On Friday, March 18, 2016 at 3:02:07 PM UTC+8, sqf wrote: >>>>>> >>>>>> Hi I have been trying to create a poc of using scalr to work with AWS >>>>>> vpc. >>>>>> for my case, the Scalr runs in the public subnet of a VPC, I followed >>>>>> the install instruction to install Scalr on a ec2 instance within public >>>>>> subnet of the VPC, and tried to spin up two instance in both public >>>>>> subnet( >>>>>> 10.1.100.0/24) and the private subnet("10.1.200.0/24"). I can see >>>>>> the two instances up and running from AWS console shortly, but from >>>>>> Scalr >>>>>> side, only the server in public subnet is showing "running" while server >>>>>> in >>>>>> the private subnet is showing "pending" on "Wait for OS to finish >>>>>> booting". both of my instances use the same base role and I enabled >>>>>> All Traffic for both inbound and outbound for the security groups. I am >>>>>> able to login to the pending machine, after check, it looks like >>>>>> Scalarizr >>>>>> is not running(netstat -tpln), but not sure why Scalarizr is not running: >>>>>> >>>>>> tcp 0 0 0.0.0.0:22 0.0.0.0:* >>>>>> LISTEN 936/sshd >>>>>> >>>>>> tcp 0 0 0.0.0.0:8008 0.0.0.0:* >>>>>> LISTEN 1153/python >>>>>> >>>>>> tcp6 0 0 :::22 :::* >>>>>> LISTEN 936/sshd >>>>>> >>>>>> >>>>>> The scalr version is 5.10.21 (Community Edition), >>>>>> I followed the wiki to configure Scalr: >>>>>> >>>>>> https://scalr-wiki.atlassian.net/wiki/display/docs/Using+VPC+-+Internal+Scalr+Deployment, >>>>>> >>>>>> as well as: >>>>>> >>>>>> https://scalr-wiki.atlassian.net/wiki/display/docs/Advanced+Configuration >>>>>> >>>>>> here is my configurations: >>>>>> >>>>>> >>>>>> # Enable all components (single server install) >>>>>> >>>>>> enable_all true >>>>>> >>>>>> >>>>>> # Scalr web UI URL >>>>>> >>>>>> routing[:endpoint_host] = "10.1.100.26" >>>>>> >>>>>> >>>>>> # Following IPs will be whitelisted on Scalr controlled instances >>>>>> >>>>>> app[:instances_connection_policy] = 'local' >>>>>> >>>>>> >>>>>> app[:configuration] = { >>>>>> >>>>>> "scalr" => { >>>>>> >>>>>> "aws" => { >>>>>> >>>>>> "ip_pool" => ["10.1.200.0/24","10.1.100.0/24"] >>>>>> >>>>>> } >>>>>> >>>>>> } >>>>>> >>>>>> } >>>>>> >>>>>> I have been testing the use case for more than two days...any >>>>>> comments will be appreciated! >>>>>> >>>>>> >>>>>> -- >>> 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 [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Regards, >> Daniele Testa | Solutions Engineer @ Scalr | [email protected] | >> www.scalr.com | blog.scalr.com >> > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
