Bug 472055 - do NOT blindly force off iptables
do NOT blindly force off iptables
Status: CLOSED CURRENTRELEASE
Product: Red Hat Hardware Certification Program
Classification: Red Hat
Component: Test Suite (harness) (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Greg Nichols
Lawrence Lim
:
Depends On:
Blocks: 494834
  Show dependency treegraph
 
Reported: 2008-11-18 09:31 EST by Patrick C. F. Ernzer
Modified: 2014-03-25 20:55 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-27 13:10:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
hts.spec.patch to remove %post that shuts down iptables (230 bytes, patch)
2008-11-18 10:02 EST, Greg Nichols
no flags Details | Diff

  None (edit)
Description Patrick C. F. Ernzer 2008-11-18 09:31:14 EST
Description of problem:
had a very nasty surprise when updating hts today. latest version just decides on it's own that I do not need a firewall. Errm, surely you jest sir and this is just an omission from testing.

Version-Release number of selected component (if applicable):
hts-5.2-20.el4

How reproducible:
always

Steps to Reproduce:
1. have a system that does HTS amongst other things (servers are not growing on trees, so a dedicated box is not an option here)
2. have a NIC in that system where certs are run against, that NIC has a -j ACCEPT iptables rule (as per the hts docs)
3. have another NIC for other functions where I most certainly want and need iptables
4. up2date system
  
Actual results:
[...]
  13:hts                    ########################################### [100%]
Flushing firewall rules: [  OK  ]
Setting chains to policy ACCEPT: filter [  OK  ]
Unloading iptables modules: [  OK  ]
[...]

Loud swearing from me. Very very glad I did not trigger the update via RHN or I would not have been able to pull my firewall back up within 30 seconds. 

# rpm -q --scripts hts
preinstall program: /bin/sh
postinstall scriptlet (using /bin/sh):
service iptables stop
chkconfig iptables off

disbelief and very very unhappy that you are now forcing me to do a full analysis of this system because you tore the firewall down. So now I have to check that indeed nothing happened in that time window.

Expected results:
Do not blindly disable a firewall. if the user has one enabled he probably knows what he is doing. s1-hts-important-notes.html is very clear for the user who does not know what he is doing.

Additional info:
Comment 1 Greg Nichols 2008-11-18 10:02:25 EST
Created attachment 323909 [details]
hts.spec.patch to remove %post that shuts down iptables
Comment 2 Rob Landry 2008-11-18 14:15:15 EST
While I was never (and remain not) a fan of this brute force solution; have we verified that simply accepting whatever the state of the firewall is (more specifically the default install firewall configuration) works?  I want to say the reason that the firewall was disabled is because one or more of the services used by the network test are blocked by default.  If it works out of the box great, if not can we check the firewall and then request the user to provide a solution when we discover blocked ports/services which are required?

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