Ansible 2.0 - synchronize change in functionality - broke my deploys

[undeadops]

I had been using a play for a few months now on the 1.9 releases. It looks like the following:

{code}
- name: Ensure All SSL Certs Are Copied to Server
synchronize: src=ssl/ dest=/opt/backup/ssl/ archive=no recursive=yes
{code}

With Ansible 2.0, its now trying to sudo on my local host, in order to be able to sudo copy them on the remote host.

From the Docs:
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 counter to the previous functionality. The user running the play has access to the remote server, the Local root account isn't available to use.

I'm not understanding the purpose of the local sudo when "become:" is enabled. When the module is showing a "set_remote_user" option as well. the purpose of 'become' is for the remote system. not the local one. Make the 'set_remote_user' to be 'set_local_user'? and keep the same functionality as was present in 1.9?

[jacobweber]

This sounds like it's the cause of #13034 . I'm guessing that using "become" on the remote host isn't possible, since it's just running the rsync command locally (thus Ansible has no control over the remote side). So there's no harm in setting "become: false" on your synchronize tasks, since it will only affect the local side.

[undeadops]

Yes, looks like the same issue.

On Wed, Jan 13, 2016 at 2:03 PM, Jacob Weber notifications@github.com
wrote:

This sounds like it's the cause of #13034
#13034, which is also causing
problems for me.

—
Reply to this email directly or view it on GitHub
#13825 (comment).

[nocive]

Facing the same issue, the change in behaviour on the synchronize module broke my deployments as well 😞

Currently working around the problem with: rsync_opts: --rsh "ssh -l {{ lookup('env', 'USER') }}", forcing ansible to use the real user and not root.

[abadger]

We're looking at what kind of fix we can apply to this for 2.0.1 or 2.0.2. synchronize has always been somewhat hacky and unfortunately the hacks will interact badly with the become code that is in 2.0. We're hoping that even if we can't make this code perfect for the next release that we can at least get something more like the 1.9.x behaviour. However, there's a lot of ugliness in the code so we'll have to be careful not to break other things even worse.

Am I correct in thinking that what you all want is for no privilege escalation to be performed locally and privileges to be escalated on the remote host via passwordless sudo? I think that's the limitations that were imposed on this usage in 1.9.x... just making sure that I'm not missing any wrinkles and additional features there.

[jacobweber]

Not sure about the original poster, but I didn't really need privilege escalation on the remote host, so setting become=false worked for me. Having "become" affect the local host was what confused me.

[nocive]

@abadger In my case I'm using privilege escalation already for both sides with become: true and rsync_path: "sudo rsync".
What i want is for ansible to respect what was formerly the ansible_ssh_user fact and pass it along to ssh (with the -l flag) when rsycing, in order to take advantage of the user's ssh key i have setup (and not the root key). This was the observed behaviour in ansible 1.9.x.

[abadger]

@nocive From my brief testing, 1.9.x does not do privilege escalation on the controller. Can you show how you have that working?

[nocive]

@abadger Apologies, maybe I didn't explain myself properly.
I'm using it in pull mode together with delegate_to, so none of it actually runs on the controller host.

synchronize:
    src:        "{{ some_src }}/"
    dest:       "{{ some_dest }}"
    mode:       pull
    archive:    yes
    compress:   yes
    rsync_path: "sudo rsync"
    #rsync_opts: --rsh "ssh -l {{ lookup('env', 'USER') }}" # for ansible 2.x
  sudo: true
  delegate_to: "{{ item }}"
  when: "play_hosts|length > 1 and item not in groups['foo'] and item not in groups['bar']"
  with_items: play_hosts

[abadger]

@nocive That's not working for me either with 1.9.4 (although I think the issue is bugs in 1.9's delegate_to handling rather than in it's sudo handling... but I'll have to figure out how to check that to be sure). Could you check for me that 1.9 really is escalating privileges on the delegate_to host? If you make some_src readable only by root does it succeed?

[abadger]

Warning: This commit isn't tested with anything except the basic problem listed in this ticket so with further testing it may not prove suitable for inclusion in the next release. I'm linking it here so you all can take a look at it but like I say, even though this change appears to fix this problem, there's no promise yet that it will go into the next release:

https://github.com/ansible/ansible/compare/synchronize-become-is-reversed?expand=1

That said, anyone who can test is encouraged to do so. I finding important cornercases is mostly about more people using it in their real-world code.

[undeadops]

On Thu, Jan 14, 2016 at 6:07 PM, Toshio Kuratomi notifications@github.com
wrote:

Am I correct in thinking that what you all want is for no privilege
escalation to be performed locally and privileges to be escalated on the
remote host via passwordless sudo? I think that's the limitations that were
imposed on this usage in 1.9.x... just making sure that I'm not missing any
wrinkles and additional features there

​Yes, this is exactly how I used it.​

[abadger]

For those following along at home, a couple new commits to this branch: https://github.com/ansible/ansible/compare/synchronize-become-is-reversed?expand=1

which fix some problems with delegate_to and sudo.

Also, proposed update to the module documentation: https://gist.github.com/abadger/b719c89497a7018f51ae

[jpcope]

If it helps anyone playing along at home:
1.9.2 does not have the issue; 1.9.4 and later appear to have the issue.

[pwaring]

Setting become_user: False at the top of the playbook fixed the problem for me in 2.0.0.2. The task which was having the problem was:

- name: synchronize static sites
      with_items: static_sites
      synchronize:
        src: "{{ static_sites_local_dir }}/{{ item }}/output/"
        dest: "{{ vhosts_top_dir }}/{{ item }}/public_html/"
        archive: no
        recursive: yes

