Node Corruption

[Doug_F]

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 fact seem to fail to RedHat. I could be that that is the first in most of my case statements but I don't know.

I have commented out the offending module.

I have at least 2 other debian nodes are still getting correct catalogues.

I have tried rolling back the node to its first install and reinstalling puppet.
I have cleaned out the Certs on both client and master.
I have restarted the Master and puppetdb.
curl localhost:8080/v3/nodes/deb-vm.part.net/facts/osfamily
...
  "name" : "osfamily",
  "value" : "Debian"
...

Anyone know of some temp / state file on the master that may need to be removed / fixed? If you know of other troubleshooting steps that would be great as well.

Thanks,
Doug

[jcbollinger]

The problem is more likely to be outside Puppet than inside.  Something has been changed on the node so that Facter no longer computes the 'osfamily' fact correctly.  That probably means it also does not compute the 'operatingsystem' fact correctly.  It might be illuminating to insert one or more Notify resources into your manifests to tell you what values the problem node is actually reporting for those facts.

Looking at the Facter source, however, it seems pretty likely that the problem revolves around the file /etc/debian_version having been removed from the node.


John

[jcbollinger]

On Thursday, January 30, 2014 8:22:35 AM UTC-6, jcbollinger wrote:

Looking at the Facter source, however, it seems pretty likely that the problem revolves around the file /etc/debian_version having been removed from the node.

Hmm.  Having re-read the problem description, I am less confident in my first response.  It's still worthwhile to check /etc/debian_version, though, and to verify more directly (i.e. via a Notify) what fact values the master is receiving for key facts.  I stand by my assertion that the proximal issue is more likely outside Puppet than inside.

If /etc/debian_version is not related to the problem, then it might be helpful to see one of the templates that is behaving unexpectedly.


John

[Doug_F]

/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.

[jcbollinger]

On Thursday, January 30, 2014 3:19:48 PM UTC-6, Doug_F wrote:

/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.

I'm looking for more direct evidence of what fact values the master receives.  Humor me, please.

It may also be worthwhile -- but separate -- to see what facts Facter computes when you run it from the command line.

Additionally, check the master's log for suspicious entries related to the problem node.


John

[Doug_F]

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 /var/lib/puppet/yaml/node/deb-vm.part.net.yaml from the puppetmaster with correct / expected values.

One think I noticed odd is that the puppetlabs-Firewall applies the appropriate class firewall::linux::debian
But in the same run the following puppet code is responsible for the error below.
case $osfamily {
      Debian: {$my_version = $osfamily}
      RedHat: {$my_version = "${osfamily}.${::operatingsystemmajrelease}"}
      default: {fail("Module $module_name is not supported on $osfamily / $operatingsystem")}
    }
file { '/etc/mail/sendmail.cf':
      owner   => root,
      group   => root,
      mode    => 644,
      source  => "puppet:///modules/$module_name/sendmail.cf.${my_version}",
    }
Error: /Stage[main]/Mail/File[/etc/mail/submit.cf]: Could not evaluate: Could not retrieve information from environment production source(s) puppet:///modules/mail/submit.cf.RedHat.7

I added this code in the mail module and got this log message:
    notice ("Module ${module_name}, OsFamily ${osfamily}, Operatingsystem ${operatingsystem}")
(Scope(Class[Mail])) Module mail, OsFamily RedHat, Operatingsystem Debian

It may also be worthwhile -- but separate -- to see what facts Facter computes when you run it from the command line.

Additionally, check the master's log for suspicious entries related to the problem node.

This is really kind of weird. Any thoughts.

[José Luis Ledesma]

Please, could you try using $::operatingsystem?

It could be some variable scoping problem...

Regards,

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/c7762a03-d3b6-4cb4-aeab-711a6873af91%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[José Luis Ledesma]

Sorry, i mean $::osfamily

Regards

[Doug_F]

Yikes...

(Scope(Class[Mail])) ::osfamily = Debian

(Scope(Class[Mail])) Module mail, OsFamily RedHat, Operatingsystem Debian

[José Luis Ledesma]

This is why you should always use explicit scoping :)

Probably someone introduced some osfamily=RedHat in the current scope.

Regards,

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/e5f77cbe-adfd-4fac-8d28-2dc65e0938a5%40googlegroups.com.