Hi All,
It''s an old problem and still isn''t fixed :( I need the
connection
marking support to enable the triplet of ISP''s we use. However, I
downloaded the latest 2.6.22.1 kernel, made an RPM and installed it. I
see the following kernel modules (which looks promising):
/lib/modules/2.6.22.1/kernel/net/netfilter
xt_connmark.ko
xt_CONNMARK.ko
Which yields the following gems:
>modinfo xt_CONNMARK.ko
filename: xt_CONNMARK.ko
author: Henrik Nordstrom <snipped his e-mail>
description: IP tables CONNMARK matching module
license: GPL
alias: ipt_CONNMARK
vermagic: 2.6.22.1 SMP mod_unload PENTIUM4 4KSTACKS
depends: x_tables,nf_conntrack
>modinfo xt_connmark.ko
filename: xt_connmark.ko
author: Henrik Nordstrom <snipped his e-mail>
description: IP tables connmark match module
license: GPL
alias: ipt_connmark
vermagic: 2.6.22.1 SMP mod_unload PENTIUM4 4KSTACKS
depends: x_tables,nf_conntrack
So far, so good. I have the default CentOS 4.4 iptables:
>rpm -qa|grep iptables
iptables-1.2.11-3.1.RHEL4
However, this is a live production firewall and scheduling downtime is a
pretty delicate affair (unless I want to go into the co-lo at dark
o''clock). So my questions to the list are:
1. Does this kernel compile look ok? I was expecting the modules, but
not with the "xt_" prefix.
2. Do I need to recompile, or get a different version of, iptables?
3. Do I need to tweak the aliases in /etc/modprobe.conf?
The system cannot be easily migrated to a different version of CentOS or
distribution of Linux (due to the configuration management system we
use...BCFG2 <shudder>). Changing just the kernel and perhaps iptables
is a reasonably straight-forward affair though.
BTW, I am still using Shorewall 3.4.5-1 (via RPM). I''d like to get
this
setup working on the old version before introducing extra complexity
with the nex 4.x branch.
Any help or insights would be greatly appreciated.
Regards,
James
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
James Gray wrote:> > 1. Does this kernel compile look ok? I was expecting the modules, but > not with the "xt_" prefix.Your kernel is probably okay. The netfilter team have been busily renaming many of the modules.> > 2. Do I need to recompile, or get a different version of, iptables?At the very least, you need to recompile it against your new kernel. I recommend upgrading to 1.3.8 while you are at it. Note that the rebuilt iptables will likely *not* work with your current kernel.> > 3. Do I need to tweak the aliases in /etc/modprobe.conf? >No. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Tom Eastep wrote:> James Gray wrote: > >> 1. Does this kernel compile look ok? I was expecting the modules, but >> not with the "xt_" prefix. > > Your kernel is probably okay. The netfilter team have been busily renaming > many of the modules. > >> 2. Do I need to recompile, or get a different version of, iptables? > > At the very least, you need to recompile it against your new kernel. I > recommend upgrading to 1.3.8 while you are at it. Note that the rebuilt > iptables will likely *not* work with your current kernel.Bummer. I was really trying to keep this as close to distribution as possible. Don''t suppose anyone has the connmark patch for 2.6.9? The problem I have is that we have (as a matter of policy) no compile tools on any production machines. We build RPM''s on dedicated build boxes, then push the RPM''s out (keeping the modified sources and spec files under version and change control). It''s a fairly detailed process but one that stops us shooting ourselves in the foot. *Sigh* it''s going to be a late night :( Tom - thanks for the pointers and prompt response. I really appreciate it. :) -- James ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On Sun, 5 Aug 2007 12:38:58 am Tom Eastep wrote:> James Gray wrote: > > 1. Does this kernel compile look ok? I was expecting the modules, but > > not with the "xt_" prefix. > > Your kernel is probably okay. The netfilter team have been busily renaming > many of the modules. > > > 2. Do I need to recompile, or get a different version of, iptables? > > At the very least, you need to recompile it against your new kernel. I > recommend upgrading to 1.3.8 while you are at it. Note that the rebuilt > iptables will likely *not* work with your current kernel.OK - created an RPM from the 1.3.8 iptables tar ball compiled against the source tree for the vanilla 2.6.22.1 kernel. BTW - if anyone else wants the source RPM, I''m happy to oblige. :) It''s not perfect (throws a few errors during install/removal of the resulting binary about not supporting "chkconfig") so needs a little more spec file tweaking, but it works.> > 3. Do I need to tweak the aliases in /etc/modprobe.conf? > > No.Sweet. Manged to reboot into the new kernel and installed the new iptables RPM (removed the 1.2.11 iptables from CentOS 4.4 along the way). However, when I tried starting Shorewall with the known-working config I got: Aug 6 12:27:10 firewall shorewall: Loading Modules... Aug 6 12:27:10 firewall shorewall: FATAL: Error inserting ipt_LOG (/lib/modules/2.6.22.1/kernel/net/ipv4/netfilter/ipt_LOG.ko): Device or resource busy http://bugzilla.kernel.org/show_bug.cgi?id=8789 So back to the kernel compile again....sigh. I thought I''d mention this problem on the list so if other people hit it, there''s something in the archives. On CentOS 4.x you''ll need to apply the patch from the URL above against 2.6.22 with "patch -l -p1 < /path/to/patch" at the top level of the kernel source. Cheers, James -- Academicians care, that''s who. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/