Bug 1080823 - [RFE] make override of iptables configurable when using hosted-engine
Summary: [RFE] make override of iptables configurable when using hosted-engine
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-hosted-engine-setup
Classification: oVirt
Component: RFEs
Version: 1.3.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ovirt-3.6.0-rc
: 1.3.0
Assignee: Sandro Bonazzola
QA Contact: Nikolai Sednev
URL:
Whiteboard:
: 1103390 (view as bug list)
Depends On:
Blocks: Hosted_Engine_HC 1191074 1234915
TreeView+ depends on / blocked
 
Reported: 2014-03-26 08:22 UTC by Sven Kieske
Modified: 2016-03-11 07:20 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
User defined iptables rules were overwritten when the host was added to the manager also if automatic configuration of the firewall was turned off. Now if automatic configuration of the firewall is turned off iptables rules won't be touched
Clone Of:
: 1191074 (view as bug list)
Environment:
Last Closed: 2016-03-11 07:20:55 UTC
oVirt Team: Integration
rule-engine: ovirt-3.6.0+
ylavi: planning_ack+
rule-engine: devel_ack+
rule-engine: testing_ack+


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
oVirt gerrit 37535 master MERGED packaging: setup: allow to disable iptables overriding Never
oVirt gerrit 37660 ovirt-hosted-engine-setup-1.2 MERGED packaging: setup: allow to disable iptables overriding Never

Description Sven Kieske 2014-03-26 08:22:31 UTC
Description of problem:

current behaviour is to always rewrite iptables, which may brake
existing rules
Version-Release number of selected component (if applicable):


How reproducible:
always

Steps to Reproduce:
1.
2.
3.

Actual results:
it's always set - ' override_iptables=True '
http://gerrit.ovirt.org/gitweb?p=ovirt-hosted-engine-setup.git;a=blob;f=src/plugins/ovirt-hosted-engine-setup/engine/add_host.py

Expected results:
make it work :)

Additional info:
See this ML - Thread:
http://lists.ovirt.org/pipermail/users/2014-March/022674.html

Comment 1 Giuseppe Ragusa 2014-03-26 19:23:07 UTC
(In reply to Sven Kieske from comment #0)
> Description of problem:
> 
> current behaviour is to always rewrite iptables, which may brake
> existing rules
> Version-Release number of selected component (if applicable):
> 
> 
> How reproducible:
> always
> 
> Steps to Reproduce:
> 1.
> 2.
> 3.
> 
> Actual results:
> it's always set - ' override_iptables=True '
> http://gerrit.ovirt.org/gitweb?p=ovirt-hosted-engine-setup.git;a=blob;f=src/
> plugins/ovirt-hosted-engine-setup/engine/add_host.py
> 
> Expected results:
> make it work :)
> 
> Additional info:
> See this ML - Thread:
> http://lists.ovirt.org/pipermail/users/2014-March/022674.html

Please note that the ML mentioned workaround of using the checkbox from web interface while adding a new node is not applicable to automatic first-node enrollment during self-hosted-engine setup.

Comment 2 Sandro Bonazzola 2014-04-16 13:18:13 UTC
Proposal:

When hosted-engine --deploy detect firewall managers and ask

iptables was detected on your computer, do you wish setup to configure it? (Yes, No)[Yes]:

if you answer "no" it should ask:

do you want to prevent automatic configuration on this host? (Yes, No)[Yes]:

and if you answer yes it should take care of creating /etc/ovirt-host-deploy.conf.d/99-prevent-iptables.conf and avoid to add the host requesting
iptables configuration.

