Exported resources applied on exporting host - EL7 only

[treydock]

I have noticed a very strange problem on CentOS 7 nodes where they are collecting and/or applying their exported resources.  I have a class called "brazos::firewall" that's used internally to export a firewall rule that is then collected by "brazos::gw" to allow specific systems through the gateway server's NAT.  Below are the actual classes.  I've found that on CentOS 6 systems, the resource is correctly exported (NOT applied by exporting host) and collected by the gw server.  On CentOS 7 systems the resource is exported, and also applied by the exporting host when it's not supposed to be.

All systems are running Puppet 3.6.2.  I have tested this issue using the Pupppetlabs yum repo version of Puppet as well as the EPEL7 version, both show this issue.

How can this behavior be debugged?

I have looked in /var/lib/puppet/state/classes.txt on the nodes incorrectly applying their exported resource and the "brazos::gw" class is not listed.  I have no idea WHY the Firewall resource is being applied when it should be exported.

I am using Hiera to assign classes and set parameters and Foreman to set the environment and provide various top-scope variables.  The only thing applied to EL7 systems that's different than EL6 systems in my Hiera configuration is the path to EPEL repos, paths to a few commands (like mco), and the Puppet version.  No separate classes are applied that differ from EL6 systems.

Thanks

- Trey

brazos::firewall:

class brazos::firewall (

  $allow_forward = false,

) inherits brazos::params {

  validate_bool($allow_forward)

  if $allow_forward {

    @@firewall { "050 allow forward ${::fqdn}":

      ensure      => 'present',

      chain       => 'FORWARD',

      action      => 'accept',

      proto       => 'all',

      source      => $::fqdn,

      destination => '0.0.0.0/0',

      tag         => 'allow_forward',

    }

  }

}

brazos::gw:

class brazos::gw (

  $private_interface = 'UNSET',

  $private_subnet = '192.168.200.0/22',

  $ib_interface = 'ib0',

  $ib_subnet = '192.168.208.0/22',

  $public_interface = 'UNSET',

) inherits brazos::params {

<snip>

  Firewall <<| tag == 'allow_forward' |>>

<snip>

}

[jcbollinger]

On Tuesday, August 12, 2014 12:49:27 PM UTC-5, treydock wrote:

I have noticed a very strange problem on CentOS 7 nodes where they are collecting and/or applying their exported resources.  I have a class called "brazos::firewall" that's used internally to export a firewall rule that is then collected by "brazos::gw" to allow specific systems through the gateway server's NAT.  Below are the actual classes.  I've found that on CentOS 6 systems, the resource is correctly exported (NOT applied by exporting host) and collected by the gw server.  On CentOS 7 systems the resource is exported, and also applied by the exporting host when it's not supposed to be.

Are you applying you using agent and master, or are you just running 'puppet apply'?  The former makes much more sense to me for exporting and collecting resources (though I think the latter can work, too).  On the other hand, only if you are running 'puppet apply' does catalog compilation happen in different environments for different machines.  If you are running in master/agent mode, then the problem must be in your manifests and/or data.

Are you certain that the exported firewall rules are in fact being collected on the wrong nodes?  Is it possible that those rules were added previously, and just not cleaned out?  You can check by cleaning them out manually and then rerunning Puppet, or by looking for them in the nodes' catalogs.

Alternatively, are you certain that there is no other Firewall<<| |>> collector somewhere in your manifests that might be picking up the rules at issue?

John

[Trey Dockendorf]

<snip lots of debug output that is just noise>

And AH HA! I did "grep -HnR "Firewall"
/etc/puppet/environments/production/modules/*/manifests/" and see the
problem, I'm using older version of puppetlabs-firewall that does
"Package['iptables-services'] -> Firewall <||>" for EL7. I had not
pushed my fork to my "master", and what's worse is I'm the one who did
the PR to fix the autorequire :-X *face palm*. Excuse my noise.

- Trey

> Alternatively, are you certain that there is no other Firewall<<| |>>
> collector somewhere in your manifests that might be picking up the rules at
> issue?
>
>
>
> John
>

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/puppet-users/3AaOJpPvGSI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> puppet-users...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/2880f45a-ae80-4ee2-99a2-a24a551961cc%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.