[SOLVED] Ansible yum: All packages providing ... are up to date

Issue

OK, I'm trying to learn ansible and am running into a problem doing a very basic operation.

Playbook:

 ---
 - hosts: fedtest
   tasks:

    - name: Install httpd package
      yum: name=httpd state=latest
      sudo: yes

    - name: Starting http service
      service: name=http state=started
      sudo: yes

ansible.cfg:

 [defaults]
 hostfile = /home/abcd/proj/ans/hosts
 remote_user = abcd
 private_key_file = /home/abcd/proj/ans/.ssh/ans.priv

Ok, I run the command:

 $ ansible-playbook setup_apache.yml

 PLAY [fedtest]     
 ****************************************************************

 GATHERING FACTS 
 ***************************************************************
 ok: [fedtest]

 TASK: [Install httpd package]    
 ***********************************************
 failed: [fedtest] => {"failed": true, "parsed": false}
 BECOME-SUCCESS-ajlxizkspxrhyrqauuvywgrtojtutomb
 {"msg": "", "changed": false, "results": ["All packages providing httpd are up to date"], "rc": 0}
 6.719u 1.760s 0:11.33 74.7%     0+0k 0+592io 0pf+0w
 OpenSSH_6.6.1, OpenSSL 1.0.1k-fips 8 Jan 2015
 debug1: auto-mux: Trying existing master
 debug1: mux_client_request_session: master session id: 2
 Shared connection to fedserwizard closed.


 FATAL: all hosts have already failed -- aborting

 PLAY RECAP 
 ********************************************************************
       to retry, use: --limit @/home/abcd/setup_apache.retry

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

 Exit 2

I did do the -vvvv on the ansible-playbook command and it looks like it is failing to execute the shell command to echo the BECOME-SUCCESS string so that playbook can continue instead of erroring out. I've tried these operations on several systems both source and destination and still get the same result.

What type of problem do I need to correct.

Solution

After a lot of experimenting, I notice that if the shell of the client (receiver) of the ansible apparently had to be /bin/bash and NOT /bin/tcsh which is what I had.

Interesting that according to the verbose output that I could find that /bin/sh was being explicitly being called. And to cause an ssh issue was extremely troublesome.

Answered By - mdpc

Answer Checked By - Gilberto Lyons (WPSolving Admin)