Issue #2157 has been updated by Yury Zaytsev.
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. Yes, it doesn't feel right, but consider 1) rc.local and all the like 2) this is about the only place that it consistently considered to contain files that are directly modified by the user / administrator 3) the scripts don't have to have executable bits set, one can fork an interpreter according to the shebang line and if it is not there, exec it The latter probably doesn't make a difference / solve anything, but anyway. > /usr/share/facter/facts.d makes more sense. Some people mounst /usr as > read-only, so that might be a problem. /usr/share is only supposed to have 1) noarch stuff, and generally not executable directly 2) stuff not directly modifiable by the user (which is why many people mount it as read-only) > Something in /var/lib/facter/facts.d > /var/lib is probably best. We can easily symlink from etc to /var/lib. Sounds better than /usr/share but still does feel SO good. Many paranoid people mount /var with noexec, for instance (which will never happen to /etc for reasons above), just because /var is for software-generated transient data which is normally not to be executed. AFAIK, according to FHS this is what /usr/libexec/packagename is officially for, although mostly for arch-dependent binaries. Still it doesn't solve your read-only concern. All this is getting real ugly :-( Maybe just go for /etc and get over it? > As far cache, the pathing discussed the far is ok. We could use > /var/cache/facter as well. Sounds like it's a perfect place for cache. > In the end will this be configurable for path locations? Err, apparently yes. 0.02 € ---------------------------------------- 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.
