1. Proposed title of this feature request Make iptables rules persistant after upgrading cfme-appliance 2. Who is the customer behind the request? Account: name and acct # 5208742 TAM customer: no SRM customer: no Strategic: no 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. 6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. By updating and checking the appliance. 7. Is there already an existing RFE upstream or in Red Hat Bugzilla? No 8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)? No 9. Is the sales team involved in this request and do they have any additional input? No 10. List any affected packages or components. None known 11. Would the customer be able to assist in testing this functionality if implemented? Yes
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