<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 27, 2017 at 1:20 PM, Martin Perina <span dir="ltr"><<a href="mailto:mperina@redhat.com" target="_blank">mperina@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_extra"><br><div class="gmail_quote"><span class="gmail-">On Mon, Mar 27, 2017 at 12:00 PM, Yaniv Kaul <span dir="ltr"><<a href="mailto:ykaul@redhat.com" target="_blank">ykaul@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 27, 2017 at 11:55 AM, Martin Perina <span dir="ltr"><<a href="mailto:mperina@redhat.com" target="_blank">mperina@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif">Hi,<br><br></div><div style="font-family:arial,helvetica,sans-serif">so personally I don't like the current way how we store firewall configuration within engine (saving complete iptables commands as string). I think should change the way how we store firewall configuration:<br><br></div><div style="font-family:arial,helvetica,sans-serif">1. On engine side I'd just store which services/ports (or port ranges) need to be enabled on host. By default only those services/ports that engine needs, but we can maintain also custom services defined by users<br></div></div></blockquote><div><br></div><div>Agreed. I hope that's enough on one hand, on the other hand, users can probably easily extend it via Ansible to the hosts and execution of a more customized firewalld configuration there - we probably should not own it.</div></div></div></div></blockquote></span><div><br><div>Right, we should take care only about services/ports which we need. So we probably could drop the ability for users to define their own custom services/ports within engine for firewalld and force them to use Ansible or other tools to handle their own configuration.<br></div></div></div></div></div></blockquote><div><br></div><div>Right, so why not create an Ansible playbook which the users can change (extend?), based on <a href="http://docs.ansible.com/ansible/firewalld_module.html">http://docs.ansible.com/ansible/firewalld_module.html</a> ? ...</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><br></div></div><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif">2. Write plugin to ovirt-host-deploy which will translate those services/ports into actual firewall configuration on the host (it should detected what firewall is currently enabled and adapt)<br></div></div></blockquote></div></div></div></blockquote></span></div></div></div></blockquote><div><br></div><div>... and then ovirt-host-deploy will be in charge of executing that playbook? Seems fairly straightforward.</div><div>Y.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif"></div></div></blockquote><div><br></div><div>Agreed.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif">3. For newly installed host I'd just use firewalld<br></div></div></blockquote><div><br></div><div>Agreed.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif">4. Also for 4.2 clusters I'd switch from iptables to firewalld when you execute Reinstall (we should document this and make firewalld preferred solution)</div></div></blockquote><div><br></div><div>That's a good question. If a user had the default, non-changed policy we have had in iptables - sure.</div><div>If not, I think it may be a bit of a challenge to switch otherwise.</div></div></div></div></blockquote></span><div><br><div>Right. We could detect if there's some custom firewall rules in IPTablesConfigSiteCustom engine-config option and if not we could probably assume that switching to firewalld could be performed.<br><br></div><div>We could also mark iptables configuration as deprecated in 4.2 and declare that it will be removed in 4.3. That would add some time for users to prepare for the switch ...<br><br></div></div><div><div class="gmail-h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Y.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif"><span class="gmail-m_-6202180951673259370gmail-m_2216812805396465477HOEnZb"><font color="#888888"><br><br><br></font></span></div><span class="gmail-m_-6202180951673259370gmail-m_2216812805396465477HOEnZb"><font color="#888888"><div style="font-family:arial,helvetica,sans-serif">Martin<br><br></div><div style="font-family:arial,helvetica,sans-serif"><br></div></font></span></div><div class="gmail-m_-6202180951673259370gmail-m_2216812805396465477HOEnZb"><div class="gmail-m_-6202180951673259370gmail-m_2216812805396465477h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 27, 2017 at 8:01 AM, Yedidyah Bar David <span dir="ltr"><<a href="mailto:didi@redhat.com" target="_blank">didi@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, Mar 26, 2017 at 6:01 PM, Leon Goldberg <<a href="mailto:lgoldber@redhat.com" target="_blank">lgoldber@redhat.com</a>> wrote:<br>
> Effectively, upgrading will leave lingering (but nonetheless operational)<br>
> iptables rules on the hosts. I'm not even sure there needs to be special<br>
> upgrade treatment?<br>
<br>
Please describe the expected flow.<br>
<br>
Please note that at least when I tried, 'systemctl start firewalld' 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" target="_blank">didi@redhat.com</a>> wrote:<br>
>><br>
>> On Sun, Mar 26, 2017 at 4:49 PM, Leon Goldberg <<a href="mailto:lgoldber@redhat.com" target="_blank">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 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 and<br>
>> > plan<br>
>> > accordingly. Many (most, even) of the services are already provided by<br>
>> > either firewalld itself (e.g. vdsm, libvirt) or the 3rd party packages<br>
>> > (e.g.<br>
>> > gluster). Some are missing (I've recently created a pull request for<br>
>> > ovirt-imageio to firewalld, for example) and I hope we'll be able 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 provide<br>
>> > the<br>
>> > capability to provide additional services (I'm not a fan of the current<br>
>> > methodology of converting strings into xmls). I don't think we'd 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 iptables<br>
>> > under<br>
>> > consideration. (3)<br>
>> ><br>
>> ><br>
>> > On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David <<a href="mailto:didi@redhat.com" target="_blank">didi@redhat.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >><br>
>> >> 1. Do we want to support in some version X both iptables and 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 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 (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 that are<br>
>> >> added to the host using other means (see there)? Obviously we do, but:<br>
>> >> If we do, do we still want to support also iptables (see (1.))? 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>
<span class="gmail-m_-6202180951673259370gmail-m_2216812805396465477m_-8287614625872159388HOEnZb"><font color="#888888">>><br>
>> --<br>
>> Didi<br>
><br>
><br>
<br>
<br>
<br>
--<br>
Didi<br>
______________________________<wbr>_________________<br>
Devel mailing list<br>
<a href="mailto:Devel@ovirt.org" target="_blank">Devel@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman<wbr>/listinfo/devel</a><br>
</font></span></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
Devel mailing list<br>
<a href="mailto:Devel@ovirt.org" target="_blank">Devel@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman<wbr>/listinfo/devel</a><br></blockquote></div><br></div></div>
</blockquote></div></div></div><br></div></div>
</blockquote></div><br></div></div>