19:34:11 <cyberpear> #startmeeting Ansible Lockdown Working Group
19:34:11 <zodbot> Meeting started Thu Apr  9 19:34:11 2020 UTC.
19:34:11 <zodbot> This meeting is logged and archived in a public location.
19:34:11 <zodbot> The chair is cyberpear. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:34:11 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:34:11 <zodbot> The meeting name has been set to 'ansible_lockdown_working_group'
19:34:55 <cyberpear> I merged a bunch of the CIS role PRs, then had to revert one of them b/c of a conflict that caused failed tests
19:35:31 <cyberpear> I don't want them to linger and have contributors get discouraged, but I don't actually use the RHEL CIS role myself.
19:35:51 <xgeorgex> Ok. David is still working on transferring the repos on GitHub to community
19:36:01 <cyberpear> sounds good
19:36:14 <xgeorgex> It sounds like he's close to making that happen, but he's still working on it
19:37:14 <cyberpear> I want to get a good role template going to allow us to re-use tasks across different security standards, with such a role runing the relevant task subset based upon the selected standard
19:38:16 <cyberpear> SCAP Security Guide has a process where they template out entire ansible tasks, but their approach is backwards: they use jinja to lay down the tasks, instead of jinja within the tasks to affect behavior
19:38:17 <xgeorgex> nice. That was something that we have talked about on our side
19:38:25 <cyberpear> the result is a giant mess
19:38:46 <xgeorgex> I think as something once we get a few of the recent payed for roles finished up
19:39:04 <xgeorgex> Oh that's weird
19:39:57 <xgeorgex> I updated the Oscap stuff in the RHEL7 stig role yesterday. Apparently the profile name for rhel7 stig changed
19:40:18 <cyberpear> that seems to happen from time to time
19:41:16 <cyberpear> Seems the oscap part would be best as a separate role, to avoid duplication of effort across roles.
19:42:45 <xgeorgex> That's a good idea. That's how it was when I picked things up back in December, so I'm not sure if there are reasons for it be included in the roles
19:42:56 <cyberpear> then we can include the optionally oscap role at the start and end as/if requested by the role user
19:43:08 <cyberpear> using `include_role`
19:44:16 <xgeorgex> That's def. stuff to run by dfed to get his input on that. I can make a note to ask him about it
19:44:18 <cyberpear> worst case, use `git subtree` and have a copy in each role, but only ever update the master copy, then re-copy, kind of like how golang likes to `vendor/` stuff into a directory
19:44:52 <cyberpear> I really don't like having lots of copies of things around, but if you do, have a clear indication of where is the master copy
19:47:02 <dfed[m]> I have always meant to separate out oscap and molecule testing from the roles to use one subtree.
19:47:15 <dfed[m]> in my copious amounts of spare time
19:47:26 <xgeorgex> Yeah the more things around the more confusing and/or likeliness to get things mucked up are. For me the slimmer things are the better
19:47:28 <cyberpear> (and/or submodules, depending on your preference)
19:48:12 <cyberpear> I tend toward "one role per discrete task", but that doesn't necessarily scale w/ "security standard" roles
19:49:00 <xgeorgex> yeah
19:49:05 <cyberpear> for example, my nss-module role really should be an ansible module, but it's a role with module-like inputs: https://github.com/jamescassell/ansible-role-nss-module
19:49:51 <cyberpear> #chair xgeorgex dfed[m]
19:49:51 <zodbot> Current chairs: cyberpear dfed[m] xgeorgex
19:50:00 <cyberpear> anything else new?
19:50:21 <xgeorgex> I finished up a pre 1.0 release of apache stig
19:50:28 <cyberpear> cool!
19:50:35 <xgeorgex> It's for both RHEL and ubuntu
19:50:37 <cyberpear> I might try to check that one out
19:50:58 <cyberpear> until now, I've been pushing folks to use nginx solely because there's no STIG to implement for it :P
19:51:29 <cyberpear> I think we still need to follow up on the "lockdown" ansible collection to gather a place to support the ansible community.general modules we depend upon
19:51:41 <xgeorgex> yes
19:51:52 <xgeorgex> I poked dfed yesterday to see if he heard back from the RH folks and he hasn't
19:52:11 <xgeorgex> There were basic modules that I assumed weren't community that are, replace is one that we use a lot
19:52:51 <cyberpear> I could have sworn `replace` is in core?
19:53:15 <cyberpear> I'll try to get some time before next meeting to send an e-mail about a "lockdown" collection
19:53:16 <xgeorgex> I feel like, at least on our LE side, our roles don't use a large number of modules. The ones we do use seem to have a pretty good track record, so I wonder if they could push some through to not Supported
19:53:25 <xgeorgex> Since it's not a massive number
19:53:55 <xgeorgex> I was hoping they would get us a list of what needs to happen for a module to become S supported
19:54:10 <cyberpear> it was just a handful: `pamd`, `ini_file`, `firewalld`, `selogin`
19:54:30 <cyberpear> RH already indirectly supports `selogin` via their `linux-system-roles/selinux` role
19:54:55 <cyberpear> (I'd copied it from there to ansible proper, with cleanups and tests for it.)
19:55:17 <xgeorgex> nice
19:56:31 <cyberpear> anything else for today?
19:56:45 <xgeorgex> I think that was it on my side
19:56:57 <xgeorgex> Anything else on your side?
19:57:04 <cyberpear> nothing else from me
19:57:08 <cyberpear> #topic Open Floor
19:57:15 <cyberpear> any lurkers with questions/comments?
19:57:26 <cyberpear> otherwise, I'll close the meeting in a minute or so
20:01:53 <cyberpear> thanks!
20:01:55 <cyberpear> #endmeeting