Puppet Labs Modules - Feature #11050 firewall: RFE that ensure could support ignore.

Transcription

1 Puppet Labs Modules - Feature #11050 firewall: RFE that ensure could support ignore. 11/28/ :16 am - Steve Traylen Status: Closed Start date: 11/28/2011 Priority: Normal Due date: Assignee: % Done: 0% Category: firewall Estimated time: 0.00 hour Target version: Spent time: 0.00 hour Keywords: iptables, firewall, Branch: Description With puppetlabs-firewall version it s currently possible to do firewall {'000 do whatever': ensure => present,... or firewall{'001 do whatever': ensure => absent,... I d like to request that firewall{'001 do whatever:': ensure => ignore... is also possible The ignore option should not add or delete a rule but just ignore. While at first site this is pretty redundant it allows a default site.pp configuration to be specified as Firewall{ ensure => $::usefirewall to be set from an ENC so firewall writing can be switched on or off globally (per host) despite firewall entries being written acrossall manifests. It s possible there is some other way of just ignoring all instances of something via something in the site.pp but I amnot aware of it. History #1-11/28/ :44 am - Ken Barber - Project changed from Puppet to Puppet Labs Modules 05/01/2016 1/5

2 - Category deleted (modules) Moving to modules area it ain t core yet : ). #2-11/28/ :46 am - Ken Barber - Subject changed from puppetlabs-firewall, RFE that ensure could support ignore. to firewall: RFE that ensure could support ignore. - Description updated - Category set to firewall - Status changed from Unreviewed to Needs Decision #3-11/28/ :50 am - Ken Barber Not a bad idea really. However you could also do something like: Firewall { noop => true, And wouldn t that be roughly the same? #4-11/28/ :14 am - Steve Traylen The noop option while true fully working results in notice: /Firewall[999 allow everything else for now]/ensure: current_value absent, should be present (noop) notice: Finished catalog run in 3.12 seconds during the puppet run, which is less than ideal. In reality absent is almost the same as ignore since the liklihood that someone addsa comment such as 999 drop everything that happens to match a puppet rule is fairly unlikely. Background since I have just written it up for colleagues: #5-11/28/ :28 am - Ken Barber Maybe I don t understand your requirement properly. You define the requirement as being able to disable firewall writing (ie. changes) on a per host basis. I would have thought the noop would have done this for you? What do you mean by less then ideal? The fact it is logging something to the console? This can be changed with loglevel => debug for example. I m not saying noop is a final solution I just think I might not understand the problem 100% : ). #6-11/28/ :48 am - Steve Traylen Thanks for the comments, It s probably a really precise thing that nobody else wants. Essentially some services within our realm want to manage their iptables completely outside puppet for various reasons. Ignoring the wisdom of doing that for now I would rather not bother them with noop notices for things that they have chosen explicitly not to use.this is what I meant by than 05/01/2016 2/5

3 less than ideal I guess the following case should also be considered for what should happen with a configuration: firewall{'500 a random rule': ensure => ignore,... purge => true In this case I guess it should not be purged if it exists. Many Thanks Steve. #7-11/28/ :05 am - Steve Traylen Apologies, I had thought that URL was public that I posted. #8-11/28/ :01 am - Ken Barber Steve Traylen wrote: Thanks for the comments, It s probably a really precise thing that nobody else wants. Lol. Always good to explore the edges : ). You never know what you find. Essentially some services within our realm want to manage their iptables completely outside puppet for various reasons. Ignoring the wisdom of doing that for now I would rather not bother them with noop notices for things that they have chosen explicitly not to use.this is what I meant by than less than ideal Sure so loglevel => debug removes it from the console unless someone uses puppet agent -t debug. Its a meta-parameter available to all resources. I guess the following case should also be considered for what should happen with a configuration: firewall{'500 a random rule': ensure => ignore,... purge => true In this case I guess it should not be purged if it exists. 05/01/2016 3/5

4 Yep but the resources entry only exists in 1 place and is easily wrapped in a conditional. noop and loglevel may even work I ve never tried it : ) but you can at least avoid defining it if your ENC var is set easily done in 1 place. if $::usefirewall == true { purge => true, else { Firewall { noop => true, loglevel => "debug", purge => false, Sorry this just feels like something that is a global Puppet feature doesn t it? I can envision many resource types wanting to be ignored/disabled based on resource type like this. Another alternative I ve thought about for this is to use a provider alternative that does nothing since you can set provider => dummy globally. The ensure => ignore is doable on a code level but there is no convention for this anywhere I can see in the existing providers and its actually harder then the other alternatives. Also the resources { firewall : purge => true won t see the ensure => ignore I don t believe. #9-11/28/ :18 pm - Steve Traylen Many thanks: The noop and loglevel is exactly the correct solution since as you say it s a general thing rather than something particular about the iptables component. It did not work like as you guessed even after changing boolean true for string truebut the following did work: case $::writefirewall { 'false': { $firewallnoop = true $firewallloglevel = 'debug' $firewallpurge = false 'true': { $firewallnoop = false $firewallloglevel = 'verbose' $firewallpurge = true default: { fail('variable $writefirewall must be set to true or false, see site.pp') Firewall { noop => $firewallnoop, 05/01/2016 4/5

5 loglevel => $firewallloglevel purge => $firewallpurge This is definitely closed I would say, should probably of asked on the mailing list in the first place. Steve. #10-11/28/ :40 pm - Ken Barber - Status changed from Needs Decision to Closed Aah yes in your ENC it probably is a string not a proper boolean : ). Anyway thats cool mate happy to help. Good luck with the module. 05/01/2016 5/5

6