iptables and patch-o-matic
grasshopper at linuxkungfu.org
Fri Jan 6 16:34:25 UTC 2006
I was looking into an iptables bug on bugzilla and noticed that the way we're building iptables has a lot of brokenness in dapper and looks unnecessarily difficult to maintain. I guess we're using Debian's methodology where iptables is treated as a standalone package, but it really likes to be compiled against the source of the running kernel, as it's done in Redhat and Mandriva with appropriate dependencies. Currently it's built against a small chunk of (old) kernel code attached to the package. The whole thing is patched with patch-o-matic, but that does little good since that code doesn't get into the kernel we actually use. Also, the netfilter code in the kernel has gone through a lot of changes recently. A lot of items that were once in patch-o-matic are now in the mainline kernel and there's new support for a lot of very useful stuff, like manipulating the conntrack table from userspace.
An example of what's broken in our package is bug 16831, which is what started me looking into this. The files are there, but the userspace and kernel code are out of sync and the rules fail. I'd like to propose a relationship between the kernel package and iptables, where iptables depends on the kernel whose source it was built against, and where a new kernel build means a new iptables build. I think this is the correct way to handle iptables, and I think it'll be easier to maintain than what we're doing now.
If there's no official maintainer for iptables I'd like to volunteer for the job, or at least for the job of fixing the package as it exists now. I bring it up on the kernel list because fixing iptables will require cooperation with the kernel team and fabbione suggested this was the right place to bring it up. He asked me to prepare a list of patches to apply and instructions on how to apply them. The following patches apply cleanly to the source tree as it exists right now, aren't known to break anything, and with the exceptions of 'expire' and 'sip-conntrack-nat' have been around for a while and in constant use by me. This list is just a proposal, of course.
for patch in comment connlimit expire nth psd time IPMARK ROUTE h323-conntrack-nat mms-conntrack-nat quake3-conntrack-nat rsh rtsp-conntrack sip-conntrack-nat; do
KERNEL_DIR=/path/to/kernel/source IPTABLES_DIR=/path/to/iptables/source ./runme --batch $patch
from the root directory of the patch-o-matic-ng tree (I used the 20060105 snapshot for my tests), where IPTABLES_DIR is (in my tests) the source of iptables-1.3.4.
Let me know what you think.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kernel-team