Need help organizing tasks/playbooks for multiple operating systems

[Snyder, Chris]

I’m stuck.  I’m sure this can all be done a better way, but right now, I’m just not seeing it. Can anyone offer suggestions of what else to try here?

 

Originally I started with one operating system, so it writing up a ansible playbook for the core OS configuration was simple and I ended up with a lot of stanzas like this:

- hosts: all:!tftp-server

  sudo: true

  tasks:

    - name: Ensure tftpd server removed

      yum: name=tftp-server state=absent

 

- hosts: tftp-servers

  sudo: true

  roles:

    - tftp-server

 

And I did this for *EVERY SERVICE* (xinetd, vsftpd, httpd, etc….) on my hosts. In short, if it didn’t have to be on, it had to be explicitly disabled. [If there’s a better form for these types of patterns, PLEASE let me know – it’s so verbose and ugly, especially duplicated for every service I have on my boxes.]

 

Now, I’m adding a second OS to my playbooks.  So I created a second parallel playbook with similar code customized for the new OS.  But now, my problem is that when I’m setting up a new box, how do I have Ansible determine which playbook to run? My head is telling me what I want to do is this: create an Ansible playbook ‘os_core.yml’ which can determine the distro/version of the OS on the target box then execute the correct OS-specific playbook for that distro/version.  But how do I do that?  I can’t do include playbook with variables in the path and I can’t move all this to roles as I need to be able to differentiate plays based upon host groups.  I REALLY do not want to create a giant single playbook which has rules for host groups based upon things like ‘rhel5-tftp-server’ vs ‘centos6-tftp-server’.  That just doesn’t scale.

 

I’m open to any and all suggestions here.

 

Thx

Chris.

[Adam Morris]

On Thursday, May 1, 2014 10:12:58 AM UTC-7, Snyder, Chris wrote:

I’m stuck.  I’m sure this can all be done a better way, but right now, I’m just not seeing it. Can anyone offer suggestions of what else to try here?

 I'm sure that there are many better ways...

First, you can detect you OS programmatically and add it to the appropriate group...  I start with a playbook that has this...

---

# file: group.yml

- hosts: all

  gather_facts: true 

  tasks:

    - group_by: key={{ ansible_os_family }} 

    - group_by: key={{ ansible_product_name.split()[0] }}

 

This creates a group for each OS family (RedHat/Debian/AIX) but you can be more specific if you want, and one that lets me detect HP Proliant hardware (I have some tasks specifically for that...)

Then I run some playbooks with generic tasks some of which have alternatives for different OSes.  Equally I could split these into four roles, one for Generic tasks, and one for each of the OS variants...

If the only difference between two tasks is some parameters (This file should be owned by group "sys" on this OS but "root" on that...) then I use variables for those differences and set variables for different groups in the group_vars directory.

 

And I did this for *EVERY SERVICE* (xinetd, vsftpd, httpd, etc….) on my hosts. In short, if it didn’t have to be on, it had to be explicitly disabled. [If there’s a better form for these types of patterns, PLEASE let me know – it’s so verbose and ugly, especially duplicated for every service I have on my boxes.]

Much better would be to have a list of services to disable and use with_items...

  - name: Ensure servers removed

    yum: name={{ item  }} state=absent

    with_items: remove_server_list

You can get fancier still, but this should be enough to get you moving along cleaner lines...

I hope that this helps,

    Adam

  

[Michael DeHaan]

I think this comes from some sort of OCD and you may wish to give this up :)

State what should be on the machines, not what should not. 

It would be impossible to define all the things a server could not be.

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/2a1392bc-17c6-42b8-8991-748e9ae24cc8%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Brian Coca]

If you really really need to ensure that software wasn't installed by mistake, keep package list dumps and compare to that, much more efficient than doing it package by package.​

[Adam Morris]

I have to say that I agree.  I was trying to show a better general solution but in my case I use an initial os load that puts the absolute minimum on the server.  Then I add to it with ansible.

On May 1, 2014 3:01 PM, "Brian Coca" <bria...@gmail.com> wrote:

If you really really need to ensure that software wasn't installed by mistake, keep package list dumps and compare to that, much more efficient than doing it package by package.​

--
You received this message because you are subscribed to a topic in the Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ansible-project/uCF7I-nx3zs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ansible-proje...@googlegroups.com.

To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CADn%2BHszft%3DvsO%2BT8YWkpLPPSXszmVAfrfb6f5XMZZtdsVS-1yA%40mail.gmail.com.

[Snyder, Chris]

It’s not so much OCD as it is DISA STIG.  The RHEL6 STIG rules explicitly state for specific services that if it’s not needed on a host it must be disabled/uninstalled.  Granted I don’t need to do that for every possible service, but I do have to do it for specific services.   What I may end up doing is have a general ‘base’ OS playbook for when I’m setting up host that only turns on stuff.  And then have a separate STIG playbook that I run occasionally to ensure that only those needed services on a given host are actually enabled and other STIG-identified services are not.

 

Thx, all.

Chris.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgyAocxjA8uqPWhZC6jxuGGMHPyHJbbHe_hDCttVvcNxOQ%40mail.gmail.com.

[Michael DeHaan]

"It’s not so much OCD as it is DISA STIG.  The RHEL6 STIG rules explicitly state for specific services that if it’s not needed on a host it must be disabled/uninstalled."

I did a small amount of consulting around STIG for a previous systems management app company -- so I know what you are talking about.   Ultimately, those tools are not *great* at describing something that isn't there, and this still holds for Ansible, though having a list of services to remove and doing the following is not heinous evil:

   - yum: name={{ item }} state=absent

     with_items: packages_to_remove

Etc.

(Of course if someone installs "banned_package" in /usr/local/you-are-not-going-to-find-it, that's not a complete solution)

Thanks for clarifying the use case!

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/BFD6B7398AEB474A9A28B39B9B5D00CB588A7183%40SRAexMBX05.sra.com.