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.

Reply via email to