I need to run a script residing on the remote machine with a switch, as in “/scripts/myscript -f” (it must be executed by root). I’m using the shell module, but can find no way to add the switch without the play failing. Help would be appreciated.
*become_user and become_method are commented out in favor of shell: “su - root” because using the former causes a timeout error, But that’s another issue.
Output of play:
TASK [command] ***************************************************************************************************************************************************************************
fatal: [admin1]: FAILED! => {“changed”: true, “cmd”: “/scripts/dnscopy.pl -f”, “delta”: “0:00:01.425695”, “end”: “2018-12-03 17:13:56.113927”, “failed”: true, “rc”: 2, “start”: “2018-12-03 17:13:54.688232”, “stderr”: “Can’t exec "rndc": No such file or directory at /scripts/dnscopy.pl line 296.\nrndc -s dns1 reload failed: No such file or directory at /scripts/dnscopy.pl line 296.”, “stderr_lines”: [“Can’t exec "rndc": No such file or directory at /scripts/dnscopy.pl line 296.”, “rndc -s dns1 reload failed: No such file or directory at /scripts/dnscopy.pl line 296.”], “stdout”: “”, “stdout_lines”: }
without the -f switch, the play completes successfully.
You are running 2 separate shells. First shell runs su - root then exits -
this is not doining anything. Then secon task runs in a new shell, you are
not leveraging the previous "su - root". You are using become: yes, and
that should be sufficient to elevate task's rights, so the second task
should work anyway. Try this:
Remove
- shell: "su - root" task
replace it with:
- shell: "whoami"
register: who
- debug: var=who
to check under which user is your script executing. If it's not 'root'
then you messed up, if it is 'root' but your script still fails, you have a
problem with your script.
Thank you, Piotr. All good, now. You’re right, and this is a mistake I shouldn’t have made, given my long history with Ansible. But, hey, never too late to learn. Thanks, again.
Before I consider this solved, let me push the envelope a bit, and ask about the switch. If I run the play like this:
Shell: /scripts/myscript
it works.
If I run it like this:
Shell: /scripts/myscript -f
it fails with:
fatal: [admin1]: FAILED! => {“changed”: true, “cmd”: “/scripts/dnscopy.pl -f”, “delta”: “0:00:02.025735”, “end”: “2018-12-04 09:34:11.123312”, “failed”: true, “rc”: 2, “start”: “2018-12-04 09:34:09.097577”, “stderr”: “Can’t exec "rndc": No such file or directory at /scripts/dnscopy.pl line 296.\nrndc -s dns1 reload failed: No such file or directory at /scripts/dnscopy.pl line 296.”, “stderr_lines”: [“Can’t exec "rndc": No such file or directory at /scripts/dnscopy.pl line 296.”, “rndc -s dns1 reload failed: No such file or directory at /scripts/dnscopy.pl line 296.”], “stdout”: “”, “stdout_lines”: }
Your continued help (or anybody else’s) would be appreciated.
In order for /scripts/dnscopy.pl -f to work in the remote host itself, I must su - root first. I thought that become: yes took care of that. Here’s the playbook as it stands (and fails) now:
I thought that’s what I should do. I made those changes, but then the playbook is stuck/runs without completion (until it ultimately times out, I’m guessing).
After putting in the directives you mentioned, if I leave become_method: su and become_flags: ‘-’ in the playbook, then the playbook is stuck/runs without completion. If I take those out, leaving only become: yes, then I get the following output:
The thing of it is, the script (which I didn’t write) runs the rndc (BIND Remote Name Daemon Control - we use it to reload zone files) command on our dns servers (which it locates), not on the host in which the script is located. Thus, the failure. Here’s a snippet from the script:
rndc -s dns1 reload
@args = (“rndc”, “-s”, “dns1”, “reload”);
system(@args) == 0
or die “rndc -s dns1 reload failed: $!”;
Dimitri
Your script is depending on rndc residing in the host's $PATH. It might
happen, that the root's profile is being set differently when you become
root in Ansible playbook, than the situation when are switching to root in
a regular way in SSH or terminal. This is why I asked you for more
information in my previous post.
A possible workaround would be to forcibly set PATH env variable when
calling dnscopy.pl. but I can't give you a ready recipe because I don't
have enough informaton about your system