Description of Problem: When using a kernel without ipchains enabled, the script in /etc/rc.d/init.d/ipchains fails to correctly identify ipchains rules as failed. There is no indication whatever during normal boot messages of ipchains failure. How Reproducible: Install any kernel without ipchains support. Despite failure, due to kernel not supporting ipchains, absolutely no indication is given of this failure. The only indication is manually running /sbin/ipchains. Steps to Reproduce: 1. Install a 2.4.x series kernel that does not work with ipchains. 2. View bootup messages, no indication of failure. Actual Results: ipchains rules will appear to be activated, or at least will not make any indication of failure. Expected Results: If ipchains in /etc/rc.d/init.d/ipchains is run with any argument of start, stop, or status, and the kernel does not support ipchains, or for ANY reason ipchains does not succeed, a big fat RED FAIL message should appear. Additional Information: Manually running "ipchains -L" can produce, from 2.4.x kernels: ipchains: Incompatible with this kernel Due to the number of weaknesses in a system without firewall, and after checking logs, it probably requires a complete system reinstall after having been on the Internet for only a few hours. Failure to inform correctly about security measures being deactivated is "not good". There is an extreme need to test for ipchains failure to activate, whether it is by direct failure, or by kernel support failure.
This is not really a bug, because Red Hat Linux does not support user compiled kernels. You're free to compile and use your own kernel of course, but problems introduced by doing so, that are not reproduceable with the supplied kernels, are not generally considered bugs. If you can cause a reproduceable problem by using the Red Hat supplied kernel, then it is something worthy of investigating further.
This is a problem of scripts that do not check return values, and is independent of kernel, other than being 2.4.x series. If a RH kernel has iptables module loaded, it likely will behave the same way. I am running XFS filesystem on my root partition, so I can't check this without reformatting my whole system, and I am not willing to do this. Other people I have talked to believe the problem is with scripts that fail to check all return values. The bug report may be closed, but I believe the bug continues to exist.