ad-hoc works, playbook fails. same task

Hi

I’m having an issue I can’t even begin to understand: I’m trying to replace some files and I can do that without any issue if I do that from an ad-hoc command. But if I try to do the SAME command from a playbook, it fails.

This is ansible 1.5 on centos 6.4 on the master and centos 6.x on the managed boxes

Here the successful run ad-hoc:

`
$ ansible antpitta0 -m copy -a “src=/deployment/files/profiled/tod_0dm/etc/bashrc dest=/etc/bashrc owner=root group=root mode=0644 force=yes”
sudo password:
previous known host file not found
previous known host file not found
previous known host file not found
antpitta0 | success >> {
“changed”: true,
“dest”: “/etc/bashrc”,
“gid”: 0,
“group”: “root”,
“md5sum”: “eb04806e1f907b98b3afa619b9a8cf64”,
“mode”: “0644”,
“owner”: “root”,
“size”: 2025,
“src”: “/tmp/ansible-tmp-1394031344.37-53546288343003/source”,
“state”: “file”,
“uid”: 0
}

`

And here the failing playbook run:

`
$ ansible-playbook tod-0dm-new.yml
sudo password:

PLAY [tod-0dm] ****************************************************************

TASK: [copy bashrc to the server] *********************************************
previous known host file not found
previous known host file not found
ok: [antpitta0]

TASK: [copy profile to the server] ********************************************
previous known host file not found
previous known host file not found
previous known host file not found
failed: [antpitta0] => {“failed”: true, “md5sum”: “4c781f5c55a1a62ac9ad09574abc9ae6”}
msg: Destination /etc not writable

FATAL: all hosts have already failed – aborting

PLAY RECAP ********************************************************************
to retry, use: --limit @/deployment/home/tod-0dm-new.retry

antpitta0 : ok=1 changed=0 unreachable=0 failed=1

`

And here the contents of my playbook:

`
$ cat tod-0dm-new.yml

The ansible command is probably running as your username vs “ansible”, do you need to request sudo: true ?

– Michael

I’ve got

`
ask_sudo_pass = True

`

on ~/.ansible.cfg

Both are run as the user ‘ansible’.
So I’m guessing I can rule that out?

No. ask_sudo_pass just tells it to ask you for the sudo password. It doesn’t tell it to use sudo try adding -s to your ansible-playbook command.

Adam

Well that is a tip I was not expecting! :slight_smile:
will try that tomorrow at work.

But if it asks you the sudo password and you need to explicitly tell ansible-playbook to use sudo, isnt that a bit counterintuitive?
Right now, it asks the sudo password, but it’s not using it for anything. What’s the point of asking then??

Anyways, thanks for the answer. Will try and report back tomorrow.

Indeed it works.

Thanks gentlemen