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.
On Thu, May 1, 2014 at 1:59 PM, Adam Morris <zwack...@gmail.com> wrote:
>
>
> 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
>
>
>
> --
> 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-project+unsubscr...@googlegroups.com.
> To post to this group, send email to ansible-project@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<https://groups.google.com/d/msgid/ansible-project/2a1392bc-17c6-42b8-8991-748e9ae24cc8%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
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-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgyAocxjA8uqPWhZC6jxuGGMHPyHJbbHe_hDCttVvcNxOQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
