iptables and patch-o-matic

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

iptables and patch-o-matic

Rocco Stanzione
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
done

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.

Thanks,

Rocco Stanzione

--
kernel-team mailing list
[hidden email]
http://lists.ubuntu.com/mailman/listinfo/kernel-team

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: iptables and patch-o-matic

Matt Zimmerman-2
On Fri, Jan 06, 2006 at 10:34:25AM -0600, Rocco Stanzione wrote:

> 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.

One of the explicit goals of our kernel packaging methodology has been to
strictly limit the number of other packages which need to be rebuilt when
the kernel changes.  This is especially important when considering that
security updates to the kernel are common in a stable release.  Currently
affected by kernel transitions in stable releases are:

- linux-source-x.y.z, the kernel itself
- linux-restricted-modules-x.y.z, modules which must be shipped separately
  due to restrictive licensing
- linux-meta, the kernel metapackages which manage transitions

Adding iptables to this list would add to the existing burden imposed by
kernel security updates.  I'd also be concerned about kernel updates causing
iptables to fail to build.

Can we find a way to keep it up to date with kernelspace while avoiding
these issues?

--
 - mdz

--
kernel-team mailing list
[hidden email]
http://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

Re: iptables and patch-o-matic

Rocco Stanzione
On Tuesday 10 January 2006 12:41, Matt Zimmerman wrote:

> One of the explicit goals of our kernel packaging methodology has been to
> strictly limit the number of other packages which need to be rebuilt when
> the kernel changes.  This is especially important when considering that
> security updates to the kernel are common in a stable release.  Currently
> affected by kernel transitions in stable releases are:
>
> - linux-source-x.y.z, the kernel itself
> - linux-restricted-modules-x.y.z, modules which must be shipped separately
>   due to restrictive licensing
> - linux-meta, the kernel metapackages which manage transitions
>
> Adding iptables to this list would add to the existing burden imposed by
> kernel security updates.  I'd also be concerned about kernel updates
> causing iptables to fail to build.
>
> Can we find a way to keep it up to date with kernelspace while avoiding
> these issues?

The alternative is to keep the copy of the kernel headers used to build
iptables current with the kernel package, and to maintain the patch-o-matic
patches between the two packages.  Patches made to iptables without patching
the kernel don't do any good (see bug 16831).  Trivial changes to the kernel
won't usually require an update to the iptables copy to maintain
compatibility, but when we're upgrading to a new kernel (as opposed to a
bugfix release) the two should be synced up again.

The reasons you listed for not establishing a dependency link between the two
packages make sense, and I figured that's why it was done this way.  My
counter-argument is that the way we do it now just plain doesn't work, and
the alternative I just described would arguably put a heavier maintenance
burden on the packagers.  Pruning the kernel source tree down to just what
you need is likely to be a recurring problem as the list of required files
changes.  Patching the two trees (iptables and the kernel) separately, and
maintaining them separately, represents duplication of effort and will
require ongoing communication and cooperation among the maintainers.

Honestly, either solution is fine with me, but having worked in a system where
the two packages were linked, it strikes me as the easiest and most correct
solution.

Thanks,

Rocco

--
kernel-team mailing list
[hidden email]
http://lists.ubuntu.com/mailman/listinfo/kernel-team