brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Downer <rich...@apache.org>
Subject Re: new jclouds/login features
Date Wed, 28 Jan 2015 17:21:03 GMT
Hi Alex,

A bit late (since it has already been merged!) but I can confirm that
your changes have *not* broken my use case :-)

Richard.

On 23 January 2015 at 13:50, Alex Heneveld
<alex.heneveld@cloudsoftcorp.com> wrote:
>
> Richard-
>
> Sure thing.  The aim is to make those awkward login configs easier of
> course, not harder, so you'll be a good litmus test whether this moves in
> the right direction!
>
> Best
> Alex
>
>
>
> On 23/01/2015 13:20, Richard Downer wrote:
>>
>> Alex,
>>
>> I've recently lost hours trying to get an awkward login configuration
>> working in Brooklyn, so I think I fit the criteria of "special login
>> situations" :-) I'll give this a try but it probably won't be until
>> Monday that I'll have the time to do it. There are a couple of warning
>> bells in your list of key changes, so if you can wait a couple of
>> days, please can we make sure that this is not merged until I've had a
>> chance to test it.
>>
>> Thanks
>> Richard.
>>
>>
>> On 23 January 2015 at 09:39, Alex Heneveld
>> <alex.heneveld@cloudsoftcorp.com> wrote:
>>>
>>> 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
>
>

Mime
View raw message