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
(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.
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.
(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.
*** Bug 1103390 has been marked as a duplicate of this bug. ***
Automated message: can you please update doctext or set it as not required?
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)
(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).
(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.
(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.
(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)
(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!
(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 (!) )
(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!
(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.
(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.
Hi Sandro, May you change the target release 3.6.0->4.0 please?
(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
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.