Issue #2157 has been updated by Ken Barber.
Michael Stahnke wrote: > I'm a jerk and thought about this more. I hate executable scripts in etc. > It's wrong. While FHS isn't clear, maybe we could do something better than > put it in etc. Something in /var/lib/facter/facts.d or > /usr/share/facter/facts.d makes more sense. Some people mounst /usr as > read-only, so that might be a problem. /var/lib is probably best. We can > easily symlink from etc to /var/lib. I hear you - I've been pondering it myself actually. The closest thing I can find is: "/usr/lib includes object files, libraries, and internal binaries that are not intended to be executed directly by users or shell scripts." /usr/share is architecture independent (which may or may not be true). /var/lib is for variable 'data'. So I would rule these out. Maybe /usr/lib/facter/facts.d ? (another note - Does the 'something.d' sound silly to you or is it just me? This generally applies to breaking up configuration which isn't what we are doing here. Maybe just /usr/lib/facter/ext or something.) The closest example of this in another application is actually: /usr/lib/nagios/plugins/check_foo (at least thats the path on debian) > Sorry for a reversal on my decision, but after reviewing some other code with > scripts in etc, I don't think we want to be part of that problem. Fair enough I think. FHS does explicitly state no execs. > In the end will this be configurable for path locations? It will be - either through API or command line arguments. But the sensible defaults should be the 'best' option. > If I've spoken up to late, just tell me and I'll shut up and deal with it :) No its cool. We can rework it. Its stuff like this we need to get right up front. ---------------------------------------- Feature #2157: External fact support in /etc/facter.d https://projects.puppetlabs.com/issues/2157 Author: Paul Nasrat Status: Code Insufficient Priority: Normal Assignee: Ken Barber Category: Target version: 1.7.0 Keywords: Branch: kbarber/tickets/master/2157-external_fact_support Affected Facter version: Facter should support non-ruby facts, preferably in /etc/facter.d. It should support these facts being either executable, in which case the result is the value of the named fact, or in a data format such as yaml, in which case the data file is read in and interpreted as the fact value. It probably makes sense to initially stick to yaml for data formats, since json doesn't ship with ruby, and to also allow executable facts to return either a plain string or yaml. Note that we can do this without supporting any kind of overriding, but it'd be much better if we supported multiple (configurable?) fact directories, with a search path. Thus, if Facter shipped with /etc/facter.d/myfactname and you wanted to override it, you could do so by creating a new file and putting it in a higher-priority location rather than editing a file distributed with the core. Given we're adding structured data support, namespaced facts would be supported with directory structures; e.g., /etc/facter.d/my/fact/name would resolve to my::fact::name. Ideally, the long-term direction here would be not to require any pure-ruby facts, such that the Facter library could be rewritten in any other language and it would function the same, because all of its actual data is outside of ruby. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" 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-bugs?hl=en.
