It’s probable something to do with the PATH in your bash environment. When you login interactively, the .profile rc file gets run and normally sets up the PATH. I would imagine that when you login via ansible you don’t have the directory for PlistBuddy or sqlite3 in your PATH so those commands fail.
You can either fiddle with your ssh_args in the ansible config files to tell ssh to make the shell a login shell, or you can just put the full path to Sqlite3 and PlistBuddy on those lines of your .bashrc file.
Thanks to some advice from elsewhere, I did try to run “shell: which sqlite3” from within my playbook and then compared the output to what I receive when I run “which sqlite3” in the command line. The results are the same.
If there was a PATH issue with Ansible trying to run sqlite3, wouldn’t the above test fail (i.e. output from each command wouldn’t match)?
Yes, if the which command found the binary from within ansible, then it should find it when running the script via ansible. That seems pretty odd that it doesn’t. I know that the script asks for the sudo password so you can run it locally, but does it run via sudo when run by ansible? If so then it would be using root’s path and not yours.
# TODO: doesn't run commands that use PlistBuddy or sqlite3
shell: ./osx.sh --ansible
notify: killall
Inside osx.sh are PlistBuddy and sqlite3 absolute-pathed? I assume they are not. I suspect they are in a path defined in your local environment, and won't be in the path for ansible, because of the way we enforce centralized and reliable configurations - not trusting 500 servers who might all have different .bashrcs, etc, we don't log in with interactive shells.
If it’s absolutely pathed that shouldn’t matter and shouldn’t be an ansible thing.
When you say it’s not being run, perhaps this is an issue with your shell script.
Ansible will tell you if the script failed and returned a non-zero status, of course, and can include output from the script if you want to add some debug.
However, if plist buddy does call sqlite and sqlite is in a different path (I don’t know ANYTHING about plistbuddy) you would still need to set the path stuff.
The script runs as expected when run directly from the command line. Admittedly, I’ve copied and tweaked the script - it wasn’t written to be run from Ansible.
I know nothing about plistbuddy either but it and sqlite3 are being called by different parts of the shell script - I don’t think they’re calling each other.
I’m gonna put this on the shelf and fallback to running this script after the playbook, directly from the command line. Not really the Ansible way I know but I can’t spend any more time on it right now.
Thanks for all your help. If you get any bright ideas, please post them!
Please try the path thing first, if sqlite is not at the default paths but is something configured in the user environment, that would explain why the shell script and plist buddy couldn’t find it.
I appreciate your persistence Michael Thanks for all your help so far.
I did try the path thing (a few comments up where I quoted some code snippets) but it didn’t seem to make any difference. The locations that I added to PATH could have been incorrect of course - I based them on what was returned from running the following:
which sqlite3
This returns:
`
/usr/bin/sqlite3
`
If I run “echo $PATH” from within my playbook I get:
Am I missing something obvious here? I’m not a sys-admin as I’m sure you can tell. Do I need to add that massive PATH above via Ansible’s environment module?
Not sure what you mean by failure mode but here’s the -vvvv output for the task that tries to run the script in case that helps. As you can see, “stderr” and “stdout” don’t seem to have anything to say.
<127.0.0.1> PUT /var/folders/5d/ry1gfqbx0rs8bmpy7lw0909w0000gn/T/tmpjDc9QL TO /Users/danbohea/.ansible/tmp/ansible-tmp-1408559599.6-238488648926013/command
I mean this by “the way in which something fails”.
Yeah, I have no idea here.
Your script returned a non-zero exit code and no output, which is all ansible knows. It would depend on the behavior of the script. And that script may not have proper error handling to say why what was called in that script died.
I’d start by adding extra output to your script, etc.
Cracked it! It absolutely was down to errors in the script that I was just missing: one I’d inherited from where I’d copied it from (the sqlite3 command) and another of my own doing that was attempting to change a property in a file that didn’t exist yet.
Thank you sooooooo much for all your help and for pushing me to see this through proper style
but it and sqlite3 are being called by different parts of the shell script - I don’t think they’re calling each other.