<div dir="ltr">Hi,<div>I like option number 3 the most from reading the comments.<div>We are not a configuration management system, so custom rules should not be a main consideration.</div><div>VDSM should probably enable the firewalld rules it needs to work and engine should not care about firewall at all.</div><div>A user wanting to add more rules then this should probably use the ones planned in:</div><div><a href="https://github.com/cockpit-project/system-api-roles">https://github.com/cockpit-project/system-api-roles</a><br></div><div><br></div><div><br></div><div>Thanks,</div><div><br></div></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><pre cols="72"><span style="font-family:arial,helvetica,sans-serif">Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109
Tel : +972 (9) 7692306
8272306
Email: <a href="mailto:ydary@redhat.com" target="_blank">ydary@redhat.com</a>
IRC : ydary</span></pre>
</div></div></div></div></div>
<br><div class="gmail_quote">On Mon, Mar 27, 2017 at 2:10 PM, Martin Sivak <span dir="ltr"><<a href="mailto:msivak@redhat.com" target="_blank">msivak@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> Right, so why not create an Ansible playbook which the users can change<br>
> (extend?), based on <a href="http://docs.ansible.com/ansible/firewalld_module.html" rel="noreferrer" target="_blank">http://docs.ansible.com/<wbr>ansible/firewalld_module.html</a> ?<br>
<br>
</span>I think I like the playbook proposal the best.<br>
<br>
Lets assume the engine provides a firewall.yaml playbook somewhere in /etc:<br>
<br>
- The default playbook would contain our default firewalld<br>
configuration (we should also provide it in /usr/share/doc to give the<br>
user a reference)<br>
- The engine or host deploy script can provide ansible variables so<br>
the playbook can even be a parametrized one (port numbers)<br>
- The user can add rules he needs<br>
- The user can REPLACE the content with iptables rules if he wishes<br>
so (we can even say it is unsupported, but possible)<br>
<br>
As an extension:<br>
<br>
- We can provide ovirt-engine-firewalld ansible role with the default<br>
config so we can properly update files using RPM. The user defined (or<br>
default) playbook would just call this role and would stay intact<br>
during package upgrades.<br>
<br>
This is outside of database, allows customization and adapts to<br>
whatever firewall backend we might need.<br>
<br>
--<br>
Martin Sivak<br>
SLA / oVirt<br>
<div class="HOEnZb"><div class="h5"><br>
On Mon, Mar 27, 2017 at 12:46 PM, Yaniv Kaul <<a href="mailto:ykaul@redhat.com">ykaul@redhat.com</a>> wrote:<br>
><br>
><br>
> On Mon, Mar 27, 2017 at 1:20 PM, Martin Perina <<a href="mailto:mperina@redhat.com">mperina@redhat.com</a>> wrote:<br>
>><br>
>><br>
>><br>
>> On Mon, Mar 27, 2017 at 12:00 PM, Yaniv Kaul <<a href="mailto:ykaul@redhat.com">ykaul@redhat.com</a>> wrote:<br>
>>><br>
>>><br>
>>><br>
>>> On Mon, Mar 27, 2017 at 11:55 AM, Martin Perina <<a href="mailto:mperina@redhat.com">mperina@redhat.com</a>><br>
>>> wrote:<br>
>>>><br>
>>>> Hi,<br>
>>>><br>
>>>> so personally I don't like the current way how we store firewall<br>
>>>> configuration within engine (saving complete iptables commands as string). I<br>
>>>> think should change the way how we store firewall configuration:<br>
>>>><br>
>>>> 1. On engine side I'd just store which services/ports (or port ranges)<br>
>>>> need to be enabled on host. By default only those services/ports that engine<br>
>>>> needs, but we can maintain also custom services defined by users<br>
>>><br>
>>><br>
>>> Agreed. I hope that's enough on one hand, on the other hand, users can<br>
>>> probably easily extend it via Ansible to the hosts and execution of a more<br>
>>> customized firewalld configuration there - we probably should not own it.<br>
>><br>
>><br>
>> Right, we should take care only about services/ports which we need. So we<br>
>> probably could drop the ability for users to define their own custom<br>
>> services/ports within engine for firewalld and force them to use Ansible or<br>
>> other tools to handle their own configuration.<br>
><br>
><br>
> Right, so why not create an Ansible playbook which the users can change<br>
> (extend?), based on <a href="http://docs.ansible.com/ansible/firewalld_module.html" rel="noreferrer" target="_blank">http://docs.ansible.com/<wbr>ansible/firewalld_module.html</a> ?<br>
> ...<br>
>><br>
>><br>
>>><br>
>>>><br>
>>>><br>
>>>> 2. Write plugin to ovirt-host-deploy which will translate those<br>
>>>> services/ports into actual firewall configuration on the host (it should<br>
>>>> detected what firewall is currently enabled and adapt)<br>
><br>
><br>
> ... and then ovirt-host-deploy will be in charge of executing that<br>
> playbook? Seems fairly straightforward.<br>
> Y.<br>
><br>
>>><br>
>>> Agreed.<br>
>>><br>
>>>><br>
>>>><br>
>>>> 3. For newly installed host I'd just use firewalld<br>
>>><br>
>>><br>
>>> Agreed.<br>
>>><br>
>>>><br>
>>>><br>
>>>> 4. Also for 4.2 clusters I'd switch from iptables to firewalld when you<br>
>>>> execute Reinstall (we should document this and make firewalld preferred<br>
>>>> solution)<br>
>>><br>
>>><br>
>>> That's a good question. If a user had the default, non-changed policy we<br>
>>> have had in iptables - sure.<br>
>>> If not, I think it may be a bit of a challenge to switch otherwise.<br>
>><br>
>><br>
>> Right. We could detect if there's some custom firewall rules in<br>
>> IPTablesConfigSiteCustom engine-config option and if not we could probably<br>
>> assume that switching to firewalld could be performed.<br>
>><br>
>> We could also mark iptables configuration as deprecated in 4.2 and declare<br>
>> that it will be removed in 4.3. That would add some time for users to<br>
>> prepare for the switch ...<br>
>><br>
>>> Y.<br>
>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> Martin<br>
>>>><br>
>>>><br>
>>>><br>
>>>> On Mon, Mar 27, 2017 at 8:01 AM, Yedidyah Bar David <<a href="mailto:didi@redhat.com">didi@redhat.com</a>><br>
>>>> wrote:<br>
>>>>><br>
>>>>> On Sun, Mar 26, 2017 at 6:01 PM, Leon Goldberg <<a href="mailto:lgoldber@redhat.com">lgoldber@redhat.com</a>><br>
>>>>> wrote:<br>
>>>>> > Effectively, upgrading will leave lingering (but nonetheless<br>
>>>>> > operational)<br>
>>>>> > iptables rules on the hosts. I'm not even sure there needs to be<br>
>>>>> > special<br>
>>>>> > upgrade treatment?<br>
>>>>><br>
>>>>> Please describe the expected flow.<br>
>>>>><br>
>>>>> Please note that at least when I tried, 'systemctl start firewalld'<br>
>>>>> stops<br>
>>>>> iptables.<br>
>>>>><br>
>>>>> Thanks,<br>
>>>>><br>
>>>>> ><br>
>>>>> > On Sun, Mar 26, 2017 at 4:59 PM, Yedidyah Bar David <<a href="mailto:didi@redhat.com">didi@redhat.com</a>><br>
>>>>> > wrote:<br>
>>>>> >><br>
>>>>> >> On Sun, Mar 26, 2017 at 4:49 PM, Leon Goldberg <<a href="mailto:lgoldber@redhat.com">lgoldber@redhat.com</a>><br>
>>>>> >> wrote:<br>
>>>>> >> > 1) Do we actually need iptables for any reason that isn't a legacy<br>
>>>>> >> > consideration?<br>
>>>>> >><br>
>>>>> >> No idea personally.<br>
>>>>> >><br>
>>>>> >> Perhaps some users prefer that, and/or need that for integration<br>
>>>>> >> with<br>
>>>>> >> other<br>
>>>>> >> systems/solutions/whatever.<br>
>>>>> >><br>
>>>>> >> If we drop iptables, how do you suggest to treat upgrades?<br>
>>>>> >><br>
>>>>> >> ><br>
>>>>> >> > 2 & 3) I am in favor of treating custom services as a requirement<br>
>>>>> >> > and<br>
>>>>> >> > plan<br>
>>>>> >> > accordingly. Many (most, even) of the services are already<br>
>>>>> >> > provided by<br>
>>>>> >> > either firewalld itself (e.g. vdsm, libvirt) or the 3rd party<br>
>>>>> >> > packages<br>
>>>>> >> > (e.g.<br>
>>>>> >> > gluster). Some are missing (I've recently created a pull request<br>
>>>>> >> > for<br>
>>>>> >> > ovirt-imageio to firewalld, for example) and I hope we'll be able<br>
>>>>> >> > to get<br>
>>>>> >> > all<br>
>>>>> >> > the services to be statically provided (by either firewalld or the<br>
>>>>> >> > relevant<br>
>>>>> >> > 3rd party packages).<br>
>>>>> >> ><br>
>>>>> >> > Ideally I think we'd like use statically provided services, and<br>
>>>>> >> > provide<br>
>>>>> >> > the<br>
>>>>> >> > capability to provide additional services (I'm not a fan of the<br>
>>>>> >> > current<br>
>>>>> >> > methodology of converting strings into xmls). I don't think we'd<br>
>>>>> >> > want to<br>
>>>>> >> > limit usage to just statically provided services. (2)<br>
>>>>> >> ><br>
>>>>> >> > As previously stated, I don't see a technical reason to keep<br>
>>>>> >> > iptables<br>
>>>>> >> > under<br>
>>>>> >> > consideration. (3)<br>
>>>>> >> ><br>
>>>>> >> ><br>
>>>>> >> > On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David<br>
>>>>> >> > <<a href="mailto:didi@redhat.com">didi@redhat.com</a>><br>
>>>>> >> > wrote:<br>
>>>>> >> >><br>
>>>>> >> >><br>
>>>>> >> >> 1. Do we want to support in some version X both iptables and<br>
>>>>> >> >> firewalld,<br>
>>>>> >> >> or<br>
>>>>> >> >> is it ok to stop support for iptables and support only firewalld<br>
>>>>> >> >> without<br>
>>>>> >> >> overlap? If so, do we handle upgrades, and how?<br>
>>>>> >> >><br>
>>>>> >> >> 2. Do we want to support custom firewalld xml to be configured on<br>
>>>>> >> >> the<br>
>>>>> >> >> host by us? Or is it ok to only support choosing among existing<br>
>>>>> >> >> services,<br>
>>>>> >> >> which will need to be added to the host using other means<br>
>>>>> >> >> (packaged by<br>
>>>>> >> >> firewalld, packaged by 3rd parties, added manually by users)?<br>
>>>>> >> >><br>
>>>>> >> >> 3. Opposite of (2.): Do we want to support firewalld services<br>
>>>>> >> >> that are<br>
>>>>> >> >> added to the host using other means (see there)? Obviously we do,<br>
>>>>> >> >> but:<br>
>>>>> >> >> If we do, do we still want to support also iptables (see (1.))?<br>
>>>>> >> >> And if<br>
>>>>> >> >> so, what do we want to then happen?<br>
>>>>> >> >><br>
>>>>> >> >> (2.) and (3.) are not conflicting, each needs its own answer.<br>
>>>>> >> >><br>
>>>>> >> >><br>
>>>>> >> >> --<br>
>>>>> >> >> Didi<br>
>>>>> >> ><br>
>>>>> >> ><br>
>>>>> >><br>
>>>>> >><br>
>>>>> >><br>
>>>>> >> --<br>
>>>>> >> Didi<br>
>>>>> ><br>
>>>>> ><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> --<br>
>>>>> Didi<br>
>>>>> ______________________________<wbr>_________________<br>
>>>>> Devel mailing list<br>
>>>>> <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
>>>>> <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
>>>><br>
>>>><br>
>>>><br>
>>>> ______________________________<wbr>_________________<br>
>>>> Devel mailing list<br>
>>>> <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
>>>> <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
>>><br>
>>><br>
>><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> Devel mailing list<br>
> <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
> <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
______________________________<wbr>_________________<br>
Devel mailing list<br>
<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br>
</div></div></blockquote></div><br></div>