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] > <javascript:>> 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] >> <javascript:>> 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] >>> <javascript:>> 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] <javascript:>. >>> To post to this group, send email to [email protected] >>> <javascript:>. >>> 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/5ac5f600-d199-4b34-8d2a-25cb8f91e12b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
