[
https://issues.apache.org/jira/browse/BROOKLYN-601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16613609#comment-16613609
]
Richard Downer commented on BROOKLYN-601:
-----------------------------------------
Possible workarounds:
* User to generate SSH keys for the brooklyn system user
* User to configure alternative SSH keys in their location/blueprint
Possible fixes:
* If Brooklyn does not have any credentials, fail fast, instead of spending 10
minutes repeatedly trying to log in
* Have the RPM postinstall script generate SSH keys for the system user
> Provisioning very long when using RPM package
> ---------------------------------------------
>
> Key: BROOKLYN-601
> URL: https://issues.apache.org/jira/browse/BROOKLYN-601
> Project: Brooklyn
> Issue Type: Bug
> Affects Versions: 1.0.0
> Environment: AWS Linux (RPM-based) but would presumably affect *any*
> environment which does not have SSH keys ready-to-use.
> Reporter: Richard Downer
> Priority: Major
>
> System is an AWS Linux box (RPM-based) using the
> apache-brooklyn-1.0.0-M1-rc1_1.noarch.rpm package.
> Deployments using this system take a very long time to provision instances
> (tested on AWS).
> On examining the debug log, I can see it is search for the {{brooklyn}}
> system user's SSH key files:
> Since this newly-created system user doesn't have any SSH key files, it ends
> up trying to log in to the instance with no credentials:
> {{2018-09-13T14:12:38,734 - DEBUG 133 o.a.b.l.j.JcloudsLocation
> [nager-DV7OEufF-4] Credentials extracted for
> {id=eu-west-1/i-05bd13b5ba7ff1f69, providerId=i-05bd13b5ba7ff1f69,
> name=brooklyn-pezzf5-applicationaijwo-aijw-server-lant-dvr8, location=}}
> {{{scope=ZONE, id=eu-west-1b, description=eu-west-1b, parent=eu-west-1,
> iso3166Codes=[IE]}}}{{,
> group=brooklyn-pezzf5-applicationaijwo-aijw-server-lant,
> imageId=eu-west-1/ami-0eb66a0c3eb9f5183, os=}}{{{family=ubuntu, arch=hvm,
> version=16.04,
> description=aws-marketplace/ubuntu/images/hvm-ssd/ubuntu-xenial-16.04-amd64-server-20180814-d83d0782-cb94-46d7-8993-f4ce15d1a484-ami-04169656fea786776.4,
> is64Bit=true}}}{{, status=RUNNING[running], loginPort=22,
> hostname=ip-172-31-41-218, privateAddresses=[172.31.41.218],
> publicAddresses=[52.214.254.195], hardware={id=t2.small, providerId=t2.small,
> processors=[}}{{{cores=1.0, speed=0.2}}}{{], ram=2048,
> volumes=[}}{{{id=vol-01112c6e3486ac4d0, type=SAN, device=/dev/sda1,
> bootDevice=true, durable=true}}}{{], hypervisor=xen,
> supportsImage=Predicates.and(requiresRootDeviceType(ebs),requiresVirtualizationType(hvm),Predicates.alwaysTrue(),Predicates.alwaysTrue())},
> loginUser=brooklyn,
> userMetadata=\{Name=brooklyn-pezzf5-applicationaijwo-aijw-server-lant-dvr8,
> brooklyn-user=brooklyn, brooklyn-app-id=aijwo81iay,
> brooklyn-app-name=Application (aijwo81iay), brooklyn-entity-id=lant5abn8y,
> brooklyn-entity-name=Server, brooklyn-server-creation-date=2018-09-13-1411}}:
> brooklyn/brooklyn with
> OsCredential[no-public-key;no-private-key,no-password]/[user=brooklyn,
> passwordPresent=true, privateKeyPresent=false, shouldAuthenticateSudo=false]}}
> {{ 2018-09-13T14:12:38,756 - DEBUG 133 o.a.b.l.j.JcloudsLocation
> [nager-DV7OEufF-4] VM
> aws-ec2:eu-west-1@EmptySoftwareProcessImpl}}{{{id=lant5abn8y}}}{{: reported
> online, now waiting 5m for it to be contactable on
> [email protected]:22; trying 1 credential: user=brooklyn,
> password=******, key=<absent>}}
> {{ 2018-09-13T14:12:38,759 - DEBUG 128 o.a.b.SSH [nager-DV7OEufF-4]
> check-connectivity, initiating ssh on machine SshMachineLocation[AWS
> Dublin:[email protected]/52.214.254.195:22(id=jd41hctb1o)]: #!/bin/bash
> -e}}
> {{ ; true}}
> {{ 2018-09-13T14:12:38,769 - DEBUG 128 o.a.b.l.s.SshMachineLocation
> [nager-DV7OEufF-4] Create-unmanaged for SshMachineLocation[AWS
> Dublin:[email protected]/52.214.254.195:22(id=jd41hctb1o)]; no explicit
> cleanup task; ssh-pool cache will only be closed when machine is closed}}
> {{ 2018-09-13T14:12:38,770 - DEBUG 128 o.a.b.l.s.SshMachineLocation
> [nager-DV7OEufF-4]
> org.apache.brooklyn.location.ssh.SshMachineLocation$4@7c8aa530 building ssh
> pool for 52.214.254.195:22 with properties:}}{{{connectTimeout=30000,
> sshTries=1, sessionTimeout=30000,
> sshTriesTimeout=30000}}}{{2018-09-13T14:12:38,863 - DEBUG 128
> o.a.b.u.c.i.s.s.SshjTool [nager-DV7OEufF-4] << ([email protected]:22)
> error acquiring}}{{{hostAndPort=52.214.254.195:22, user=brooklyn,
> ssh=1626499876, password=xxxxxx, privateKeyFile=null, privateKey=null,
> connectTimeout=30000, sessionTimeout=30000}}}{{(attempt 1/1, in time
> 84ms/30s) (rethrowing, out of retries): Exhausted available authentication
> methods}}
> {{ 2018-09-13T14:12:38,864 - DEBUG 128 o.a.b.u.c.i.s.s.SshjTool
> [nager-DV7OEufF-4] [email protected]:22 failed to connect (rethrowing)}}
> {{ org.apache.brooklyn.util.core.internal.ssh.SshException:
> ([email protected]:22) ([email protected]:22) error
> acquiring}}{{{hostAndPort=52.214.254.195:22, user=brooklyn, ssh=1626499876,
> password=xxxxxx, privateKeyFile=null, privateKey=null, connectTimeout=30000,
> sessionTimeout=30000}}}{{(attempt 1/1, in time 84ms/30s); out of retries:
> Exhausted available authentication methods}}}}
> It then repeats the connection attempt for 10 minutes.
> Strangely, once this process has failed, it's not an error: Brooklyn
> continues, and somehow it's found some useful credentials and it logs in:
> {{2018-09-13T14:22:40,295 - DEBUG 128 o.a.b.c.l.LocationConfigUtils
> [nager-DV7OEufF-4] Inferring OS credentials}}
> {{2018-09-13T14:22:40,296 - DEBUG 128 o.a.b.c.l.LocationConfigUtils
> [nager-DV7OEufF-4] Public key data extracted}}
> {{2018-09-13T14:22:40,297 - DEBUG 128 o.a.b.c.l.LocationConfigUtils
> [nager-DV7OEufF-4] OS credential inference: OsCredential[ssh-rsa
> AAAAB3NzaC1yc2EAAAADAQABAAAAgQDD1jMycpme/Acx57BwGmVExPbNFOISJD66IoI1zCVwr0sErgmQuukZpvw1/dP3ZGeRo3UImieiSZ1Re8lA7Mw5anYgOwRMzbt/lLnc/aphMq3qwV2jJHmz3oohDOADa13DWKRSn9zoOdQxnmzt1Q5JHPpxGEiiA5IdHJzWOfCfkQ==;private-key-present,no-password]}}
> This obviously gives a very poor impression. Adding an SSH key for the
> Brooklyn user means that provisioning happens much, much faster.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
