Published Contribution Guidelines

[Jonathan Davila]

Hello,

I've published the initial Contribution guidelines for ansible-lockdown and can be seen here https://github.com/ansible/ansible-lockdown/blob/master/CONTRIBUTING.md.

I'm more than open to suggestions/criticisms/etc.

[Sam Doran]

A few thoughts on the syntax of the name field.

The initial "| " is unnecessary because it gets inserted when Ansible is run and makes the output look a bit funny.

TASK: [rhel6stig | | HIGH | V-38497 | PATCH | The system must not have accounts configured with blank or null passwords] ***

ok: [stigtest-cos6.infosec.royall.com]

Is it possible to put the description on the same line as the "metadata" in the task? The tasks in prelim.yml are formatted this way and it makes the running output easier to read as well as permits YAML syntax highlighting to work properly in text editors. Syntax highlighting provides a visual indicator that the syntax is incorrect while writing code. Breaking the description across lines breaks this. I propose this:

- name: "HIGH | V-38653 | AUDIT | The snmpd service must not use a default password"

Instead of this:

- name: "| HIGH | V-38653 | AUDIT |\n

        The snmpd service must not use a default password"

Breaking the description across multiple lines was helpful when there multiple findings remediated per task. With the guidelines instructing no more than one remediation per task and that being the goal going forward, a better standard would be putting the description on the same line. The only exception to this I can think of would be if it's not possible to separate out remediations into separate tasks, e.g., what we discussed on GitHub regarding Jinja2 logic inside a template for targeted remediation instead of tons and tons of lineinfile tasks. The broken-across-lines syntax for the name can be the exception rather than the rule.

[Jonathan Davila]

That's a good point that hadn't yet clicked. It does look cleaner to omit the first pipe. And I'm open to removing the new line breaks. If you don't mind, could you open up a PR to the CONTRIBUTING doc?

--
You received this message because you are subscribed to the Google Groups "Ansible Lockdown" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-lockdo...@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-lockdown/98c80eff-8ec2-4a8a-ae16-5493b3ee220e%40googlegroups.com.

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

[Sam Doran]

Sure thing! I'll get a PR together in the morning.

[Sam Doran]

It's been a crazy Monday. I'm still finalizing this PR. Sorry it's taking me so long.

[Jonathan Davila]

No worries, it's no rush. We still have a good ways to go before it's all release ready anyways.

On Mon, Oct 5, 2015 at 4:52 PM, Sam Doran <sam....@me.com> wrote:

It's been a crazy Monday. I'm still finalizing this PR. Sorry it's taking me so long.

--

You received this message because you are subscribed to the Google Groups "Ansible Lockdown" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-lockdo...@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-lockdown/fdaa8703-10ca-41ba-860f-7ff56a1733b0%40googlegroups.com.

[Sam Doran]

I think it would also be helpful to post any information on tests that can be run prior to submitting PRs. I know you did quite a bit of work developing a grown up test for this role. Is there any way to make that available for others to run?

Also, general instructions on running OpenSCAP and STIGMA to validate remediations would also be helpful. Maybe we would distill some of the information in your posts (really great work there, by the way!) and include that in the document. I'm not familiar with Codeship, but is it possible to make your tests available for others to use there?  

[Daniel Shepherd]

I've got a test method I've been using when making changes to the role that don't require going through the Codeship build each time. I had planned on updating the ansible-lockdown repo with a few changes to better support that sort of ad-hoc testing but I just haven't gotten around to it yet. I'll try and bump that up on my list.

[Jonathan Davila]

Good points, I'll see what I can do to open up the test process a bit more along with more elaborate documentation in that regard. I think Bas has a test process he runs via docker as well using https://github.com/dockpack/dockpack IIRC. 

On my end, I'll do this bit once the RHEL6 refactor is complete.

--

You received this message because you are subscribed to the Google Groups "Ansible Lockdown" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-lockdo...@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-lockdown/fde3ee83-ff51-4280-932e-95d1361fc612%40googlegroups.com.