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 <[email protected]
> 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 [email protected].
> 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 [email protected].
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