/etc/sysconfig/iptables format

/etc/sysconfig/iptables format

[Arch Harris]

I was rather surprised at being unable to find hardly any information on 
the format of the /etc/sysconfig/iptables file.  It seems everyone uses a 
three step approach: execute a bunch of iptables commands, store the
result by executing iptables->save, restore using iptables->restore.
It strikes me as being much easier to just write /etc/sysconfig/iptables
and let /etc/rc.d/init.d/iptables take care of the saving and restoring.

Whether my approach is easier or not, one should be able to find 
documentation that describes the format of the file used by iptables-save
and iptables-restore.  But I could not find that info in any of the HOWTOs 
or in any man pages in the distribution.

I realize the syntax fllows the iptables command arguments.  But there
are some differences.  Things like: *filter, COMMIT, etc.  I think
I have figured most of this stuff out, but a man page and/or HOWTO
chapter describing the file format sure would be nice.

Arch
+------------------------------------------------------+
| Dr. J. Archer Harris     MSC 4103, Computer Science  |
| netfilter02@jah.cs.jmu.edu James Madison University  |
| (540) 568 - 2774         Harrisonburg, VA 22807      |
+------------------------------------------------------+

Re: /etc/sysconfig/iptables format

[Patrick Schaaf]

Hi Arch,

[regarding iptables-save format]

> I realize the syntax fllows the iptables command arguments.  But there
> are some differences.  Things like: *filter, COMMIT, etc.  I think
> I have figured most of this stuff out, but a man page and/or HOWTO
> chapter describing the file format sure would be nice.

I agree to the need for docs (do you volunteer writing them?), if, and
only if, at the same time, future compatibility promises regarding the
format, are carefully formulated. I'd propose "can change completely
any time soon when the new pkttables replaces the current mess that
is iptables". To Harald Welte: would that be an appropriate formulation?

As far as I know, the format was never intended for end user usage,
and distributions (redhat, in your case, right?) were wrong basing
their operation on it. At least the Debian maintainers seem to be
aware of that fact, as the comments in the relevant startup scripts
basically say not to use or rely on them (my information stemming
from the Woody distribution of Debian.)

Personally, I write my iptables "templates" in the traditional shell
script form, executing anew on each boot, and when I need to change
the rules, I change the scripts, and rerun "init.d/xxx start".
Sometimes, first I prototype the change by modifying the running
ruleset. Never do I use save/restore. The lack of structure and
comments alone, is reason enough for me to avoid going that route.

best regards
  Patrick

Re: /etc/sysconfig/iptables format

[Bart De Schuymer]

On Sunday 24 November 2002 11:40, Patrick Schaaf wrote:
Hello,

I'd like your opinion about the way ebtables makes atomically writing a 
complete table to the kernel, possible.

ebtables uses another approach for getting table data into the kernel 
atomically.
If you add the parameter --atomic <<FILE>> for each rule added on the command 
line, ebtables will use the FILE instead of the kernel data to operate on. 
The data in the FILE is a binary format, which can be read with this command:
ebtables --atomic <<FILE>> -L. The binary format is the exact binary data that 
have to be given to the kernel to put the table data in the kernel.
Once the rules are set up in FILE, ebtables --atomic-commit <<FILE>> will give 
the table inside FILE to the kernel. So, only the last command actually 
changes the kernel data.
Example:
# inits the file filter_table with the default filter table
# (no rules, policies on ACCEPT)
ebtables -t filter --atomic-init  filter_table
# adds a silly rule to the forward chain in filter_table
# this command doesn't talk to the kernel
ebtables -t filter --atomic filter_table -A FORWARD
# overwrites the current kernel filter table data with the filter table data
# inside the file filter_table
ebtables --atomic-commit filter_table

I was wondering if this is a good scheme, from a user's point of view...
One could say the file being binary is a problem. But the init script for the 
ebtables tables can be written using the --atomic parameters, and that format 
is well-defined (just the command line format)... Directly using the binary 
file (without constructing it in the scripts) is just an option, it's not 
necessary.

cheers,
Bart

Re: /etc/sysconfig/iptables format

[Patrick Schaaf]

Hello Bart,

> I'd like your opinion about the way ebtables makes atomically writing a 
> complete table to the kernel, possible.
[description of "reference file manipulation" approach to construct tables]

I like the scheme! May I have it for iptables, too, please?

Why do I like it? Using the reference file, permits test-construction
of an arbitrary rule set, with full rule consistency / error checking,
and inspection of the result, without modifying the runtime rule set
in any way. That's a great help when extending / modifying rule sets.
With the current iptables, about the only sane alternative is to
carefully construct a user mode linux instance mirroring your real
system, and testing table construction there. The idea of applying
all changes (optionally) to a reference file, saves big effort here.

