On Wed, Sep 06, 2000 at 16:46 +1200, Volker Kuhlmann wrote:
+# optional(?): empty function body as a fallback, +# would be overridden when sourcing the specified script +fw_custom_rules() { + # EMPTY +} + +# make use of what the user supplies us with +[ -r "$FW_CUSTOMRULES" ] && . "$FW_CUSTOMRULES"
Excellent idea. If $FW_CUSTOMRULES was sourced at the location in SuSEfirewall from which I called fw_custom_rules, the need to call a function would go away.
You didn't get the idea of my patch. :) Yes, the custom file gets sourced. But *only* to redefine the (previously empty) functions. Their invocations could get scattered all over the "real" code. And in later versions SuSE (as well as following them the users) are free to expand the number of hooks and rearrange the code. Without experiencing unnecessary "collisions" when updating the SuSE provided script. But still with all the advantages of personal preferences getting obeyed.
For those 2 cases where I had to insert a rule before already existing ones, instead of appending it to the end of the chain, some other mechanism would be useful too. Here it would be easier to call a function, rather than have a new file for each location at which it might be useful to insert more custom rules. For consistency it might be better to stick with a function as well for custom rules appended to the input chain.
That's exactly what the previously provided "architecture" is able to give at your hands. :> To summarize: - collect all the "static" switches and parameters in rc.conf or wherever they reside - don't ever touch the distributor's provided parts as long as you can achieve your goals otherwise, instead expect them to provide enough (better: well placed) hooks for your customization and - override the defaults with the methods created for this very purpose, don't try to force things The latter two items go close together and will save you from trouble when updating. The time you spend doing it the appropriate way pays back when updates go smoother.
I would favour calling functions at various places in SuSEfirewall, with the functions being declared empty by default. Any/all could be defined in another file sourced near the start of SuSEfirewall.
It's all there. All that's left to do in this thread is to identify how many hooks users need and where to place them.
+# script's filename with local rules in addition to or as a +# substitute for what can be done with the FW_* variables +# e.g. FW_CUSTOMRULES=/sbin/init.d/rc.d/firewall.custom +FW_CUSTOMRULES=""
Yes, but I'd put it into firewall.rc.config.
I don't know. And strictly speaking I don't really care. :) I've never experienced any version of SuSE Linux beyond 5.3 ...
- leave the FW_ variables alone and doing it *all* yourself :)
Possible already by replacing SuSEfirewall with another script...
That's a chance you _always_ had and will always have. When you're not satisfied with the template SuSE provides, feel free to drop a script of your own into the boot sequence.
2) Taking the risk of greatly embarrassing myself, would it be possible to add a couple more sentences to explain what DMZ is good for???
Just place a hint to the little-idiot Firewall HowTo somewhere for the interested reader to follow (it was mentioned in the SuSE lists several times and should be available in the archives). When a user has the distro handbook only when planning / setting up the firewall topology, there's probably no need for the "more advanced topics". But I could be mistaking in this. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.