Any updates on this? I took a gander through the GitHub issues but didn't see one that seemed related.
On Monday, November 10, 2014 at 9:52:43 AM UTC-8, Matt Jaynes wrote: > > Sounds like some great possible solutions. > > Either > > 1) Reading the SSH config to pick up the correct known_hosts locations > (and perhaps setting 'host_key_checking' to false if the location is > '/dev/null' since that's a common pattern - for instance, Vagrant does this > by default, see https://docs.vagrantup.com/v2/cli/ssh_config.html ) > > or > > 2) A simple warning message when serialization is triggered due to > known_hosts in order to save folks from some really tough debugging > > Just lost a few hours debugging this issue. For several environments, I > have a client's known_hosts locations set to custom locations in their SSH > config, so everything was running serially (a 3 minute process * 20 servers > = 60 minutes!). Persistence and sweat finally lead me to try > "host_key_checking = False" and it finally ran in parallel - was so nice to > finally see since I'd tried just about everything else I could imagine > (forks, serial, ssh options, restructuring inventory, removing inventory > groups, etc). > > Thanks, > Matt > > On Monday, September 29, 2014 6:57:35 PM UTC+2, Michael DeHaan wrote: >> >> I'm wondering if we can detect configuration of alternative known_hosts >> locations in the ~/.ssh/config and issue a warning, which should be able to >> key people in to turn off the checking feature. >> >> This should close this out, I'd think. >> >> >> >> On Mon, Sep 29, 2014 at 12:54 PM, Michael DeHaan <[email protected]> >> wrote: >> >>> Ansible does not find your known hosts location from ~/.ssh/config on a >>> per host basis and does read your ~/.ssh/known_hosts. >>> >>> It does this because it needs to know, in advance of SSH asking, whether >>> it needs to lock. >>> >>> Assume it's running at 50/200 forks and needs to ask a question >>> interactively, that's why it needs to know. >>> >>> So if you are saying use known_hosts in a different file, that may be >>> EXACTLY the problem. With host key checking on, and the data going >>> elsewhere, it can't be found, and ansible is locking pre-emptively. >>> >>> >>> On Mon, Sep 29, 2014 at 12:45 PM, Michael Blakeley < >>> [email protected]> wrote: >>> >>>> I took it that Vincent was referring to my message of 2013-09-12 >>>> <https://groups.google.com/d/msg/ansible-project/8p3XWlo83ho/Q1SflaZ9dyAJ>. >>>> >>>> In that post I mentioned using /dev/null for the ssh UserKnownHostsFile >>>> configuration key, scoped to Host *.amazonaws.com >>>> >>>> This configuration triggers single-threaded behavior from ansible >>>> because ssh never stores any record of connecting to the EC2 hosts: not >>>> the >>>> first time, not ever. Because known_hosts is /dev/null. >>>> >>>> -- Mike >>>> >>>> On Monday, September 29, 2014 9:30:32 AM UTC-7, Michael DeHaan wrote: >>>>> >>>>> So I'm confused - are you saying you are using known_hosts that are >>>>> empty? >>>>> >>>>> This seems to be a completely unrelated question. >>>>> >>>>> The mention of /dev/null above seemed to be based on confusion that we >>>>> didn't read it, not that it was actually symlinked to /dev/null. >>>>> >>>>> Can each of you clarify? >>>>> >>>>> On Mon, Sep 29, 2014 at 12:29 PM, Michael Blakeley < >>>>> [email protected]> wrote: >>>>> >>>>>> Vincent, I now use a slightly different workaround. Instead of >>>>>> routing known_hosts to /dev/null I route it to a temp file. This keeps >>>>>> the >>>>>> EC2 noise out of my default known_hosts file, and seems to play well >>>>>> with >>>>>> ansible. >>>>>> >>>>>> From my ~/.ssh/config file: >>>>>> Host *.amazonaws.com >>>>>> PasswordAuthentication no >>>>>> StrictHostKeyChecking no >>>>>> UserKnownHostsFile /tmp/ec2_known_hosts >>>>>> User ec2-user >>>>>> >>>>>> >>>>>> Hope that helps you. >>>>>> >>>>>> -- Mike >>>>>> >>>>>> On Monday, September 29, 2014 8:37:43 AM UTC-7, Vincent Janelle wrote: >>>>>>> >>>>>>> Exactly like what was described at the start of this thread. :( >>>>>>> Setting the environment variable produces the desired parallel >>>>>>> execution. >>>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Ansible Project" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> To post to this group, send email to [email protected]. >>>>>> To view this discussion on the web visit https://groups.google.com/d/ >>>>>> msgid/ansible-project/550bdafe-2892-477b-9452- >>>>>> bbed389bfbce%40googlegroups.com >>>>>> <https://groups.google.com/d/msgid/ansible-project/550bdafe-2892-477b-9452-bbed389bfbce%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Ansible Project" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To post to this group, send email to [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/ansible-project/aa3c8257-cb5c-40b1-94fc-051fee1748fc%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/ansible-project/aa3c8257-cb5c-40b1-94fc-051fee1748fc%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >> -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/7448bd62-9452-43ca-86bd-723ac2238ada%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
