Bug 17676 - No init.d startup script like w/ ipchains
Summary: No init.d startup script like w/ ipchains
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: iptables   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-09-19 08:00 UTC by Pekka Savola
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-01-17 18:26:56 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Pekka Savola 2000-09-19 08:00:51 UTC
RH 7.0 Final.

There is no initialization script for iptables like
/etc/rc.d/init.d/ipchains.  As ipchains won't work anymore
(at least without a wrapper), such a thing should be implemented for
iptables too for a smoother 2.4
upgrade path.

Comment 1 Bernhard Rosenkraenzer 2000-09-23 14:55:05 UTC
This will be fixed when it becomes more current (iptables is for kernel 2.4).
Integrating this well is not exactly trivial; it takes some time.

Comment 2 Pekka Savola 2001-01-11 22:23:59 UTC
This has to be reconsidered now.

One approach would be to use something like ipchains.  The latest iptables has support for these {-save,restore}.

Anyway, I'd prolly update to iptables-1.2.0

Comment 3 Bernhard Rosenkraenzer 2001-01-15 21:15:58 UTC
Fixed && done

Comment 4 Pekka Savola 2001-01-16 23:43:13 UTC
A few small bugs :-)

- please add ipchains-{save,restore}.8 too.  There is no --help ;-)
- add the init script to %files

# iptables -A INPUT -s 0/0 -j ACCEPT
iptables v1.2: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.

It seems ip_tables module doesn't autoload.  This is a problem with the init script too.

Also, there seems to be 'gprintf' used.  This is probably due to i18n. Significant new initscripts 
versions or the like aren't required though.

Also, there are some stuff badly merged from ipchains.  At least (spaces prolly corrupted):

--- iptables.init.orig  Wed Jan 17 00:34:23 2001
+++ iptables.init       Wed Jan 17 00:35:53 2001
@@ -36,13 +36,13 @@
        if [ -f $IPTABLES_CONFIG ]; then
            # If we don't clear these first, we might be adding to
            #  pre-existing rules.
-           action "Flushing all current rules and user defined chains:" ipchains -F
-           action "Clearing all current rules and user defined chains:" ipchains -X
-           ipchains -Z
-           gprintf "Applying ipchains firewall rules: "
+           action "Flushing all current rules and user defined chains:" iptables -F
+           action "Clearing all current rules and user defined chains:" iptables -X
+           iptables -Z
+           gprintf "Applying iptables firewall rules: "
                grep -v "^[[:space:]]*#" $IPTABLES_CONFIG | grep -v '^[[:space:]]*$' | /sbin/iptables-restore -p -f && \
-                   success "Applying ipchains firewall rules" || \
-                   failure "Applying ipchains firewall rules"
+                   success "Applying iptables firewall rules" || \
+                   failure "Applying iptables firewall rules"
            touch /var/lock/subsys/iptables

Comment 5 Pekka Savola 2001-01-16 23:44:31 UTC
Umm.  Now that I think about it

"user defined chains"

doesn't apply that well anymore..

Comment 6 Bernhard Rosenkraenzer 2001-01-17 18:26:53 UTC
What's wrong with user defined chains?
The iptables man page refers to them all the time.

Comment 7 Bernhard Rosenkraenzer 2001-01-17 18:30:18 UTC
The other things are fixed now. Please don't reopen this bug; if you're still
seeing problems, open a new one.

Comment 8 Pekka Savola 2001-01-17 18:43:04 UTC
It just sounded a bit.. ipchainish.  ;-)

Note You need to log in before you can comment on or make changes to this bug.