synchronize complains that it needs a password to do a sudo

[Christophe Meessen]

When executing a synchronize I get the following error.

This the executed code

- name: Restore repositories
  synchronize: src="{{ item }}" mode=push dest="/home/git"
  with_lines: "find /home/git/*.git -type d -maydepth 0"
  tags: restore


This is the error message I get with each directory.

failed: [srv01] => (item=/home/git/XXX.git) => {"failed": true, "invocation": {"module_args": {"_local_rsync_path": "rsync", "dest": "X...@XX.XX.XX.XX:/home/git", "dest_port": XX, "mode": "push", "private_key": "id_rsa_XXX", "rsync_path": "\"sudo rsync\"", "src": "/home/git/DIR.git"}, "module_name": "synchronize"}, "item": "/home/git/DIR.git", "module_stderr": "sudo: sorry, a password is required to run sudo\n", "module_stdout": "", "msg": "MODULE FAILURE", "parsed": false}

The remote user XXX has a passwordless sudo to root. It works since I can install packages. So why does it complain that sudo requires a password ?

[Christophe Meessen]

I get the same error message even if I add rsync_path="rsync" to the synchronize action. So I don't see who is trying to do a sudo and where (locally or remotely).

The error persist even if I do a local "sudo rsync" just to give the root password.

[Christophe Meessen]

I changed the find instruction to a more correct one, but the synchronize still fails because some sudo requires a password.
This is the instruction I used.

with_lines: find /home/git/ -maxdepth 1 -name "*.git" -type d

[Christophe Meessen]

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.

[Christophe Meessen]

I forgot the solution. Here it is:

- name: Restore repositories
  synchronize: src="{{ item }}" dest="/home/git"

  with_lines: find /home/git/ -maxdepth 1 -name "*.git" -type d

  become: no
  tags: restore

This will attempt a synchronize by executing the rsync as the user who executes the playbook. This works in my case.

If you want to change the identity of the user executing locally the rsync, you have to set become: yes, become_user: X where X is the new local user identity.
If switching the local user identity to X with su or sudo requires a password, you are doomed. Note that running the command as root which in principle should allow changing the local user identity without password didn't work. So I'm not fully sure if my current understanding is correct.

The command line parameter --ask-become-pass applies to the change of the remote user identity. There is currently no support for changing the local user identity.

[Toshio Kuratomi]

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

> --
> 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-proje...@googlegroups.com.
> To post to this group, send email to ansible...@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.

[Toshio Kuratomi]

On Thu, Jan 21, 2016 at 7:25 AM, Christophe Meessen
<christoph...@gmail.com> wrote:
>

> 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.

Note that in 1.9.x (and in the code I'm working on to fix this for
2.0.1) I believe it's impossible to define a local identity change
within ansible. But you can sudo first and then run ansible to
workaround that.

-Toshio

[Christophe Meessen]

Thank you very much for fixing this. In most uses cases it works provided become is set to no.

It might still be useful to change the local user identity when synchronizing, but the way to do it seem to be lacking in the current interface.

Thank you very much for the synchronize module. It is a very powerful and useful module.

You received this message because you are subscribed to a topic in the Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ansible-project/hhTkkKPcCt8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ansible-proje...@googlegroups.com.

To post to this group, send email to ansible...@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.

[Christophe Meessen]

Thank you very much for taking the time to answer and also for this great module. It is very useful.
Being able to change the local user identity would indeed be a useful addition to ansible.
The synchronize module does need it.
It could also be useful for with_lines: which execute a command locally. i.e. accessing a database on the localhost.