Run Script and display its output on the remote node

Archives Ansible Project
1

Like the subject explains. I want to run an un-ending script and want to see the output on the remote node only. Is that possible ?

2

Maybe sth like:
shell: screen -d -m bash /home/dell/tester_server_2/runserver.sh

But this is not doing the trick

3

See here for some info about running “fire and forget” non-blocking tasks.

http://docs.ansible.com/playbooks_async.html

You may also be instead interested in

http://docs.ansible.com/faq.html#how-do-i-keep-secret-data-in-my-playbook

Depending on how I interpret the question about “not seeing local output”, one or both may be appropriate.

4 
---


- hosts: server
  gather_facts: False

  tasks:
  - name: Run runserver.sh and save the output of script
    shell: screen -dRR bash /home/dell/tester_server_2/runserver.sh
    async: 99999999999
    poll: 0

I have already incorporated sth like that in my playbook. Now what I need is that if any of the remote nodes have been accessed by using Puttty or OpenStack Dashboard, they should display the output of the script on that individual screen. For instance, if the script I am executing contains echo “hello from ansible control node” and then goes to sleep for some time. The output on the individual user (all the nodes) should be hello form ansible control node . Each remote node should display this message on their respective screen, so that it is readable to any user that is currently sshed into the VM.

5

You mean acting as a remote wall(1) ?

maybe then just pipe the output to wall(1)

Phil

6

I am sorry but I am not familiar with that. Do you have a solution to this problem. Any relevant documentation?

7

“, it should execute a script on all the targeted hosts and anybody who has sshed into that node should be able to see that script being run on their respective screen (for example if a script contains echo “hello from ansible control node”)”

AFAIK, such things do not exist.

You could definitely run something like “wall” to broadcast messages, start things in screen sessions, and so on, but this seems a bit weird for a standard automation use case to me.

Maybe I’m not following.