Group variables conditional based on OS distribution release

Archives Ansible Project
1

Hi,

After various docs and some trial and error, I can’t figure out how to handle setting a variable differently when the target operating system version is newer than a certain release. OpenBSD 5.8 and newer have replaced sudo(8) with doas(1), so I’d like to set ansible_become_method correctly based on the OS version. The only idea I could come up with was this template logic in /etc/ansible/group_vars/openbsd, which is clearly incorrect:

{% if {{ ansible_distribution_release | version_compare(‘5.8’, ‘>=’) }} %}
ansible_become_method: doas
{% else %}
ansible_become_method: sudo
{% endif %}

What is the correct/cleanest way to ansible_become_method conditionally for a given OS family based on the value of ansible_distribution_release?

Ansible manager: ansible 2.0.1.0 on OpenBSD 5.7

Managed nodes: OpenBSD 5.7, OpenBSD 5.8, various Linux

Thanks,

2

​Y​
ou cannot use jinja2 commands in vars file, the templates are not used in the vars file, they are just assigned as strings that later get recognized as templates and templated. But you can do this:

ansible_become_method: “{{ (ansible_distribution_release|version_compare(‘5.8’, ‘>=’))|ternary(‘doas’, ‘sudo’) }}”

—​

3

We do stuff with inventory variales and dicts, like

  become_method:
    5.7: doas
    5.8: doas
    6.0: sudo

  ansible_become_method: become_method[ansible_distribution_release]

You can't do the >= thing this way, you have to enumerate all the options.
(Or you could have a default and only enumerate the ones that are
different from the defaults.) You might have to quote the numbers if
ansible_distribution_release is a string, I've gotten tripped up by stuff
like that once in a while but don't remember if this is one of them. :^)

                                      -Josh (jbs@care.com)

This email is intended for the person(s) to whom it is addressed and may contain information that is PRIVILEGED or CONFIDENTIAL. Any unauthorized use, distribution, copying, or disclosure by any person other than the addressee(s) is strictly prohibited. If you have received this email in error, please notify the sender immediately by return email and delete the message and any attachments from your system.

4

This looks elegant, thanks. In my environment when I run the playbook using
this configuration, it fails with the variable showing undefined:

$ ansible-playbook site.yml --limit sinoptik --tags snmpd

PLAY

5

yes, you need to gather facts before that variable is available, you might want to use |default filter to avoid the error

6

I'm still finding myself stumped on this.

7

Hi Darren,

I'm still finding myself stumped on this.

See my answer below.

yes, you need to gather facts before that variable is available, you might want to use |default filter to avoid the error

ansible_become_method: "{{
(ansible_distribution_release|version_compare('5.8',
'>='))|ternary('doas', 'sudo') }}"

I think Brian meant something like this:

ansible_become_method: "{{
(ansible_distribution_release|version_compare('5.8',

'>='))|ternary('doas', 'sudo')|default(sudo) }}"

This way, when ansible_distribution_release is undefined, the
default(sudo) strikes and sets a default. Once
ansible_distribution_release is defined, default does nothing anymore.

Johannes