Hi Brian, You can get ahold of the catalog directly by using the 'catalogue' object.
See the following for an example: https://github.com/simp/pupmod-simp-auditd/blob/master/spec/classes/config/audit_profiles/simp_spec.rb#L85 Thanks, Trevor On Wed, Apr 12, 2017 at 9:20 AM, brian mancuso <snidd...@gmail.com> wrote: > Hey guys, > > My group has been working on deploying puppet to existing servers and > newer servers. During this time practices have naturally changed and we're > trying to write tests to ensure that when we migrate from one way of > writing firewall rules to another, we don't miss any. So here's some > background and an example of what we're trying to do. > > Old rules: > > firewall { '018 accept TCP-1521 from 10.96.0.0/24': > source => '10.96.0.0/24', > dport => [1521], > state => 'NEW', > proto => 'tcp', > action => 'accept', > } > firewall { '018 accept TCP-1521 from 10.32.0.0/11': > source => '10.32.0.0/11', > dport => [1521], > state => 'NEW', > proto => 'tcp', > action => 'accept', > } > firewall { '018 accept TCP-1521 from 10.64.0.0/25': > source => '10.64.0.0/25', > dport => [1521], > state => 'NEW', > proto => 'tcp', > action => 'accept', > } > > > To replace repetitive stuff like this amongst the classes, we have the > following method: > > define profiles::base::firewall_rule ($order = '030', > $dport = undef, > $port = undef, > $proto = 'tcp', > $chain = 'INPUT', > $action = 'accept', > $state = undef, > ) > { > if ($dport) { > if ($state) { > firewall { "${order} ${action} ${dport} traffic from ${name}": > source => $name, > dport => $dport, > proto => $proto, > action => $action, > chain => $chain, > state => $state, > } > } else { > firewall { "${order} ${action} ${dport} traffic from ${name}": > source => $name, > dport => $dport, > proto => $proto, > action => $action, > chain => $chain, > } > } > } elsif ($port) { > if ($state) { > firewall { "${order} ${action} ${port} traffic from ${name}": > source => $name, > port => $port, > proto => $proto, > action => $action, > chain => $chain, > } > } else { > firewall { "${order} ${action} ${port} traffic from ${name}": > source => $name, > port => $port, > proto => $proto, > action => $action, > chain => $chain, > state => $state, > } > } > } > } > > So now in the original class we can just have this: > > profiles::base::firewall_rule{ $db_access: > dport => [1521], > state => 'NEW', > } > > With the hiera file for the node: > > profiles::banner::database::samplenode::db_access: > - 10.96.0.0/24 > - 10.32.0.0/11 > - 10.64.0.0/25 > > Anyway, with the background information, we need to verify (preferably > with rspec) that the node has a firewall rule given a certain > port/protocol/state/etc. The rspec tests examples we've found and the > original tests we had are all based on the firewall name. Sure we could > change the new system to try and match the old names, but that kind of > testing doesn't seem as effective since the name itself could be anything. > We want to test the firewall rule's parameters. > > Does anyone have an example of how we could do this? > > This is a snippet of what we have, but like I said, it tests via name, > which is not what we want. This only tests that the new rule exists. We > can't use it against both the new rules and the old rules. We want to have > complete coverage on the old rules, then migrate to the new rules and > verify that the new rules meet the tests. > > require 'spec_helper' > describe "profiles::samplenode" do > on_supported_os.each do |os, facts| > context "on #{os}" do > let(:facts) do > facts.merge({ > :hostname => 'samplenode', > :apptier => 'production', > :clientcert => 'samplenode.example.com', > }) > end > it { should create_firewall("030 accept 1521 traffic from > 10.96.0.0/24") } > it { should create_firewall("030 accept 1521 traffic from > 10.32.0.0/11") } > it { should create_firewall("030 accept 1521 traffic from > 10.64.0.0/25") } > end > end > end > > -- > 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/2d1c3d33-4586-4f2d-bb53-265d45305058%40googlegroups.com > <https://groups.google.com/d/msgid/puppet-users/2d1c3d33-4586-4f2d-bb53-265d45305058%40googlegroups.com?utm_medium=email&utm_source=footer> > . > 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%2BFoUf23AuzaYMgdPQu-dK%2B7rU8bYrjtg%3Dm2XHFFGeYdvO7A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
