On 3/15/12 1:42 PM, "Steve Grubb" sgrubb@redhat.com wrote:
On Thursday, March 15, 2012 10:14:46 AM Spencer R. Shimko wrote:
As of right now I think this list is the best place to have those conversations.
For content, sure.
Even for puppet content? While I would really like to get it into a SCAP remediation standard it will be in Puppet for now. I know there has been movement towards BASH scripts for the content and honestly the content we written in the past was basically BASH scripts wrapped in a Puppet module. This time around we're using Augeas which I hope will allow us to develop more robust content with far fewer BASH scripts wrapped in Puppet. Thoughts?
One of the goals I have in mind is being able to take an XCCDF file and run it through oscap to generate a fix.
Do you mean OVAL? I'm not sure how XCCDF can be used to accomplish this.
Then slap on a begining section that defines a few global settings that anaconda needs and then we have a kickstart script.
Now you lost me. Why is anaconda part and parcel to the end solution? Or is this for integration into Satellite?
Its possible to do this because the basic commands are present. But if you get too far from that using augeas, for example, then the command might not exist prior to install. I think busybox has the commands that are using during kickstart.
Is this based on the assumption that the fixes will be applied in a spec %post and not a ks %post? If so, why is that desirable? Is there an issue with doing this in %post as opposed to anaconda "proper"?
I guess the real question here is if we should ignore the fact that it isn't in a SCAP standard and push the Puppet-based remediation content into SSG. I would really prefer this approach but I completely understand if the SSG community doesn't want to start cramming non-SCAP content in SSG's git repo.
I'd like to think both can be done. But maybe not. Managing a system by puppet is very different than use cases I am considering. If you ran a scan and found something wrong, wouldn't you need to remediate the repository and push the changes to the system being scanned?
Ah is this coming from the thought of using Puppet Master (puppet server)? While we hope to support that eventually as it is being adopted in some environments right now we just want to run it locally. Install the content in an RPM containing content, run puppet in a %post to remediate. If necessary update puppet content and re-run locally. We aren't to the point of using the puppet master model.
Which reminds me - the first step down this path is to ensure the generated remediation content can be reliably re-applied (e.g. Running it twice in a row won't break things). Then we are closer to integrating into the full Puppet model including Puppet master.
Thanks, --Spencer
Which is a whole kettle of fish different than what I was thinking of.
-Steve