synchronize module doesn't work with ansible sudo user

[darkone23]

When you use the new synchronize module with a sudo user it syncs to the ssh user instead of the sudo user.

tasks:
  - name: sync
    sudo: yes
    sudo_user: sudo_user
    synchronize: src=foo/ dest=~/bar/

Instead of syncing to /home/sudo_user/bar it syncs to /home/ssh_user/bar

[mpdehaan]

cc @tima

[tima]

Without some debugging output I'm shooting in the dark here. I'm guessing that I'm not taking in to account if Ansible is in sudo mode to use a different username that the usual.

    user = inject.get('ansible_ssh_user', self.runner.remote_user)

That's a guess though. @eggsby can you run your test with -vvv and post it?

[jctanner]

@eggsby I think you have described the behavior for the copy module.

Example:

    - copy: src=~/1 dest=~/foofile1
      sudo: yes
      sudo_user: bob

If I run that task as "jtanner", src evals to /home/jtanner/1 and dest evals to /home/bob/foofile1

@tima fyi

[darkone23]

@jctanner ah, that's a different problem entirely. However, the rsync module still doesn't work with sudo: changing to use an absolute path shows the following as the cmd:

rsync --delay-updates --compress --archive --rsh 'ssh -o StrictHostKeyChecking=no' --out-format='<<CHANGED>>%i %n%L' files/ ssh_user@myhost.example.com:/home/sudo_user/files

I don't know of a good way to get around this, seems like a pretty deep issue with the way rsync works.

I would love to see any progress on this end, but currently the module works for many use cases as is. Maybe there should just be a caveat that it currently doesn't work with sudo?

Thanks for any help,
Thomas Omans

[jctanner]

Suggested workaround from irc is to append a --rsync-path option to the rsync command if the task is sudo'ed. This will require "Defaults !requiretty" to be set on the remote machine or the following error will occur ...

root@u1304:~# rsync --delay-updates --compress --archive --rsh 'ssh  -o StrictHostKeyChecking=no'  ~/foo root@el5.lab.net:~jill/bar --rsync-path='sudo -u jill rsync'
sudo: sorry, you must have a tty to run sudo

If !requiretty is set, the command should work as expected ...

root@u1304:~# rsync --delay-updates --compress --archive --rsh 'ssh  -o StrictHostKeyChecking=no'  ~/foo root@el5.lab.net:~jill/bar --rsync-path='sudo -u jill rsync'
root@u1304:~# echo $?
0
root@u1304:~# ssh root@el5.lab.net 'find /home/jill/bar'/home/jill/bar
/home/jill/bar/foo
/home/jill/bar/foo/1
/home/jill/bar/foo/2
/home/jill/bar/foo/0

We also have to check that the rsync binary on the originating host supports --rsync-path, which is not a concern for el5 or higher.

[tima]

@jctanner Is there something that can be done that doesn't require a work around? If I'm following your example, if contacting a remote server, don't run rsync with sudo (cancel it) and instead prepend the remote rsync path with sudo and the user name. Would there be a case where a user would want the initial rsync execution to be run via sudo? It's sort of fuzzy now, but I seem to recall others concluding were to apply sudo was too ambiguous to automatically. I'm not sure though.

[jctanner]

@tima my last comment was just recording what was discussed in irc and how it -could- be done with straight rsync. I'm still digging through the code to see if there's a safe way to implement it.

[mpdehaan]

We could probably just see if sudo was set and temporarily set ansible_ssh_user to the sudo user.

(Should also include some debug in the output in case this is confusing and mention in docs)

[darkone23]

rsync has a lot of options, another possibility would be to use a sudo command to start an rsync daemon on the remote end and sync over rsync:// instead of ssh.

Switching the ansible_ssh_user would work for some cases. In some use cases the sudo_user would be locked down from ssh access.

I think anything is fine, so long as it is documented.

:)

[jctanner]

In testing this, I noticed that no matter how we alter the code, it's very likely that the rsync command will need input for the remote password and will hang indefinitely. I added 0adf095 to handle this better by setting a configurable timeout (default = 10s) to the rsync command.

[jctanner]

5c34ed0 adds some notes to the module docs to clarify what happens when sudo==True. This is the best we can do for now on resolving this issue because there are too many consequences from overriding the destination <remote_user>@<hostname> with the sudo_user.

[tima]

Thanks for working this out @jctanner.

[darkone23]

Thanks @jctanner

It might also be worth noting that you can use the rsync_path module parameter to run the command as a sudo user (with the sudo users permissions) if the module can only run as the local/remote_user.

[eprigorodov]

Files synced by sudo user in non-archive mode can have correct owner at least:

       synchronize:
           owner: yes
           rsync_opts:
               - "--usermap=*:{{ ansible_user_id }}"

The primary group of remote sudo user seems to be not exposed into the playbook. Setting its default group can be safe enough:

           rsync_opts:
               - "--chown={{ ansible_user_id }}:{{ ansible_user_id }}"

Required dependency for these options is rsync>=3.1.0.