Bug 1109326
| Summary: | 3.4 upgrade does not set correct iptables rules when serving ISO domain from RHEV-M host | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Thom Carlin <tcarlin> | |
| Component: | ovirt-engine-setup | Assignee: | Simone Tiraboschi <stirabos> | |
| Status: | CLOSED ERRATA | QA Contact: | Pavel Stehlik <pstehlik> | |
| Severity: | high | Docs Contact: | ||
| Priority: | high | |||
| Version: | 3.4.0 | CC: | aberezin, amureini, audgiri, bazulay, dfediuck, didi, dkuznets, dornelas, ecohen, gwatson, herrold, iheim, lbopf, lpeer, lveyde, mkalinin, pstehlik, rbalakri, Rhev-m-bugs, sbonazzo, sherold, stirabos, wdaniel, yeylon | |
| Target Milestone: | --- | Keywords: | ZStream | |
| Target Release: | 3.5.0 | |||
| Hardware: | All | |||
| OS: | All | |||
| Whiteboard: | integration | |||
| Fixed In Version: | Doc Type: | Bug Fix | ||
| Doc Text: |
During upgrades, if automatic firewall configuration with iptables was chosen, NFS server ports were closed off. This caused problems for NFS storage domains. Now, NFS status is checked before iptables configuration is generated.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 1157678 (view as bug list) | Environment: | ||
| Last Closed: | 2015-02-11 18:03:37 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: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1133612, 1157678 | |||
|
Description
Thom Carlin
2014-06-13 16:41:33 UTC
Diagnosing the error may be difficult. Once you do, an easy workaround is to add the appropriate iptables rules after the fact. sandro - please verify for: 1. clean install 3.3 with ISO domain and firewall, check rules, upgrade to 3.4 (with reconfigure firewall), check rules. 2. same from 3.4 to 3.5... Simone is taking care of trying to reproduce the issue. Moving the needinfo on him. Reproduced. Upgrading from 3.3.4 to 3.4.2 it loses this rules: ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:6100 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:111 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:111 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:662 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:662 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:875 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:875 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:892 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:892 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:2049 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:32769 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:32803 Hey, Simone.
I am using recent master rpms, and I have some problems with running engine-setup, it fails with the following message (pretty much default on all options):
[ ERROR ] Failed to execute stage 'Setup validation': 'str' object has no attribute 'review_config'
And this is the trace from the log:
2014-09-28 14:15:36 DEBUG otopi.context context._executeMethod:138 Stage validation METHOD otopi.plugins.ovirt_engine_setup.base.network.firewall_manager.Plugin._review_config
2014-09-28 14:15:36 DEBUG otopi.context context._executeMethod:152 method exception
Traceback (most recent call last):
File "/usr/lib/python2.6/site-packages/otopi/context.py", line 142, in _executeMethod
method['method']()
File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/base/network/firewall_manager.py", line 247, in _review_config
manager.review_config()
AttributeError: 'str' object has no attribute 'review_config'
2014-09-28 14:15:36 ERROR otopi.context context._executeMethod:161 Failed to execute stage 'Setup validation': 'str' object has no attribute 'review_config'
Could it be somehow related to http://gerrit.ovirt.org/#/c/33085/ ?
Thanks
Yes, it's a fault of mine. I added a patch to address that case. Thanks. *** Bug 1071306 has been marked as a duplicate of this bug. *** Moving this to Scott. Added to 3.4.4 tracker in vt8 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/RHSA-2015-0158.html |