Bug 1192462 - [RFE][HC] make override of iptables configurable when using hosted-engine
Summary: [RFE][HC] make override of iptables configurable when using hosted-engine
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-hosted-engine-setup
Version: 3.4.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 3.5.1
Assignee: Sandro Bonazzola
QA Contact: Nikolai Sednev
URL:
Whiteboard: integration
Depends On:
Blocks: 1193058 1197441
TreeView+ depends on / blocked
 
Reported: 2015-02-13 12:40 UTC by rhev-integ
Modified: 2015-04-28 18:47 UTC (History)
20 users (show)

Fixed In Version: ovirt-hosted-engine-setup-1.2.2-2.el6ev
Doc Type: Enhancement
Doc Text:
Previously, hosts were hardcoded to overwrite the iptables rules when the host was added using the 'hosted-engine --deploy' command, even if the user answered 'No' to the question 'iptables was detected on your computer, do you wish setup to configure it?'. Now, the host is not hardcoded and an answer of 'No' to this question is recognised by both the 'hosted-engine --deploy' configuration as well as during the request to the engine to add the host. Therefore, answering 'No' prevents the existing iptables rules from being overwritten on the host.
Clone Of: 1191074
Environment:
Last Closed: 2015-04-28 18:47:09 UTC
oVirt Team: ---
Target Upstream Version:
sherold: Triaged+


Attachments (Terms of Use)
setup log (434.75 KB, text/plain)
2015-03-25 13:48 UTC, Artyom
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1191074 high CLOSED [RFE][HC] make override of iptables configurable when using hosted-engine 2021-01-20 06:05:38 UTC
Red Hat Bugzilla 1207062 urgent CLOSED [hosted-engine] Deployment fails with "The VDSM host was found in a failed state. Please check engine and bootstrap inst... 2021-01-20 06:05:38 UTC
Red Hat Product Errata RHBA-2015:0910 normal SHIPPED_LIVE ovirt-hosted-engine-setup bug fix update 2015-04-28 22:49:43 UTC
Red Hat Product Errata RHSA-2015:0888 normal SHIPPED_LIVE Moderate: Red Hat Enterprise Virtualization Manager 3.5.1 update 2015-04-28 22:40:04 UTC
oVirt gerrit 37660 ovirt-hosted-engine-setup-1.2 MERGED packaging: setup: allow to disable iptables overriding Never
oVirt gerrit 37661 ovirt-hosted-engine-setup-1.2 MERGED packaging: spec: require iptables-services Never
oVirt gerrit 39192 master MERGED packaging: setup: requiring iptables-services also on f20 Never
oVirt gerrit 39223 ovirt-hosted-engine-setup-1.2 MERGED packaging: setup: requiring iptables-services also on f20 Never

Internal Links: 1191074 1207062

