I have tried additionally disconnecting puppetdb via removing storeconfigs
and puppetdb.yaml on the puppet master.
I'm looking for more direct evidence of what fact values the master
receives. Humor me, please.
If I run Factor on deb-vm it matches
: escribió:
Please, could you try using $::operatingsystem?
It could be some variable scoping problem...
Regards,
El 31/01/2014 18:27, Doug_F dfor...@part.net javascript: escribió:
I have tried additionally disconnecting puppetdb via removing storeconfigs
and puppetdb.yaml on the puppet master
/etc/debian_version is in place and facter on the box returns correctly.
If I run the puppetmaster in debug I can see it checking hiera for RedHat
not Debian values as it does when another debian client contacts it.
On Thursday, January 30, 2014 7:32:41 AM UTC-7, jcbollinger wrote:
On
All,
I have a problem where I was mucking about in a Module which failed. One of
my Debian nodes I was testing it on started acting funky. Now my single
Debian node is getting some weird module activity.
Classes defined by $::kernel fact are defined properly.
Templates based off $::osfamily
List
I want to have a per server snmp password setup. When I set it up as below
and run the client it is unable to process the module because it cannot
find the $snmp_password.
Is there a way to export a $variable from a node so it can be read when the
node processes one of its inherited