[abadger]

Okay, the synchronize branch I've been working on to fix this has been merged to devel and stable-2.0. This should now be fixed if you checkout and run either of those from a checkout. It is schedued to be in the 2.0.1 release.

[makmanalp]

🍰 This solved my issue - the tricky part was realizing that the Password: prompt was a local one versus a remote one and for sudo vs ssh login.

[javiermatos]

Hi, I'm still having the issue using the latest ansible version (2.0.0.2). The problem appears when I use the rsync_opts to change ownership.

I have a main.yml file with the following:

- include: backend.yml
  become_user: '{{ project_user }}'

and then I have my backend.yml as follows:

- name: update backend
  synchronize:
    src: '{{ backend_path }}/'
    dest: '{{ project_path }}/backend/'
    delete: yes
    rsync_opts: '--chown={{ project_user }}:{{ project_user }}'

It works on ansible 1.9.4 but on 2.0.0.2 it has an error:
fatal: [192.168.220.104]: FAILED! => {"changed": false, "cmd": "rsync --delay-updates -F --compress --delete-after --archive --rsh 'ssh -S none -o StrictHostKeyChecking=no' --rsync-path=\"sudo rsync\" --out-format='<<CHANGED>>%i %n%L' \"/home/ubuntu/Workspace/go/src/backend/\" \"192.168.220.104:/srv/go/backend/\"", "failed": true, "msg": "Could not create directory '/var/www/.ssh'.\r\nFailed to add the host to the list of known hosts (/var/www/.ssh/known_hosts).\r\nPermission denied (publickey).\r\nrsync: connection unexpectedly closed (0 bytes received so far) [sender]\nrsync error: unexplained error (code 255) at io.c(226) [sender=3.1.0]\n", "rc": 255}

My project_user is www-data, that's why it tries to add host to /var/www/.ssh. As I told, it works when moving back to ansible 1.9.4. I think mine is a strange corner case because of the ownership thing.

[magnetik]

I had a playbook that was working on 1.9.(not sure) but not in 2.0.0.2

- name: Copy config includes
  synchronize: src=includes dest=/etc/apache2

with the global config become = True

But had it working by changing it to:

- name: Copy config includes
  synchronize: src=includes dest=/etc/apache2 rsync_path="sudo rsync"
  become: false

[lfalcao]

@magnetik 👍 tks

[ramayer]

The workaround to explicitly call rsync as mentioned here works well for me:

https://groups.google.com/d/msg/ansible-project/aC3WStjfoh4/Hd1Pjvvsb-wJ

I.e. use this:

rsync task:

    - name: my copy in bin dir
      sudo: no
      local_action: >
        command
        rsync
        --delay-updates -FF --compress --timeout=10 --delete-after
        --archive --no-owner --no-group
        --rsh 'ssh -i /home/mumble/.ansible/keys/mumble-id_rsa -o stricthostkeychecking=no'   
        --rsync-path 'sudo rsync'
        --out-format='<<CHANGED>>%i %n%L'
        {{ inventory_dir }}/working/mumble-bin/
        admin@{{ inventory_hostname }}:/mumble/bin

instead of the synchronize module.

[jeff1985]

My vagrant deployment also has been broken with the switch from ansible 1.9.2 to 2.0.2
In my case ansible has been trying to sync the given local path to the global path on the same machine. I had to explicitly set
dest="{{ ansible_ssh_user }}@{{ ansible_ssh_host }}:/etc/somedir/" to fix it.

[flyte]

I have the same issue as @jeff1985 in Ansible 2.0.2. The docs say:

# Synchronization of src on the control machine to dest on the remote hosts
synchronize: src=some/relative/path dest=/some/absolute/path

but in fact the src and dest are both relative to my own machine and not the remote host.

[jeff1985]

@flyte
i must admit, my issue must have to do with using vagrant in combination with ansible as provisioner. i had to use the usual dest="/etc/somedir/" when i tried to run the playbook on a remote host without vagrant. so i believe there might me some bug related to handling local virtual machines.

[jeffwidman]

I am still hitting this on a playbook with a globally defined become: true:

- name: Deploy code using rsync
  synchronize:
    mode: push
    src: ../data_pusher/
    dest: "{{ code_path }}/test"
    archive: no
    recursive: yes
  become: false

When I don't set become: false at the task level, I get an error about three password failures, which I assume is my macbook because other sudo tasks on the remote host are succeeding.

[mydagobah]

@jeffwidman I had the same issue with Ansible 2.0.2.0. My walk around is using rsync_path

synchronize:
 ...
 rsync_path: "sudo -u <remote user> rsync"

[jesusch]

+1

[nocive]

bumped into this again after another try at migrating my codebase to ansible 2.x

[tima]

@nocive and others: This issue was closed some time ago and isn't going to get the attention of the core developers.

[nocive]

@tima fair enough, im still gonna rant about it anyway.

[ritzk]

@nocive could you try - #16138 .

[abadger]

@nocive what tima means is that once an issue has been "closed, fixed", people who can do something about any problems that exist after the fix has been applied are probably not going to see the comments on the closed ticket. Opening the new ticket is the way to get attention on the issue.

For people suffering issues with synchronize and vagrant pushing files to the wrong machine, we merged this PR in the last few days which probably fixes that bug: #15993

I'm going to lock this issue now. if you are having issues still, (1) search for open issues that have the same symptoms to chime in on rather than closed issues. (2) if no open issue exists, open a fresh issue so that we see that there's still problems and can sort them out.