Comment 5 Nikolai Sednev 2015-03-01 12:25:15 UTC
Works for me on these components:
libvirt-client-0.10.2-46.el6_6.3.x86_64
vdsm-4.16.12-2.el6ev.x86_64
ovirt-hosted-engine-setup-1.2.2-1.el6ev.noarch
qemu-kvm-rhev-0.12.1.2-2.448.el6.x86_64
ovirt-hosted-engine-ha-1.2.5-1.el6ev.noarch
sanlock-2.8-1.el6.x86_64
root@brown-vdsc ~]# cat /usr/share/ovirt-hosted-engine-setup/plugins/ovirt-hosted-engine-setup/engine/add_host.py | grep override_iptables=
                    override_iptables=self.environment[
rhevm-3.5.1-0.1.el6ev.noarch

Comment 6 Sandro Bonazzola 2015-03-12 15:05:38 UTC
Moving back to modified.
On RHEL 7 ovirt-hosted-engine-setup-1.2.2-1 is missing iptables-service dependency so it will fail there.
Fix will be included in ovirt-hosted-engine-setup-1.2.2-2

Comment 8 Nikolai Sednev 2015-03-23 11:59:40 UTC
We don't have the required package released to QA yet, returning back to assigned as our current build is ovirt-hosted-engine-setup-1.2.2-1.el6ev.noarch.

Comment 10 Yedidyah Bar David 2015-03-24 07:16:59 UTC
Andrew, current doctext sounds as if all hosts in a hosted-engine env were affected. Actually the affected ones were those serving the hosted engine, i.e. those on which hosted-engine --deploy was run successfully.

You might also want to add that the actual choice is done based on the answer to the already-existing question 'iptables was detected on your computer, do you wish setup to configure it?'. Before the fix, the answer was used only to decide whether to overwrite iptables directly (by hosted-engine --deploy itself), now it's used also when the utility asks the engine to add the host (same as the checkbox "Automatically configure host firewall" in the "New Host" dialog).

Comment 11 Artyom 2015-03-25 13:48:48 UTC
Created attachment 1006339 [details]
setup log

Checked on ovirt-hosted-engine-setup-1.2.2-2.el7ev.noarch
Run deployment on clean environment with next answer file:
[environment:default]
OVEHOSTED_NETWORK/firewallManager=str:iptables
OVEHOSTED_NETWORK/iptablesEnable=bool:False

but after deployment is finish I still see that deployment override iptables:
[root@alma06 ~]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain
ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootps
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:bootps
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
ACCEPT     icmp --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:54321
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:sunrpc
ACCEPT     udp  --  anywhere             anywhere             udp dpt:sunrpc
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh
ACCEPT     udp  --  anywhere             anywhere             udp dpt:snmp
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:16514
ACCEPT     tcp  --  anywhere             anywhere             multiport dports rfb:6923
ACCEPT     tcp  --  anywhere             anywhere             multiport dports 49152:49216
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             192.168.122.0/24     ctstate RELATED,ESTABLISHED
ACCEPT     all  --  192.168.122.0/24     anywhere            
ACCEPT     all  --  anywhere             anywhere            
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable
REJECT     all  --  anywhere             anywhere             PHYSDEV match ! --physdev-is-bridged reject-with icmp-host-prohibite

And under setup log I can see:
DEBUG otopi.context context.dumpEnvironment:500 ENV NETWORK/iptablesRules=str:'# Generated by ovirt-hosted-engine-setup installer
#filtering rules
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT ...

Comment 12 Andrew Burden 2015-03-26 08:52:28 UTC
Hey didi,

Much obliged for the feedback. I've updated the doc text. Can you please review and let me if that's technically accurate?

Cheers

Comment 13 Yedidyah Bar David 2015-03-26 10:04:32 UTC
(In reply to Andrew Burden from comment #12)
> Hey didi,
> 
> Much obliged for the feedback. I've updated the doc text. Can you please
> review and let me if that's technically accurate?

Sorry, not exactly :-(

The question wasn't added now - it already existed.

The change was that we now use the answer in two different places:

1. When hosted-engine --deploy itself needs to decide if to update iptables (already done since 3.3)

2. When hosted-engine --deploy asks the engine to add the host, running on it host-deploy (this is the change done now).

> 
> Cheers

Comment 14 Sandro Bonazzola 2015-03-26 12:47:46 UTC
(In reply to Artyom from comment #11)
> Created attachment 1006339 [details]
> setup log
> 
> Checked on ovirt-hosted-engine-setup-1.2.2-2.el7ev.noarch
> Run deployment on clean environment with next answer file:
> [environment:default]
> OVEHOSTED_NETWORK/firewallManager=str:iptables
> OVEHOSTED_NETWORK/iptablesEnable=bool:False
> 


Hi Artyom, how was the iptables rules set before you started the setup?


> but after deployment is finish I still see that deployment override iptables:
> [root@alma06 ~]# iptables -L
> Chain INPUT (policy ACCEPT)
> target     prot opt source               destination         
> ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain
> ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain
> ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootps
> ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:bootps
> ACCEPT     all  --  anywhere             anywhere             state
> RELATED,ESTABLISHED
> ACCEPT     icmp --  anywhere             anywhere            
> ACCEPT     all  --  anywhere             anywhere            
> ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:54321
> ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:sunrpc
> ACCEPT     udp  --  anywhere             anywhere             udp dpt:sunrpc
> ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh
> ACCEPT     udp  --  anywhere             anywhere             udp dpt:snmp
> ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:16514
> ACCEPT     tcp  --  anywhere             anywhere             multiport
> dports rfb:6923
> ACCEPT     tcp  --  anywhere             anywhere             multiport
> dports 49152:49216
> REJECT     all  --  anywhere             anywhere             reject-with
> icmp-host-prohibited
> 
> Chain FORWARD (policy ACCEPT)
> target     prot opt source               destination         
> ACCEPT     all  --  anywhere             192.168.122.0/24     ctstate
> RELATED,ESTABLISHED
> ACCEPT     all  --  192.168.122.0/24     anywhere            
> ACCEPT     all  --  anywhere             anywhere            
> REJECT     all  --  anywhere             anywhere             reject-with
> icmp-port-unreachable
> REJECT     all  --  anywhere             anywhere             reject-with
> icmp-port-unreachable
> REJECT     all  --  anywhere             anywhere             PHYSDEV match
> ! --physdev-is-bridged reject-with icmp-host-prohibite


Very weird, can you also attach the server logs and the host-deploy logs?

> 
> And under setup log I can see:
> DEBUG otopi.context context.dumpEnvironment:500 ENV
> NETWORK/iptablesRules=str:'# Generated by ovirt-hosted-engine-setup installer
> #filtering rules
> *filter
> :INPUT ACCEPT [0:0]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [0:0]
> -A INPUT -i lo -j ACCEPT ...

This is not relevant, the string is allocated but shouldn't be written on the disk when firewall changes are disabled.

Comment 15 Simone Tiraboschi 2015-03-26 14:32:11 UTC
(In reply to Artyom from comment #11)
> Run deployment on clean environment with next answer file:
> [environment:default]
> OVEHOSTED_NETWORK/firewallManager=str:iptables
> OVEHOSTED_NETWORK/iptablesEnable=bool:False

The issue is there
OVEHOSTED_NETWORK/iptablesEnable doesn't exist and so get completely ignored while
OVEHOSTED_NETWORK/firewallManager=str:iptables is enough to ask for iptables configuration and is exactly what it does. 

Can you please retry using:
OVEHOSTED_NETWORK/firewallManager=bool:False

Comment 16 Artyom 2015-03-26 14:55:08 UTC
Thanks to Simone, answer file was not correct, so when I send
[environment:default]
OVEHOSTED_NETWORK/firewallManager=bool:False

deployment not override ip tables.
Verified on ovirt-hosted-engine-setup-1.2.2-2.el7ev.noarch

Comment 17 Yedidyah Bar David 2015-04-01 06:28:16 UTC
Andrew, sorry for the ping-pong, but I changed the doc text again. Please fix if you do not like it... At least I hope that now the intention is clear. Thanks.

Comment 18 Yedidyah Bar David 2015-04-01 06:34:58 UTC
In particular, feel free to replace 'the answer to this question is obeyed' with something nicer if needed. Changed it a bit again. Thanks!

Comment 19 Andrew Burden 2015-04-01 07:23:22 UTC
No worries, didi. The clarification is most appreciated. I've updated the doc text. Can you please check to see if that's alright now.

Comment 20 Yedidyah Bar David 2015-04-01 07:27:32 UTC
Seems good to me. Thanks!

Comment 21 Yedidyah Bar David 2015-04-01 07:28:32 UTC
fixed a typo.

Comment 23 errata-xmlrpc 2015-04-28 18:47:09 UTC
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-0888.html


Note You need to log in before you can comment on or make changes to this bug.