I wouldn't mess up rc.config with "code". Instead it would be
Agreed - it was only a first go. And fine if it was just me...
better to stick with rc.config as a bunch of variables and ask SuSE to extend the firewall script like sketched below (didn't
Yes please - Marc??
+# 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. 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. I also used this for appending to output rules: FW_BLOCK_DOMAINS="no" FW_BLOCK_DOMAINS="yes" # uncomment to block listed domains # # This needs to do DNS lookups, which can take a while. It would be better # off in a background process. fw_block_domains() { domainlist="/etc/local/firewall.block" if [ ! -r "$domainlist" ]; then echo "Can't read list of domains to block! ($domainlist)" else echo "Blocking domains from list: $domainlist" while read; do #echo "read: $REPLY" test -z "$REPLY" && continue test "$REPLY" != "${REPLY#\#}" && continue echo "Blocking: $REPLY" $IPCHAINS -A output -j "$REJECT" -d "$REPLY" \ 2>&1 | grep -v 'for more information.$' done < "$domainlist" fi } (A quick way to get rid of adpop.com & Co.) 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.
+# 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.
- leave the FW_ variables alone and doing it *all* yourself :)
Possible already by replacing SuSEfirewall with another script...
- switching between several rule sets just by pointing to a different function (i.e. script)
Possible already by "SuSEfirewall file someotherfile"
- deliver some "usually asked for" scripts in /usr/doc/packages with the SuSEfirewall script
Yes please :-) 2 other suggestions: 1) This "dns" is confusing. I would have thought to be rather common to run xntpd, even on dial-up connections? Could that be changed to # Common: "dns", or "domain, ntp" ?? FW_ALLOW_INCOMING_HIGHPORTS_TCP="yes" # Common: "ftp-data" (sadly!) FW_ALLOW_INCOMING_HIGHPORTS_UDP="yes" # Common: "dns" # # For the ntpdate command to work, the ntp port must belisted here. # Note: "dns" is a script-internal string. To specify the dns # port, use "domain"!! -VK FW_ALLOW_INCOMING_HIGHPORTS_TCP="ftp-data" FW_ALLOW_INCOMING_HIGHPORTS_UDP="domain ntp" 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??? Volker