[ 
https://issues.apache.org/jira/browse/BROOKLYN-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16024477#comment-16024477
 ] 

ASF GitHub Bot commented on BROOKLYN-477:
-----------------------------------------

Github user drigodwin commented on a diff in the pull request:

    https://github.com/apache/brooklyn-docs/pull/192#discussion_r118455694
  
    --- Diff: guide/locations/provisioned-machine-requirements.md ---
    @@ -0,0 +1,161 @@
    +---
    +title: Provisioned Machine Requirements
    +layout: website-normal
    +---
    +
    +The requirements for how a provisioned machine should behave will depend 
on the
    +entites subsequently deployed there.
    +
    +Below are a set of common assumptions, made by many entity 
implementations, which
    +could cause subsequent errors if they do not hold. These relate to the 
machine's 
    +configuration, rather than additional networking or security that a given 
Cloud 
    +might offer.
    +
    +Also see the [Troubleshooting]({{ site.path.guide }}/ops/troubleshooting/) 
docs.
    +
    +
    +## Remote Access
    +
    +### SSH or WinRM Access
    +
    +Many entities require ssh'ing (or using WinRM for Windows), to install and 
configure 
    +the software.
    +
    +An example of disabling all ssh'ing is shown below:
    +
    +    location:
    +      aws-ec2:us-east-1:
    +        identity: XXXXXXXX
    +        credential: XXXXXXXX
    +        waitForSshable: false
    +        pollForFirstReachableAddress: false
    +    services:
    +    - type: org.apache.brooklyn.entity.software.base.EmptySoftwareProcess
    +      brooklyn.config:
    +        onbox.base.dir.skipResolution: true
    +        sshMonitoring.enabled: false
    +
    +
    +### Parsing SSH stdout: No Extra Lines
    +
    +For entities that execute ssh commands, these sometimes parse the 
resulting stdout.
    +
    +It is strongly recommended that VMs are configured so that no additional 
stdout is written when executing 
    +remote ssh (or WinRM) commands. Such stdout risks interfering with the 
response parsing in some blueprints.
    +
    +For example, if configuring the VM to write out "Last login" information, 
this should be done for only 
    +"interactive" shells (see 
[Stackoverflow](http://stackoverflow.com/a/415444/1393883) for more details).
    +
    +
    +### Passwordless Sudo
    +
    +Does passwordless sudo work?
    +
    +Try executing:
    +
    +    sudo whoami
    +
    +See [Passwordless Sudo]({{ site.path.guide 
}}/locations/index.html#passwordless-sudo).
    +
    +
    +## Advertised Addresses
    +
    +### Hostname Resolves Locally
    +
    +Does the hostname known at the box resolve at the box?
    +
    +Try executing:
    +
    +    ping $(hostname)
    +
    +if not, consider setting `generate.hostname: true` in the location config, 
for jclouds-based locations.
    +
    +
    +### IP Resolves Locally
    +
    +For the IP address advertised in Brooklyn using the sensor 
`host.addresses.private` (or `host.subnet.address`), 
    +can the machine reach that IP?
    +
    +Get the sensor value, and then try executing:
    +
    +    ping ${PRIVATE_IP}
    --- End diff --
    
    You should indicate that these commands should be run on the target machine 
and It wont work locally.


> Add docs for target machine requirements/expectations
> -----------------------------------------------------
>
>                 Key: BROOKLYN-477
>                 URL: https://issues.apache.org/jira/browse/BROOKLYN-477
>             Project: Brooklyn
>          Issue Type: Improvement
>            Reporter: Aled Sage
>            Priority: Minor
>
> We should improve our docs for the machine requirements/expectations, for 
> blueprints to behave as expected.
> This became evident when investigating 
> https://issues.apache.org/jira/browse/BROOKLYN-475 (extra stdout when 
> ssh'ing). For example, our docs could say:
> {noformat}
> It is strongly recommended that VMs are configured so that no additional 
> stdout is written 
> when executing remote ssh (or WinRM) commands. Such stdout risks interfering 
> with the
> response parsing in some blueprints.
> For example, if configuring the VM to write out "Last login" information, 
> this should be 
> done for only "interactive" shells (see 
> http://stackoverflow.com/a/415444/1393883 for more 
> details).
> {noformat}
> There are no doubt many other things we could mention, such as:
> * {{/tmp/}} should be writable
> * Sufficient entropy (e.g. see 
> https://brooklyn.apache.org/v/latest/ops/troubleshooting/increase-entropy.html
>  for setting up Brooklyn itself)
> * Outbound network connectivity (but not all blueprints require that)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to