Bug 1030902

Summary: The default RHEL 6 firewall rules retained for RHSS ISO installation
Product: Red Hat Gluster Storage Reporter: Rejy M Cyriac <rcyriac>
Component: doc-Installation_GuideAssignee: Bhavana <bmohanra>
Status: CLOSED NOTABUG QA Contact: Sudhir D <sdharane>
Severity: high Docs Contact:
Priority: high    
Version: 2.1CC: asriram, divya, grajaiya, mhideo, rhs-bugs, shaines, storage-doc, vraman
Target Milestone: ---Keywords: ZStream
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-21 03:49:08 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Rejy M Cyriac 2013-11-15 10:44:22 UTC
Description of problem:
On installing RHSS from ISO, the default RHEL 6 firewall rules, which restricts incoming network traffic to ssh, icmp, and related/established packets, and prevents packets being forwarded, are being retained. So immediately after installation, the network ports required for RHS to function would have to be opened at the firewall, by manually flushing the current rules, or by inserting new appropriate rules.

There is no warning regarding this in the 'RHS Installation Guide'.

Version-Release number of selected component (if applicable):
RHSS-2.1-20131114.0-RHS-x86_64-DVD1.iso

How reproducible:


Steps to Reproduce:
1. Install RHSS using RHSS-2.1-20131114.0-RHS-x86_64-DVD1.iso
2. On first boot, examine firewall rules by running 'iptables -nvL'
3. The output shows that the default RHEL 6 firewall rules are available

# iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 3852  671K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           
 3770  548K ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
    3   316 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22 
 5693  484K REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited 

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited 

Chain OUTPUT (policy ACCEPT 7703 packets, 1218K bytes)
 pkts bytes target     prot opt in     out     source               destination         


Actual results:
The default restrictive RHEL 6 firewall rules are being retained by RHSS installation. There is no warning in the 'RHS Installation Guide' regarding this.

Expected results:
The default restrictive RHEL 6 firewall rules should either be flushed on an RHSS installation, or there should be sufficient warning regarding it in the 'RHS Installation Guide'.

Additional info:

Comment 2 Anjana Suparna Sriram 2013-11-19 02:46:23 UTC
Bhavana,

Could you update the Installation Guide with a warning.

Regards,
Anjana

Comment 3 Rejy M Cyriac 2013-11-20 16:10:31 UTC
The issue reported in this BZ is no longer applicable, for install from the latest RHSS 2.1 U1 RC ISO - RHSS-2.1-20131120.0-RHS-x86_64-DVD1.iso . The firewall rules are now kept cleared after installation.

----------------------------------------
# iptables -nvL
Chain INPUT (policy ACCEPT 3812 packets, 464K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 2181 packets, 318K bytes)
 pkts bytes target     prot opt in     out     source               destination         
----------------------------------------

It appears that the fix for BZ 1032128 inadvertently led to fixing this issue as well, since the root cause for both the issues were apparently the same. Now that is a bonus ;-)

Comment 4 Gowrishankar Rajaiyan 2013-11-20 16:13:42 UTC
Based on comment #3, request to change status to CLOSED NOTABUG.

Comment 5 Anjana Suparna Sriram 2013-11-21 03:49:08 UTC
Based on Comment 3 and 4, closing this bug.