On Jul 14, 2011, at 1:29 AM, Dominic Cleal <[email protected]> wrote:
> On 13/07/11 08:46, Luke Kanies wrote: >> This primarily takes Volcane's code[1], adds tests, and >> splits it into multiple files. >> >> It has support for facts in non-ruby files, using either plain test, >> json, or yaml. You can also have a script that returns facts on >> execution. > > Very nice, this will be useful. > > I'd thought of this as something for the proposed Facter 2.0 redesign. > Will other patches for 2.x targeted features be considered for 1.x now? > (Personally, I'd love to see something to fix #2066 included). I haven't thought much about which version would include this code, but generally any of the open tickets will be released as soon as possible after they're developed. I assume this will make it into something like a 1.7 release or wherever we are now, but if we get enough work done, maybe we would bump to 2.0. We'd certainly accept code for #2066 any time. :) >> Things of note: >> >> * We're defaulting to /etc/facts.d, just like the original code. The >> ticket calls for this to be /etc/facter.d. > > I'd agree with the ticket here, it'd be better to have the product name > in the path as it'll no doubt be needed later for other configuration. > For executable scripts, they should probably be sitting under /usr/share > or lib - perhaps even symlinked back to /etc (Munin does something > similar from memory). > >> * We're defaulting to a cache file in /tmp rather than, say, /var/tmp. >> This is probably fine, but worthy of note. > > Not particularly keen on this - the cache should really be somewhere > that isn't world-writeable, such as /var/cache/facter. > > Could there be attacks where an unprivileged user writes to > /tmp/facts_cache.yaml and Facter (running as root, remember) loads it, > deserialising a dangerous Ruby object inside? It seems to simply let > untrusted data enter a privileged Facter process. > > Similarly, there might be symlink attacks when writing to the file under > /tmp. > >> * There's no way to turn this off or configure any of this at this >> point. > > I think some sort of configuration might be needed very soon, just to > make packaging for different distributions easier. At the very least, > OpenCSW is going to change these paths and this will require patching. > In Puppet, it's trivial to change all of the different cache and > configuration directories (vardir etc.) to other locations. There seems to be common consensus on most of these, so I think we're doing a quick informal survey to see whether we should go straight to a configuration file,or just use different paths on different platforms but have them all determined at install time. I don't have any opinions on it, other than not liking anything in tmp - my main concern is just getting the code in soon. -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