Part of why I like this, is the possibility to run the ruleset
construction under an arbitrary uid. Only the final commit needs
to be done as root. When your construction scripts become large
that may be a great option, I think.

I have a small proposal to augment the idea: as an alternative to
specifying the reference file on the command line, could you define
a "standard environment variable" which, when set, gives the name
of the reference file to use? That way, one could run "rule set
construction scripts" completely unchanged, i.e. without fiddling
with the commandline of all the ??tables-commands in the scripts.
Just give something different in the environment before calling
the initial construction script.

> One could say the file being binary is a problem.

I don't think so. Having it binary, provides a rather strong hint that
nothing but the delivered tools (ebtables, in your case) are supposed
to understand the format. Doesn't raise futile expectations that way.

best regards
  Patrick

Re: /etc/sysconfig/iptables format

[Bart De Schuymer]

On Sunday 24 November 2002 12:52, Patrick Schaaf wrote:
> Hello Bart,
>
> > I'd like your opinion about the way ebtables makes atomically writing a
> > complete table to the kernel, possible.
>
> [description of "reference file manipulation" approach to construct tables]

I changed to another mail alias and forgot to subscribe with that alias to 
this list, so that's probably why my first mail hasn't arrived yet.

> I like the scheme! May I have it for iptables, too, please?

It shouldn't be too difficult. I'll try next week.

> Why do I like it? Using the reference file, permits test-construction
> of an arbitrary rule set, with full rule consistency / error checking,
> and inspection of the result, without modifying the runtime rule set
> in any way. That's a great help when extending / modifying rule sets.

Yes, what I didn't mention in the other mail is that the command --atomic-save 
saves the kernel table into the file, so then you can add rules in that file 
to eventually atomically update the kernel.

> I have a small proposal to augment the idea: as an alternative to
> specifying the reference file on the command line, could you define
> a "standard environment variable" which, when set, gives the name
> of the reference file to use? That way, one could run "rule set
> construction scripts" completely unchanged, i.e. without fiddling
> with the commandline of all the ??tables-commands in the scripts.
> Just give something different in the environment before calling
> the initial construction script.

Good suggestion, I wonder why I didn't think of that.

-- 
cheers,
Bart

kernel 2.5 and patch-o-matic

[laurent.ml]

Hi,

I'm wondering how to use patch-o-matic(cvs) with kernel 2.5.
I've tested the runme from patch-o-matic_2.5 (cvs). it doesn't work.
I've tested with the last patch posted in that mailing-list, it
doesn't work either.
Could you tell me where I can find a working runme or give me some advice ?

Thanks in advance.

<ERRORS>
/usr/src/linux-2.5.49/../737c36473fcb3498c35a0412415654394916b91f187dc2606a1863b07ae6c057/net/ipv6/netfilter/Config.help
or /usr/src/linux-2.5.49/../737c36473fcb3498c35a0412415654394916b91f187dc2606a1863b07ae6c057/Documentation/Configure.help
fgrep: /usr/src/linux-2.5.49/../737c36473fcb3498c35a0412415654394916b91f187dc2606a1863b07ae6c057/net/ipv6/netfilter/Config.in: No such file or directory
Could not find place to slot in Config.in line
TEST FAILED: patch NOT applied.
</ERRORS>

-- 
Laurent

kernel 2.5 and patch-o-matic

[laurent.ml]

Hi,

I'm wondering how to use patch-o-matic(cvs) with kernel 2.5.
I've tested the runme from patch-o-matic_2.5 (cvs). it doesn't work.
I've tested with the last patch posted in that mailing-list, it
doesn't work either.
Could you tell me where I can find a working runme or give me some advice ?

Thanks in advance.

<ERRORS>
/usr/src/linux-2.5.49/../737c36473fcb3498c35a0412415654394916b91f187dc2606a1863b07ae6c057/net/ipv6/netfilter/Config.help
or /usr/src/linux-2.5.49/../737c36473fcb3498c35a0412415654394916b91f187dc2606a1863b07ae6c057/Documentation/Configure.help
fgrep: /usr/src/linux-2.5.49/../737c36473fcb3498c35a0412415654394916b91f187dc2606a1863b07ae6c057/net/ipv6/netfilter/Config.in: No such file or directory
Could not find place to slot in Config.in line
TEST FAILED: patch NOT applied.
</ERRORS>

-- 
Laurent
 
[sorry, I re-post with good headers]