Rules do not appear to be running in string order about puppetlabs-firewall HOT 8 CLOSED

They will 'run' or be displayed in the order specified through relationships, but this is different to the order they are inserted with iptables.

If you do 'iptables -vnL' they should show the order is lexical.

from puppetlabs-firewall.

Gotcha - I thought from reading the docs that puppet applied the rules in lexical order, so I was confused to see my last rule being applied first (and thus locking out my SSH session). I've gone in and applied relationships now.

from puppetlabs-firewall.

Err - maybe I've confused the issue.

You don't need to order your rules really with require/before. While the rules are applied in what seems to be a random order - they are inserted in lexical order so the end result should be proper lexical ordering.

from puppetlabs-firewall.

In that case, there may be a bug, because I have the namevars in lexical order (000 to 999), but when I was running the rules, Number 999 ("deny all") was getting applied early in the process, and my SSH session would get cut (because 999 deny all was being applied before 001 allow SSH).

from puppetlabs-firewall.

Aaah ... okay. So the intended behaviour is that we insert orders lexically ... but as you have pointed out its important to ensure the deny all is inserted last. Then ... in that case - yes - do use require/before ordering to work around that issue.

In fact - perhaps your best bet is to put the deny in a 'post' stage to ensure it always gets inserted last perhaps ... that way you don't have to stress as much about finicky relationships across classes.

Interesting.

I think this might not be a code bug - but more of a documentation bug ... I'm going to re-open it.

from puppetlabs-firewall.

Great - where in the puppet docs is the post stage defined? I'm pretty new to the software, but that sounds like what I need.

from puppetlabs-firewall.

http://docs.puppetlabs.com/references/stable/type.html#stage
http://docs.puppetlabs.com/guides/language_guide.html

So what you do is you put your deny all rule in a class somewhere like (this should be in a module I guess):

class my_fw::deny {
  iptables { "999 deny all":
    jump => "DENY"
  }
}

Set up your stages in say site.pp:

stage { pre: before => Stage[main] }
stage { post: require => Stage[main] }

Then in site.pp or in the nodes/classes you want to apply this behaviour declare the class runs in stage post:

class { "my_fw::deny": stage => "post" }

Then that should ensure it always gets inserted last.

from puppetlabs-firewall.

I've added some notes on this problem to the quickstart section of the README now. Its a start - a lot of that generic documentation needs better flow ... but its down on paper 'so to speak' now ... :-).

from puppetlabs-firewall.