On 03/19/2012 02:45 PM, Spencer R. Shimko wrote:
On 3/16/12 12:47 PM, "Steve Grubb" sgrubb@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. ;)
What about small/embedded devices. Or some medical appliances with small memory, augeas is simply too heavy for them. So it boils down to shell or even C. (Maybe these devices are out of concern for this list. (?))
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