Mailing-List: contact dev-help@brooklyn.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@brooklyn.incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of alex.heneveld@cloudsoftcorp.com
 designates 74.125.82.172 as permitted sender)
From: Alex Heneveld <alex.heneveld@cloudsoftcorp.com>
Message-ID: <54C216C1.3010804@CloudsoftCorp.com>
Date: Fri, 23 Jan 2015 09:39:13 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
 rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: dev@brooklyn.incubator.apache.org
Subject: new jclouds/login features
References: <apache/incubator-brooklyn/pull/465@github.com>
 <apache/incubator-brooklyn/pull/465/c71165826@github.com>
In-Reply-To: <apache/incubator-brooklyn/pull/465/c71165826@github.com>
Content-Type: multipart/alternative;
 boundary="------------090204040000080208060208"

--------------090204040000080208060208
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


Hi folks-

I finished #465 last night [1] which refactors inferencing for login 
credentials to use for jclouds-provisioned machines.

Because logging in to machines is quite important to what we do :) it 
would be good to test this in a wide range of situations.  If you have 
some special login situations I'd appreciate it if you could test this out.

Key changes are:

* if there is an invalid key or a missing passphrase, it fails fast
* if no keys are supplied it tries the usual ~/.ssh/id_{r,d}sa, and if 
those are missing or invalid it logs a message and then it creates a new 
*key* (rather than a password as some images don't allow passwords)
* an explicit blank value for privateKeyFile can force use of a new key 
for each host
* if a passphrase is supplied, the key is decrypted before passing it to 
jclouds (previously jclouds wouldn't respect passphrases in some places)
* public keys can be extracted from private key pem files if no *.pub is 
present

Also:

* you can set extra public keys to be authorized (comma separated 
file/url string in brooklyn.properties or a list in yaml)
* you can supply extra first-boot commands as part of the template 
options script (e.g. if sudoers file needs different treatment)

This should be totally compatible with all sensible existing 
configurations, but just give more features and better feedback on bad 
configs.

Best
Alex

> incubator-brooklyn-pull-requests #685 
> <https://builds.apache.org/job/incubator-brooklyn-pull-requests/685/> 
> SUCCESS
>
Best
Alex

[1] https://github.com/apache/incubator-brooklyn/pull/465

--------------090204040000080208060208--