<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 27, 2017 at 7:07 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="">> Clients should be made aware their custom rules are going to be obsolete and<br>
> that they should reapply them once they reinstall.<br>
<br>
</span>Would you want to manually fix every reinstalled host? I would<br>
consider that very annoying. This has to be somewhat automatic if we<br>
want to support custom firewall rules. And although I agree the engine<br>
is not the right place for that, it is the only central place we have<br>
and from which we are starting the reinstall task.<br></blockquote><div><br></div><div>But we do not want to support custom firewall rules, we are not a firewall manager.<br>IMO, oVirt should support the hardening of its services and co-exist with other rules.<br>Custom firewall settings imply one of these:<br></div><div>- We need to extend current firewall options.<br></div><div>- It needs to be implemented outside oVirt.<br><br></div><div>But if the need to support back doors is proven to be a must, then implement them<br></div><div>outside the main core solution, these edge cases should not block the main business<br></div><div>logic.<br></div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Martin<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Mon, Mar 27, 2017 at 4:16 PM, Leon Goldberg <<a href="mailto:lgoldber@redhat.com">lgoldber@redhat.com</a>> wrote:<br>
> You're right, but I don't think it matters; hosts will remain unaffected<br>
> until they're reinstalled via an upgraded Engine.<br>
><br>
> Clients should be made aware their custom rules are going to be obsolete and<br>
> that they should reapply them once they reinstall.<br>
><br>
> On Mon, Mar 27, 2017 at 9:01 AM, Yedidyah Bar David <<a href="mailto:didi@redhat.com">didi@redhat.com</a>> 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 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">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 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<br>
>> >> > 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 for<br>
>> >> > ovirt-imageio to firewalld, for example) and I hope we'll be able to<br>
>> >> > 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 want<br>
>> >> > 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">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 (packaged<br>
>> >> >> 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<br>
>> >> >> 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.))? And<br>
>> >> >> 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>
><br>
><br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> ______________________________<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></div>