BUG: This is some weird stuff. Copy module changing file

[John Harmon]

# rpm -q ansible
ansible-2.4.1.0-1.el7.ans.noarch

I was having problems after running one of my playbooks with an unknown module.  I narrowed it down to a task in my playbook.  Can someone explain this?  Seems like a bug.

---
- hosts: "{{ host }}"
  tasks:
    - name: PAM conf - Copy various pam files
      copy:
        src: "{{item.src}}"
        dest: "{{item.dest}}"
        force: no
      with_items:
        - {src: "/etc/pam.d/system-auth-ac", dest: "/etc/pam.d/system-auth-local"}
        - {src: "/etc/pam.d/password-auth-ac", dest: "/etc/pam.d/password-auth-local"}

Before the copy, here is one of the source files:

# cat password-auth-ac
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

After the copy here is the destination.  Notice all the changes!

# cat password-auth-local
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        required      pam_faildelay.so delay=2000000
auth        [default=1 ignore=ignore success=ok] pam_succeed_if.so uid >= 1000 quiet
auth        [default=1 ignore=ignore success=ok] pam_localuser.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        sufficient    pam_sss.so forward_pass
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 1000 quiet
account     [default=bad success=ok user_unknown=ignore] pam_sss.so
account     required      pam_permit.so

password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient    pam_sss.so use_authtok


password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_sss.so

What is going on?  I did a compare of the whole pam.d directory and the only changes are to the .local files I created using the copy module.

[John Harmon]

I filed a bug:

https://github.com/ansible/ansible/issues/32445

[Brian Coca]

force: no prevents a copy if the dest file exists




--
----------
Brian Coca

[John Harmon]

Yes, but the contents of the file change.... the force option is set that way on purpose so I don't overwrite any local changes if they exist.

[Toshio Kuratomi]

Ansible is stateless. So it doesn't know if the remote file exists in
the way you have it because you changed it on the remote system or
because a previous ansible run dropped that version of hte file there.
If you want Ansible to ensure that the remote file matches what you
have at your source then you must have force: yes. If you want
ansible to always respect remote changes then you have force: no.

You can come up with your own method to track remote state to
determine whether to overwrite the file or not (by taking a hash of
previous files pushed out by ansible and saving it somewhere for
comparison in the future) you certainly can write several tasks to
take care of that but that is outside of the scope of what's built
into Ansible.

-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/742ab2e7-8d00-488d-becd-6546d408668e%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

[John Harmon]

I set force to yes, and it is still happening.

[John Harmon]

OK, I see it is grabbing the file from my ansible server, and copying it to the managed server.  I was expecting it to copy it from the managed server to the managed server... now I just need to figure out the right syntax for that.

[John Harmon]

Done, the key is to add:

remote_src: yes