Sorry to  resurrect an old post. 

I'm trying to get ansible/vagrant integration working. 

Vagrant uses a generated inventory file to communicate with Ansible. 

But it is not setting Ansible to perform agent forwarding. 
 




On Wednesday, August 7, 2013 2:53:20 AM UTC+1, Michael DeHaan wrote:
>
> > if you use ANSIBLE_SSH_ARGS you loose the "sensible ControlMaster 
> options".
>
> This is not the case, you can pass in whatever arguments you wish to pass 
> in, including ControlMaster/ControlPersist.
>
> The user who wanted the ProxyCommand parameter was asking for the same 
> kind of option sprawl that resulted in this command being rejected -- 
> because if you want to set individual ProxyCommands, you can specify an SSH 
> config usign ANSIBLE_SSH_ARGS or the configuration file to specify a 
> configuration file that sets this up on a per host basis pretty easily.
>
> There isn't a reason to add a parameter for every possible SSH 
> configuration parameter in Ansible *UNLESS* ansible needs to have 
> significant behavior changes when those parameters are used.
>
> As for your arguments that it are "not nice", I disagree!  It's quite nice 
> and ultimately flexible, and presenting a SSH option for every single flag 
> in OpenSSH quickly results in unmanageable option sprawl.
>
>
>
>
>
> On Tue, Aug 6, 2013 at 7:28 PM, <[email protected] <javascript:>> wrote:
>
>> Hello all,
>>
>> First, being new to ansible and the ansible community, and having already 
>> this proposal rejected in a pull request (
>> https://github.com/ansible/ansible/pull/3756)
>> let me know if the path I'm taking to have my arguments heard is the good 
>> one and I do not hurt or annoy anyone.
>>
>> I began with a problem I'm far from the only one to have: using ssh jump 
>> hosts.
>> Apparently, the only ways to manage it with ansible are either via 
>> ANSIBLE_SSH_ARGS/ansible.cfg or via an entry in ~/.ssh/config.
>>
>> The first is far from convenient:
>> - According to http://www.ansibleworks.com/docs/gettingstarted.html#id4, 
>> if you use ANSIBLE_SSH_ARGS you loose the "sensible ControlMaster options".
>> - These parameters are system-wide/user-wide, and outside of the ansible 
>> - I want to version my ansible playbooks/inventory
>> - I expect my ansible playbooks/inventory to be playable on any 
>> out-of-the-box ansible installation, like you'd expect any PDF file to open 
>> on any PDF reader out of the box.
>>
>> The second is also inconvenient
>> - it's a user-wide setting
>> - you cannot version it with your playbooks/inventory because it is 
>> outside of it
>>
>> I stumbled upon somebody with same needs that proposed a 
>> ansible_ssh_proxy_cmd inventory parameter
>> https://github.com/ansible/ansible/pull/2970 
>> that would solve my problems but I find this solution in either not 
>> generic enough or not specific enough.
>>
>> So that would be nice to have a ansible_ssh_jump_host for instance, like 
>> we already have ansible_ssh_user, ansible_ssh_port, 
>> ansible_ssh_host. Why not also add ansible_ssh_known_hosts_file, or 
>> ansible_ssh_verify_host_key_dns, or any of the bazillions ssh parameters.
>> But that would make a lot of parameters in the inventory file which goal 
>> seems to be more about listing and grouping hosts.
>>
>> On the other hand, why not separate the the inventory and the connections 
>> parameters. ssh config file is good enough to explain how to connect to a 
>> host
>> (user, real name, identity file to use, proxy command, know_host file to 
>> use, etc.) already working with every option you'd happen to need.
>>
>> But, as I already said, I think that:
>> - using ~/.ssh/config is not nice 
>> - using ansible.cfg or ANSIBLE_SSH_ARGS to relocate ssh config into 
>> ansible playbook/inventory repository is also not nice
>> - what if we would like to use several ssh config files according to 
>> inventory groups ?
>>
>> Hence, I think ansible_ssh_config is a light and convenient way to 
>> - integrate ssh config files into the inventory/playbook repository
>> - have this repository be self-sufficient and work from any host with a 
>> working ansible installation (git clone + point ansible to cloned 
>> repository + ansible-playbook my_playbook) as anyone would expect
>> - permit to separate inventory and description on how to connect to hosts
>>
>> I hope that was not too long. I'm ready for the 
>> suggestions/critics/flames?/anything.
>>
>>  
>>
>> -- 
>> 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:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>
>
>
> -- 
> Michael DeHaan <[email protected] <javascript:>>
> CTO, AnsibleWorks, Inc.
> http://www.ansibleworks.com/
>
> 

-- 
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].
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to