Red Hat Bugzilla – Bug 1192462
[RFE][HC] make override of iptables configurable when using hosted-engine
Last modified: 2015-04-28 14:47:09 EDT
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
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
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.
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).
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 ...
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
(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
(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.
(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
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
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.
In particular, feel free to replace 'the answer to this question is obeyed' with something nicer if needed. Changed it a bit again. Thanks!
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.
Seems good to me. Thanks!
fixed a typo.
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