Add two new options to "ipfw table <NAME> create" to simplify firewall reload

[lev]

Summary

Now it is very hard to reload (with service ipfw restart and such) firewall which uses tables and have create table NAME commands, as these commands will fail because tables already exists And delete table NAME will fail for first firewall load, as tables are not exist yet.

This patch adds two new options for create table command:

• missing — this option suppresses EEXISTS error, but check, that existing table has same parameters as new one.
• or-flush — this options implies missing and additionally flush table if it exists.

[mizhka]

ipfw/ipfw.8

2140–2159

Bump date of man doc?

ipfw/tables.c

329–332

Should be tabs instead of spaces

501

(flush != 0)
better to follow same style over whole code ;)

[lev]

Address comments by @mizhka_gmail.com

[mizhka]

sbin/ipfw/tables.c

499–502 ↗

(On Diff #51163)

double indentation. please use && to simplify code

[0mp]

ipfw/ipfw.8

2155

Just a minor thing, but we usually put a new sentence in a new line.

You may find more style issues in the patch by running igor and mandoc -Tlint on the manpage.

[lev]

ipfw/ipfw.8

2155

mandoc -Tlint shows a lot of errors, much more than my changes.

[0mp]

OK from manpages. Please remember to bump the date in the manual page.

ipfw/ipfw.8

2155

I wouldn't care about those other errors. Not in this patch at least. :) Thanks!

2158

typo? s/tabel/table/

[ae]

I think you can add to the beginning of your ipfw rules script something like this:

ipfw -q flush
ipfw -q table all destroy

And then create needed tables and fill them.

[lev]

In D18339#426430, @ae wrote:

I think you can add to the beginning of your ipfw rules script something like this:

ipfw -q flush
ipfw -q table all destroy

And then create needed tables and fill them.

But this change is more flexible. I could imagine situation when you don't want to flush existing table but want to be sure that it is exists without external (for example, sh) logic.

[ae]

Ok. It is more flexible, but produces additional options. I think ipfw(8) is already very complex.
What if we will make "missing"+"flush" behavior as default.
It seems if user wants to create table, it is expected that later this table will be filled. So, if we are creating some table, and it is already exist, we will check that the table has the same configuration and then flush it.
If configuration is different, then we return error. What you think?

[lev]

In D18339#426772, @ae wrote:

Ok. It is more flexible, but produces additional options. I think ipfw(8) is already very complex.
What if we will make "missing"+"flush" behavior as default.
It seems if user wants to create table, it is expected that later this table will be filled. So, if we are creating some table, and it is already exist, we will check that the table has the same configuration and then flush it.
If configuration is different, then we return error. What you think?

Looks good for me personally (for my goals), but what if user doesn't want flush existing, if s/he wants to be sure, that table is exists, but if it exists already, to save current content? It could be programmed externally to ipfw (with sh or by other means), of course, but stadard service ipfw reload doesn't allow it.
For example firewall could have table with addresses which are blacklisted by some log analyzer ("file2ban"). User want to reload firewall, but don't want to lose accumulated black list. Now (or with "default to flush") user need to ether dump table before restart and load after it or temporary commet-out table creation from firewall config (table creation should be here, because same config is used on system boot!). Both solutions are possible (and they are possible now, without any changes) but very inconvenient, IMHO.

Maybe, we could have or-flush by default and or-preserve as new option. It adds only one new option (instead of two), but allows both scenarios.

[debdrup]

Is it okay to ask what the status of this is? Because it looks really useful!