Bug 1173216

Depending on when this lands, we may have to deal with iptables or firewalld on rhel7. I'm wondering if we can mark the /etc/sysconfig/iptables as a configuration file in the rpm and it will automatically leave the existing one untouched.

We are in the process of re-evaluating all RFEs, for the short-term, anything in unspecified is getting set to a low priority.  In the coming weeks, these will all be reviewed and re-prioritized to something that closer reflects reality.

So, Jared, would an option to "self manage the iptables configuration" be what they're looking for with an example minimal configuration we need?

Joe, 
Yea that would work. What would we do with any conflicts?

Well, we'd need to know what they want to do that would conflict with our changes.  

If they're managing their iptables configuration and things work, it should be fine but it could make supporting them difficult if they disable things we don't know about.  

For example, if they block ssh traffic, any support request to ssh onto the appliance for diagnostics would be impossible.  We'd need to ask for their iptables configuration whenever there's an issue that could be remotely related to dropped packets.

As another example, if we need local ports 3000-3010+ and 4000-40010+ for UI/WS workers and they've blocked all local traffic other than their "Well known ports", it could completely break our application.

I haven't looked at the code to see how feasible it is to implement "manage iptables myself" option but it's clearly easier than trying to have both CFME + user changes.

Please discuss with them and report back what option they're looking for on this issue.

0206 rfe triage determine severity/priority should be set to High/High

The route we're going with for now is to deploy the iptables configuration file once into new appliances(/etc/sysconfig/iptables) from a template file in the /var/www/miq/SYSTEM directory tree.  

Any updates to the rpm/codebase will pull in the NEW template but this file will not overwrite the one in /etc/sysconfig/iptables.  If you want to use the new template, you'll need to upgrade to a new appliance or manually copy/merge the template file into /etc/sysconfig/iptables.

See https://github.com/ManageIQ/manageiq/pull/2364

This issue will be addressed as a result of:

commit e88aadbaa10119646e9b18735d1a8c055da730e9
Author:     Joe VLcek <jvlcek>
AuthorDate: Wed Mar 25 18:44:45 2015 -0400
Commit:     Joe VLcek <jvlcek>
CommitDate: Mon Mar 30 11:58:45 2015 -0400

    Incorporate the iptable updates without overwriting installed version
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1205920
    https://bugzilla.redhat.com/show_bug.cgi?id=1202478
    
    [skip ci]

 system/COPY/etc/sysconfig/iptables     | 22 ----------------------
 system/TEMPLATE/etc/sysconfig/iptables | 22 ++++++++++++++++++++++
 system/cfme-setup.sh                   |  7 +++++++
 3 files changed, 29 insertions(+), 22 deletions(-)
 delete mode 100644 system/COPY/etc/sysconfig/iptables
 create mode 100644 system/TEMPLATE/etc/sysconfig/iptables

New commit detected on manageiq/master:
https://github.com/ManageIQ/manageiq/commit/cf9f8924d68568e89595cd1156290069114ec878

commit cf9f8924d68568e89595cd1156290069114ec878
Author:     Joe Rafaniello <jrafanie>
AuthorDate: Wed Apr 8 12:18:36 2015 -0400
Commit:     Joe Rafaniello <jrafanie>
CommitDate: Wed Apr 8 17:59:22 2015 -0400

    Use kickstart's firewall setup to do initial iptables setup.
    
    Let's setup the appliance with our firewall settings initially.
    We don't want to overwrite iptables settings users may have changed.
    Kickstart can do these things for us, so let's use it.
    
    Replaces #2364 and #2470
    https://bugzilla.redhat.com/show_bug.cgi?id=1173216
    
    Note:
    * --enabled is required
    * service=http syntax is not available in centos6
    * --https isn't a valid option on centos6, use explicit 443:tcp,443:udp instead
    * icmp option is done by default
    * --trust=lo is done by default
    * --http only does 80:tcp, not udp, use manual 80:tcp,80:udp
    
    [skip ci]

 build/kickstarts/base.ks.erb           |  5 ++++-
 system/TEMPLATE/etc/sysconfig/iptables | 22 ----------------------
 system/cfme-setup.sh                   |  7 -------
 3 files changed, 4 insertions(+), 30 deletions(-)
 delete mode 100644 system/TEMPLATE/etc/sysconfig/iptables

Verified fixed in 5.3.4.2 > 5.4.0.4 upgrade (5.4.0.4.20150528174021_88cc76c).

I modified the iptables (chose to add SNMP as mentioned above), upgraded, checked it, rebooted the appliance and checked it again and the rule is still present - it has not been removed during upgrade.

Apologies, stupid me looked at a different appliance...
It's not fixed. The rules are empty after upgrade.

I added snmp and ran "iptables-save > /etc/sysconfig/iptables".
Then I upgraded it and checked "iptables --list -n" which was unchanged, rebooted and now there are no active rules.

# iptables --list -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Jan, to clarify this issue, I renamed the title to match the RFE description.

Specifically, the issue reported was this:
"3. What is the nature and description of the request?  
Rules were added to IPtables (custom rules) to allow certain connections to CFME appliances for our monitoring system. It appears that the upgrade of cfme-appliance wiped those out by replacing /etc/sysconfig/iptables. We would like a way to make these persistant so that they don't get overwritten. 


4. Why does the customer need this? (List the business requirements here)  
Everytime they upgrade they will have to re-configure there iptables.

      
5. How would the customer like to achieve this? (List the functional requirements here)  
Keep the settings in that table if possible.
"

This issue is resolved by no longer modifying the /etc/sysconfig/iptables within the rpms.  We instead build the iptables configuration as part of the kickstart so only NEW appliances will get iptables set.  This enables users to create their own /etc/sysconfig/iptables and have it be left alone on future upgrades.

Note, you may have run into an issue in the upgrade in that an unmodified iptables configuration previously in the rpm would be removed on upgrade, leaving possibly no /etc/sysconfig/iptables.

If the user wants to keep the existing iptables configuration, they could use iptables-save/restore like this to perform the upgrade:

Before:
iptables-save > /etc/sysconfig/iptables.cfme

After upgrade:
iptables-restore < /etc/sysconfig/iptables.cfme

I believe this should then have the old iptables rules enabled after restart/reboot.


See: 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-IPTables-Saving_IPTables_Rules.html

http://sharadchhetri.com/2014/02/22/how-to-backup-and-restore-iptables-on-linux-systems/

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-1100.html