RHEL 6 STIG Role

[Sam Doran]

I'm working an a role for the RHEL 6 DISA STIG for anyone that is interested. The project is hosted on GitHub. Once I get 1.0 complete, I'll add it on Ansible Galaxy.

The main philosophy behind the role is a remediation and compliance tool: it is not an evaluation tool. It will make lots of changes to the target system, some of them possibly breaking things (welcome to the wonderful world of STIGS). I'm doing my best to structure the role in such a way that it can be used in a broad or very targeted manner. I use a lot of tags (as a side note, it would be really nice to have a --list-tags option in Ansible). It's currently a work in progress and I welcome input and feedback.

There are certain things that are outside the power of Ansible that are in the STIG, such as performing regular backups. This role should cover a lot of ground in accomplishing STIG compliance though. Plus an Ansible role is much better than a kickstart file, SRR, or home grown shell scripts (all of which I have used in the past with varying levels of frustration)

[Michael DeHaan]

Hi Sam!

Super excited to see this and I'd be interested in talking about organization of it sometime if you are interested.

I did some work with some previous tools to enable this sort of thing and one of the things that was hard then - and a lot easier in ansible, is the ability to make tests and conditionals easy.  Such as, skip these steps if there's no database, etc.

Anyway, this is good stuff!

--Michael

--
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/e56c7476-0da7-49a4-b1f9-60d52101db46%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sam Doran]

I'd love your input on testing whether or not a specific action is applicable. I'm using a combination of setting variables and command/shell actions with register variables to trigger or skip certain actions. My usually strategy to two tasks: the first is a shell/command that runs grep and registers the output. The task runs based on the rc of the registered variable from the previous step. Let me know if there is a better way to do this. Thanks!

[Brent Langston]

This has been on my backlog of things to do... let me know if you want some help and I'll gladly pitch in to work on this with you.

--------
Brent
--------

On Tue, Aug 12, 2014 at 9:13 AM, Sam Doran <sam....@me.com> wrote:

I'd love your input on testing whether or not a specific action is applicable. I'm using a combination of setting variables and command/shell actions with register variables to trigger or skip certain actions. My usually strategy to two tasks: the first is a shell/command that runs grep and registers the output. The task runs based on the rc of the registered variable from the previous step. Let me know if there is a better way to do this. Thanks!

--

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/c095b210-d646-4faa-9339-20ff977c7ef3%40googlegroups.com.