LinuxQuestions.org
Visit the LQ Articles and Editorials section
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 02-28-2007, 12:12 PM   #16
jeenam
Member
 
Registered: Dec 2006
Distribution: Slackware 11
Posts: 144

Rep: Reputation: 15

Quote:
Originally Posted by robw810
It's clear from your previous posts that you should use the iptables package that's included with Slackware. The kernel support for packet filtering is netfilter, and it's part of the actual kernel. The iptables package is only the userspace portions, and it's built separately from the kernel. Until/unless you understand this distinction and how it affects what you're trying to do, you should stick to the distribution-provided packages.
I disagree. Load the rules from a script such as /etc/rc.d/rc.firewall and all will work fine. I've never trusted the iptables-restore as I like to know exactly what is being loaded into the ruleset.

The iptables package included with slackware 11 is simply outdated. There were no specific options for the package. Simply build the source from netfilter.org and load the rules via script instead of using the restore function. The link I posted above to the iptables 1.3.7 package works with 2.6.18+. Try it out and see for yourself.

*NOTE* Unless the proper modules were built for or included with the kernel currently running then yes, iptables will return errors due to unsupported features. Manually load the modules or recompile a kernel with proper feature support for iptables.

Last edited by jeenam; 02-28-2007 at 12:14 PM.
 
Old 02-28-2007, 01:08 PM   #17
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 1,912

Rep: Reputation: Disabled
Quote:
Originally Posted by jeenam
I disagree. Load the rules from a script such as /etc/rc.d/rc.firewall and all will work fine. I've never trusted the iptables-restore as I like to know exactly what is being loaded into the ruleset.
You disagree with what exactly? I did not suggest that the original poster should or should not use the iptables-save(8) and/or iptables-restore(8) functions. For that matter, they *do* work fine, they are built with the default Slackware iptables package, and if you understand how they work, then you *will* know "exactly what is being loaded into the ruleset."

Quote:
The iptables package included with slackware 11 is simply outdated. There were no specific options for the package.
How is it outdated? What do you mean by options? What functionality is missing from the stock iptables package?

Is there some *legitimate* need to have the latest version of iptables on your system, or are you simply wanting some shiny new version number?

Quote:
Simply build the source from netfilter.org and load the rules via script instead of using the restore function. The link I posted above to the iptables 1.3.7 package works with 2.6.18+. Try it out and see for yourself.
No thanks - I can't seem to find any desire to try some random person's package, especially something as critical as iptables. If you are truly concerned about security, perhaps you should rethink the decision as well...

Quote:
*NOTE* Unless the proper modules were built for or included with the kernel currently running then yes, iptables will return errors due to unsupported features. Manually load the modules or recompile a kernel with proper feature support for iptables.
Yes, but then, that's exactly what I was trying to get across to linuxhippy in my reply. His question of "Should I first uninstall iptables 1.3.7 from my old kernel?" indicates a clear misunderstanding of the relationship.
 
Old 03-01-2007, 04:54 PM   #18
jeenam
Member
 
Registered: Dec 2006
Distribution: Slackware 11
Posts: 144

Rep: Reputation: 15
Quote:
Originally Posted by robw810
It's clear from your previous posts that you should use the iptables package that's included with Slackware. The kernel support for packet filtering is netfilter, and it's part of the actual kernel. The iptables package is only the userspace portions, and it's built separately from the kernel. Until/unless you understand this distinction and how it affects what you're trying to do, you should stick to the distribution-provided packages.
This is getting old. It's obviously the more seasoned vets are not having any problems. Instead of using the save/restore function in iptables I suggest you create an rc.firewall script and have that load during boot. I believe /etc/rc.d/rc.inet1 or rc.inet2 calls the rc.firewall script.

The package I built for 1.3.7 and posted in a previous link works fine with 2.6.18+. Try it yourself if you don't believe me. The issue here is that 1.3.5 DOES NOT WORK with 2.6.20. This is reported on the netfilter.org website in the iptables changelogs. Telling him to use the 'official' slackware 11 package is pointless because it DOES NOT WORK with 2.6.20.
 
