You're right about this being the wrong thing for synchronize to do. My fault for not understanding sooner that this wasn't the behaviour in 1.9.x. We consider it a bug in 2.0.0.x and I'm working on a fix to it for 2.0.1 right now. Progress on the fix is here: https://github.com/ansible/ansible/issues/13825
I'll be pushing a documentation update in a few hours so that the website documentation no longer says that it is expected that synchronize works this way (and that it is a bug in 2.0.0.x only). -Toshio On Thu, Jan 21, 2016 at 7:25 AM, Christophe Meessen <christophe.mees...@gmail.com> wrote: > > I finally fixed the problem after reading the doc on synchronize. I found > the following note: > >> The user and permissions for the synchronize src are those of the user >> running the Ansible task on the local host, or the become_user if become: >> yes is active. synchronize will attempt to escalate privileges to the >> become_user on the local host. > > > This is changing the semantic of the become and become_user parameters. > > Normally, as I understood it, it is to define the behavior remotely. For > this reason I defined it globally to yes in my playbook. > > But synchronize use it to control the identity change locally. This is > inconsistent and confusing. > > As a consequence I don't know what synchronize is doing. I'm running the > playbook as user A. In the inventory I defined the variable ansible_user=B. > In the playbook I defined become:yes and become_method: sudo. > > So I assumed that while running the playbook as user A, ansible will connect > remotely as user B and run the tasks after performing a sudo. I have > configured it to be a password less sudo to root. This is apparently how > things work as I deduced by trial and error. > > Now synchronize hijacks the parameter become and change it's purpose. For > synchronize it now specify if the identity should be changed locally and > become_user would specify to what. But then how is the remote identity and > privilege escalation define ? > > It looks like there is still a confusing mix up in the way to define the > different identities and change method and optional password. It's not yet > fully orthogonal. > > It should be possible to define a local identity change and a remote > identity as the ssh user identity (ansible_user?) and authentication method. > The hack made by synchronize about this is really confusing. > > -- > 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 ansible-project+unsubscr...@googlegroups.com. > To post to this group, send email to ansible-project@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/d4ed87fc-f4ae-442e-83b3-7d937831b5f9%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 ansible-project+unsubscr...@googlegroups.com. To post to this group, send email to ansible-project@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAG9juEr%3Dm4MKoD4ck0%2BccR1d%3DZLA3vd%2B_Fg8aLmZUvjvk8gQTg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
