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 changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #1 from Ludwig Nussel 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 lnussel@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=462482#c3 Ludwig Nussel 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 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 lnussel@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=462482#c5 --- Comment #5 from Ludwig Nussel 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.