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 <[email protected]> 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 [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/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 [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/CAG9juEr%3Dm4MKoD4ck0%2BccR1d%3DZLA3vd%2B_Fg8aLmZUvjvk8gQTg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
