yum task fails in playbook

Archives Ansible Project
1

Ansible 2.0.0.2

I can run the yum module via ansible ad-hoc command

ansible testloader -i inventory --vault-password-file ~/.vault_pass.txt -u ec2-user -m yum -a “name=* state=latest”

But when I run the module as a task inside the playbook I get module failed

TASK [test] ********************************************************************
fatal: [54.175.222.151]: FAILED! => {“changed”: false, “failed”: true, “module_stderr”: “”, “module_stdout”: “Traceback (most recent call last):\r\n File "/home/ec2-user/.ansible/tmp/ansible-tmp-1454614620.72-202915244324385/yum", line 3767, in \r\n main()\r\n File "/home/ec2-user/.ansible/tmp/ansible-tmp-1454614620.72-202915244324385/yum", line 1025, in main\r\n disablerepo, disable_gpg_check, exclude, repoquery)\r\n File "/home/ec2-user/.ansible/tmp/ansible-tmp-1454614620.72-202915244324385/yum", line 948, in ensure\r\n res = latest(module, pkgs, repoq, yum_basecmd, conf_file, en_repos, dis_repos)\r\n File "/home/ec2-user/.ansible/tmp/ansible-tmp-1454614620.72-202915244324385/yum", line 759, in latest\r\n rc, out, err = module.run_command(yum_basecmd + [‘check-update’])\r\n File "/home/ec2-user/.ansible/tmp/ansible-tmp-1454614620.72-202915244324385/yum", line 2792, in run_command\r\n args = [ os.path.expandvars(os.path.expanduser(x)) for x in args ]\r\n File "/usr/lib64/python2.7/posixpath.py", line 254, in expanduser\r\n if not path.startswith(‘~’):\r\nAttributeError: ‘NoneType’ object has no attribute ‘startswith’\r\n”, “msg”: “MODULE FAILURE”, “parsed”: false}

I don’t understand why this is happening as I have an identical task within a different playbook (using a different set of group hosts), it works.

2

try using single quotes around the -a arguments as the shell might be
trying to 'interpret' the * as a glob

3

In my play I have this:

tasks:

  • name: test
    yum: name=‘*’ state=latest
    become: true
    become_method: sudo

Even when I replace ‘*’ with git or another package it still with the same error message.

4

i cannot reproduce this, looking at the code this would be cause by an
empty path argument to the internal function, but looking at the yum
modules i don't see how this could happen

5

Hmm okay. I’ll blow everything up and start over on this. I am able to get the yum module to run in a play on a different group so I’ll see if updating my inventory or something can make this go away.

6

Figured out the issue. I set some environmental variables (for Oracle sqlplus) in my playbook that caused conflicts with the yum module.