Comment 3 Yedidyah Bar David 2014-04-22 07:20:31 UTC
(In reply to Sandro Bonazzola from comment #2)
> Proposal:
> 
> When hosted-engine --deploy detect firewall managers and ask
> 
> iptables was detected on your computer, do you wish setup to configure it?
> (Yes, No)[Yes]:
> 
> if you answer "no" it should ask:
> 
> do you want to prevent automatic configuration on this host? (Yes, No)[Yes]:

Well, I am not really certain we need another question for this.

Can you think of a scenario where a user will provide different answers to them?

> 
> and if you answer yes it should take care of creating
> /etc/ovirt-host-deploy.conf.d/99-prevent-iptables.conf and avoid to add the
> host requesting
> iptables configuration.

I think that if the answer is yes it should call engine_api.hosts.add with 'override_iptables=False'. Adding the file was suggested just as a workaround.

Comment 4 Sandro Bonazzola 2014-08-13 08:20:12 UTC
*** Bug 1103390 has been marked as a duplicate of this bug. ***

Comment 5 Sandro Bonazzola 2015-02-20 11:08:17 UTC
Automated message: can you please update doctext or set it as not required?

Comment 6 Nicolas Ecarnot 2015-03-21 22:42:17 UTC
Just to be sure things are clear : this issue is not related to hosted only scenario.
It is appearring also in stand-alone engine setups. (and witnessed since 3 years by me)

Comment 7 Yedidyah Bar David 2015-03-22 07:22:12 UTC
(In reply to Nicolas Ecarnot from comment #6)
> Just to be sure things are clear : this issue is not related to hosted only
> scenario.
> It is appearring also in stand-alone engine setups. (and witnessed since 3
> years by me)

You refer to all-in-one? That's a bit different.

Please open a new bug if you are not happy with the current behavior.

In all-in-one, engine-setup may configure iptables if asked to, but actually adds the host to the engine with 'override_iptables=False', which is the opposite of what hosted-engine did (passing True).

Comment 8 Nicolas Ecarnot 2015-03-22 12:38:26 UTC
(In reply to Yedidyah Bar David from comment #7)
> (In reply to Nicolas Ecarnot from comment #6)
> > Just to be sure things are clear : this issue is not related to hosted only
> > scenario.
> > It is appearring also in stand-alone engine setups. (and witnessed since 3
> > years by me)
> 
> You refer to all-in-one? That's a bit different.

I don't.
I refer to a good old stand alone bare metal manager, managing a cluster of classic hosts. An absolute standard setup.

Since my beggining with oVirt in 2012, every upgrade so far stepped by an engine setup, in which I explicitely asked it NOT to do anything to my iptables setup.
And this point was never respected.
I always had to manually correct it host by host.

Not very severe, but still annoying.

Comment 9 Yedidyah Bar David 2015-03-22 14:04:33 UTC
(In reply to Nicolas Ecarnot from comment #8)
> (In reply to Yedidyah Bar David from comment #7)
> > (In reply to Nicolas Ecarnot from comment #6)
> > > Just to be sure things are clear : this issue is not related to hosted only
> > > scenario.
> > > It is appearring also in stand-alone engine setups. (and witnessed since 3
> > > years by me)
> > 
> > You refer to all-in-one? That's a bit different.
> 
> I don't.
> I refer to a good old stand alone bare metal manager, managing a cluster of
> classic hosts. An absolute standard setup.

ok.

> 
> Since my beggining with oVirt in 2012, every upgrade so far stepped by an
> engine setup, in which I explicitely asked it NOT to do anything to my
> iptables setup.
> And this point was never respected.
> I always had to manually correct it host by host.

engine-setup does not control iptables of hosts. At least not directly, at least not all of them.

It controls iptables of the machine it's running on. When using all-in-one, it also controls how host-deploy will be called - it tells it to not touch iptables, as engine-setup does that itself (if asked).

Can you please detail your flow?

> 
> Not very severe, but still annoying.

I'd personally consider it quite severe if I decide I want to control iptables myself and some software overrides me.

Comment 10 Nicolas Ecarnot 2015-03-23 07:54:15 UTC
(In reply to Yedidyah Bar David from comment #9)
> > Since my beggining with oVirt in 2012, every upgrade so far stepped by an
> > engine setup, in which I explicitely asked it NOT to do anything to my
> > iptables setup.
> > And this point was never respected.
> > I always had to manually correct it host by host.
> 
> engine-setup does not control iptables of hosts. At least not directly, at
> least not all of them.
> 
> It controls iptables of the machine it's running on. When using all-in-one,
> it also controls how host-deploy will be called - it tells it to not touch
> iptables, as engine-setup does that itself (if asked).
> 
> Can you please detail your flow?

What you describer is not what I'm witnessing for 3 years.
I think I don't have a special flow, just the usual upgrades, following the steps described in every release wiki page.
I'm surprised to be the first to notice that as my setup is very very basic (not hosted, no all-in-one, no gluster on hosts - just minimal centos 6.6 hosts)

Comment 11 Yedidyah Bar David 2015-03-23 08:28:30 UTC
(In reply to Nicolas Ecarnot from comment #10)
> What you describer is not what I'm witnessing for 3 years.
> I think I don't have a special flow, just the usual upgrades, following the
> steps described in every release wiki page.
> I'm surprised to be the first to notice that as my setup is very very basic
> (not hosted, no all-in-one, no gluster on hosts - just minimal centos 6.6
> hosts)

Again, it's not completely clear what your problem is.

Our release notes usually mention how to upgrade the engine.

Admittedly they should include instructions re how to upgrade the hosts.

If you do that through the web interface, by moving to maintenance, removing and adding again, you have a checkbox to prevent overwriting iptables.

If you use other means, please describe what these are, and where they break. Probably in a new bug.

Thanks!

Comment 12 Nicolas Ecarnot 2015-03-23 09:07:38 UTC
(In reply to Yedidyah Bar David from comment #11)
> If you do that through the web interface, by moving to maintenance, removing
> and adding again, you have a checkbox to prevent overwriting iptables.
> 
> If you use other means, please describe what these are, and where they
> break. Probably in a new bug.
> 
> Thanks!

After the manager upgrade, I'm using the web UI to move the hosts to maintenance, then use the re-install feature.
Then get it into running state, move one VM to check everything is OK.
Then put it back to maintenance, reboot it and double check with a VM.
Then do that cycle again with a local yum upgrade.

I confirm that the first part (ie. NOT the yum upgrade) is the part where I witnessed the iptables being re-activated where I did a chkconfig iptables off and stop.

Before you ask, I'm sure you'll understand that it won't be something easy to reproduce for me, as I don't have a test lab, and I don't do upgrades frequently (not more that the release dates (!) )

Comment 13 Yedidyah Bar David 2015-03-23 09:37:58 UTC
(In reply to Nicolas Ecarnot from comment #12)
> After the manager upgrade, I'm using the web UI to move the hosts to
> maintenance, then use the re-install feature.

And you are certain you unchecked 'Automatically configure host firewall', right?

> Then get it into running state, move one VM to check everything is OK.
> Then put it back to maintenance, reboot it and double check with a VM.
> Then do that cycle again with a local yum upgrade.
> 
> I confirm that the first part (ie. NOT the yum upgrade) is the part where I
> witnessed the iptables being re-activated where I did a chkconfig iptables
> off and stop.
> 
> Before you ask, I'm sure you'll understand that it won't be something easy
> to reproduce for me, as I don't have a test lab, and I don't do upgrades
> frequently (not more that the release dates (!) )

Of course, but can you please check/post relevant logs from the last time this happened to you?

engine: /var/log/ovirt-engine/host-deploy/* /var/log/ovirt-engine/{engine,server}.log

host: /var/log/vdsm/*

Also please check, if at all possible, the exact time iptables was overwritten (by checking timestamps of backups of /etc/sysconfig/iptables, if you have them).

Thanks!

Comment 14 Nicolas Ecarnot 2015-04-06 17:32:21 UTC
(In reply to Yedidyah Bar David from comment #13)
> (In reply to Nicolas Ecarnot from comment #12)
> > After the manager upgrade, I'm using the web UI to move the hosts to
> > maintenance, then use the re-install feature.
> 
> And you are certain you unchecked 'Automatically configure host firewall',
> right?

Yes.

> > Before you ask, I'm sure you'll understand that it won't be something easy
> > to reproduce for me, as I don't have a test lab, and I don't do upgrades
> > frequently (not more that the release dates (!) )
> 
> Of course, but can you please check/post relevant logs from the last time
> this happened to you?
> 
> engine: /var/log/ovirt-engine/host-deploy/*
> /var/log/ovirt-engine/{engine,server}.log
> 
> host: /var/log/vdsm/*
> 
> Also please check, if at all possible, the exact time iptables was
> overwritten (by checking timestamps of backups of /etc/sysconfig/iptables,
> if you have them).
> 
> Thanks!

OK, the main point is probably that in some precise case, I don't want iptables to be enable at all ("chkconfig iptables off", or systemctl equivalent).
And this disabling is not respected.
Iā€™m sorry if I incorrectly described my issue.

Comment 15 Yedidyah Bar David 2015-04-09 08:39:36 UTC
(In reply to Nicolas Ecarnot from comment #14)
> OK, the main point is probably that in some precise case, I don't want
> iptables to be enable at all ("chkconfig iptables off", or systemctl
> equivalent).
> And this disabling is not respected.

I personally think that the behavior of engine-setup is reasonable, see bug 1024707 comment 9 and the very long review process in the linked gerrit patch.

That one does allow the user to enable a disabled firewall manager, if no active ones are found.

In principle we might want to adapt hosted-engine to behave similarly, in practice this is a bit more complex - because it might configure the firewall both by itself, and by telling the engine to do so when adding it to the engine (and making the engine then run host-deploy on it), and also considering the fact that engine still does not support firewalld for hosts.

Now, besides semantics, if you had a real problem (selecting 'No' everywhere possible and still getting iptables overwritten), that's obviously a bug, but we'll need logs and/or exact flow to try and understand how it happened and how to solve it.

Comment 16 Nikolai Sednev 2015-09-07 14:43:32 UTC
Hi Sandro, 
May you change the target release 3.6.0->4.0 please?

Comment 17 Sandro Bonazzola 2015-09-07 16:06:28 UTC
(In reply to Nikolai Sednev from comment #16)
> Hi Sandro, 
> May you change the target release 3.6.0->4.0 please?

Hi Nicolai, this can be verified on 3.6.0 too, without HC.
Also, this has been already verified downstream: see bug #1191074

It's alsto there in 3.5.1, see bug #1192462

Comment 18 sefi litmanovich 2016-02-23 16:08:07 UTC
Verified with:

ovirt-hosted-engine-ha-1.3.4.1-1.el7ev.noarch
ovirt-hosted-engine-setup-1.3.3.3-1.el7ev.noarch

flow 1:
1. set some custom rule in my iptables e.g. 
iptables -A OUTPUT -d {some_ip} -j DROP
2. hosted-engine --deploy
answer 'no' to question - configure iptables automatically?
3.After deployment is done, engine is up and host and sd are up in engine, check host iptables - > custom rule persisted.

flow2:
1. set some custom rule in my iptables e.g. 
iptables -A OUTPUT -d {some_ip} -j DROP
2. hosted-engine --deploy
answer 'yes' to question - configure iptables automatically?
3.After deployment is done, engine is up and host and sd are up in engine, check host iptables - > custom rule is overridden.


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