| 1 |
Michael Orlitzky <michael@××××××××.com> wrote: |
| 2 |
> |
| 3 |
> And my counterarguments: |
| 4 |
> |
| 5 |
> 1. The iptables-restore syntax is uglier and harder to read. |
| 6 |
> |
| 7 |
> 2. You get better error reporting calling iptables repeatedly. |
| 8 |
> |
| 9 |
> 3. The published interface will never change; iptables-restore reads an |
| 10 |
> input language whose specification is "whatever iptables-save outputs." |
| 11 |
> |
| 12 |
> 4. A bash script is far more standard and less confusing to your coworkers. |
| 13 |
> |
| 14 |
> 5. You can't script iptables-restore! |
| 15 |
|
| 16 |
Well, actually you can script iptables-restore. |
| 17 |
In fact, you can write a function "ip4tables" which emulates the |
| 18 |
behaviour of ip4tables by storing data in variables which are then |
| 19 |
later passed to iptables-restore, and so the user sees almost no |
| 20 |
difference although race conditions are avoided. |
| 21 |
|
| 22 |
However, 3. is a severe problem for such complex functions. |
| 23 |
There should be an official way how to avoid races, |
| 24 |
e.g. if ip4tables itself would be able to successively extend |
| 25 |
an output file which can then be used for iptables-restore. |
| 26 |
If you have contact to the iptables developers, please suggest |
| 27 |
such a thing. Or maybe somebody has a bette idea? |
Archives