Bug 17676

Summary:	No init.d startup script like w/ ipchains
Product:	[Retired] Red Hat Linux	Reporter:	Pekka Savola <pekkas>
Component:	iptables	Assignee:	Bernhard Rosenkraenzer <bero>
Status:	CLOSED RAWHIDE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	high
Version:	7.1
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2001-01-17 18:26:56 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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"
            echo
            touch /var/lock/subsys/iptables
        fi
---

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