On 05/27/2011 08:11 PM, Tom Eastep wrote: > On 5/27/11 7:51 PM, Tom Eastep wrote: >> On 5/27/11 6:11 PM, Mr Dash Four wrote: >>> 4. Not a bug, but a suggestion. >>> >>> Every time I upgrade shorewall I am spending time executing diff and >>> peeling my eyes out to see what new options have been introduced and >>> what options, if any, have been deprecated. This exercise is very much >>> prone to errors and I believe there is a simpler and better solution to >>> this, which could be done "automagically" without much fuss.
I think this topic warrents further discussion. The philosophy of shorewall.conf has always been that if you don't change it during an upgrade, then the behavior of your firewall won't change (fully backward compatible). So the default (value assigned when the option does not appear in the file or is supplied with an empty value) is chosen to achieve backward compatibility. I used to assign a different value in shorewall.conf when I wanted new users to experience behavior different from the default. I gave that up, however, because people seem bound and determined to do what you are apparently doing and add every new option to your existing shorewall.conf with the value defined in mine. This lead to many laments of "I upgraded and you broke my firewall". So now, new options in shorewall.conf always get their compiler-defaulted values and I only assign a different value in the sample configurations. >>> - Create (and distribute) shorewall.conf.default, which contains all >>> shorewall.conf options with their default values for the current >>> shorewall version being distributed; The shorewall.conf in the tarball is presumably this file. >>> >>> - Create (and distribute) shorewall.conf.template which also contains >>> all available options for the shorewall version being distributed, but >>> lists their "values" in the following manner: >>> USE_ACTIONS=$USE_ACTIONS >>> LEGACY_FASTSTART=$LEGACY_FASTSTART >>> ... >>> >>> - Create a shell script which: >>> 1). simply reads shorewall.conf.default as a shell source, so that all >>> "variables" listed there are "defined" and have their values loaded up. >>> 2). check to see if shorewall.conf exists (from a previous shorewall >>> version perhaps) and if that is the case read this file also as a shell >>> source, so that the variables previously "defined" in >>> shorewall.conf.default get overwritten from the existing shorewall.conf >>> 3). use shorewall.conf.template to output all shorewall.conf variables >>> with their values and redirect this output to shorewall.conf >>> >>> - Job done and I don't have to spend any more time diff-ing old and new >>> shorewall configs ever! Again, I question why this is necessary. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________ Shorewall-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-devel
