Node executor ignores "Ansible binaries path" option

[polski-g]

I have ansible installed into a Python virtualenv. (Let's assume I will want a separate ansible install for every Rundeck project)

It is not present on the $PATH. It is at /var/lib/rundeck/_workspace/ansible/venv/bin/ansible-playbook

The Ansible default node executor for my project has the path for the ansible binaries set:

ansible-binaries-dir-path=/var/lib/rundeck/_workspace/ansible/venv/bin
project.ansible-binaries-dir-path=/var/lib/rundeck/_workspace/ansible/venv/bin
resources.source.2.config.ansible-binaries-dir-path=/var/lib/rundeck/_workspace/ansible/venv/bin/

You can see from strace output, when I run an ad-hoc ansible playbook job, that rundeck is just trying to find the ansible-playbook binary on $PATH instead of the exact directory I gave it in the setup.

Rundeck should look in the directory specified (ansible-binaries-dir-path) in the project setup for the binary, should it not?

[rundeck@rundeck ~]$ id 
uid=1000(rundeck) gid=1000(rundeck) groups=1000(rundeck) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

[rundeck@rundeck ~]$ which ansible-playbook
/usr/bin/which: no ansible-playbook in (/var/lib/rundeck/.local/bin:/var/lib/rundeck/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin)

[rundeck@rundeck ~]$ ls -l /var/lib/rundeck/_workspace/ansible/venv/bin/ansible-playbook 
-rwxrwxr-x. 1 rundeck rundeck 257 Feb  2 13:50 /var/lib/rundeck/_workspace/ansible/venv/bin/ansible-playbook

[root@rundeck keys]# strace -f -p 76664 2>&1 | grep ansible-playb
[pid 77444] execve("/var/lib/rundeck/.local/bin/ansible-playbook", ["ansible-playbook", "/tmp/rundeck/ansible-runner64188"..., "-l", ...
[pid 77444] execve("/var/lib/rundeck/bin/ansible-playbook", ["ansible-playbook", "/tmp/rundeck/ansible-runner64188"..., "-l", ...
[pid 77444] execve("/usr/local/bin/ansible-playbook", ["ansible-playbook", "/tmp/rundeck/ansible-runner64188"..., "-l", ...
[pid 77444] execve("/usr/bin/ansible-playbook", ["ansible-playbook", "/tmp/rundeck/ansible-runner64188"..., "-l", ...
[pid 77444] execve("/usr/local/sbin/ansible-playbook", ["ansible-playbook", "/tmp/rundeck/ansible-runner64188"..., "-l", ...
[pid 77444] execve("/usr/sbin/ansible-playbook", ["ansible-playbook", "/tmp/rundeck/ansible-runner64188"..., "-l", ...

[edrik]

Can confirm this, encountered the same while trying to use ansible from a custom venv path. Using the same venv binary path for importing nodes from the ansible inventory works.

[dingouerinitx]

I have a related problem and would like to have someone confirme that this is not just a problem with my setup and is related to this.

Brief: The "Ansible binaries directory path" in the Project Settings is not safed after clicking "Save" button. No error appears.

Rundeck: 4.13.0 Ansible-Plugin: ansible-plugin-3.2.3.jar

To reproduce the issue/bug do:

1. Go to Project -> Project Settings -> Edit Configuration
2. Change to Tab "Default Node Executor" -> "Ansible Ad-Hoc Node Executor"
3. Set "Ansible binaries directory path" to your venv bin or any value (in my case /etc/ansible/venv-ansible/bin)
4. Adjust other mandatory fields
5. Click "Save"

You will jump back to your project, so go back to the Settings via (Step 1 and 2 above)

The "Ansible binaries directory path" field is still empty and not set in my case.

Before: Saving

After: Saving and Return

Question 1: Can this be verfied as a bug or setup issue on my side? Thanks for clarification.

Question 2: Where is/should the value be saved on the machine? In DB, on Disk? I checked the DB and could not find it so far. (Using postgresql). I checked under /etc/rundeck in the *.properties files and could not find it either.

[MegaDrive68k]

Confirmed on the latest Rundeck / Plugin version.

[andrewm659]

I was told there is a work around. I was given this as the work around - https://imgur.com/9fiCwoT Is there a way to this at the project level? I would have to changes lots of projects to resolve this.

[andrewm659]

Is anyone using the h2 database while having this issue? I'm using it because i'm still testing.

[andrewm659]

Hello, any update on when this will get resolved? It is blocking our ability to update and migrate the application.

[andrewm659]

So I just installed the rpm version of rundeck on CentOS Stream 9. I used the default DB (h2). I then created a new project and went back into the settings and was able to configure the Ansible path. After hitting save it worked. Also this was in the Edit Nodes -> Sources -> Ansible Resource Model Source. But this works!!! Has anyone else tried this?

[dingouerinitx]

Whats the progress on this? Is any java developer looking into this?

[andrewm659]

This is a bit of a show stopper for us. Not sure how others are getting around this....

[simon-c-msc]

I have a related problem and would like to have someone confirme that this is not just a problem with my setup and is related to this.

Brief: The "Ansible binaries directory path" in the Project Settings is not safed after clicking "Save" button. No error appears.

Rundeck: 4.13.0 Ansible-Plugin: ansible-plugin-3.2.3.jar

To reproduce the issue/bug do:

1. Go to Project -> Project Settings -> Edit Configuration
2. Change to Tab "Default Node Executor" -> "Ansible Ad-Hoc Node Executor"
3. Set "Ansible binaries directory path" to your venv bin or any value (in my case /etc/ansible/venv-ansible/bin)
4. Adjust other mandatory fields
5. Click "Save"

You will jump back to your project, so go back to the Settings via (Step 1 and 2 above)

The "Ansible binaries directory path" field is still empty and not set in my case.

Before: Saving

After: Saving and Return

Question 1: Can this be verfied as a bug or setup issue on my side? Thanks for clarification.

Question 2: Where is/should the value be saved on the machine? In DB, on Disk? I checked the DB and could not find it so far. (Using postgresql). I checked under /etc/rundeck in the *.properties files and could not find it either.

Looks like it's solved in the latest version (4.15) but sadly it's still not used at the job level.

My bad, it's still an issue in 4.15.0 :(