Issue #2157 has been updated by Ken Barber.
Hey thanks for the help Yury.
In regards to temp space - something I haven't yet discussed in the ticket is
that /tmp is an insecure place to have a named file so I'm probably going to
need to change that as well on Unix to a proper data area.
Its a well known problem - if the file doesn't exist yet its trivial for any
user to create the file with bogus content and thereby prime the cache with bad
content.
Windows doesn't suffer this problem as the temp area generally belongs to a
user ... but I would want to align both using a more valid data storage area.
Generally for data the paths that make sense are:
%APPDATA%\facter (which is %HOMEPATH%\AppData\Remote\facter)
%LOCALAPPDATA%\facter (which is %HOMEPATH%\AppData\Local\facter)
%ProgramData%\facter (which is C:\ProgramData\facter)
In Puppet ... we use:
require 'rubygems'
require 'win32/dir'
Dir::COMMON_APPDATA
Which actually resolves to:
C:\ProgramData
In Windows 2008R2. I'm leaning towards aligning with Puppet here most probably:
File.join(Dir::COMMON_APPDATA, "Puppetlabs", "facter")
Which is:
C:\ProgramData\Puppetlabs\facter
And sub-directories thereof ...
----------------------------------------
Feature #2157: External fact support in /etc/facter.d
https://projects.puppetlabs.com/issues/2157
Author: Paul Nasrat
Status: In Topic Branch Pending Merge
Priority: Normal
Assignee: Ken Barber
Category:
Target version: 2.0.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.
