Adding firewalld service to FIREWALLD_SERVICES assumes the service file is in /share/ovirt-engine/firewalld/... Some 3rd party packages include service which are placed elsewhere (for example: /etc/firewalld/services).
engine-setup assumes location of templates of firewalld services included within ovirt-engine package itself. Third party services should just follow firewalld specs.
(In reply to Sandro Bonazzola from comment #1) > engine-setup assumes location of templates of firewalld services included > within ovirt-engine package itself. > Third party services should just follow firewalld specs. This bug is about those that do. It was opened in the context of setting up openvswitch ovn. This one packages a firewalld service file and puts it in the right location, but does not configure firewalld to use it (and I do not think it should). If we want an engine-setup plugin to allow using ovn, this plugin should also open access in the firewall. Also, the solution for current bug should handle configuring iptables. Now tried 'firewall-cmd --info-service=SOME_SERVICE', with firewalld down, says: 'FirewallD is not running'. So we'll need to access the files directly.
So the request here is: "please add ovirt-engine-setup plugins for setting up openvswitch ovn"? If so, please update bug summary accordingly and reopen the bug.
(In reply to Yedidyah Bar David from comment #2) > > Also, the solution for current bug should handle configuring iptables. I don't think we have to. Firewalld is on by default on el7, and I'm happy to say that if someone wants automatic firewall configuration for OVN, they need to keep it on. (In reply to Sandro Bonazzola from comment #3) > So the request here is: > "please add ovirt-engine-setup plugins for setting up openvswitch ovn"? I can live with a solution tailored for us, though I suspect that letting each plugin provide the list of firewalld services it wants would be even prettier.
After discussion with Didi, we believe that it would be possible to simply soft-link from the firewalld services supplied by ovirt-provider-ovn to /usr/share/ovirt-engine/firewalld/ovn. This would make it possible to self.environment[osetupcons.NetEnv.FIREWALLD_SERVICES].extend([ { 'name': 'ovirt-provider-ovn', 'directory': 'ovn' }, ]) in the ovn setup plugin.
I now looked at the code, and I think you do not need to link. Didn't test, but I think this will work: self.environment[osetupcons.NetEnv.FIREWALLD_SERVICES].extend([ { 'name': 'ovirt-provider-ovn', 'directory': '/full/path/to/ovn/services/directory' }, ])
(In reply to Yedidyah Bar David from comment #6) > I now looked at the code, and I think you do not need to link. Didn't test, > but I think this will work: > > self.environment[osetupcons.NetEnv.FIREWALLD_SERVICES].extend([ > { > 'name': 'ovirt-provider-ovn', > 'directory': '/full/path/to/ovn/services/directory' > }, > ]) Missing .in extension, it seems: [ ERROR ] Failed to execute stage 'Misc configuration': [Errno 2] No such file or directory: '/usr/lib/firewalld/services/ovirt-provider-ovn-central.xml.in'
(In reply to Leon Goldberg from comment #7) > Missing .in extension, it seems: > > [ ERROR ] Failed to execute stage 'Misc configuration': [Errno 2] No such > file or directory: > '/usr/lib/firewalld/services/ovirt-provider-ovn-central.xml.in' OK. So either patch somehow to try also .xml files (can't think of an elegant way right now, but ugly ones will work too), or go back to comment 5 and link the .xml to a .xml.in.
*** Bug 1447883 has been marked as a duplicate of this bug. ***
Dan, should it be ON_QA? Ansible firewalld handling on hosts is already added?
This RFE is about firewalld on *central* and provider, both running on Engine. Once https://gerrit.ovirt.org/#/c/81527/ was taken in by Didi and Sandro, you can check it out. Deployment to hosts is not yet a done deal https://gerrit.ovirt.org/#/q/topic:%22ovirt-provider-ovn-driver+deployment%22+(status:open+OR+status:merged)
Leon, I see the service file in multiple locations (on a clean env): /etc/firewalld/services/ovn-central-firewall-service.xml /etc/ovirt-engine/firewalld/ovn-central-firewall-service.xml /usr/lib/firewalld/services/ovn-central-firewall-service.xml Is it okay?
(In reply to Mor from comment #12) > Leon, I see the service file in multiple locations (on a clean env): > > /etc/firewalld/services/ovn-central-firewall-service.xml > /etc/ovirt-engine/firewalld/ovn-central-firewall-service.xml > /usr/lib/firewalld/services/ovn-central-firewall-service.xml > > Is it okay? On a clean env? Odd /usr/ service is deployed via rpms /etc/ovirt-engine/ service is copied during engine-setup IIRC /etc/firewalld/ service I can't account for
(In reply to Leon Goldberg from comment #13) > (In reply to Mor from comment #12) > > Leon, I see the service file in multiple locations (on a clean env): > > > > /etc/firewalld/services/ovn-central-firewall-service.xml > > /etc/ovirt-engine/firewalld/ovn-central-firewall-service.xml > > /usr/lib/firewalld/services/ovn-central-firewall-service.xml > > > > Is it okay? > > On a clean env? Odd > > /usr/ service is deployed via rpms > /etc/ovirt-engine/ service is copied during engine-setup IIRC > /etc/firewalld/ service I can't account for Last one is also by engine-setup - actually otopi [1]. Second one is OVIRT_FIREWALLD_EXAMPLE_DIR [2] and is used to provide examples. So the only real question is why we need both first and third. The answer is that engine-setup expects template files, which it can process, also replacing e.g. port numbers. Compare the other files in /etc with those in /usr/share/ovirt-engine/firewalld/ . We considered writing a larger patch for current bug (see the first comments), then decided it's not worth it - keeping the existing design and only reusing it for ovn. This results in this duplication, which should be harmless. [1] https://gerrit.ovirt.org/gitweb?p=otopi.git;a=blob;f=src/plugins/otopi/network/firewalld.py;h=a9bda749cc01a221f90d8e1380d36730a8925580;hb=HEAD#l283 [2] https://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=packaging/setup/plugins/ovirt-engine-common/base/network/firewall_manager_firewalld.py;h=fd029a08a5e426389e3d98cde0ea82f534a06f61;hb=HEAD#l117
Verified on: ovirt-provider-ovn-1.2-0.20170929144033.git7000023.el7.centos.noarch Method: Firewalld is running, verified that TCP ports: 9696, 35357, 6641 and 6642 on central server are accessible from remote client.
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017. Since the problem described in this bug report should be resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.