On 3/14/12 2:23 PM, "David Egts" degts@redhat.com wrote:
----- Original Message -----
On 3/14/12 12:49 PM, "David Egts" degts@redhat.com wrote:
----- Original Message -----
On Wednesday, March 14, 2012 12:41:51 AM Spencer R. Shimko wrote:
On 3/13/12 9:52 PM, "Shawn Wells" shawn@redhat.com wrote:
On 3/13/12 9:44 PM, Steve Grubb wrote: > On Tuesday, March 13, 2012 07:37:07 PM Jeffrey Blank wrote:
<snip> >> > >> > I understand that we can generate whatever we want from the >> > <fix> >> > tags but >> > I want to ensure the generated content is consumable by the >> > larger >> > community. Are the <fix> tags flexible enough to support the >> > forward >> > movement of system configuration tools? >> > >> > I know the rest of this is long but bear with me here because, >> > much >> > like >> > SCAP, there are a lot of relationships that must be addressed by >> > a >> > successful solution. >> >> There are hard fixes and there are easy fixes. Let's look at one >> publicly >> available validated solution: >> >> http://people.redhat.com/sgrubb/files/usgcb/rhel5/workstation-ks.cfg >> >> NIST published an exact copy of that file. Look at what is being >> done >> to configure >> the system. The vast majority break down to this: >> >> chkconfig >> chmod >> echo >> gconftool-2 >> mkdir >> rpm --import >> sed >> touch >> useradd >> >> They are all one liners. Now if a package was required and it >> needing >> to be in a >> specific configuration and it drags in dependencies and they also >> have changes to >> their configs or perhaps have multilpe daemons which may or may >> not >> need to be >> enabled or disabled...we have a hard problem. In which case, maybe >> the solution >> is: >> >> echo "Requirement xyz cannot be met by this script, please solve >> it >> manually. Do >> you understand? [y/n]" >> read ANS > >That's a great idea. It would also be good to have a yum-like "-y" >option for automation. One wouldn't want to run the remediation on >1000 >systems interactively by hand.
Are you thinking of something significantly different from the secstate effort?
If that's the accepted approach, great! I'm just saying that automation (however we do it) is highly desired.
So does SSG plan to provide secstate remediation content? Apologies for the n00b question.
Jeff and I have been discussing this and I think that we will host the Puppet remediation content as part of the CLIP project. When/if the SCAP remediation standard is mature enough to handle the task we will convert the content and push it to SSG.
We have also discussed the issue of binding the two sets of content (SSG and Puppet in CLIP). We have some ideas here but nothing significant.
I'm definitely interested in any input you or other members of the list have on this plan. Particularly since I see the binding of content from two repos to be very fragile.
Also, it looks like secstate is tied closely with Puppet (good intro for me = https://fedorahosted.org/secstate/wiki/RemediationContentHowTo). How would one use secstate if their DAA doesn't allow packages from community supported sources (i.e., puppet from EPEL)? Maybe Red Hat's possible formal support for Puppet in the future will eventually solve this, but I wonder what the plan would be in the mean time.
This is certainly an issue and I don't have an answer. To-date our CLIP user base has been OK with us including Puppet and a few other necessary packages from EPEL. It is basically devs rolling custom ISOs with the EPEL packages already included. I'm not sure if their DAAs have been made aware. For better or worse I think they just aren't telling them this level of detail.
Thanks, --Spencer
Thanks for helping me learn more about this Spencer!
Dave