Old 03-01-2007, 05:46 PM   #19
linuxhippy
Senior Member
 
Registered: Sep 2004
Location: Philadelphia, PA
Distribution: Xubuntu, Mythbuntu, Lubuntu, Picuntu
Posts: 1,185

Original Poster
Rep: Reputation: 47
This is informative. It seemed as if iptables-1.3.7 compiled ok for kernel 2.6.20.1 and I just have a problem with the iptables-restore program which doesn't have to be used. I guess there's a difference between iptables-restore and iptables? My iptables rules are in /etc. I'm obviously an amateur at this-my degree is in civil engineering and not pcs!
 
Old 03-01-2007, 08:15 PM   #20
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 1,912

Rep: Reputation: Disabled
Quote:
Originally Posted by jeenam
This is getting old. It's obviously the more seasoned vets are not having any problems. Instead of using the save/restore function in iptables I suggest you create an rc.firewall script and have that load during boot. I believe /etc/rc.d/rc.inet1 or rc.inet2 calls the rc.firewall script.
Yes, at least one "more seasoned vet" is telling you that the iptables-1.3.5 package works fine.
As you can see here:
bash-3.1# iptables-save > /etc/iptables
bash-3.1# iptables-restore < /etc/iptables
bash-3.1#
the iptables-save(8) and iptables-restore(8) functions work just fine. I normally load my rules from the /etc/rc.d/rc.firewall script (which, for the record, is called from /etc/rc.d/rc.inet2), but for your benefit, I just verified that the two save/restore functions work as advertised.

Quote:
The package I built for 1.3.7 and posted in a previous link works fine with 2.6.18+. Try it yourself if you don't believe me. The issue here is that 1.3.5 DOES NOT WORK with 2.6.20. This is reported on the netfilter.org website in the iptables changelogs. Telling him to use the 'official' slackware 11 package is pointless because it DOES NOT WORK with 2.6.20.
Oh really? Explain this then.

bash-3.1# uname -a
Linux isotope 2.6.20 #1 SMP PREEMPT Tue Feb 6 18:49:52 CST 2007 i686 pentium4 i386 GNU/Linux
bash-3.1# iptables --version
iptables v1.3.5
bash-3.1# ls /var/log/packages/iptables-1.3.5-i486-2
/var/log/packages/iptables-1.3.5-i486-2

Last edited by rworkman; 03-01-2007 at 08:20 PM.
 
Old 03-01-2007, 08:34 PM   #21
linuxhippy
Senior Member
 
Registered: Sep 2004
Location: Philadelphia, PA
Distribution: Xubuntu, Mythbuntu, Lubuntu, Picuntu
Posts: 1,185

Original Poster
Rep: Reputation: 47
ok, I followed the advice of loading each rule individually and found (I think) the offending rule:

-A INPUT -m state --state ESTABLISHED -j ACCEPT

This rule loaded up fine in the other kernels....what do I need to enable now in the .config for the kernel?
 
Old 03-01-2007, 10:04 PM   #22
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 1,912

Rep: Reputation: Disabled
Quote:
Originally Posted by linuxhippy
ok, I followed the advice of loading each rule individually and found (I think) the offending rule:

-A INPUT -m state --state ESTABLISHED -j ACCEPT

This rule loaded up fine in the other kernels....what do I need to enable now in the .config for the kernel?
You need to have connection tracking enabled in the netfilter section of the kernel config. Like most of my recommendations, I suspect that this might be ignored, but I suggest enabling *all* of the netfilter-related items as modules (except for the ones marked as deprecated or obsolete), even if you don't think you need them - they won't hurt anything, and that way, you won't have to go into troubleshoot mode later as your knowledge base increases and you decide to try some of the more advanced features it offers.
 
