+++ This bug was initially created as a clone of Bug #981583 +++ Description of problem: Firewall rules are applied by packstack via iptables, but in f19 the default firewall management tool is firewalld, this means that the rules are not persistent across reboot if firewalld is enabled. Version-Release number of selected component (if applicable): openstack-packstack-2013.1.1-0.3.dev527.fc19.noarch How reproducible: Always if firewalld is enabled and iptables is not. Steps to Reproduce: 1. run packstack 2. reboot Actual results: After the reboot "iptables -L" shows no packstack specific rules. Expected results: There should be firewall rules for openstack present after reboot. Additional info: This can be fixed by disabling/stopping the firewalld service and enabling/starting the iptables service. --- Additional comment from Fedora Admin XMLRPC Client on 2013-10-14 05:50:53 EDT --- This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. --- Additional comment from Fedora Admin XMLRPC Client on 2013-10-14 05:51:39 EDT --- This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. --- Additional comment from Sandro Mathys on 2013-11-14 04:40:07 EST --- --- Additional comment from Pádraig Brady on 2014-01-08 11:31:18 EST --- I'm not sure we should depend on 981652. Well ideally yes, but could we specifically handle this in packstack? This is still an issue on Fedora 20. --- Additional comment from Lars Kellogg-Stedman on 2014-01-15 10:17:46 EST ---
This also fixes the issue, and leaves the packstack iptables working after reboot: # yum remove firewalld # reboot May be we should just add this step to packstack scripts?
I'm against removing firewalld with packstack. Users should use default firewall service, there are good reasons why fedora and RHEL migrated to the new implementation.
Note that at the time the original bug was filed there were also problems with the puppetlabs "firewall" module, which was not installing the necessary "iptables-services" package under Fedora (which provides legacy support of /etc/sysconfig/iptables). This has since been fixed, and since both iptables-services and firewalld may be installed in parallel this may no longer be an issue. It would be nice if packstack worked with firewalld, but that will require substantial work with the puppetlabs "firewall" module, which currently has no support for firewalld.
Thanks for the info. My understanding is that Miguel cloned the bug to RHOSP5 because he had his firewall rules not applied after reboot until firewalld was disabled.
Yes, in my case it's that. The firewall rules didn't get applied after reboot until firewalld was disabled/removed. I'm with you Ihar, that the final solution may be supporting firewalld correctly, but if that's not possible in the short term, may be removing/disabling firewalld in the meanwhile could be acceptable.
Patch under review: https://review.openstack.org/#/c/96511/
*** Bug 1097435 has been marked as a duplicate of this bug. ***
Fixed in new package openstack-puppet-modules-2014.1-13.1.el7ost
sorry i pasted the wrong package, fixed in: openstack-packstack-2014.1.1-0.16.dev1100.el7ost
Seems to be fine on my tested server which I installed with these versions: # cat system-release Red Hat Enterprise Linux Server release 7.0 (Maipo) # rpm -qa | grep "openstack-packstack\|openstack-puppet" | sort openstack-packstack-2014.1.1-0.22.dev1117.el7ost.noarch openstack-packstack-puppet-2014.1.1-0.22.dev1117.el7ost.noarch openstack-puppet-modules-2014.1-14.1.el7ost.noarch After installation: # systemctl status firewalld firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled) Active: inactive (dead) However I do not understand if this is the path to close this issue or just a stepping stone. If the latter, then I won't verify it until a final thing is implemented. If however we want to see this working now and handle it at the next version, then its possible to verify and close this bug and open a new one for whichever version it will be closed in.
no answer so I guess that I am closing it for now.
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. http://rhn.redhat.com/errata/RHEA-2014-0846.html
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days