Hey John,

We added this to 'simplib' a while ago. We named it 'simp_puppet_settings'
so we didn't get name smashed whenever Puppet Inc decides to incorporate it.

https://github.com/simp/pupmod-simp-simplib/blob/master/lib/facter/simp_puppet_settings.rb

Thanks,

Trevor

On Fri, Apr 13, 2018 at 5:04 AM, Henrik Lindberg <henrik.lindb...@puppet.com
> wrote:

> On 12/04/18 14:58, jcbollinger wrote:
>
>>
>>
>> On Wednesday, April 11, 2018 at 11:28:12 AM UTC-5, Henrik Lindberg wrote:
>>
>>     On 11/04/18 18:21, jcbollinger wrote:
>>      > I'm writing a module for Puppet self-management, or at least I
>>     think I
>>      > am.  I was surprised to not find very much along those lines on the
>>      > Forge, and maybe I should take that as a bad sign, but I want to
>>     explore
>>      > it at least a little bit.  Maybe I just didn't find the right
>> search
>>      > terms -- searching there for "puppet" is not very useful.
>>      >
>>      > Anyway, I've run into a snag with a threshold issue: how to find
>> the
>>      > config file(s) to manage in the first place.  I know where Puppet
>>     stores
>>      > its config files by default, for various versions of Puppet and for
>>      > various operational contexts, but with the existence of the
>>     --confdir
>>      > option that can be specified on a per-run basis, it is not safe to
>>      > assume that the config files that informed the current Puppet run
>>     is in
>>      > the default location (and those are the ones I want to manage).
>>  In any
>>      > case, I'm lazy, so I'd rather get Puppet to tell me what it already
>>      > knows than try to recompute it.
>>      >
>>      > But there does not seem to be a standard fact that communicates
>> this
>>      > information (at least, 'puppet facts' does not print one), and
>>     I'm not
>>      > seeing any appealing ways to extract the necessary information
>>     from a
>>      > custom fact's runtime context.  I do see at least one nasty,
>>     tricksome,
>>      > system-dependent way, but I'm more likely to chuck the whole idea
>>     than
>>      > go there.  Am I missing some clean way to write a custom fact for
>>     this
>>      > purpose?  Or does someone have an alternative to suggest?
>>      >
>>
>>     Have you read the documentation regarding $settings ?
>>     https://puppet.com/docs/puppet/5.5/lang_facts_and_builtin_
>> vars.html#puppet-master-variables
>>     <https://puppet.com/docs/puppet/5.5/lang_facts_and_builtin_
>> vars.html#puppet-master-variables>
>>
>>
>>     - henrik
>>
>>
>>
>> Thanks, Henrik, I'm not sure I had read those in detail, since they come
>> under the heading of variables set by the master, and the whole problem is
>> that the master doesn't have the wanted information.  Still, having now
>> read them, I find that the documentation seems to agree with my
>> expectations.  In particular:
>>
>>     Note that, other than $environment and $clientnoop, the agent node’s
>>     settings are not available in manifests. If you wish to expose them
>>     to the master in this version of Puppet, you will have to create a
>>     custom fact.
>>
>>
>> Creating a custom fact to report on the agent's /dynamic/ $confdir
>> setting, as recommended by those docs, is precisely what I would like to
>> do.  What I'm struggling with is how the fact implementation can determine
>> the value for such a fact, inasmuch as the value I want is a property of
>> the puppet (agent) process on whose behalf Facter is computing facts.
>>
>>
> I recall now that we have a ticket with a request to make agent settings
> available on the master side. No progress on that for quite some time
> though. Not sure if ticket is still open or if it was closed in the last
> big triage. I assume it could be implemented as sending all of the settings
> as one fact. Or - indeed as you plan, just the actual setting you are
> interested in.
>
> - henrik
>
> --
>
> Visit my Blog "Puppet on the Edge"
> http://puppet-on-the-edge.blogspot.se/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/ms
> gid/puppet-users/paprm7%24t64%241%40blaine.gmane.org.
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788

-- This account not approved for unencrypted proprietary information --

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CANs%2BFoXG48JLkNdkTphS7BeutUL1eB8rBxbpy5Y0OxQwh2LaMw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to