Old 03-01-2007, 10:56 PM   #23
linuxhippy
Senior Member
 
Registered: Sep 2004
Location: Philadelphia, PA
Distribution: Xubuntu, Mythbuntu, Lubuntu, Picuntu
Posts: 1,185

Original Poster
Rep: Reputation: 47
that was it....I have iptables-1.3.7 booting fine with kernel-2.6.20.1. After booting into the new kernel I built iptables with only make and make install and a sym link between /usr/src/linux and /usr/src/linux-2.6.20.1. The .config file for the kernel (using menuconfig) had all the options enabled in:

Networking>Networking Options>Network Packet Filtering Framework>Core Netfilter Configuration
 
Old 03-02-2007, 03:30 PM   #24
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 1,912

Rep: Reputation: Disabled
Quote:
Originally Posted by linuxhippy
that was it....I have iptables-1.3.7 booting fine with kernel-2.6.20.1.
I'm willing to bet some dignity on this - remove that iptables version and reinstall the stock Slackware package (iptables-1.3.5), and you'll see that it works as expected.

Also, don't forget to remove the custom iptables binaries and libraries if you later want to install/upgrade it with an official Slackware package. Unless you changed it, you installed it to /usr/local. Official (and most unofficial) packages will install to /usr, so you'll wind up with two sets of iptables files, and the one in /usr/local will usually override the one in /usr unless the path is explicitly defined in scripts and such.

Quote:
After booting into the new kernel I built iptables with only make and make install and a sym link between /usr/src/linux and /usr/src/linux-2.6.20.1.
You didn't need the symlink at all - iptables looks in /lib/modules/$(uname -r)/{build,source} for the running kernel source. See this link for a bit more information on that: http://www.linuxquestions.org/questi...04#post2629704

RW

Last edited by rworkman; 03-02-2007 at 03:34 PM.
 
Old 03-02-2007, 03:35 PM   #25
linuxhippy
Senior Member
 
Registered: Sep 2004
Location: Philadelphia, PA
Distribution: Xubuntu, Mythbuntu, Lubuntu, Picuntu
Posts: 1,185

Original Poster
Rep: Reputation: 47
I get peace of mind from using the latest stable version of software so I keep my kernel and iptables current. I don't know enough about pc security to use the snapshots of iptables. Thanks for all the help here!
 
Old 03-02-2007, 03:53 PM   #26
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 1,912

Rep: Reputation: Disabled
Quote:
Originally Posted by linuxhippy
I get peace of mind from using the latest stable version of software so I keep my kernel and iptables current. I don't know enough about pc security to use the snapshots of iptables. Thanks for all the help here!
There haven't been an security fixes in iptables since 1.3.5 (actually, since quite a bit before that). Building newer versions for no good reason, especially if it makes things more difficult to maintain later if/when new packages are released by the distribution, can actually be detrimental to security. A system that is difficult to maintain will often not *get* maintained. Ultimately, it's your system, so admin it as you see fit, but be wary of getting caught up in the constant rush of staying current with latest version numbers...

If you're wanting the latest *stable* version of a 2.6 kernel for a production system, you should probably lean toward 2.6.16.x (which is currently at 2.6.16.42) - that kernel series is going to maintained long-term with security and reliability fixes.
 
Old 03-02-2007, 04:07 PM   #27
linuxhippy
Senior Member
 
Registered: Sep 2004
Location: Philadelphia, PA
Distribution: Xubuntu, Mythbuntu, Lubuntu, Picuntu
Posts: 1,185

Original Poster
Rep: Reputation: 47
Quote:
Originally Posted by robw810
If you're wanting the latest *stable* version of a 2.6 kernel for a production system, you should probably lean toward 2.6.16.x (which is currently at 2.6.16.42) - that kernel series is going to maintained long-term with security and reliability fixes.
I didn't know that the 2.6.16.x kernel was still being kept current. I just went to the Linux Kernel archive and see that it was updated about the same time as 2.6.16.42. Maybe I'll do that.

