> 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 agree with that. There is a difference, however, between "default 
value assigned in shorewall.conf" and "using default value" and that 
difference is that unless I see it in shorewall.conf for me this option 
does not exist and if it does not exist I wouldn't know about it (a bit 
like your FAKE_AUDIT option really - unless I read that post from you on 
this list, I wouldn't have known about this option, which I don't think 
is right - that's a bit Microsoft like!).

> So now, new options in shorewall.conf always get their
> compiler-defaulted values and I only assign a different value in the
> sample configurations.
>   
What do you mean - that the sample shorewall.conf provided with the 
shorewall package does not contain the "default" values?

>>>> - 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.
>   
Yep! I have, however, changed that as of today.

>>>> - 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.
>   
My view is that all available options should be listed in shorewall.conf 
and visible to users, like myself, so that I know what I have - both in 
terms of capabilities, as well as functionality (old and new). The old 
settings should be respected, the new ones should also be present, so 
that when I go through the config file and see an option I don't know 
about I look at its value, check the manual and alter it, if necessary.

If I can't see that option I cannot do that and I am not that smart to 
remember *all* options listed in the shorewall.conf man page as well as 
those in my shorewall.conf file so that I could compare and see what is 
missing - that ain't happening.

So, what I did a couple of hours ago is discarded the notion of 
"shorewall.conf" completely and replaced it with "shorewall.default", 
introduced "shorewall.template", devised a small %postun script, which 
merges "shorewall.default" with my existing shorewall.conf (if it exists 
from the previous installation), thus honouring my old settings, while 
"piping" this through "shorewall.template" creating final version of 
shorewall.conf, while preserving the old as shorewall.conf.org - just in 
case.

I also devised a separate shell script, which is installed as part of 
that package and it serves a similar purpose to my %postun routine in 
that it provides additional functionality for those occasions where 
shorewall.conf is not in its "standard" location (i.e. /etc/shorewall) 
so that it could be run separately by the user merging both old and new 
configs respecting the old values. It works a treat, so I am more than 
happy to continue using it.

------------------------------------------------------------------------------
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

Reply via email to