Answers: <p>Maybe try using <code>lsb_release</code> to derive the information, setting it as a fact, then look up the family from an Ansible hash map populated with the associations. Here is a mention of <code>ansible_facts['os_family']</code> at <a href="https://docs.ansible.com/ansible/latest/user_guide/playbooks_conditionals.html#ansible-facts-os-family" rel="nofollow noreferrer">https://docs.ansible.com/ansible/latest/user_guide/playbooks_conditionals.html#ansible-facts-os-family</a></p>
  
Answers: CC BY-SA 4.0
Answers: 2021-10-08T14:01:35.923Z
Answers: 2021-10-08T14:01:35.923Z
Answers: mikequentel
Answers: <p>Based on the link that mr. @mikequentel share</p>
  <blockquote>
  <p><a href="https://docs.ansible.com/ansible/latest/user_guide/playbooks_conditionals.html#ansible-facts-os-family" rel="nofollow noreferrer">https://docs.ansible.com/ansible/latest/user_guide/playbooks_conditionals.html#ansible-facts-os-family</a></p>
  </blockquote>
  <p>There is a list of distro or OS name that listed on <code>ansible_distribution</code> but not on <code>ansible_os_family</code>. So if your OS or distro listed on both you can choose what <code>facts</code> do you wanted to use.</p>
  
Answers: CC BY-SA 4.0
Answers: 2023-08-22T07:37:37.633Z
Answers: 2023-08-22T07:37:37.633Z
Answers: Iyus Dedi Putra
Body: <p>Sometimes in an Ansible playbook, you'll want to condition running a task on whether or not the distribution is CentOS, RHEL, etc, or if it's something else. A very common example is when a package is named one thing on CentOS and something else on Debian.</p>
  <p>I see a lot of Ansible playbooks (and have written a few myself) that will handle this by adding a &quot;when:&quot; to the task like this:</p>
  <p><code>when: ansible_distribution == 'CentOS' or ansible_distribution == 'RedHat'</code></p>
  <p>Is there a reason that that's so common instead of checking for os_family? Why do I not see this more often?:</p>
  <p><code>when: ansible_os_family == 'RedHat'</code></p>
  <p>Besides being more direct and concise, that also allows for other EL Linuxes like Scientific Linux and Rocky Linux without having to continually add to a list of all the possible EL derivatives. Is there something I'm missing?</p>
  
Comments: CC BY-SA 4.0
Comments: 2021-11-07T20:31:08.713Z
Comments: That's not really an answerable question. People wrote their code that way because it met their needs. There are other ways to write it that might also meet their needs, but once they have something that works for them there's no reason for them to go looking for alternative solutions. If `ansible_facts.os_family` meets your needs, use it. If it doesn't, don't.
Comments: flowerysong
Tags: <ansible>
Title: Testing for EL with Ansible facts; distribution or os_family?
UserDisplayName: Todd Walton
ThreadText: # Testing for EL with Ansible facts; distribution or os_family?
  
  (Asked by: username_0 on 2021-10-08)
  
  Sometimes in an Ansible playbook, you'll want to condition running a task on whether or not the distribution is CentOS, RHEL, etc, or if it's something else. A very common example is when a package is named one thing on CentOS and something else on Debian.
  
  I see a lot of Ansible playbooks (and have written a few myself) that will handle this by adding a "when:" to the task like this:
  
  `when: ansible_distribution == 'CentOS' or ansible_distribution == 'RedHat'`
  
  Is there a reason that that's so common instead of checking for os\_family? Why do I not see this more often?:
  
  `when: ansible_os_family == 'RedHat'`
  
  Besides being more direct and concise, that also allows for other EL Linuxes like Scientific Linux and Rocky Linux without having to continually add to a list of all the possible EL derivatives. Is there something I'm missing?
  
  **Tags:** ansible
  
  > **Comments:**
  > **username_1**: That's not really an answerable question. People wrote their code that way because it met their needs. There are other ways to write it that might also meet their needs, but once they have something that works for them there's no reason for them to go looking for alternative solutions. If `ansible_facts.os_family` meets your needs, use it. If it doesn't, don't.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2021-10-08. Score: 2
  
  Maybe try using `lsb_release` to derive the information, setting it as a fact, then look up the family from an Ansible hash map populated with the associations. Here is a mention of `ansible_facts['os_family']` at <https://docs.ansible.com/ansible/latest/user_guide/playbooks_conditionals.html#ansible-facts-os-family>
  
  
  ---
  
  ### Answer by username_3 on 2023-08-22. Score: 2
  
  Based on the link that mr. @username_2 share
  
  > <https://docs.ansible.com/ansible/latest/user_guide/playbooks_conditionals.html#ansible-facts-os-family>
  
  There is a list of distro or OS name that listed on `ansible_distribution` but not on `ansible_os_family`. So if your OS or distro listed on both you can choose what `facts` do you wanted to use.
  
  
  ---
  
  