Red Hat Bugzilla – Bug 988849
edit-node does not handle firewall rules
Last modified: 2014-03-31 08:32:18 EDT
Description of problem:
plugins can install a file to /etc/ovirt-plugins.d containing a list of ports and protocols to open like this:
These are not being added to the firewall configuration currently
Version-Release number of selected component (if applicable):
Note: need to ignore comments in the file (lines prefixed with #)
Need to handle firewalld vs iptables
ovirt-host-deploy sets iptables rules specified by engine.
We are not ready for firewalld at host side.
(In reply to Alon Bar-Lev from comment #2)
> ovirt-host-deploy sets iptables rules specified by engine.
> We are not ready for firewalld at host side.
Need to correct... ovirt-engine does not support firewalld but only iptables, and this is what it sends to ovirt-host-deploy (otopi).
otopi supports firewalld... but engine should use that feature.
handles both iptables and firewalld
I am unsure how this change solves the problem.
As I wrote in comment#3, ovirt-engine does not support firewalld, it will configure machine using iptables.
In future, when ovirt-engine will support firewalld, it will configure firewalld during host-deploy, the plugin will be a simple registration notification, nothing more.
ovirt-node had firewalld support since F18, what was being done in F18 timeframe with ovirt-host-deploy to make it work?
I can open the ports that ovirt-host-deploy would do in the base image but the patch will work for other plugins that don't expect to manage firewalld/iptables.
Are you asking to revert back to just iptables or can we meet in the middle and open necessary ports?
(In reply to Joey Boggs from comment #6)
> ovirt-node had firewalld support since F18, what was being done in F18
> timeframe with ovirt-host-deploy to make it work?
There was no RFE for ovirt-engine as far as I know to support firewalld. The fact that ovirt-node reverted this as standalone component without synchronization is not correct.
> I can open the ports that ovirt-host-deploy would do in the base image but
> the patch will work for other plugins that don't expect to manage
The ports to be opened are set by the engine and not by the deploy process. If we want to have it set by the node, we should modify the engine not to push iptables rules into the node.
But this will break 3.2 compatibility.
> Are you asking to revert back to just iptables or can we meet in the middle
> and open necessary ports?
I think we should revert back and have something working, then analyze the need of firewall throughout the project and provide a complete solution.
I would have the vdsm plugin or ovirt-host deploy include:
systemctl mask firewalld
systemctl stop firewalld
systemctl enable iptables.service
systemctl start iptables.service
I'm going to just revert the ovirt-node side since we will end up not opening the ports configured with firewalld ssh,libvirt, etc. So no work to be done within the vdsm-plugin unless its a safeguard.
# cat /etc/ovirt-plugins.d/vdsm-plugin.firewall
#ports and protocols that vdsm needs opened
# iptables -L | grep 54321
ACCEPT tcp -- anywhere anywhere tcp dpt:54321
The file /etc/ovirt-plugins.d/vdsm-plugin.firewall can list ports and protocols that vdsm needs opened. so the bug is fixed, change bug status to VERIFIED.
this is an automated message: moving to Closed CURRENT RELEASE since oVirt 3.4.0 has been released