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 <[email protected]> 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 >> <[email protected]> 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 > >
