Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.

Bug 472055

Summary: do NOT blindly force off iptables
Product: Red Hat Hardware Certification Program Reporter: Patrick C. F. Ernzer <pcfe>
Component: Test Suite (harness)Assignee: Greg Nichols <gnichols>
Status: CLOSED CURRENTRELEASE QA Contact: Lawrence Lim <llim>
Severity: medium Docs Contact:
Priority: medium    
Version: 5CC: rlandry, tools-bugs, ykun
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
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: ---
Bug Depends On:    
Bug Blocks: 494834    
Attachments:
Description Flags
hts.spec.patch to remove %post that shuts down iptables none

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?