New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ansible 2.0 - synchronize change in functionality - broke my deploys #13825
Comments
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. |
Yes, looks like the same issue. On Wed, Jan 13, 2016 at 2:03 PM, Jacob Weber notifications@github.com
|
Facing the same issue, the change in behaviour on the synchronize module broke my deployments as well Currently working around the problem with: |
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. |
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. |
@abadger In my case I'm using privilege escalation already for both sides with |
@nocive From my brief testing, 1.9.x does not do privilege escalation on the controller. Can you show how you have that working? |
@abadger Apologies, maybe I didn't explain myself properly.
|
@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? |
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. |
On Thu, Jan 14, 2016 at 6:07 PM, Toshio Kuratomi notifications@github.com
Yes, this is exactly how I used it. |
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 |
If it helps anyone playing along at home: |
Setting
|
* In 2.0.0.x become was reversed for synchronize. It was happening on the local machine instead of the remote machine. This restores the ansible-1.9.x behaviour of doing become on the remote machine. However, there's aspects of this that are hacky (no hackier than ansible-1.9 but not using 2.0 features). The big problem is that it does not understand any become method except sudo. I'm willing to use a partial fix now because we don't want people to get used to the reversed semantics in their playbooks. * synchronize copying to the wrong host when inventory_hostname is localhost * Fix problem with unicode arguments (first seen as a bug on synchronize) Fixes #14041 Fixes #13825
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. |
|
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:
and then I have my backend.yml as follows:
It works on ansible 1.9.4 but on 2.0.0.2 it has an error: 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. |
I had a playbook that was working on 1.9.(not sure) but not in 2.0.0.2
with the global config But had it working by changing it to:
|
@magnetik |
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:
instead of the synchronize module. |
My vagrant deployment also has been broken with the switch from ansible 1.9.2 to 2.0.2 |
I have the same issue as @jeff1985 in Ansible 2.0.2. The docs say:
but in fact the |
@flyte |
I am still hitting this on a playbook with a globally defined
When I don't set |
@jeffwidman I had the same issue with Ansible 2.0.2.0. My walk around is using rsync_path
|
+1 |
bumped into this again after another try at migrating my codebase to ansible 2.x |
@nocive and others: This issue was closed some time ago and isn't going to get the attention of the core developers. |
@tima fair enough, im still gonna rant about it anyway. |
@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. |
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?
The text was updated successfully, but these errors were encountered: