How to order rules since 6.0?
tbe opened this issue · comments
Since 6.0, the ability to order blocks of rules from multiple cookbooks is gone, as the rules are now applied in order of apperance.
Using line_number is also not effective, as multiple rules with the same line-number will override each other.
Is there any way to restore the old behavior?
Hi @tbe
How would you envisage it working?
I think this is best left up to the implementing user personally, there are a variety of ways this can be done via a wrapper cookbook.
I have a helper library module that generates resources at compile time from a hash (I use it for pretty much everything), each rule name is prefixed with a 4/5 digit number with blocks allocated to each use case, then sort the hash by key before the resources are instantiated. Raise a warning if there are duplicates.
Hi @xorima
How would you envisage it working?
Before 6.0, we could prefix our rules with a number, and the rebuild-iptables script applied them in the correct order.
Now, we would have to use the way @bmhughes proposed, which would require a major (redundant) development afford on the users side.
Example:
With 5.0 we had one cookbook, containing all the default rules. Starting with 00_related ended with 99_log, containing all the basic default rules for all hosts, and each cookbook could provide something like 10_appXXX to make sure these rules are applied in the right order.
For now, we have to stick with 5.0 for these reason.
That behaviour was by luck more than judgement though, as the script just went through the filesystem provided list of rule files in the rule.d directory. The filesystem just happened to return those in ascending order, moving to an accumulated rule file removed this behaviour but also removed a fair bit of (slightly flaky) complication as well.
As these sort of cookbooks are moving to a resource-only format they've got to be thought of as purely a library (gem) with no implementation as they had before. The idea of these cookbooks is solely to provide a resource to create an ip(6)tables rule and manage getting that in place, anything else is outside of the scope of this cookbook.
I can think of a way to make sure the rules are in order by name by changing how the template is constructed at the end of the run, the problem is that now, implementation has leaked into the library. Perhaps someone else has wrapped the resource in a different way and this breaks their use case. We can't use a property to turn this function on/off (easily anyway) as what happens when one rule resource has ordered set to true and another has it set to false? It's a accumulated template so every resource needs to touch the template variables in the same way.
I appreciate it's a paradigm shift and requires a little more effort on the end-users side but going forward 99% of the time it's up to the implementer to implement they for their use case, there's no way that every different possible permutation can be covered centrally. That's why there has been a push to resource/library only cookbooks from the more 'official' sources, they're just adding to the list of resources already provided by Chef.
I can think of a way to make sure the rules are in order by name
No need for that. Adding something like priority would be helpful. As the cookbooks works now, this would be fare more convenient.
I'm failing to see what that would achieve that the present line number doesn't? What is a priority for you may not be for someone else, and how would that work programmatically? Priority rules first in groups? Is there an example of this in other resources we could look at?
The point I was trying to make with the previous essay was to explain that this really falls out of the scope of this cookbook, it's intended direction and why it's that way. These are abstract resources only. Unless anyone else in the group feels differently I'm afraid this is going to be a wontfix 🤷🏻♂️, you'll have to create a wrapper cookbook for your use case (which is the intention I'm afraid).
I'm failing to see what that would achieve that the present line number doesn't?
In a complex system landscape, there may be on team, providing the basic cookbooks for the infrastructure, containing default rules, maybe logging rules that are crafted to send the output later on to a central security system. Another team that provides the application server and therefore the cookbooks. And an team that glues them all together, use their own rules on top of that and roll out the system.
line_number is IMHO the most useless attribute for a rule. Because what in reality happens is one of two things.
- Two cookbooks define the same line number and overriding each other
- There are HUGE gaps between the line numbers, resulting in a file with massive empty lines ( and iptables-restore is not always happy about this).
A priority would allow the template to sort by this.
you'll have to create a wrapper cookbook for your use case
All fine, but i have to tell you: It is easier to implement just a own resource then using this one in this case. And chef seems to focus more on single server installs then on data center scale configuration management in the last time. And this is sad
So after discussions on this we have decided this will not be a feature we want to support going forward. We feel it would be best handled in a wrapper cookbook, as this is organisation specific logic which can (and does) vary between enterprises.