coming soon: consistency checking scripts

Spencer R. Shimko sshimko at tresys.com
Mon Mar 19 13:45:41 UTC 2012


On 3/16/12 12:47 PM, "Steve Grubb" <sgrubb at redhat.com> wrote:
>
> 
>> >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?
>
>No. I'd have to see it work. But in the appliance situation they want a
>minimal 
>system. So, the common denominator is shell and busybox.

So all we have to do is get Ruby, Puppet, and Augeas in busy box right? Or
perhaps just switch RPM's baked-in Lua interpreter to Ruby.  ;)

Our experiences developing appliances based on Red Hat leads me to
believe that sticking to the least common denominator is not appropriate
approach.  We tried this for years before switching to Puppet. Add the
package you need to leverage to the packages list, e.g. Puppet, then
remove it at the end of %post.  Hacking around in shell scripts is far
from a robust solution to t‡he problem.  Of
course this doesn't help at run-time but our customers have totally
different ideas about handling systems at run-time and tend to completely
avoid changes once a system is deployed.

This triggers another thought though - how do you account for the deps for
the shell scripts themselves?  Granted most will be sed/awk/etc but once
again this is an issue that increases the fragility of the shell script
solution.  Perhaps it can be solved by stating you can only use things in
@Base and @Core but we intentionally don't leverage groups when building
our solutions.  At least with the pure Puppet/Augeas solution that isn't
an issue.

--Spencer

>
>
>-Steve




More information about the scap-security-guide mailing list