Damn. I just thought of something. How will "ansible -m ping <somewhere_behind_a_bastion_host>" work?
Hope I've overlooked something, but that could be a snag. -T On Monday, November 3, 2014 6:15:37 PM UTC-6, Matt Davis wrote: > > OK, PR 9477 <https://github.com/ansible/ansible/pull/9477> implements > bastion host/port/user/key and ssh_args as inventory vars... > > On Thursday, October 30, 2014 2:01:03 PM UTC-7, Michael DeHaan wrote: >> >> i.e. let's have both, if we want. >> >> >> >> On Thu, Oct 30, 2014 at 4:59 PM, Michael DeHaan <[email protected]> >> wrote: >> >>> Commented on Matt's PR, but I think this is a good start. >>> >>> I have also mentioned recently (today) that adding ansible_ssh_args as >>> an inventory variable is also fine with me, to override what might be set >>> in ansible.cfg. >>> >>> >>> >>> On Thu, Oct 30, 2014 at 3:31 PM, Matt Martz <[email protected]> wrote: >>> >>>> I submitted a PR a month or so ago as a possible solution to specifying >>>> bastion hosts via an inventory variable: >>>> >>>> https://github.com/ansible/ansible/pull/9122 >>>> >>>> >>>> On Thursday, October 30, 2014, Tennis Smith <[email protected]> >>>> wrote: >>>> >>>>> Here is a possible compromise. Another way >>>>> <http://en.wikibooks.org/wiki/OpenSSH/Cookbook/Proxies_and_Jump_Hosts> >>>>> to use a proxy is via this kind of ssh construct: >>>>> >>>>> ssh -o "ForwardAgent=yes" -tt [email protected] ssh -tt [email protected] >>>>> >>>>> It accomplishes the same thing. Could that be passed somehow in >>>>> Ansible in its current code? >>>>> >>>>> -T >>>>> >>>>> >>>>> On Wednesday, October 29, 2014 1:04:01 PM UTC-5, Matt Davis wrote: >>>>>> >>>>>> I suppose I could do both. I personally prefer the explicit vars- I >>>>>> find it makes the playbooks more readable and maintainable than >>>>>> deciphering >>>>>> ssh_args line noise. I can see where it'd nice to have the "escape >>>>>> hatch" >>>>>> to do unsupported things, though, too. The trick is getting everything >>>>>> to >>>>>> behave if things get set with the explicit vars and also in ssh_args- >>>>>> there's a bit of code in ssh.py to deal with that already (ssh_args >>>>>> takes >>>>>> precedence IIRC), but there would probably need to be a lot more to make >>>>>> it >>>>>> really robust. >>>>>> >>>>>> On Wednesday, October 29, 2014 10:26:26 AM UTC-7, erewh0n wrote: >>>>>>> >>>>>>> If there was a more generic "ansible_ssh_args" parameter, it could >>>>>>> be used however the user sees fit. It's a more flexible approach >>>>>>> because >>>>>>> it assumes less about how the parameter might be used or implemented in >>>>>>> SSH. It just means a little more overhead for the user to know how to >>>>>>> construct that string correctly. >>>>>>> >>>>>>> >>>>>>> On Wednesday, October 29, 2014 1:04:45 PM UTC-4, Michael Peters >>>>>>> wrote: >>>>>>>> >>>>>>>> I think that would be my preference. I know in the past there's >>>>>>>> been >>>>>>>> some pushback against implementing more ansible_ssh_* parameters >>>>>>>> because that's long rabbit whole considering the number of ssh >>>>>>>> configuration parameters that exist. I agree with this point, so if >>>>>>>> adding one more (ansible_ssh_proxy) is too much, then maybe a last >>>>>>>> and >>>>>>>> final ansible_ssh_config to point to a config file on a >>>>>>>> per-host/play/task level. Then anything you want can be put into >>>>>>>> that >>>>>>>> config file and ansible itself wouldn't have to ever add any other >>>>>>>> ansible_ssh_* parameters. >>>>>>>> >>>>>>>> Either way would solve the problem, although the latter is more >>>>>>>> complicated to implement for users (would probably need to have the >>>>>>>> dynamic inventory dynamically generate ssh config files too). >>>>>>>> >>>>>>>> On Wed, Oct 29, 2014 at 12:45 PM, Tennis Smith <[email protected]> >>>>>>>> wrote: >>>>>>>> > >>>>>>>> > How about implementing "ansible_ssh_proxy" to match >>>>>>>> "ansible_ssh_user" and >>>>>>>> > "ansible_ssh_host"? >>>>>>>> > -T >>>>>>>> > >>>>>>>> > >>>>>>>> > On Wednesday, October 29, 2014 11:36:42 AM UTC-5, erewh0n wrote: >>>>>>>> >> >>>>>>>> >> Good point -- so configuration per play might be inflexible. I >>>>>>>> guess the >>>>>>>> >> better choice is a variable that can be modified per >>>>>>>> host/group/play. Call >>>>>>>> >> it "ssh_args" and give it the same meaning as ANSIBLE_SSH_ARGS. >>>>>>>> Assign it >>>>>>>> >> per host, group or play where required and use the "-o" option >>>>>>>> to pass in >>>>>>>> >> ProxyCommand parameters. >>>>>>>> >> >>>>>>>> >> This seems pretty clean, although I'm not sure what the >>>>>>>> convention is for >>>>>>>> >> exposing new "global" variable state in Ansible. :) >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> On Wednesday, October 29, 2014 12:19:41 PM UTC-4, Michael Peters >>>>>>>> wrote: >>>>>>>> >>> >>>>>>>> >>> Another use case to consider (that I myself have come up >>>>>>>> against) is >>>>>>>> >>> configuring the bastion per-host from a dynamic inventory. The >>>>>>>> servers >>>>>>>> >>> need to use a different bastion depending on their role and >>>>>>>> location. >>>>>>>> >>> >>>>>>>> >>> On Wed, Oct 29, 2014 at 12:17 PM, erewh0n <[email protected]> >>>>>>>> wrote: >>>>>>>> >>> > Thinking on this a bit more ... it seems there are two use >>>>>>>> cases here: >>>>>>>> >>> > how >>>>>>>> >>> > to dynamically change your SSH control connection during >>>>>>>> playbook >>>>>>>> >>> > execution >>>>>>>> >>> > and how to subsequently refer to the new bastion host on >>>>>>>> subsequent >>>>>>>> >>> > calls to >>>>>>>> >>> > ansible-playbook. If you could set SSH arguments per play, >>>>>>>> then I >>>>>>>> >>> > think >>>>>>>> >>> > both of these cases are addressed: >>>>>>>> >>> > >>>>>>>> >>> > - hosts: all >>>>>>>> >>> > connection: ssh >>>>>>>> >>> > connection_args: >>>>>>>> >>> > proxy_host: {{ groups.bastion[0] }} >>>>>>>> >>> > proxy_port: 22 >>>>>>>> >>> > user: johndoe >>>>>>>> >>> > >>>>>>>> >>> > The 'connection_args' feature implies you no longer require >>>>>>>> SSH config >>>>>>>> >>> > files >>>>>>>> >>> > (but could optionally use them if preferred). It could be >>>>>>>> used >>>>>>>> >>> > dynamically >>>>>>>> >>> > within a playbook to override your defaults that come from >>>>>>>> >>> > "ANSIBLE_SSH_ARGS", for example. >>>>>>>> >>> > >>>>>>>> >>> > I can see an argument for just specifying raw SSH command >>>>>>>> line >>>>>>>> >>> > arguments as >>>>>>>> >>> > well, something like: >>>>>>>> >>> > >>>>>>>> >>> > - hosts: all >>>>>>>> >>> > connection: ssh >>>>>>>> >>> > connection_args: >>>>>>>> >>> > command_line: "-o ProxyCommand ssh -W %h:%p -l johndoe >>>>>>>> johndoe@{{ >>>>>>>> >>> > groups.bastion[0] }}" >>>>>>>> >>> > >>>>>>>> >>> > >>>>>>>> >>> > >>>>>>>> >>> > -- >>>>>>>> >>> > 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/ >>>>>>>> 2f75fa3d-cc99-4bc5-aa3b-28562d9d8db9%40googlegroups.com. >>>>>>>> >>> > 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/ >>>>>>>> df0108fb-0405-4f10-8b04-2295a3912b7a%40googlegroups.com. >>>>>>>> > >>>>>>>> > 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/11928401-fc81-4fe2-946d-7d74dbd671aa%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/ansible-project/11928401-fc81-4fe2-946d-7d74dbd671aa%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>>> -- >>>> Matt Martz >>>> @sivel >>>> sivel.net >>>> >>>> -- >>>> 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/CAD8N0v9HwugTWmfyYJvVJ9JrivRtE9c-W0RHYgVv4GppgW0gdw%40mail.gmail.com >>>> >>>> <https://groups.google.com/d/msgid/ansible-project/CAD8N0v9HwugTWmfyYJvVJ9JrivRtE9c-W0RHYgVv4GppgW0gdw%40mail.gmail.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/2538f137-94fa-4304-8b65-e9c8980d46cc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