I have iptable tgz packages installed for 1.3.5 and 1.3.6. I have been building 1.3.7 for each stable kernel update since December. How would I go back to iptables 1.3.5?
 
Old 03-02-2007, 06:33 PM   #28
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 1,912

Rep: Reputation: Disabled
Quote:
Originally Posted by linuxhippy
I didn't know that the 2.6.16.x kernel was still being kept current. I just went to the Linux Kernel archive and see that it was updated about the same time as 2.6.16.42. Maybe I'll do that.
Your call

Quote:
I have iptable tgz packages installed for 1.3.5 and 1.3.6. I have been building 1.3.7 for each stable kernel update since December. How would I go back to iptables 1.3.5?
This is what I was referring to earlier about the distinction between netfilter (the kernel portion of the linux packet filter) and iptables (the userspace portion). Generally speaking, there is no need to rebuild iptables (the userspace portion) with each new kernel release. Granted, if you want the shared library for the recent match to be built, you have to build against 2.6.x kernel sources, and there have been a few instances of (mostly temporary) breakage of iptables compilation on new kernels, but anyway, to answer your question: You will need to remove the custom-installed iptables stuff (there should be an 'uninstall' target in the Makefile), and just to be safe, removepkg both of the installed iptables packages. Once you're done, install either the stock iptables-1.3.5 package (or the iptables-1.3.6 package from /testing if you want to go that route, but 1.3.5 should suffice).

With all that said, if you *really* want to run the latest version of iptables, then please, for your sake, consider using the SlackBuild script and associated files available at http://slackware.osuosl.org/slackwar...ptables-1.3.6/
See http://slackbuilds.org/howto/ for an idea of how to work with that. The benefit of using the SlackBuild script is that it will build a package that you can install/upgrade/remove with the standard pkgtool(8) suite.
 
Old 03-02-2007, 06:45 PM   #29
linuxhippy
Senior Member
 
Registered: Sep 2004
Location: Philadelphia, PA
Distribution: Xubuntu, Mythbuntu, Lubuntu, Picuntu
Posts: 1,185

Original Poster
Rep: Reputation: 47
wow-SlackBuild looks good! I now have something new to mess with-thank you!
 
Old 03-13-2007, 09:20 AM   #30
monsm
Member
 
Registered: Feb 2005
Location: London, UK
Distribution: Gentoo
Posts: 568

Rep: Reputation: 37
Thumbs up Success

Thanks to all who contributed to this thread. Very useful.

Had the same problem with my FC6 installation when I tried to update the kernel to a custom 2.6.20.2 just now. Got error during boot saying iptables-restore failed at line 27 (which is the commit statement in my case).

I run 'make menuconfig' again and went into:
Networking>Networking Options>Network Packet Filtering Framework>Core Netfilter Configuration

Enabled everything as modules in there, then make, reinstall kernel and modules, reboot, problem solved

Mons
Edit: just for completeness, the iptables version I have is 1.3.5 and when loading the lines in /etc/sysconfig/iptables one by one, the failing line is a similar one to robw810 above (...state ESTABLISHED...). That's just if others get the same problem, all green 'OK's on my machine now

Last edited by monsm; 03-13-2007 at 09:27 AM.
 
  


Reply

Tags
fedora 6, kernel, networking


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
tgz package for acrobat reader cutraman88 Slackware 4 10-14-2004 11:12 PM
installing a tgz.tar package? onegear Slackware 28 09-03-2004 05:57 PM
How can I install my .tgz package under a directory besides root? bankfishin Slackware 1 05-22-2004 05:31 PM
X Sever crash after xset.tgz & vg16.tgz install lachlan Slackware 0 08-13-2003 02:48 AM
tgz package for cups-1.1.12 fabio-i Slackware 1 07-18-2003 10:09 PM


All times are GMT -5. The time now is 06:10 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration