[Bug 462482] New: iptables-batch: raison d'=?UTF-8?Q?=C3=AAtre?=
https://bugzilla.novell.com/show_bug.cgi?id=462482 Summary: iptables-batch: raison d'être Product: openSUSE 11.1 Version: Final Platform: All OS/Version: All Status: NEW Severity: Normal Priority: P5 - None Component: Network AssignedTo: lnussel@novell.com ReportedBy: jengelh@medozas.de QAContact: qa@suse.de Found By: Beta-Customer What's the point of iptables-batch, and if it has one, why is not it merged upstream? What can it do that iptables-restore cannot? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=462482 User lnussel@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=462482#c1 Ludwig Nussel <lnussel@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Ludwig Nussel <lnussel@novell.com> 2009-01-07 01:14:08 MST --- The point is speeding up SuSEfirewall2 without having to rewrite all of SuSEfirewall2. SuSEfirewall2 issues random iptables calls that cost a lot of time. The idea to speed this up is to collect those calls instead of directly calling the iptables command (via shell alias). At the end all collected calls are carried out by one binary. Theoretically iptables-restore could be used for that indeed but then one would need a wrapper that orders the calls by chain/table first. Instead of adding that extra level of indirection iptables-batch just calls do_command/iptc_commit itself. At the time I introduced iptables-batch I posted it upstream but there was no interest in merging it. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=462482 User jengelh@medozas.de added comment https://bugzilla.novell.com/show_bug.cgi?id=462482#c2 Jan Engelhardt <jengelh@medozas.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Normal |Enhancement Status|RESOLVED |REOPENED Component|Network |Network Product|openSUSE 11.1 |openSUSE 11.2 Resolution|INVALID | --- Comment #2 from Jan Engelhardt <jengelh@medozas.de> 2009-01-07 01:52:03 MST ---
At the time I introduced iptables-batch I posted it upstream but there was no interest in merging it.
It indeed looks very redundant, hence this BZ item.
but then one would need a wrapper that orders the calls by chain/table first.
The only order you need is per table. So realistically it is doable with less than 5 variables, one for each table. With some tempfiles, any number of tables are possible: function iptables_add() { local table; local chain; table="filter"; if [[ "$1" == "-t" ]]; then table="$2"; shift 2; fi; if [[ "$1" == "-P" ]]; then echo ":$2 $3 [0:0]" >>"$tmpdir/$table"; elif [[ "$1" == "-N" ]]; then echo ":$2 - [0:0]" >>"$tmpdir/$table"; else echo "$@" >>"$tmpdir/$table"; fi; } function iptables_emit() { local table; local i; for i in "$tmpdir"/*; do table="${i##*/}"; { echo "*$table"; cat "$i"; echo "COMMIT"; } | \ iptables-restore; done; } -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=462482 User lnussel@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=462482#c3 Ludwig Nussel <lnussel@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |ASSIGNED Priority|P5 - None |P4 - Low Summary|iptables-batch: raison d'être |iptables-batch: consider wrapper for iptables- | |restore instead --- Comment #3 from Ludwig Nussel <lnussel@novell.com> 2009-01-07 05:36:20 MST --- Well, I could try it out but I don't see much benefit as long as iptables-batch works. Also the shell code needs to store the original command lines as SuSEfirewall2 falls back to individual iptables calls if the batch commit failed for whatever reason. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=462482 User jengelh@medozas.de added comment https://bugzilla.novell.com/show_bug.cgi?id=462482#c4 --- Comment #4 from Jan Engelhardt <jengelh@medozas.de> 2009-01-07 15:55:33 MST --- Simply augment iptables_add(): function iptables_add() { iptables_add_as_above; echo "iptables $@" >>"$tmpdir2/fallback.sh"; } function iptables_emit() { iptables_emit_as_above || . "$tmpdir2/fallback.sh"; } I think that, if there is a reason iptables-restore fails, then the manual commands will also fail at some point and leave the ruleset in a state which may lock out the user, at which point iptables-restore seems to be the better solution which does an atomic restore --- if this atomic restore fails, the previous ruleset will be used, which is either 1. empty chains all with policy of ACCEPT. 2. the minimal ruleset installed by SuSEfirewall2_init (the first stage thing) How's that sound? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=462482 User lnussel@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=462482#c5 --- Comment #5 from Ludwig Nussel <lnussel@novell.com> 2009-01-08 01:05:38 MST --- (In reply to comment #4 from Jan Engelhardt)
I think that, if there is a reason iptables-restore fails, then the manual commands will also fail at some point and leave the ruleset in a state which may lock out the user, at which point iptables-restore seems to be the better solution which does an atomic restore --- if this atomic restore fails, the previous ruleset will be used, which is either 1. empty chains all with policy of ACCEPT. 2. the minimal ruleset installed by SuSEfirewall2_init (the first stage thing) How's that sound?
Typically iptables doesn't fail on the crucial rules but rather on individual ones where users made a mistake in /etc/sysconfig/SuSEfirewall2. Such as typos in IP addresses or port numbers or using features that are only available for IPv4 and then some ip6tables call fails (like e.g. using ipt_recent). So it's ok to deploy all working rules and only omit the faulty ones. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com