When you gather facts on the machine, you should be able to see the
'PATH' that ansible sees under ansible_env, ansible uses it's own path
list to find apt and dpkg, but that should not influence the other
tools, which ansible is not using directly.
When you gather facts on the machine, you should be able to see the
‘PATH’ that ansible sees under ansible_env, ansible uses it’s own path
list to find apt and dpkg, but that should not influence the other
tools, which ansible is not using directly.
Thanks for your response. If I understand you correctly, I can also do this to see what PATH Ansible is using:
The USERNAME of “root” tells me that Ansible is correctly sudo-ing before running the setup, so I’d expect it to be doing the same before apt-ing.
If this is the PATH setting when Ansible runs apt-get though, it’s no surprise to me that it’s failing when it tries to hit things in /sbin.
What could be responsible for this discrepancy in the PATHs based on how the system is being accessed? Is this likely to be a system configuration issue or an Ansible (v1.9.1) issue?
I can’t really see an issue there, but I’m not very experienced with these files. I note though that if I SSH into this machine manually, the PATHs are still okay:
I’ve been unable to resolve this issue with the ideas presented so far. In the absence of any further responses, should I consider this an Ansible bug and file a bug report?
i'm unable to reproduce the issue, the path seems fine, not sure if
its a bug or not, but without a way to reproduce the issue I'm not
sure how it will get resolved.
if you are looking for problems with sudo you can login as your ansible user and issue “sudo -l”. This will list all commands your ansible user is allowed to use.
From your sudo config files, %sudo group can fire all kind of commands, but needs a password. That’s by intention?
if you are looking for problems with sudo you can login as your ansible user and issue “sudo -l”. This will list all commands your ansible user is allowed to use.
The output of this command on the affected machine is as follows:
$ sudo -l
Matching Defaults entries for osmc on osmc:
env_reset, mail_badpass, secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin, env_keep+=RPI_UPDATE_UNSUPPORTED, !secure_path
User osmc may run the following commands on osmc:
(root) NOPASSWD: ALL
To me, this indicates that after running sudo, the PATH should still contain /sbin. My problems with Ansible’s apt module seem to strongly indicate that this is only not the case when Ansible is involved. Although I appreciate that this is not easy to replicate on another machine, I still feel that on the current balance of probabilities, this indicates an Ansible bug. I’m happy to provide Ansible developers with SSH access to this particular machine for further diagnosis if it’s not possible to suggest any other solutions at this time.
From your sudo config files, %sudo group can fire all kind of commands, but needs a password. That’s by intention?
This is a largely pre-configured system based off another distribution, so it wouldn’t surprise me if this definition is an unintended remnant from the base distribution. The Ansible user is not part of the sudo group. so I don’t believe it should have any effect.
which prompted me to cut out Ansible altogether and just try this:
$ ssh osmc@XXX /bin/sh -c ‘“echo $PATH”’
OSMC: Open Source Media Center
osmc@XXX’s password:
/usr/local/bin:/usr/bin:/bin:/usr/games
$ ssh osmc@XXX /usr/bin/sudo -u root /bin/sh -c ‘“echo $PATH”’
OSMC: Open Source Media Center
osmc@XXX’s password:
/usr/local/bin:/usr/bin:/bin:/usr/games
which is a very different PATH to when I log in interactively:
$ ssh osmc@XXX
OSMC: Open Source Media Center
osmc@XXX’s password:
osmc@XXX:~$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin:/opt/vc/bin
osmc@XXX:~$ sudo echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin:/opt/vc/bin
So on the bright side, it doesn’t seem to be an Ansible problem after all, which means it’s probably out of scope for this discussion group. Time to read up on the differences between interactive, non-interactive, login and non-login bashsessions, it seems…
Thanks anyway for all of your attention to this point. I’m sorry to have wasted your time.
Worked for me so far and I don’t have to set env vars during apt tasks (useful because I don’t want to alter my site-yml playbook for just the osmc node).